OpenCode CLI en pratique : flux de travail, automatisation et pièges à éviter

L’interface en ligne de commande d’OpenCode est conçue pour l’écriture de scripts, les pipelines CI et l’exécution d’agents en mode non supervisé. Cet article constitue un guide pratique pour l’utiliser dans le travail quotidien.

Derrière le CLI se trouve un système composé 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 des tâches à des sous-agents. Le même environnement fonctionne de manière interactive dans l’interface TUI ou de manière 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 du choix du modèle, des instructions du dépôt, des limites de permissions, de la gestion du contexte et de l’agressivité avec laquelle vous autorisez l’agent à opérer. Cet article se concentre sur cette seconde étape, depuis la ligne de commande : quels cas d’usage sont rentables, quels workflows d’automatisation tiennent la route dans l’usage quotidien et quels problèmes apparaissent une fois la nouveauté d’un terminal alimenté par l’IA retombée. Il fait partie de la section Outils de développement IA de ce site.

Les observations ci-dessous ont été vérifiées par rapport à OpenCode 1.18.9 et à la documentation actuelle en août 2026. OpenCode évolue rapidement, donc les exemples de configuration méritent une vérification rapide de la documentation avant d’être copiés dans une configuration d’équipe à long terme. Si vous n’avez pas encore installé OpenCode, le guide de démarrage rapide d’OpenCode couvre l’installation, la vérification et la connexion aux fournisseurs.

Ce qu’est réellement OpenCode : un environnement d’agent, pas une boîte de chat

OpenCode est un agent de codage IA open source conçu autour du terminal. Une vue simplifiée de ce qu’il assemble ressemble à ceci :

La partie importante est la couche de permissions entre l’intention du 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 bien régler les deux aspects.

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

Configuration : installation, connexion et l’importance de l’indépendance des fournisseurs

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 guide de 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), donc cet article ne le répète pas.

Vous pouvez utiliser les propres services de modèles d’OpenCode ou connecter des fournisseurs externes pris en charge. OpenCode construit actuellement une grande partie de son catalogue de fournisseurs à l’aide de Models.dev et prend en charge une large gamme de configurations de modèles commerciaux et locaux.

L’indépendance des fournisseurs 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 un travail d’architecture difficile, un autre pour des tâches d’implémentation bon marché, et un modèle local pour du code qui ne devrait pas quitter votre environnement.

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

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

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

/init

OpenCode analyse le projet et crée un fichier AGENTS.md. Committez 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 prévenir les erreurs prévisibles. Par exemple :

# Instructions du dépôt

## Architecture

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

## Validation

Après les modifications TypeScript, exécutez :

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

Après les modifications du frontend, exécutez é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 si explicitement demandé.
- N'exécutez jamais de 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 contrat de dépôt court é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 plupart des attentions, mais le mode non interactif d’OpenCode modifie considérablement la gamme des workflows utiles :

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

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

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

Ou pipez 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 "Révisez le diff git actuel pour la justesse et les tests manquants. Ne modifiez pas les fichiers."

Parce qu’une exécution scriptée n’a pas d’humain au prompt, la politique de permissions que vous configurez est la seule barrière 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’usage interactif.

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 des endroits où la logique shell traditionnelle devient pénible, tout en gardant une validation déterministe autour.

Les meilleurs cas d’usage du CLI OpenCode

OpenCode peut tenter presque toute tâche de programmation, mais cela ne signifie pas que chaque tâche doit être déléguée de la même manière. Les workflows à plus forte valeur ont tendance à avoir trois propriétés : le résultat souhaité est testable, le contexte pertinent du dépôt peut être découvert et les changements incorrects sont bon marché à inspecter ou à annuler. 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 nécessiteraient autrement une séquence de commandes grep, de recherches dans l’éditeur, de sauts de fichiers et de git log. Par exemple :

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

Suivez 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 cherchera les points d’entrée, suivra les références, inspectera les tests et retournera quelque chose de plus proche d’une visite guidée de l’architecture 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 parce que 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 :

Le CLI se termine avec le statut 0 lorsque la validation de la configuration échoue.

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

Ne refactorisez pas le code non lié.

La phrase clé n’est pas “corriger le bug”. Ce sont les contraintes entourant la tâche. OpenCode fonctionne mieux lorsque la réussite peut être démontrée par un test, un compilateur ou une commande observable. Des exigences vagues donnent au modèle la liberté de créer du code plausible plutôt que du code correctement démontrable.

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

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

Révisez src/parser.ts et ses tests existants.

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

Exécutez la suite de tests du parser 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 en un seul passage non contraint, il peut accidentellement créer des tests qui valident son propre interprétation plutôt que le comportement prévu.

4. Refactoring mécanique

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

• remplacer une API dépréciée dans tout un dépôt ;
• convertir un code répété en un assistant partagé ;
• renommer un champ de configuration ;
• migrer des tests d’un motif d’assertion à un autre ;
• mettre à jour les imports après le déplacement d’un package ;
• remplacer une abstraction de journalisation obsolète.

Le compilateur et les tests du dépôt deviennent la boucle de feedback 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 la vérification de types du package.
À la fin, exécutez la suite de tests du package et montrez-moi le résumé final du diff git.

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

5. Revue de code

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

Révisez 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 n'ont pas changé.
Classez les résultats par gravité.

Un revueur en lecture seule est utile même si un autre agent de codage a produit les changements. La séparation est précieuse parce que 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 à l’égard de cette approche qu’un revueur frais.

Utilisez les modes Plan et Build comme différents modes mentaux

OpenCode fournit des agents principaux et des sous-agents, avec des workflows intégrés incluant un comportement orienté planification et implémentation. Même lorsque la configuration exacte de l’agent 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 les 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 commande unique :

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

Puis 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 fausses hypothèses 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 les spécifications: 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 GitHub Spec Kit vs Kiro vs Claude Code couvre les workflows SDD structurés qui vont plus loin qu’un seul prompt.

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 mentions explicites. Par exemple :

@general trouvez où le comportement de réessai 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 frontend ou la documentation. Le même motif fonctionne dans d’autres harnais ; le guide des sous-agents Claude Code couvre le design analogue côté 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 relisent chacun 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. Lorsque 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 réellement fiable.

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

Si la tâche a réellement besoin d’un orchestrateur complet déléguant à une liste 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 ces primitives, pas un prompt plus grand. Le démarrage rapide Oh My Opencode couvre ce harnais.

Utilisez les agents personnalisés comme limites de permissions

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

---
description: Révise 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
---

Révisez 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 bien meilleur 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.

Configurez les permissions 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 lors d’une démonstration et pas forcément ce que je veux sur une station de travail contenant des clés SSH, des identifiants de production, des jetons de publication de packages, des contextes Kubernetes et l’accès à plusieurs comptes cloud. Pour les jobs opencode run non supervisés, les enjeux sont encore plus élevés : 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 modifications, 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 conservateur 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 doivent 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 bac à sable

Les règles de permissions sont utiles, mais elles ne sont pas la même chose 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 packages et d’autres outils de développement.

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

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

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

Si vous tapez régulièrement les mêmes instructions, ils devraient probablement cesser d’être de l’historique de chat et devenir de la configuration. OpenCode prend en charge des commandes slash personnalisées de projet et globales pour l’interface interactive. Par exemple, créez :

.opencode/commands/review.md

avec :

---
description: Révise les changements actuels
agent: plan
---

Révisez le diff git actuel.

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

Ne modifiez pas les fichiers.

Puis utilisez :

/review

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

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

Utilisez les compétences pour les workflows réutilisables

OpenCode prend également en charge les fichiers SKILL.md. Les compétences sont utiles lorsqu’un workflow 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 :

• procédures de migration de base de données ;
• workflows de publication ;
• investigation d’incidents ;
• revues de compatibilité d’API ;
• publication de packages ;
• validation d’infrastructure ;
• conventions d’architecture internes.

Par exemple :

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

Une description de compétence pourrait dire à 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 en arrière et exécuter des 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/ “Compétences Claude expliquées : structure SKILL.md, disposition des dossiers, bonnes pratiques, tests et dépannage.”}) mappe les mêmes décisions de design.

L’avantage est la discipline du contexte. Déverser chaque règle organisationnelle dans AGENTS.md finit par créer un énorme prompt système 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 lorsque nécessaire.

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 faciles à 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 dans 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 des outils parce qu’un workflow en a besoin, pas 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 terminaison de modèles locaux ou auto-hébergés compatibles OpenAI. C’est attrayant lorsque :

• le code source doit rester local ;
• les coûts d’API sont significatifs ;
• vous exploitez déjà une infrastructure GPU ;
• vous voulez 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 terminaison local tel que LM Studio, llama.cpp via llama-server, vLLM, une infrastructure compatible Ollama ou un autre serveur compatible OpenAI.

C’est ici 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, en planification à long terme, en raisonnement sur le code ou en rétention d’instructions. Les discussions communautaires autour des configurations locales d’OpenCode convergent régulièrement vers la même observation : les modèles locaux peuvent être excellents pour des tâches borné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, consultez mon comparaison pratique de LLM 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 de dépôt ;
• la documentation ;
• les tests simples ;
• les modifications répétitives ;
• les changements de mise en forme ;
• les corrections de bugs simples.

Utilisez un modèle plus fort pour :

• les changements d’architecture ;
• les bugs ambigus ;
• les refactorings inter-packages ;
• la concurrence ;
• le code sensible à la sécurité ;
• les migrations difficiles.

L’indépendance des fournisseurs rend cette stratégie possible. Elle ne rend pas la qualité du modèle irréal.

Un flux de travail quotidien pratique avec OpenCode

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

Étape 1 : Commencer depuis un état Git propre

git status

Committez soit 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 enquête 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 unique :

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’enquête est fausse, la corriger est bon marché.

Étape 3 : Réduire 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

Ne déléguez pas entièrement cette étape à un autre modèle. 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 une 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 :

Révisez 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 fausse.

Ne modifiez pas les fichiers.

La variante en ligne de commande :

opencode run "Révisez 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 fausse. Ne modifiez pas les fichiers."

La phrase “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 les applaudissements.

Étape 7 : Committez uniquement après que le diff ait du sens

git add -p
git commit

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

Où OpenCode devient frustrant : pièges courants

Les limitations intéressantes ne sont pas généralement “l’IA a fait une erreur de syntaxe”. Les compilateurs sont bons pour les attraper. Les problèmes difficiles proviennent de l’autonomie, du contexte, des hypothèses cachées et de la configuration.

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

Le même workflow OpenCode peut sembler excellent avec un modèle et presque inutilisable avec un autre. Cela rend les revues de produits difficiles parce que les utilisateurs attribuent souvent le comportement du modèle au harnais de l’agent.

Si OpenCode répète :

• 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 repenser toute la configuration d’OpenCode. Le terminal n’est pas soudainement devenu plus intelligent. Le modèle l’a fait.

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

Les sessions d’agent de codage deviennent moins fiables à mesure que les fausses hypothèses 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 aient 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 nouvelle session est souvent plus propre que de continuer une conversation héroïque de 80 000 jetons. Avec des exécutions scriptées, la réponse est encore plus simple : une nouvelle opencode run commence avec un contexte propre chaque fois, donc l’état à long terme appartient dans des fichiers comme AGENTS.md, pas dans 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 workflow plutôt que sur une seule ligne de configuration.

Il y a également eu de vraies discussions communautaires et GitHub sur le comportement de permissions des sous-agents et l’héritage de permissions. La leçon est plus large que n’importe quel bug : 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 y avez refusée. Si une action ne doit absolument pas se produire, ne comptez pas uniquement sur des 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 différente d’OpenCode. La documentation actuelle contient également des matériaux V2 distincts 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 accidentellement des exemples de :

/docs/

et :

/v2/docs/

sans vérifier quel runtime 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 rend un changement de dix fichiers plus petit qu’un changement de dix fichiers. L’agent peut rapporter :

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 proches :

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

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

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

Plus d’intégrations 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 avoir installé la moitié de l’écosystème MCP, désactivez la plupart d’entre eux et comparez. Une surface d’outils plus petite produit souvent un meilleur comportement de l’agent.

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

L’exécution d’un modèle local ne garantit pas automatiquement que chaque partie de la chaîne d’outils est locale. Les discussions communautaires début 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 uniquement local 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 prévoyez de déployer. Les exigences de sécurité doivent être validées, pas inférées d’une catégorie de produit.

OpenCode vs 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 valorisez :

• une implémentation open source ;
• la flexibilité des fournisseurs ;
• les workflows terminal-first ;
• les agents configurables ;
• les permissions granulaires ;
• la prise en charge des modèles locaux ;
• le MCP ;
• les commandes et compétences réutilisables ;
• l’architecture client/serveur.

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

Je ne choisirais pas entre 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 workflow, un agent de codage de première partie peut être attrayant. Si vous voulez que le harnais reste remplaable 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 font bien au sujet d’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 de terminal apparemment simple devient une infrastructure. Les deux perspectives sont raisonnables.

OpenCode n’est pas difficile parce que la ligne de commande est difficile. Il 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é raffiné peut prendre beaucoup de ces décisions pour vous. OpenCode en rend plus des vôtres. C’est précisément pourquoi les utilisateurs avancés l’aiment.

Une configuration de démarrage que je recommanderais

Je résisterais à la construction d’une configuration élaborée immédiatement. Commencez avec :

1. un modèle par défaut fort ;
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 workflow devient répétitif, promouvez-le en command, compétence ou agent. Une fois qu’une capacité devient risquée, restreignez-la avec des permissions. Une fois que le contexte devient gonflé, divisez le workflow au lieu de simplement acheter une fenêtre de contexte plus grande. Cette approche incrémentale est moins impressionnante dans les captures d’écran et considérablement plus agréable à maintenir.

Qui devrait utiliser OpenCode

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

• travaillez avec plusieurs fournisseurs de LLM ;
• voulez une prise en charge des modèles locaux ;
• détestez être verrouillé à 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 une 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 accès à ces outils ne fera pas disparaître la complexité sous-jacente.

Verdict final

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

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 aussi assez de contrôle pour créer un essaim d’agents compliqué, coûteux, mal isolé avec vingt serveurs MCP et aucune frontière de vérification claire.

Je n’optimiserais pas OpenCode pour l’autonomie maximale. Je l’optimiserais pour des boucles de feedback courtes. Donnez-lui un problème borné, 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 OpenCode : https://opencode.ai/docs/
• Journal des changements OpenCode : https://opencode.ai/changelog
• Dépôt GitHub OpenCode : https://github.com/anomalyco/opencode
• Catalogue de fournisseurs Models.dev : https://models.dev