Utiliser OpenCode : démarrage rapide, 7 conseils pratiques et quand ajouter Oh My OpenCode

Name

Soren Atelier

Mis à jour le 17/03/2026

OpenCode est un agent de coding open source pensé pour le terminal, avec une app desktop, une extension IDE et une couche de modèles agnostique vis-à-vis du provider. La vraie question n’est pas seulement "est-ce qu’il peut écrire du code ?" mais plutôt : "à quel moment rester sur OpenCode seul, et à quel moment ajouter une couche d’orchestration plus lourde comme Oh My OpenCode ?"

La version courte : commencez par OpenCode seul. Apprenez son flux plan / build, générez un vrai AGENTS.md, puis habituez-vous aux permissions et aux commandes personnalisées. Ajoutez Oh My OpenCode seulement si vous avez besoin d’un routage multi-modèles plus agressif, de spécialistes en arrière-plan et d’un harness plus opiniâtre pour aller jusqu’au bout des tâches.

Si vous voulez d’abord replacer le sujet dans le paysage AI coding, commencez par le hub AI Coding, How to Use Codex et Parallel Code Agents Explained. Si vous comparez des frameworks d’agents à un niveau plus large, OpenClaw vs ZeroClaw vs Pi Agent vs Nanobot est la bonne page de comparaison.

Réponse rapide : OpenCode seul ou OpenCode + Oh My OpenCode ?

OpenCode couvre déjà le cycle essentiel pour la plupart des développeurs : comprendre le dépôt, planifier le changement, éditer proprement et travailler depuis le terminal. Le couplage avec Oh My OpenCode est utile, mais ce n’est pas le premier pas.

Ce qu’est réellement OpenCode

OpenCode est un agent de coding open source construit autour d’un workflow terminal-first. La documentation officielle et le README actuel le décrivent comme :

• un agent TUI-first ;
• une app desktop en bêta ;
• une extension IDE ;
• un système agnostique qui fonctionne avec OpenAI, Anthropic, Google et d’autres backends ;
• une boîte à outils avec agents intégrés, permissions, commandes personnalisées, règles, formatage et support LSP.

Le changement de posture important est celui-ci : OpenCode n’est pas juste une fenêtre de chat qui génère du code. C’est une surface de travail pour agents. Vous pouvez l’utiliser pour :

• inspecter un dépôt inconnu ;
• planifier un changement sans éditer ;
• modifier des fichiers et exécuter des commandes shell ;
• créer des règles projet avec AGENTS.md ;
• définir des commandes slash répétables ;
• durcir ou assouplir les permissions selon le niveau de risque.

Un détail pratique compte beaucoup, car les anciens tutoriels sont déjà dépassés. Au 17 mars 2026, les releases actuelles d’OpenCode sont publiées depuis anomalyco/opencode, et la dernière release GitHub est v1.2.27, publiée le 16 mars 2026. Si vous tombez sur d’anciens repos archivés ou redirigés, vous êtes sur du contexte historique, pas sur la cible d’installation actuelle.

Démarrer avec OpenCode

1. Installer OpenCode

Le démarrage rapide officiel est le suivant :

curl -fsSL https://opencode.ai/install | bash

Vous pouvez aussi passer par Homebrew, npm, Scoop, Chocolatey, mise ou nix, mais le script d’installation reste le chemin le plus rapide pour commencer.

2. Connecter un provider et ouvrir un vrai projet

Après le lancement, la documentation officielle recommande :

/connect

Ensuite, sélectionnez opencode dans la TUI et finalisez l’auth à opencode.ai/auth, ou utilisez un autre provider déjà en place.

La règle la plus pragmatique est simple : ne commencez pas par le plus gros dépôt avec la demande la plus vague. Ouvrez un projet que vous connaissez assez bien pour relire le résultat.

3. Lancer /init avant les tâches sérieuses

OpenCode peut générer un fichier AGENTS.md pour le repo :

/init

Vous donnez ainsi à l’agent des consignes projet durables. Committez ce fichier dans Git. C’est l’un des gestes les plus rentables du workflow, parce qu’il réduit les répétitions dans les prompts et stabilise le comportement d’une session à l’autre.

4. Commencer en plan, pas en build

OpenCode fournit deux agents intégrés que vous pouvez changer avec Tab :

• build pour le travail de développement complet ;
• plan pour l’analyse et l’exploration du code.

Pour votre premier cas d’usage, restez sur plan et gardez le périmètre étroit :

Résume le flux de build, de test et de release de ce dépôt.
Indique les points d’entrée principaux.
Ne modifie rien pour l’instant.

Passez ensuite en build seulement quand la carte du repo paraît correcte.

7 conseils pratiques pour OpenCode

Conseil 1 : faites de plan votre mode par défaut sur les codebases inconnues

La séparation entre planification et édition n’est pas seulement une question de sécurité. Elle améliore aussi la qualité.

Si vous arrivez directement en build, le modèle peut commencer à modifier des fichiers avant que vous ayez validé sa compréhension. En commençant par plan, vous gagnez un tour peu coûteux pour vérifier l’architecture, les noms, le flux de tests et le rayon d’impact.

Utilisez par exemple :

Explique comment fonctionne l’auth dans @src/auth/index.ts
Puis propose deux options de correctif minimales.
N’édite rien encore.

Le préfixe @ est utile ici, car OpenCode sait faire une recherche de fichiers souple directement dans le prompt.

Conseil 2 : considérez /init et AGENTS.md comme des multiplicateurs, pas comme de la paperasse

Beaucoup de développeurs sous-estiment cette étape parce qu’elle ressemble à du contexte documentaire.

En réalité, AGENTS.md est l’endroit où placer :

• les commandes build, test et lint ;
• la structure du repo et les frontières entre packages ;
• les règles de style et les attentes de review ;
• les contraintes du type "ne jamais toucher à ceci" ;
• la définition de done.

Si vous sautez cette étape et répétez les règles du repo dans le chat, vos résultats deviennent plus bruyants et plus coûteux.

Si le sujet vous intéresse, Build a Claude-Code-Like AI Agent with Claude Agent SDK est un bon complément, car il traite la même idée côté construction d’agent.

Conseil 3 : serrez les permissions avant de faire confiance aux valeurs par défaut

OpenCode est configurable, et la documentation sur les permissions le dit clairement : les actions peuvent être mises en allow, ask ou deny.

Pour un nouveau repo, une base prudente ressemble à ceci :

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "edit": "ask",
    "bash": "ask"
  }
}

Cela ralentit un peu l’agent, mais évite des surprises pendant la phase d’apprentissage. Une fois la confiance établie, vous pouvez assouplir sélectivement certains gestes à faible risque.

Conseil 4 : créez quelques commandes slash avant d’ajouter encore plus d’outillage

OpenCode supporte déjà des commandes intégrées comme /init, /undo, /redo, /share et /help. Il permet aussi d’ajouter des commandes personnalisées via la config ou des fichiers markdown dans .opencode/commands/.

Autrement dit, beaucoup de gains "workflow avancé" ne nécessitent pas encore un nouveau framework. Vous pouvez définir des commandes comme :

• /test
• /review
• /ship-check
• /seo-page

Par exemple :

---
description: Exécute les tests liés au changement en cours
agent: build
---
 
Lance les tests pertinents pour les fichiers touchés pendant cette session.
Résume d’abord les échecs, puis propose le correctif le plus petit possible.

Cela garde les prompts courants courts et relisibles.

Conseil 5 : maîtrisez un provider avant de courir après tous les providers

Le côté agnostique de OpenCode est un vrai atout, mais il pousse facilement à sur-configurer trop tôt.

Ne commencez pas par brancher cinq providers, trois chaînes de fallback et une matrice de modèles custom. Commencez par le provider que vous payez déjà et que vous comprenez. Étendez seulement après avoir compris le comportement d’OpenCode lui-même.

Si vous découvrez la catégorie, How to Use Codex vaut aussi le détour, car il transmet la même leçon opérationnelle : des tâches bien cadrées battent la complexité inutile.

Conseil 6 : sachez quand le terminal, le desktop ou l’IDE est le bon choix

OpenCode est désormais plus qu’un simple binaire terminal.

Utilisez le terminal si vous voulez la boucle prompt-edit-test la plus rapide.

Utilisez l’application desktop si la visibilité sur la review, la gestion des sessions et le confort d’interface comptent plus que la vitesse brute.

Utilisez l’extension IDE si votre éditeur actuel est déjà votre surface de contrôle.

L’erreur n’est pas de choisir "la mauvaise option pour toujours". L’erreur est d’utiliser la mauvaise surface pour la tâche en cours puis d’en accuser l’agent.

Conseil 7 : laissez OpenCode formater et structurer le changement, mais relisez toujours le diff comme un ingénieur

La documentation OpenCode indique qu’il peut utiliser automatiquement des formatters spécifiques après édition. C’est utile, mais le formatage n’est pas la même chose que la qualité du changement.

Vous devez encore vérifier :

• si l’implémentation correspond vraiment à la demande ;
• si les commandes bash proposées sont adaptées ;
• si les consignes AGENTS.md sont respectées ;
• si le patch n’est pas trop large pour la tâche.

Les agents de coding réduisent la frappe. Ils ne suppriment pas le jugement d’ingénierie.

Quand ajouter Oh My OpenCode

Oh My OpenCode n’est pas OpenCode lui-même. C’est une couche d’orchestration plus directive construite autour d’OpenCode.

La documentation actuelle du projet le présente comme un harness multi-modèles qui ajoute :

• un modèle d’orchestration plus fort autour d’agents spécialisés ;
• du routage de modèles par catégorie ;
• des background agents et du travail parallèle ;
• des workflows orientés MCP ;
• un style plus agressif du type "continuer jusqu’à ce que la tâche soit finie" ;
• des commandes comme ultrawork / ulw.

C’est intéressant quand OpenCode seul commence à paraître trop léger pour votre charge de travail.

L’intérêt de Oh My OpenCode n’est pas qu’OpenCode serait faible. C’est que certains utilisateurs veulent un harness plus directif : plus de délégation, plus d’orchestration, plus de spécialisation de modèles et moins de pilotage manuel une fois la tâche lancée.

Comment coupler OpenCode et Oh My OpenCode

1. Faites d’abord fonctionner OpenCode seul

N’ajoutez pas un harness au-dessus d’un outil de base que vous n’avez même pas testé.

Avant d’ajouter quoi que ce soit, assurez-vous de pouvoir :

• installer OpenCode ;
• authentifier un provider ;
• exécuter /init ;
• terminer une tâche plan ;
• terminer une tâche build.

Si cette base est fragile, ajouter Oh My OpenCode rendra le debugging plus difficile.

2. Comprenez le nommage avant d’installer

Un détail de nom peut prêter à confusion :

• le repo GitHub est actuellement code-yeongyu/oh-my-openagent ;
• le branding et le package renvoient toujours à Oh My OpenCode ;
• la commande d’installation utilise encore oh-my-opencode.

Au 17 mars 2026, il faut les considérer comme la même lignée de projet.

3. Installez le harness avec l’installeur officiel

Le chemin manuel le plus simple est :

bunx oh-my-opencode install

Le projet recommande aussi explicitement de laisser un agent IA récupérer le guide d’installation et le suivre, ce qui colle à sa philosophie d’orchestration.

4. Commencez par une commande à fort impact, pas par toute la surface

La commande emblématique est :

ultrawork

ou son alias court :

ulw

Mais n’en faites pas une formule magique. Testez-la d’abord sur une tâche de taille moyenne avec une fin claire. Bons cas d’usage :

• corriger un bug ciblé et ajouter les tests liés ;
• implémenter une fonctionnalité bien cadrée ;
• nettoyer une série de fichiers trop bruyants ;
• faire de la recherche parallèle puis l’implémentation dans un repo déjà compris.

Mauvais premiers cas :

• architecture greenfield trop vague ;
• migration de prod sans rollback ;
• repo sensible sans politique de permissions relue.

5. Le meilleur rendement arrive quand vous profitez vraiment de l’orchestration multi-modèles

Oh My OpenCode devient plus défendable quand votre travail bénéficie réellement de :

• modèles différents pour la planification, le raisonnement et le frontend ;
• spécialistes en arrière-plan ;
• usage plus large de MCP ;
• discipline plus forte des subagents.

Si votre quotidien ressemble surtout à "petit fix dans un fichier, tests, puis on passe à autre chose", OpenCode seul suffit souvent.

OpenCode seul ou OpenCode + Oh My OpenCode

Le conseil pratique reste simple :

1. Apprenez OpenCode seul.
2. Écrivez et committez un vrai AGENTS.md.
3. Ajoutez 2 ou 3 commandes custom.
4. Serrez les permissions.
5. Décidez ensuite si votre charge de travail justifie Oh My OpenCode.

Pièges fréquents

Confondre OpenCode et OpenClaw

Ce n’est pas le même projet.

Si vous avez cherché OpenClaw mais que vous voulez l’agent de coding open source en terminal avec plan, build, /init et la compatibilité Oh My OpenCode, vous pensiez probablement à OpenCode.

Utiliser des liens de repo obsolètes

Il existe déjà assez de churn autour des anciens repos OpenCode pour qu’il faille vérifier le chemin d’installation. Commencez par les docs officielles.

Installer le harness avant de connaître la base

Si vous ne comprenez pas comment OpenCode se comporte seul, vous ne saurez pas si un résultat étrange vient de l’agent de base, du harness, du provider ou de vos règles repo.

Surinvestir dans les abonnements dès le premier jour

La flexibilité des providers est utile, mais la plupart des utilisateurs devraient d’abord démarrer avec l’accès qu’ils ont déjà.

FAQ

OpenCode est-il la même chose qu’OpenClaw ?

Non. Ce sont deux projets différents. Cette page parle d’OpenCode, l’agent de coding open source documenté sur opencode.ai.

Ai-je besoin de Oh My OpenCode pour bien utiliser OpenCode ?

Non. OpenCode est déjà utile seul. Oh My OpenCode devient intéressant quand vous voulez une orchestration plus lourde, une délégation plus directive et un workflow multi-modèles plus large.

Que dois-je faire juste après l’installation ?

Lancez /connect, ouvrez un vrai projet, exécutez /init, passez en plan, puis demandez d’abord un résumé du dépôt avant d’autoriser des modifications.

Dois-je commencer par le terminal, le desktop ou l’IDE ?

Commencez par le terminal, sauf si vous savez déjà que vous préférez un flux desktop centré review ou une intégration IDE native.

Quand suis-je prêt pour Oh My OpenCode ?

Vous êtes prêt quand OpenCode seul est déjà confortable, que votre AGENTS.md est en place, et que vous sentez régulièrement le besoin de coordonner plusieurs passes spécialisées.

Guides associés

• Hub AI Coding
• How to Use Codex
• Parallel Code Agents Explained
• Build a Claude-Code-Like AI Agent with Claude Agent SDK
• OpenClaw vs ZeroClaw vs Pi Agent vs Nanobot