Le moment des agents de code open source n’arrive pas parce que les développeurs auraient soudain redécouvert le charme du terminal. Il arrive parce que les outils fermés ont changé la facture.

L’annonce d’avril de GitHub a posé le changement clairement : à partir du 1er juin 2026, l’usage de Copilot consomme des GitHub AI Credits, calculés à partir des tokens d’entrée, de sortie et de cache. Les prix de base restent familiers, mais les longues sessions agentiques n’ont plus la même économie. La discussion officielle sur GitHub Community compte des centaines de commentaires et de réponses. Ce n’est pas une querelle sur un détail tarifaire. Les développeurs se demandent si la prochaine couche d’outils de programmation doit être une fonction d’IDE, une charge cloud mesurée à l’usage, ou une infrastructure qu’une équipe peut exécuter et budgéter elle-même.

C’est ce qui explique l’attention autour d’OpenCode. Le projet se présente comme un AI coding agent open source pour terminal, IDE et desktop. Son site met en avant LSP, les sessions multiples, les liens de partage, plus de 75 fournisseurs de modèles, les modèles locaux, ainsi que les connexions GitHub Copilot et ChatGPT Plus/Pro. L’API GitHub redirige l’ancien chemin sst/opencode vers anomalyco/opencode; le dépôt affichait environ 186 000 étoiles, 23 000 forks, une licence MIT, des milliers d’issues et une version v1.18.1 publiée le 14 juillet 2026. Hacker News l’a déjà passé au banc d’essai habituel : un grand fil avec plus de mille points et des centaines de commentaires, entre comparaisons avec Claude Code, Aider, Cline et workflows réels.

Agent de code open source dans un sandbox avec modèle local et contrôle de budget

Le titre facile serait : “OpenCode, l’alternative à Copilot”. C’est trop court. La meilleure lecture est que les agents open source deviennent une nouvelle catégorie d’infrastructure développeur. Ils réduisent le lock-in, permettent d’apporter ses propres clés ou modèles locaux, et rendent le harness de l’agent inspectable. Mais ils déplacent aussi la responsabilité : coûts, sécurité, permissions, cadence de versions et rayon de dégâts.

Pourquoi la facturation de Copilot pousse à regarder ailleurs

L’explication de GitHub est compréhensible. Copilot n’est plus seulement un autocompléteur. GitHub parle d’une plateforme agentique capable de longues sessions, de travail entre dépôts et d’une consommation de calcul bien supérieure aux anciennes suggestions inline. Quand un outil se comporte davantage comme un worker cloud que comme une fonction d’éditeur, le forfait devient plus difficile à défendre côté fournisseur.

Pour les développeurs et managers, la facturation aux tokens change le quotidien. Une souscription prévisible devient un problème de budget. Les tokens d’entrée comptent. Les tokens de sortie comptent. Les tokens en cache peuvent compter. Le choix du modèle compte. Une demande comme “refactorise ce service” peut devenir une chaîne de lectures du dépôt, appels d’outils, réécritures et tests. C’est ce qui rend les agents utiles, et ce qui rend la facture moins lisible.

Copilot n’est pas devenu mauvais en une nuit. Il garde le polish, l’intégration Microsoft/GitHub, les contrôles admin et un achat simple pour l’entreprise. Beaucoup d’équipes paieront encore pour cela. Mais le changement donne une raison pratique de poser la question : et si le runner de l’agent n’était pas le produit loué, mais une couche que l’on contrôle ?

Ce qu’OpenCode propose vraiment

OpenCode attire parce qu’il combine une interface d’agent reconnaissable avec une histoire de modèles moins verrouillée. Le site officiel décrit un outil pour terminal, IDE et desktop, avec LSP, sessions multiples, partage de sessions et plus de 75 fournisseurs LLM. Le support des modèles locaux compte aussi pour les équipes qui testent Ollama, vLLM, llama.cpp ou des endpoints privés.

La formule “privacy first” affirme que le service ne stocke pas le code ni les données de contexte. Il faut la traiter comme une déclaration du projet, pas comme un audit. Mais elle indique le terrain sur lequel OpenCode veut être jugé : contrôle, transparence et portabilité.

Les métriques GitHub montrent que ce n’est pas un jouet de week-end. Le chemin canonique pointe vers anomalyco/opencode; l’API montrait MIT, de très gros chiffres d’étoiles et de forks, des mises à jour récentes et v1.18.1. Cette version était un petit correctif desktop. C’est presque plus parlant qu’une grosse annonce : les outils matures vivent aussi de corrections de panneaux fournisseurs, de bugs de plateforme, de dépendances et d’authentification.

Ce que l’open source corrige, et ce qu’il ne corrige pas

L’open source corrige l’inspectabilité. On peut lire le code, figer une version, ouvrir une issue, patcher un comportement, forker le projet ou l’exécuter avec son propre fournisseur. Si un agent envoie du contexte à un endroit inattendu, change son modèle par défaut ou élargit ses permissions, il existe au moins un chemin pour le voir.

Mais l’open source ne rend pas l’outil sûr par magie. La plupart des développeurs n’auditent pas chaque dépendance installée. La plupart des équipes ne liront pas chaque ligne d’un agent qui peut lire le dépôt, lancer un shell et modifier des fichiers. Le code ouvert donne le droit d’auditer. Il ne fait pas l’audit.

Le débat Hacker News autour d’OpenCode reflète cette tension. Certains le voient comme un remplaçant pratique de Claude Code ou Aider. D’autres parlent de télémétrie, comportement cloud par défaut, permissions, bugs Windows et Wayland, usage des ressources et cadence de release. Ce sont les bonnes questions pour un outil de développement privilégié.

La séparation utile n’est pas open contre fermé. Elle est audité contre non audité, isolé contre trop trusted, budgété contre surprise de facture.

La nouvelle pile : modèle, harness, permissions et budget

Un outil AI de code était simple à décrire : installer une extension, accepter ou refuser des suggestions. Les agents cassent cette simplicité.

Première couche : le modèle. API fournisseur, login Copilot, plan ChatGPT, modèle local ou endpoint privé. Chaque choix change la latence, le coût, l’exposition du code et la qualité.

Deuxième couche : le harness. OpenCode, Aider, Continue, Cline, Roo Code et Tabby décident comment choisir le contexte, éditer les fichiers, exécuter les outils, montrer les diffs, stocker les sessions et donner de l’autonomie au modèle.

Troisième couche : les permissions. L’agent peut-il lancer des commandes shell ? Écrire hors du worktree ? Accéder au réseau ? Lire .env ou SSH config ? Ouvrir un navigateur ou appeler des outils MCP ? Plus il est puissant, plus cette frontière compte.

Quatrième couche : le budget. Il faut des plafonds de dépense, des clés par projet, du routage de modèles, des logs et une réponse à “combien cette tâche a coûté ?”.

Où essayer OpenCode d’abord

OpenCode vaut un test si vous vivez déjà dans le terminal et voulez choisir vos modèles. Pour un développeur solo, les premières tâches doivent être bornées : ajouter des tests, refactoriser un petit module, expliquer un fichier legacy, câbler une option CLI, nettoyer de la documentation.

Pour une petite équipe, il faut un pilote, pas une installation libre. Commencez par des dépôts non sensibles, des clés séparées, pas de secrets de production, un worktree propre et une revue normale de chaque diff. Si l’outil tient ses promesses, écrivez la politique avant d’élargir : modèles autorisés, commandes autorisées, dépôts autorisés, plafonds de dépenses et versions pinées.

Pour les équipes sensibles à la sécurité, la question n’est pas “OpenCode est-il open source ?” mais “que peut-il lire, exécuter et exfiltrer ?”. Si la réponse ressemble aux droits du laptop d’un senior engineer, il faut des contrôles équivalents : conteneurs ou VM, no-egress si possible, scan de secrets, audit logs, tokens restreints et actions reproductibles.

Où se placent Aider, Continue, Cline, Roo Code et Tabby

OpenCode n’est pas seul. Aider reste fort comme pair programmer en terminal proche de Git et du shell. Continue convient mieux à ceux qui veulent une intégration IDE et un projet Apache-2.0 inspectable. Cline et Roo Code amènent les workflows agentiques dans des environnements type VS Code, avec des approbations visibles, mais exigent une vraie politique de permissions. Tabby vise l’assistance self-hosted ; pour les organisations qui ne peuvent pas envoyer leur code à des fournisseurs externes, c’est parfois le premier pas acceptable.

Le bon test n’est pas le nombre d’étoiles. Faites un bake-off : tests, refactor, enquête sur un bug. Passez les mêmes tâches dans OpenCode, Aider et un agent d’IDE. Comparez qualité du diff, tests, configuration, tokens dépensés, erreurs de contexte et interventions humaines.

Checklist sécurité

N’installez pas un coding agent dans votre environnement principal avec tous les accès le premier jour. Utilisez un worktree neuf ou un clone jetable. S’il y a secrets, scripts de déploiement ou accès production, commencez dans un conteneur ou une VM. Retirez .env et credentials. Utilisez une clé API séparée avec un plafond strict.

Vérifiez le réseau. Même si le projet dit ne pas stocker code ou contexte, le fournisseur du modèle reçoit les prompts sauf modèle local ou endpoint privé. Si la politique interdit la sortie du code source, une API publique n’est pas une exception.

Inspectez commandes et écritures avant exécution. Bloquez les commandes destructrices sauf demande explicite. Ne laissez pas l’agent lancer des scripts de package manager depuis un dépôt non fiable sans isolation. Relisez le diff comme le premier PR d’un junior dans une base risquée : permissions élargies, dépendances modifiées, config générée, appels réseau cachés et changements hors scope.

Checklist coûts

Les agents open source ne rendent pas l’AI coding automatiquement bon marché. Ils rendent les coûts visibles et configurables. L’API directe peut coûter cher si l’agent envoie beaucoup de contexte, demande du raisonnement long, répète les essais ou utilise des modèles coûteux pour des tâches routinières. Les modèles locaux réduisent la facture fournisseur, mais ajoutent hardware, maintenance et compromis qualité.

Suivez tokens d’entrée, de sortie et de cache. Utilisez de plus petits modèles pour documentation, petits edits, tests simples ou recherche. Gardez les modèles forts pour debug difficile et design entre modules. La bonne métrique est le coût par changement accepté, relu et fonctionnel.

À surveiller

Regardez les parties ennuyeuses. La télémétrie est-elle documentée ? Les destinations réseau sont-elles visibles ? Le sandboxing est-il supporté ou recommandé honnêtement ? Peut-on pinner modèles et fournisseurs ? Y a-t-il des logs de coûts ? Windows, Linux desktop et remote development fonctionnent-ils sans hacks fragiles ? Les permissions risquées sont-elles expliquées simplement ?

La gouvernance compte aussi. OpenCode est MIT. Aider, Continue, Cline et Roo Code affichaient Apache-2.0 dans les snapshots API. Tabby montrait un champ de licence non standard, donc il faut lire la licence dans le dépôt avant de bâtir une politique. Si l’outil devient critique, licence, bus factor, process de release et écosystème de plugins comptent autant que la démo.

Juggler et les nouveaux GUI agents montrent la prochaine compétition : pas “agent ou pas agent”, mais quelle interface rend l’agence compréhensible. Les bons outils montreront ce qu’ils ont lu, ce qu’ils vont changer, ce qu’ils ont exécuté, combien ils ont dépensé et ce que l’humain doit encore vérifier.

Verdict : essayez-les, mais pas comme de simples extensions

Les open-source coding agents valent déjà un essai. OpenCode est particulièrement intéressant parce qu’il combine choix de modèles, modèles locaux, terminal/IDE workflows, grosse communauté et réponse directe au lock-in.

Mais la liberté n’est pas gratuite. Passer de Copilot ou Claude Code à OpenCode, Aider, Continue, Cline ou Roo Code ne supprime pas la gouvernance. Cela la rapproche de votre équipe. C’est une bonne chose si vous avez sandboxing, limites de budget, revue de télémétrie et rollback.

Pour un développeur curieux, testez OpenCode sur un dépôt non critique. Pour une équipe, lancez un pilote contrôlé : trois outils, trois vraies tâches, clés séparées, plafonds de dépenses, sandboxing, versions pinées et code review normal. La vague open source n’est pas qu’une réaction au billing Copilot. Elle montre que l’AI coding devient une infrastructure. Et une infrastructure doit être inspectable, remplaçable, budgétée et verrouillée avant de modifier du code de production.