OpenCode CLI en pratique : flux de travail, automatisation et écueils

L’interface en ligne de commande d’OpenCode est conçue pour l’écriture de scripts, les pipelines CI et les exécutions d’agents en autonome. Cet article est un guide pratique pour l’utiliser au quotidien.

Derrière la CLI se cache un système de modèles, d’outils, de permissions, d’agents, de compétences, de commandes, de sessions, de serveurs MCP et d’une architecture client/serveur. L’agent peut lire et modifier les fichiers du projet, rechercher dans les dépôts, exécuter des commandes shell, appeler des outils externes et déléguer du travail à des sous-agents. Le même environnement fonctionne de manière interactive dans l’interface TUI ou non interactive depuis des scripts.

Pour les petites tâches, vous pouvez l’installer, connecter un modèle et commencer à poser des questions en quelques minutes. Pour un travail sérieux, la qualité de l’expérience dépend fortement de la sélection du modèle, des instructions du dépôt, des limites de permissions, de la gestion du contexte et de la mesure dans laquelle vous autorisez l’agent à opérer. Cet article se concentre sur cette deuxième étape, depuis la ligne de commande : quels cas d’usage sont rentables, quels flux de travail d’automatisation tiennent la distance en utilisation quotidienne et quels problèmes apparaissent une fois que la nouveauté d’un terminal alimenté par l’IA s’est dissipée. Il fait partie de la section Outils de développement IA de ce site.

Les observations présentées ici ont été vérifiées par rapport à OpenCode 1.18.9 et à la documentation en vigueur en août 2026. OpenCode évolue rapidement, il est donc conseillé de vérifier rapidement la documentation avant de copier des exemples de configuration dans une configuration d’équipe de longue durée. Si vous n’avez pas encore installé OpenCode, le démarrage rapide d’OpenCode couvre l’installation, la vérification et la connexion aux fournisseurs.

Ce qu’OpenCode est réellement : un environnement agentique, pas une boîte de dialogue

OpenCode est un agent de code open source conçu autour du terminal. Une vue simplifiée de ce qu’il assemble est la suivante :

La partie importante est la couche de permissions située entre l’intention d’un modèle et les actions qu’OpenCode peut effectuer. Un excellent modèle avec de mauvaises permissions peut être dangereux. Un modèle faible avec des permissions parfaites est simplement lent et agaçant. Une utilisation productive d’OpenCode nécessite de régler correctement les deux côtés.

Le même environnement sert les deux interfaces : le TUI interactif et la ligne de commande non interactive. C’est ce qui permet à OpenCode d’être scriptable d’une manière qu’une interface de chat pure ne peut pas l’être. Si vous souhaitez une approche volontairement minimale de la même idée d’agent terminal — quatre outils par défaut, aucune sandbox intégrée, tout le reste via des extensions — la critique de Pi Coding Agent est un contraste utile.

Configuration : installer, connecter et pourquoi l’indépendance du fournisseur compte

OpenCode s’installe en une ligne — script d’installation officiel, npm ou Homebrew — et démarre avec opencode depuis un répertoire de dépôt. Le démarrage rapide d’OpenCode couvre la matrice d’installation complète (Arch, Windows, Docker), la vérification et la connexion aux fournisseurs (/connect et /models), cet article ne la répète donc pas.

Vous pouvez utiliser les services de modèles d’OpenCode lui-même ou connecter des fournisseurs externes pris en charge. OpenCode construit actuellement une grande partie de son catalogue de fournisseurs en utilisant Models.dev et prend en charge une large gamme de configurations de modèles commerciaux et locaux.

L’indépendance du fournisseur est l’une des décisions architecturales les plus utiles d’OpenCode. Votre flux de travail de codage n’a pas besoin d’être couplé de manière permanente à un seul fournisseur de modèles : vous pouvez utiliser un modèle pour les travaux d’architecture complexes, un autre pour des tâches d’implémentation peu coûteuses et un modèle local pour le code qui ne devrait pas quitter votre environnement.

Cette flexibilité est réelle, mais elle crée une autre variable à gérer. Quand OpenCode se comporte mal, le problème peut être le harnais, le prompt, le contexte disponible, le modèle sélectionné ou l’interaction entre ces quatre éléments.

Initialiser le dépôt avec AGENTS.md avant de demander du code

L’une des premières commandes à exécuter dans un nouveau dépôt est :

/init

OpenCode analyse le projet et crée un fichier AGENTS.md. Commitez ce fichier.

AGENTS.md est l’endroit où les contraintes spécifiques au dépôt peuvent devenir un contexte durable pour chaque conversation — interactive ou scriptée — au lieu d’être répétées manuellement. Un fichier utile est assez court pour rester pertinent mais assez concret pour empêcher les erreurs prévisibles. Par exemple :

# Instructions du dépôt

## Architecture

- Les gestionnaires d'API sont situés sous src/api.
- La logique métier appartient sous src/services.
- L'accès à la base de données appartient sous src/repositories.
- N'appelerez pas directement les clients de base de données depuis les gestionnaires HTTP.

## Validation

Après les modifications TypeScript, exécuter :

```bash
npm run typecheck
npm test
```

Après les modifications du frontend, exécuter également :

```bash
npm run lint
```

## Contraintes

- Ne modifiez pas les fichiers générés.
- Ne changez pas les contrats d'API publics sans demander d'abord.
- Ne créez pas de migrations de base de données sauf demande explicite.
- N'exécutez jamais les commandes de déploiement.

C’est moins excitant que d’installer un autre serveur MCP, mais cela fournit généralement plus de valeur. Les agents de codage échouent de manière surprenante fréquente parce qu’ils ne savent pas quelles contraintes sont importantes. Un court contrat de dépôt élimine une partie de cette ambiguïté avant le premier appel d’outil.

Travailler depuis la ligne de commande avec opencode run

L’interface interactive reçoit la plus grande partie de l’attention, mais le mode non interactif d’OpenCode modifie considérablement la portée des flux de travail utiles :

opencode run "Expliquez la stratégie de gestion des erreurs dans ce paquet"

Vous pouvez utiliser OpenCode depuis des scripts shell, des tâches CI, des Makefiles, des gestionnaires de tâches ou des automatisations locales sans avoir à saisir manuellement le TUI chaque fois. Par exemple, une revue de diff en tant que commande ponctuelle :

opencode run \
  "Reveuillez le diff git actuel pour la justesse et les tests manquants. Ne modifiez pas les fichiers."

Ou acheminer le contexte directement dans une exécution :

git diff --name-only HEAD~1 |
  opencode run "Inspectez les fichiers modifiés et identifiez les changements de comportement risqués."

Dans un Makefile, le même appel devient une cible :

.PHONY: review
review:
	opencode run "Revueillez le diff git actuel pour la justesse et les tests manquants. Ne modifiez pas les fichiers."

Comme une exécution scriptée n’a pas d’humain au prompt, la politique de permissions que vous configurez est la seule garde-fou entre le modèle et votre environnement. C’est pourquoi la section sur les permissions ci-dessous est plus importante pour l’automatisation que pour l’utilisation interactive.

La direction intéressante ici n’est pas de remplacer les scripts déterministes par un LLM. Il s’agit d’insérer le raisonnement du modèle dans les endroits où la logique shell traditionnelle devient contraignante, tout en gardant une validation déterministe autour de lui.

Les meilleurs cas d’usage de la CLI OpenCode

OpenCode peut tenter presque toute tâche de programmation, mais cela ne signifie pas que toute tâche devrait être déléguée de la même manière. Les flux de travail à la plus haute valeur ont tendance à avoir trois propriétés : le résultat souhaité est testable, le contexte du dépôt pertinent peut être découvert, et les changements incorrects sont peu coûteux à inspecter ou à révoquer. Chaque prompt ci-dessous fonctionne dans le TUI ou en tant qu’argument pour opencode run.

1. Exploration du dépôt

OpenCode est excellent pour répondre à des questions qui exigeraient autrement une séquence de commandes grep, de recherches dans l’éditeur, de sauts de fichiers et git log. Par exemple :

Expliquez comment l'authentification fonctionne dans ce dépôt.

Tracez une requête depuis le middleware HTTP à travers la validation du jeton,
le chargement de l'utilisateur, l'autorisation et le gestionnaire final.

Ne modifiez rien.

Un bon agent recherchera les points d’entrée, suivra les références, inspectera les tests et retournera quelque chose de plus proche d’un tour d’horizon architectural que d’une simple recherche textuelle. C’est l’une des façons les plus sûres d’introduire OpenCode dans une base de code existante car l’agent peut fournir de la valeur sans écrire de code.

2. Petites corrections bien délimitées

Un bug à portée étroite est proche de la tâche idéale pour un agent de codage. Par exemple :

La CLI quitte avec le statut 0 lorsque la validation de la configuration échoue.

Retrouvez le chemin de code responsable, ajoutez un test de régression, implémentez
le correctif minimal et exécutez les tests pertinents.

Ne refactorisez pas le code non lié.

L’expression clé n’est pas « corriger le bug ». Ce sont les contraintes entourant la tâche. OpenCode fonctionne mieux quand le succès peut être démontré avec un test, un compilateur ou une commande observable. Des exigences vagues donnent au modèle de la place pour créer du code plausible plutôt que du code correctement démontrable.

3. Génération de tests après implémentation

Les tests sont un travail utile pour les agents parce que l’implémentation existante donne à OpenCode quelque chose de concret à raisonner. Un prompt productif pourrait être :

Reveuillez src/parser.ts et ses tests existants.

Identifiez les cas limites importants qui sont actuellement non couverts.
Ajoutez uniquement des tests. Ne modifiez pas l'implémentation.

Exécutez la suite de tests du parseur une fois terminé.

Séparer la génération de tests de l’implémentation est important. Si le même agent écrit à la fois la fonctionnalité et les tests dans une passe non contrainte, il peut accidentellement créer des tests qui valident sa propre interprétation plutôt que le comportement prévu.

4. Refactorisation mécanique

OpenCode est très bon pour les transformations répétitives où l’état final souhaité est clair. Les exemples incluent :

• le remplacement d’une API obsolète dans tout un dépôt ;
• la conversion de code répété en un auxiliaire partagé ;
• le renommage d’un champ de configuration ;
• la migration des tests d’un motif d’assertion à un autre ;
• la mise à jour des imports après le déplacement d’un paquet ;
• le remplacement d’une abstraction de journalisation obsolète.

Le compilateur et les tests du dépôt deviennent la boucle de rétroaction de l’agent. Un motif utile est :

Remplacez les utilisations de LegacyResult<T> par Result<T, AppError> dans
packages/api uniquement.

Préservez le comportement d'exécution.

Travaillez par petits lots. Après chaque lot, exécutez le typecheck du paquet.
À la fin, exécutez la suite de tests du paquet et affichez-moi le résumé
du diff git final.

C’est souvent plus fiable que de demander toute la migration dans une étape énorme unique.

5. Revue de code

OpenCode devient beaucoup plus utile lorsque la revue est traitée comme un rôle d’agent distinct plutôt qu’un autre prompt envoyé au même contexte d’édition. Vous pouvez créer un agent orienté vers la revue qui ne peut pas modifier de fichiers. Donnez-lui ensuite des instructions telles que :

Reveuillez le diff git actuel.

Concentrez-vous sur :
- la justesse ;
- la sécurité ;
- la concurrence ;
- les tests manquants ;
- la gestion des erreurs ;
- les changements d'API accidentels.

Ne résumez pas les fichiers qui ne sont pas modifiés.
Classez les constats par gravité.

Un réviseur en lecture seule est utile même si un autre agent de codage a produit les changements. La séparation est précieuse car l’implémentation et la critique sont des tâches différentes : un agent qui vient de passer plusieurs milliers de jetons à défendre une approche est souvent moins sceptique quant à cette approche qu’un réviseur neuf.

Utiliser les modes Plan et Build comme modes mentaux distincts

OpenCode fournit des agents principaux et des sous-agents, avec des flux de travail intégrés incluant un comportement orienté vers la planification et l’implémentation. Même lorsque la configuration exacte des agents change au fil du temps, la séparation conceptuelle reste utile.

La planification devrait répondre à des questions telles que :

• Quels fichiers sont importants ?
• Quels motifs existants doivent être suivis ?
• Que pourrait casser ?
• Comment vérifierons-nous le changement ?
• Le changement demandé est-il réellement local ?

L’implémentation ne devrait se produire qu’après que ces questions aient des réponses raisonnables. Pour les tâches substantielles, je préfère une séquence de prompts comme celle-ci :

D'abord, enquêtez sur la demande.

Ne modifiez pas encore de fichiers.

Retournez :
1. les fichiers pertinents ;
2. le comportement actuel ;
3. le changement proposé ;
4. les risques ;
5. les commandes de vérification exactes.

La même séquence fonctionne comme une commande ponctuelle :

opencode run "D'abord, enquêtez sur la demande. Ne modifiez pas encore de fichiers. Retournez : les fichiers pertinents ; le comportement actuel ; le changement proposé ; les risques ; les commandes de vérification exactes."

Ensuite, inspectez le plan avant d’autoriser les modifications. Cela semble plus lent que de dire immédiatement à un agent de « l’implémenter », mais les échecs coûteux dans le codage agentique proviennent généralement de prémisses incorrectes faites avant la première modification.

C’est une version légère, par tâche, du même instinct derrière le développement piloté par spécification) : convenir du plan avant que l’agent commence à éditer. Pour un travail qui s’étend sur plusieurs fichiers, sessions ou contributeurs, une spécification écrite justifie son surcoût d’une manière qu’un simple prompt d’enquête préalable ne peut pas ; la comparaison de GitHub Spec Kit contre Kiro contre Claude Code couvre les flux de travail SDD structurés qui vont plus loin qu’un prompt unique.

Les sous-agents sont utiles, mais la délégation n’est pas gratuite

OpenCode peut invoquer des sous-agents spécialisés automatiquement ou par des mentions explicites. Par exemple :

@general trouve où le comportement de nouvelle tentative est implémenté

Vous pouvez également définir des sous-agents dédiés pour des tâches telles que la revue de sécurité, l’analyse des dépendances, les tests de frontend ou la documentation. Le même motif fonctionne dans d’autres harnais ; le guide des sous-agents de Claude Code couvre le design analogue du côté d’Anthropic.

C’est puissant parce que le travail des sous-agents peut rester en dehors du chemin de raisonnement immédiat de la conversation principale. Un agent principal peut déléguer l’exploration du dépôt et consommer le résultat au lieu de remplir son propre contexte avec chaque recherche intermédiaire. Mais les sous-agents créent trois coûts moins évidents :

1. Ils consomment des jetons. Un arbre d’agents qui re-lisent tous le dépôt peut devenir surprenamment coûteux — mon rapport d’expérience Oh My Opencode) documente ce qui se passe lorsque cette surcharge est poussée à l’extrême.
2. Ils créent une complexité politique. Les permissions doivent être considérées pour l’agent délégué, pas seulement pour le parent.
3. La délégation peut cacher le raisonnement. Quand l’agent principal dit « le sous-agent a trouvé X », vous pourriez avoir besoin d’inspecter la session enfant pour comprendre à quel point cette conclusion est fiable.

Pour la plupart des tâches de codage, deux ou trois agents délibérés sont plus utiles qu’une société logicielle fictive élaborée vivant dans votre terminal.

Si la tâche a vraiment besoin d’un orchestrateur complet déléguant à un effectif fixe de spécialistes — exécution en arrière-plan parallèle, phases de planification et de recherche, routage de modèles par rôle — c’est un produit différent construit sur le dessus de ces primitives, pas un prompt plus grand. Le démarrage rapide de Oh My Opencode) couvre ce harnais.

Utiliser des agents personnalisés comme limites de permissions

Les agents d’OpenCode peuvent avoir des prompts, des modèles et des permissions séparés. Cela rend les agents utiles comme frontières de sécurité et de flux de travail, et pas seulement comme des personnalités différentes. Par exemple, un agent de revue local au projet peut être défini comme un fichier Markdown :

---
description: Revoit le code sans modifier le dépôt
mode: subagent
permission:
  edit: deny
  bash:
    "*": ask
    "git diff *": allow
    "git status *": allow
    "git log *": allow
  webfetch: deny
---

Revuez le code pour la justesse, la sécurité, la maintenabilité,
les changements de comportement inattendus et les tests manquants.

Ne modifiez pas les fichiers.

C’est beaucoup mieux que d’écrire « s’il vous plaît, ne modifiez rien » en prose. Les instructions influencent le modèle. Les permissions contraignent l’outil. Ce ne sont pas des contrôles équivalents.

Configurer les permissions d’OpenCode dès le premier jour

L’une des caractéristiques pratiques les plus importantes d’OpenCode est que ses valeurs par défaut normales sont permissives. C’est pratique pendant une démonstration et ce n’est pas nécessairement ce que je veux sur une station de travail contenant des clés SSH, des identifiants de production, des jetons de publication de paquets, des contextes Kubernetes et un accès à plusieurs comptes cloud. Pour les tâches non supervisées opencode run, l’enjeu est encore plus élevé : rien n’arrête une exécution sauf la politique que vous configurez.

Le modèle de permissions actuel d’OpenCode prend en charge :

allow
ask
deny

Les règles peuvent être appliquées à l’accès aux fichiers, aux éditions, aux commandes shell, aux opérations Web, aux sous-agents, aux compétences, aux répertoires externes et à d’autres catégories d’outils. Un point de départ prudent pourrait ressembler à ceci :

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "*": "ask",
    "read": "allow",
    "grep": "allow",
    "glob": "allow",
    "edit": "ask",
    "bash": {
      "*": "ask",
      "git status *": "allow",
      "git diff *": "allow",
      "git log *": "allow",
      "git push *": "deny",
      "rm *": "deny"
    }
  }
}

Les règles exactes devraient correspondre à votre environnement. Ce qui compte, c’est de rendre la politique intentionnelle plutôt que de découvrir la valeur par défaut après que l’agent a déjà exécuté quelque chose de surprenant.

Ne confondez pas les prompts d’approbation avec le sandboxing

Les règles de permissions sont utiles, mais elles ne sont pas les mêmes que l’isolation du système d’exploitation. Si OpenCode a la permission d’exécuter une commande shell autorisée, ce processus s’exécute avec l’accès disponible pour votre environnement. Un agent de codage peut potentiellement interagir avec des fichiers, des services réseau, des variables d’environnement, des identifiants, des sockets, des gestionnaires de paquets et d’autres outils de développement. Le [démarrage rapide de la CLI OpenHands](https://www.glukhov.org/fr/ai-devtools/openhands/ “Installez la CLI OpenHands 1.16.0, pointez-la vers un modèle local ou hébergé, et exécutez des tâches headless ou ACP. Les nouvelles installations sont dirigées vers Agent Canvas.)) est l’équivalent sandboxé : un espace de travail Docker, un mode headless qui approuve toujours et la passation Agent Canvas que le projet OpenHands documente maintenant.

Pour les dépôts sensibles ou les exécutions non supervisées, une isolation plus forte mérite d’être considérée :

Git est le retour arrière. Les permissions sont la politique. Un conteneur ou une VM est l’isolation. Ce sont trois couches différentes.

Transformer les prompts répétitifs en commandes personnalisées

Si vous saisissez répétitivement les mêmes instructions, elles devraient probablement cesser d’être de l’historique de chat et devenir de la configuration. OpenCode prend en charge les commandes slash personnalisées pour le projet et globales pour l’interface interactive. Par exemple, créez :

.opencode/commands/review.md

avec :

---
description: Revue des changements actuels
agent: plan
---

Revuez le diff git actuel.

Recherchez :
- des bogues ;
- des problèmes de sécurité ;
- une gestion d'erreurs incomplète ;
- des tests manquants ;
- des changements d'API accidentels.

Ne modifiez pas les fichiers.

Ensuite, utilisez :

/review

C’est une petite fonctionnalité avec une valeur disproportionnée. Les flux de travail fiables d’agents de codage émergent quand les bons prompts deviennent une infrastructure de projet partagée plutôt que des fragments d’presse-papiers personnels. D’autres commandes de projet utiles pourraient inclure :

/test-changes
/review
/prepare-pr
/check-migration
/update-docs
/release-check

Utiliser les compétences pour des flux de travail réutilisables

OpenCode prend également en charge les fichiers SKILL.md. Les compétences sont utiles lorsqu’un flux de travail a besoin de plus qu’un simple prompt. Une compétence peut contenir des conseils opérationnels détaillés et des fichiers d’accompagnement tout en restant non chargée jusqu’à ce que l’agent en ait réellement besoin. Les candidats utiles incluent :

• les procédures de migration de base de données ;
• les flux de travail de publication ;
• l’investigation d’incidents ;
• les revues de compatibilité API ;
• la publication de paquets ;
• la validation de l’infrastructure ;
• les conventions d’architecture internes.

Par exemple :

.opencode/skills/database-migration/SKILL.md

La description d’une compétence pourrait indiquer à OpenCode quand la procédure s’applique, tandis que le corps explique comment inspecter les schémas, créer des migrations, valider le comportement de retour arrière et exécuter les tests d’intégration. Si vous utilisez déjà le concept équivalent dans un autre harnais, le [guide des compétences Claude pour les développeurs](https://www.glukhov.org/fr/ai-devtools/claude-code/claude-skills-for-developers/ “Les compétences Claude expliquées : structure SKILL.md, agencement des dossiers, bonnes pratiques, tests et dépannage.)) cartographie les mêmes décisions de design.

L’avantage est la discipline du contexte. Déverser toutes les règles organisationnelles dans AGENTS.md finit par créer un système prompt géant qui est coûteux et de plus en plus facile pour le modèle à ignorer. Les compétences permettent aux instructions spécialisées d’entrer dans le contexte uniquement quand elles sont nécessaires.

MCP : utile jusqu’à ce que le catalogue d’outils devienne le problème

OpenCode prend en charge les serveurs MCP locaux et distants. Cela peut exposer des traceurs de problèmes, des systèmes de documentation, des navigateurs, des plateformes d’observabilité, des bases de données, des API et d’autres outils à l’agent de codage. Une configuration typique pourrait fournir un serveur de documentation :

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "context7": {
      "type": "remote",
      "url": "https://mcp.context7.com/mcp"
    }
  }
}

MCP est l’une de ces fonctionnalités qui est facile à surutiliser. Chaque outil que l’agent doit comprendre consomme de l’attention et fréquemment des jetons de contexte. Une configuration avec quinze serveurs MCP peut paraître puissante sur une capture d’écran de configuration tout en rendant le comportement réel du modèle plus lent, plus coûteux et moins prévisible.

Ma règle est simple : si un outil n’est pas utile dans une semaine de travail normale, il ne devrait probablement pas être activé globalement. Chargez les outils parce qu’un flux de travail les exige, et non parce que l’intégration existe.

Les modèles locaux dans OpenCode : une option réelle, pas un correctif magique

L’un des cas d’usage les plus forts d’OpenCode est sa capacité à fonctionner avec des points de fin de modèles compatibles OpenAI locaux ou auto-hébergés. C’est attractif lorsque :

• le code source doit rester local ;
• les coûts d’API sont significatifs ;
• vous opérez déjà une infrastructure GPU ;
• vous souhaitez expérimenter avec des modèles ouverts ;
• la connectivité Internet est peu fiable ;
• le routage de modèles fait partie de votre plateforme.

Un fournisseur personnalisé peut pointer OpenCode vers un point de fin local tel que LM Studio, llama.cpp) via llama-server, vLLM, une infrastructure compatible Ollama, ou un autre serveur compatible OpenAI.

C’est là que les attentes comptent. Un bon harnais de codage ne peut pas compenser complètement un modèle qui est faible en utilisation d’outils, planification de longue haleine, raisonnement sur le code ou rétention des instructions. Les discussions communautaires autour des configurations locales d’OpenCode convergent régulièrement sur la même observation : les modèles locaux peuvent être excellents pour des tâches délimitées, mais les plus petits ont souvent besoin de plus de supervision. Pour des chiffres mesurés sur la façon dont des modèles spécifiques se comportent réellement dans OpenCode, voir ma comparaison de LLM en pratique pour OpenCode)

La solution pratique est le routage de modèles par complexité de tâche. Utilisez un modèle moins cher ou local pour :

• la recherche dans le dépôt ;
• la documentation ;
• les tests simples ;
• les éditions répétitives ;
• les changements de formatage ;
• les corrections de bogues straightforward.

Utilisez un modèle plus fort pour :

• les changements architecturaux ;
• les bogues ambigus ;
• les refactorisations inter-paquets ;
• la concurrence ;
• le code sensible à la sécurité ;
• les migrations complexes.

L’indépendance du fournisseur rend cette stratégie possible. Elle ne rend pas la qualité du modèle indifférente.

Un flux de travail quotidien pratique avec OpenCode

Mon flux de travail préféré est volontairement conservateur. Il fonctionne de la même manière dans le TUI ou via opencode run ; là où une étape est un prompt, la variante en ligne de commande est montrée à côté.

Étape 1 : Partir d’un état Git propre

git status

Commitez les changements existants ou enregistrez délibérément ce qui est déjà modifié. Un agent de codage IA opérant dans un arbre de travail sale rend la revue beaucoup plus difficile parce que les changements humains et les changements de l’agent se mélangent.

Étape 2 : Demander une investigation d’abord

Enquêtez sur le problème #482.

Ne modifiez pas les fichiers.

Expliquez :
- le comportement actuel ;
- la cause racine probable ;
- les fichiers pertinents ;
- les tests existants ;
- le correctif proposé ;
- les commandes de vérification.

Le même prompt en tant que commande ponctuelle :

opencode run "Enquêtez sur le problème #482. Ne modifiez pas les fichiers. Expliquez le comportement actuel, la cause racine probable, les fichiers pertinents, les tests existants, le correctif proposé et les commandes de vérification."

Si l’investigation est erronée, la corriger est peu coûteux.

Étape 3 : Restreindre l’implémentation

Implémentez uniquement le correctif proposé.

Ne refactorisez pas le code non lié.
Ajoutez d'abord le test de régression.
Exécutez la plus petite suite de tests pertinente après le changement.

Ou non interactivement :

opencode run "Implémentez uniquement le correctif proposé. Ne refactorisez pas le code non lié. Ajoutez d'abord le test de régression. Exécutez la plus petite suite de tests pertinente après le changement."

L’agent a maintenant un espace de décision plus petit.

Étape 4 : Inspectez le diff vous-même

git diff --stat
git diff

N’externalisez pas cette étape à un autre modèle entièrement. Vous vérifiez non seulement si le code semble plausible, mais si l’agent a modifié des fichiers qu’il n’avait pas besoin de toucher.

Étape 5 : Exécuter la vérification déterministe

npm run typecheck
npm test
npm run lint

Utilisez les commandes réelles du projet. « OpenCode dit que les tests passent » n’est pas une preuve plus forte que votre terminal affichant un processus de test réussi.

Étape 6 : Exécuter une revue indépendante

Demandez à un agent en lecture seule :

Revuez le diff non commité comme s'il s'agissait d'une demande de tirage
écrite par un autre ingénieur.

Essayez de trouver des raisons pour lesquelles cette implémentation est erronée.

Ne modifiez pas les fichiers.

La variante en ligne de commande :

opencode run "Revuez le diff non commité comme s'il s'agissait d'une demande de tirage écrite par un autre ingénieur. Essayez de trouver des raisons pour lesquelles cette implémentation est erronée. Ne modifiez pas les fichiers."

L’expression « essayez de trouver des raisons pour lesquelles c’est faux » est intentionnelle. Les modèles sont très bons pour confirmer poliment un travail plausible. Les prompts de revue devraient encourager la falsification plutôt que l’applaudissement.

Étape 7 : Commiter uniquement après que le diff a du sens

git add -p
git commit

Je préfère toujours le ciblage interactif après les changements générés par l’agent. Cela force un dernier passage humain sur chaque bloc de code qui fait partie de l’historique du dépôt.

Là où OpenCode devient frustrant : pièges courants

Les limites intéressantes ne sont pas généralement « l’IA a fait une erreur de syntaxe ». Les compilateurs sont bons pour en attraper. Les problèmes difficiles viennent de l’autonomie, du contexte, des prémisses cachées et de la configuration.

Défi 1 : La qualité du modèle domine l’expérience

Le même flux de travail OpenCode peut sembler excellent avec un modèle et presque inutilisable avec un autre. Cela rend les critiques de produit difficiles parce que les utilisateurs attribuent souvent le comportement du modèle au harnais d’agent.

Si OpenCode :

• ignore les instructions ;
• réécrit trop de code ;
• appelle les outils incorrectement ;
• boucle sur la même action échouée ;
• perd le fil des contraintes ;
• invente des API ;

essayez un autre modèle avant de redessiner toute la configuration d’OpenCode. Le terminal n’est pas soudain devenu plus intelligent. Le modèle l’est devenu.

Défi 2 : Les sessions longues accumulent un mauvais contexte

Les sessions d’agents de codage deviennent moins fiables à mesure que les prémisses incorrectes s’accumulent. Une erreur précoce telle que « ce service est sans état » peut influencer des dizaines de décisions ultérieures même après que les fichiers pertinents ont changé.

OpenCode prend en charge la compaction pour gérer les limites de contexte, mais la compression crée son propre compromis. Un résumé décide nécessairement quels détails survivent. Pour les transitions de tâches majeures, démarrer une session neuve est souvent plus propre que de continuer une conversation héroïque de 80 000 jetons. Avec les exécutions scriptées, la réponse est encore plus simple : un nouveau opencode run commence avec un contexte propre à chaque fois, donc l’état de longue durée appartient à des fichiers comme AGENTS.md, pas à une conversation.

Le contexte n’est pas une mémoire gratuite. C’est un état de travail, et l’état de travail devient obsolète.

Défi 3 : Les permissions peuvent devenir trompeusement compliquées

Les règles simples sont faciles :

read -> allow
edit -> ask
git push -> deny

Les hiérarchies d’agents complexes sont plus difficiles. Une fois que les agents principaux peuvent invoquer des sous-agents, des outils personnalisés, des serveurs MCP et des commandes shell, vous devez raisonner sur les capacités effectives de l’ensemble du flux de travail plutôt que sur une seule ligne de configuration.

Il y a également eu de véritables discussions communautaires et GitHub sur le comportement des permissions des sous-agents et l’héritage des permissions. La leçon est plus large que tout bogue unique : testez les hypothèses de sécurité avec un dépôt jetable réel — par exemple, git init /tmp/opencode-perm-test et essayez de faire exécuter à l’agent une commande que vous avez interdite là-bas. Si une action ne doit absolument pas se produire, ne vous reposez pas uniquement sur les instructions en prose.

Défi 4 : OpenCode change rapidement

OpenCode a été livré à un rythme remarquable. C’est bon pour les fonctionnalités et moins agréable pour la longévité de la documentation. Un piège particulièrement facile en 2026 est de trouver des exemples de configuration d’une génération d’OpenCode différente. La documentation actuelle contient également des matériaux V2 séparés dont le schéma de configuration diffère de la syntaxe 1.x établie. Par exemple, les concepts de permissions peuvent apparaître sous des noms de champs différents dans la documentation V2.

Ne combinez pas négligemment des exemples de :

/docs/

et :

/v2/docs/

sans vérifier quel temps d’exécution vous utilisez réellement. Lors du dépannage d’une configuration copiée d’un article de blog, vérifiez sa date de publication avant de supposer qu’OpenCode est cassé.

Défi 5 : Le TUI peut cacher l’échelle

Une interface conversationnelle fait qu’un changement de dix fichiers semble plus petit qu’un changement de dix fichiers. L’agent peut signaler :

Implémenté la nouvelle validation et mis à jour les tests pertinents.

Cette phrase pourrait représenter trois lignes ou 600 lignes. Gardez les outils shell indépendants à proximité :

git status --short
git diff --stat
git diff --name-only
git diff

L’agent de codage ne devrait pas être la seule interface à travers laquelle vous observez l’agent de codage.

Défi 6 : MCP peut détruire l’efficacité du contexte

Des intégrations plus nombreuses ne produisent pas automatiquement un meilleur agent de codage. Les grands serveurs MCP peuvent exposer de nombreux schémas d’outils, chacun consommant le contexte du modèle et augmentant la complexité de sélection d’outils. Si OpenCode semble étrangement indécis après que vous avez installé la moitié de l’écosystème MCP, désactivez la majeure partie et comparez. Une surface d’outils plus petite produit souvent un meilleur comportement d’agent.

Défi 7 : La confidentialité locale exige de vérifier tout le chemin

L’exécution d’un modèle local ne garantit pas automatiquement que chaque partie d’une chaîne d’outils est locale. Les discussions communautaires du début de 2026 ont soulevé des questions de confidentialité autour du comportement du modèle auxiliaire d’OpenCode et de l’architecture de l’interface Web. Certaines de ces affirmations se référaient à des versions plus anciennes, certaines étaient contestées et certains chemins de code ont changé depuis.

La leçon durable n’est pas « OpenCode envoie tout quelque part ». La leçon durable est : si le fonctionnement local exclusif est une exigence stricte, vérifiez-le. Utilisez l’inspection réseau, lisez la configuration actuelle, comprenez quelle interface vous utilisez, désactivez les intégrations distantes inutiles et testez la version exacte que vous avez l’intention de déployer. Les exigences de sécurité doivent être validées, pas inférées d’une catégorie de produit.

OpenCode contre Claude Code et Codex CLI

Le différenciateur le plus fort d’OpenCode n’est pas nécessairement la qualité de codage. Le modèle sous-jacent contribue encore fortement à la qualité de codage. Son différenciateur est le contrôle sur le harnais.

OpenCode est convaincant lorsque vous valuez :

• une implémentation open source ;
• la flexibilité des fournisseurs ;
• les flux de travail axés sur le terminal ;
• des agents configurables ;
• des permissions granulaires ;
• la prise en charge des modèles locaux ;
• le MCP ;
• des commandes et compétences réutilisables ;
• une architecture client/serveur.

Claude Code) est convaincant lorsque vous voulez une expérience Anthropic étroitement intégrée avec un comportement de modèle de première partie solide et des flux de travail d’agents intégrés de plus en plus polis. Codex CLI est convaincant lorsque vos modèles et flux de travail préférés sont déjà centrés sur la pile de codage d’OpenAI.

Je ne choisiraient pas parmi eux en comptant les fonctionnalités. Choisissez en fonction de la couche que vous voulez posséder. Si vous voulez qu’un fournisseur prenne la plupart des décisions de flux de travail, un agent de codage de première partie peut être attractif. Si vous voulez que le harnais reste remplaible pendant que vous expérimentez avec les fournisseurs et les configurations d’agents, OpenCode fait un argument plus fort.

Ce que Reddit et Hacker News ont de juste sur OpenCode

Les discussions communautaires autour d’OpenCode sont inhabituellement polarisées. Certains développeurs le décrivent comme leur harnais de codage préféré, surtout lorsqu’il est combiné avec des modèles Codex, des modèles locaux ou des configurations d’agents personnalisées. D’autres se concentrent sur l’utilisation des ressources, le comportement des permissions, les questions de confidentialité, les changements d’authentification des fournisseurs ou la complexité qui apparaît une fois qu’une application terminal apparemment simple devient une infrastructure. Les deux points de vue sont raisonnables.

OpenCode n’est pas difficile parce que la ligne de commande est difficile. C’est difficile parce qu’un environnement de codage autonome expose des questions que les développeurs n’avaient pas besoin de répondre explicitement auparavant :

• Quel modèle devrait prendre cette décision ?
• Quels fichiers peut-il lire ?
• Quelles commandes peut-il exécuter ?
• Quels identifiants le processus peut-il voir ?
• Quelles tâches devraient devenir des sous-agents ?
• Combien de contexte devrait survivre ?
• Quels outils méritent un contexte permanent ?
• Quel résultat un humain doit-il vérifier ?

Un produit fermé poli peut prendre beaucoup de ces décisions pour vous. OpenCode en rend plus les vôtres. C’est précisément pourquoi les utilisateurs avancés l’aiment.

Une configuration de départ que je recommanderais

Je résisterais à construire une configuration élaborée immédiatement. Commencez par :

1. un modèle fort par défaut ;
2. un AGENTS.md ;
3. des permissions shell et d’édition conservatrices ;
4. un agent de revue en lecture seule ;
5. deux ou trois commandes personnalisées ;
6. pas de serveurs MCP jusqu’à ce qu’un besoin réel apparaisse.

Un environnement simple est plus facile à déboguer. Une fois qu’un flux de travail devient répétitif, promuevez-le dans une commande, une compétence ou un agent. Une fois qu’une capacité devient risquée, restreignez-la avec des permissions. Une fois que le contexte devient enflé, divisez le flux de travail plutôt que d’acheter simplement une fenêtre de contexte plus grande. Cette approche incrémentale est moins impressionnante sur les captures d’écran et considérablement plus agréable à maintenir.

Qui devrait utiliser OpenCode

OpenCode est particulièrement adapté aux développeurs qui vivent déjà dans les terminaux et qui veulent que leur agent de codage se comporte comme un autre outil de développement programmable. Je le considérerais fortement si vous :

• travaillez à travers plusieurs fournisseurs de LLM ;
• voulez la prise en charge des modèles locaux ;
• détestez être verrouillé sur un seul fournisseur d’IA ;
• avez besoin d’agents spécifiques au projet ;
• automatisez des tâches de développement depuis des scripts shell ;
• voulez inspecter ou modifier le harnais de codage ;
• comprenez déjà Git et les outils CLI normaux.

C’est moins convaincant si vous voulez principalement une couche IA invisible dans un IDE. OpenCode s’attend également à plus de jugement opérationnel qu’un outil d’autocomplétion traditionnel. Si la revue des diffs, la compréhension des commandes shell et la gestion des branches Git vous semblent déjà inconfortables, donner à un processus autonome l’accès à ces outils ne fera pas disparaître la complexité sous-jacente.

Verdict final

OpenCode est l’un des exemples plus convaincants d’un outil de codage IA devenant une infrastructure pour développeurs plutôt que simplement une interface de chat. Ses meilleures fonctionnalités ne sont pas flashy. L’indépendance du fournisseur, les permissions explicites, les agents réutilisables, l’exécution non interactive, les instructions du dépôt, les commandes, les compétences et les outils composables permettent de façonner l’agent autour d’un flux de travail d’ingénierie réel.

La faiblesse est l’image miroir de cette force. OpenCode vous donne assez de contrôle pour créer un environnement de codage discipliné, mais il vous donne également assez de contrôle pour créer un essaim d’agents compliqué, coûteux, mal isolé avec vingt serveurs MCP et aucune limite de vérification claire.

J’optimiserais pas OpenCode pour l’autonomie maximale. J’optimiserais pour de boucles de retour courtes. Donnez-lui un problème délimité, assez de contexte pour comprendre le problème, la permission d’exécuter uniquement les actions nécessaires, et des commandes déterministes qui peuvent prouver si le résultat fonctionne. C’est moins magique que de demander à un agent de construire une application entière pendant que vous dormez. C’est aussi beaucoup plus proche de la façon dont OpenCode devient réellement utile.

Références

• Documentation d’OpenCode : https://opencode.ai/docs/
• Journal des changements d’OpenCode : https://opencode.ai/changelog
• Dépôt GitHub d’OpenCode : https://github.com/anomalyco/opencode
• Catalogue de fournisseurs Models.dev : https://models.dev