Commence avec ce que tu as
Pour prototyper autour de h0SINT, j’ai utilisé OpenCode, OpenRouter, Proxmox, Tailscale et Cloudflare. L’intérêt, c’est de garder une dépense supplémentaire faible pendant qu’on essaie des idées. Je parle ici de la façon de prototyper, pas d’une architecture où tous les déploiements h0SINT enverraient leurs données à ces services.
Chacun a son rôle. OpenCode pour travailler sur le code, OpenRouter pour accéder à des fournisseurs de modèles. Proxmox pour les VM et conteneurs sur ton matériel. Tailscale pour relier les machines autorisées en privé. Cloudflare pour les parties exposées sur internet. Un réseau privé ne rend pas un modèle distant local, au passage.
La petite facture, ça se construit
Une petite tâche n’a pas toujours besoin du plus gros modèle. Envoie les fichiers utiles, pas tout le dépôt à chaque échange. Limite les boucles de l’agent, regarde la consommation et configure les budgets ou alertes disponibles. Vérifie surtout si la limite coupe vraiment la dépense : un mail d’alerte, ce n’est pas un plafond.
Les offres gratuites aident tant qu’on reste dans leurs quotas et leurs conditions d’usage. Ça ne veut pas dire usage commercial gratuit partout, ni capacité illimitée. Le serveur déjà acheté consomme encore du courant, du temps et de la maintenance. Les sauvegardes aussi ont besoin d’une place. « Ça me coûte peu en plus pour ce prototype », oui. « Tout est gratuit », faut pas pousser.
Il peut y avoir un autre prix
Certaines offres gratuites collectent des données pour améliorer le service. D’autres ont des conditions différentes. Et payer ne garantit pas la confidentialité non plus. OpenRouter distingue les politiques des fournisseurs sur l’entraînement et la conservation ; OpenCode Zen détaille la confidentialité selon le modèle. Regarde le trajet réel, y compris les fournisseurs de secours.
Logs, entraînement, éventuelle relecture humaine : ce sont trois questions différentes. Qu’est-ce qui est gardé, combien de temps, qui peut le voir ? L’agent peut envoyer des fichiers et des sorties de commandes, pas seulement ton petit prompt innocent. Des données bidon pour un prototype, très bien. Un dossier client, des identifiants ou un inventaire sensible chez un fournisseur non approuvé… on va éviter, hahaha.
Et en local, alors ?
Les modèles locaux valent le coup d’être essayés sur un travail bien cadré : un brouillon, un résumé de notes nettoyées, par exemple. Teste sur ton vrai besoin et ton matériel. Le petit modèle hors ligne ne remplace pas automatiquement le meilleur modèle distant pour tout.
Si les données doivent rester hors ligne, vérifie toute la chaîne : modèle, agent, outils, plugins et connexions réseau. Coupe les bascules vers le cloud et les appels distants inutiles. Avoir la fenêtre de chat sur ton ordinateur ne suffit pas. Un bac à sable peu cher pour expérimenter, puis un environnement choisi et approuvé pour le sensible : ça me paraît déjà une base beaucoup plus saine.