OpenCode : comment constituer une équipe d’agents IA avec n’importe quelle passerelle compatible OpenAI

Discuter avec un modèle atteint vite ses limites : il ne voit pas votre projet, ne lance pas les tests et ne conserve pas le contexte. D’où l’engouement pour les agents. Un agent, au fond, c’est un modèle associé à un harness, une couche logicielle qui lui apporte des compétences, du contexte, des intégrations et une logique multiagent. Claude Code et Codex ont fixé la barre, mais le premier est lié aux modèles Anthropic, tandis que le second reste un produit OpenAI. OpenCode propose une troisième voie : une licence MIT, 75+ fournisseurs, des modèles locaux via Ollama ou vLLM et le libre choix du modèle pour chaque rôle.

L’article a été publié sur Habr AI et rédigé par un salarié du service Bothub : la passerelle et le lien de parrainage qui y figurent ont donc une vocation publicitaire. La configuration elle-même reste toutefois universelle et convient à n’importe quel endpoint compatible OpenAI.

Connecter un fournisseur et éviter les pièges des proxys

La branche actuelle, v2, s’installe avec npm i -g @opencode/cli. L’ancien paquet opencode-ai appartient à la lignée 1.x, ce qui prête facilement à confusion. D’autres méthodes existent : brew, bun ou le script d’installation officiel.

Le fournisseur se configure dans opencode.json avec le paquet @ai-sdk/openai-compatible : il suffit de renseigner la baseURL de la passerelle et de lister les identifiants des modèles. Mieux vaut saisir la clé via opencode auth login plutôt que de la placer dans la configuration ou dans les variables d’environnement. Elle ne se retrouvera ainsi pas dans les fichiers du projet.

Le principal piège pratique concerne les proxys. OpenCode fonctionne avec Bun, dont le fetch natif gère HTTP_PROXY et HTTPS_PROXY de manière instable. Lors de l’installation de plugins, l’erreur fetch() proxy.url must be a non-empty string peut apparaître : l’agent renvoie un objet URL, alors que fetch attend une chaîne de caractères. Bun n’accepte pas le format socks5:// : il faut utiliser http://. Même avec une configuration correcte, NO_PROXY doit inclure localhost et 127.0.0.1, faute de quoi l’interface peut tourner en boucle sur ses propres requêtes. La solution la plus simple consiste à supprimer toutes les variables de proxy, puis à redémarrer le service. Ce n’est qu’après cette étape qu’il est pertinent de constituer l’équipe d’agents.

Une équipe d’agents aux permissions distinctes

OpenCode distingue deux types d’agents. Primary est celui avec lequel vous échangez directement. Subagent travaille dans une session enfant, avec son propre contexte, et ne renvoie que le résultat dans la conversation principale. Les agents intégrés build et plan sont de type primary ; general et explore sont des sous-agents. Vous pouvez les conserver tels quels et simplement ajouter les vôtres.

L’auteur a défini sept rôles :

• orchestrator (GPT-6.1 Sol) décompose la tâche et délègue, sans écrire lui-même de code ;
• architect (Gemini 4 Argon) conçoit les modules et les flux de données ;
• coder (Claude Sonnet 5.5) réalise l’implémentation en limitant les diffs au strict nécessaire ;
• reviewer (Claude Opus 5.5) se cantonne à la revue, sans produire de correctifs ;
• security (GLM-5.3) recherche les vulnérabilités ;
• docs (GPT-6 Luna) rédige la documentation ;
• tests (GLM-5.3 Flash) écrit les tests.

Les modèles sont répartis selon le principe suivant : « un modèle coûteux là où il faut de fortes capacités de raisonnement, un modèle moins cher là où il suffit ». L’auteur souligne le caractère en partie subjectif de ses choix : il s’est appuyé sur l’actualité et souhaitait essayer différents modèles, y compris des modèles ouverts.

La règle centrale de cette organisation : seul coder dispose de edit: allow. Si tous les agents modifient les fichiers, le diff grossit et il devient difficile de savoir qui a changé quoi. Le relecteur et security conservent néanmoins bash: allow, car ils doivent exécuter les linters, consulter git diff et vérifier les tests.

Des interdictions dans le harness plutôt que dans le prompt

Un modèle peut ignorer la consigne « ne fais pas de git push » inscrite dans un prompt, surtout lorsque la tâche est ambiguë. Une interdiction définie dans permission ne peut pas être contournée. Les règles sont granulaires : par défaut, bash demande une confirmation ; git status et git diff sont autorisés, tandis que git commit et git push sont interdits. La définition des agents peut également être déplacée du JSON vers des fichiers Markdown .opencode/agents/<name>.md : le nom du fichier devient celui de l’agent, le frontmatter contient sa configuration et le corps du fichier sert de prompt système. C’est pratique lorsque les prompts sont longs et doivent être versionnés.

Comment en tirer parti

Si vous utilisez déjà Claude Code ou Codex, OpenCode mérite un essai, ne serait-ce que pour comparer les modèles sur vos propres tâches en une journée. Retenez ce principe : un seul agent dispose du droit d’écriture, les autres conseillent et vérifient, et les interdictions critiques sont définies dans les permissions. Mieux vaut tester la sélection de modèles sur votre propre code, car les choix de l’auteur reposent davantage sur ses impressions que sur des benchmarks. L’article ne remplace pas la documentation, mais il permet d’économiser quelques heures face aux pièges les plus courants.