Cursus
Principes fondamentaux de l'intelligence artificielle dans le monde des affaires
12 h
OpenCode est conçu pour exécuter une tâche. C’est un agent open source qui relie un modèle d’IA à votre dépôt, à votre terminal et à vos outils de développement. Demandez-lui de corriger un bug : il peut trouver les fichiers pertinents, élaborer un plan, modifier le code, lancer des tests et réagir aux erreurs. Un simple autocomplément ne peut pas faire cela seul.
Ce rôle plus large a attiré l’attention. Au moment d’écrire ces lignes, le dépôt OpenCode actif comptait environ 189 000 étoiles GitHub. Je ne considérerais pas les étoiles comme une preuve de qualité du code, mais elles montrent l’intérêt suscité par le projet.
La réalité est moins lisse. OpenCode vous laisse le choix du modèle… puis vous demande de gérer ce choix. Un changement de politique d’un fournisseur en janvier 2026 a montré à quelle vitesse ces options peuvent évoluer. J’aborderai ce point en même temps que le fonctionnement d’OpenCode et sa place dans l’outillage.
Une précision de nommage avant de continuer : si vous cherchez OpenCode, vous pouvez tomber sur le dépôt archivié en Go opencode-ai/opencode. Ce projet n’est plus maintenu depuis septembre 2025. Nous nous concentrerons sur le projet actif à l’adresse github.com/anomalyco/opencode, développé par l’équipe à l’origine du framework Serverless Stack (SST).
Qu’est-ce qu’OpenCode ?
OpenCode est un agent de codage IA open source publié sous licence MIT. Il est indépendant des modèles, c’est-à-dire non lié à un unique fournisseur. Les utilisateurs peuvent lire le code source et le modifier. Ils peuvent également l’auto-héberger. Le logiciel est gratuit. La facturation des modèles est séparée, comme je l’explique dans les fonctionnalités.
OpenCode n’est pas un grand modèle de langage (LLM). Le modèle sélectionné lit les invites et produit des réponses. OpenCode fournit les outils de fichiers, l’accès au shell, l’historique de session, les règles d’autorisation et l’interface autour de ce modèle. Cette distinction est utile : changer de modèle ne nécessite pas de changer le reste de l’outil.
Il est développé par Anomaly, ex-SST, et repose principalement sur TypeScript et Bun.
Comparaison des dépôts OpenCode archivié et actuel. Image de l’auteur.
OpenCode n’est pas lié à une famille de modèles. Via le registre Models.dev, il se connecte à plus de 75 fournisseurs, dont Anthropic, OpenAI, Google, DeepSeek, Groq, ainsi qu’à des modèles locaux via Ollama. Certains abonnements existants peuvent également être reliés, comme je l’indiquerai dans la section fonctionnalités.
Session terminal OpenCode affichant des modifications de fichiers. Image de l’auteur.
Bien qu’OpenCode ait démarré dans le terminal, il se présente désormais sous forme d’interface terminal (TUI), d’une application de bureau bêta pour macOS, Windows et Linux, et d’extensions pour éditeurs comme VS Code. La dernière version stable au moment d’écrire ces lignes est la v1.18.8.
Pourquoi OpenCode a été créé
Comme indiqué plus haut, OpenCode prend en charge des modèles de nombreux fournisseurs. Ce choix vient du fait que la qualité et les prix des modèles évoluent, et qu’un outil lié à un seul fournisseur laisse moins d’options aux utilisateurs.
La documentation précise qu’OpenCode n’est couplé à aucun fournisseur. Le registre Models.dev cité plus haut fournit les détails et les tarifs des modèles qu’OpenCode utilise.
Ce choix influe sur plus que la facturation. Les modèles diffèrent par leurs limites de contexte, leurs formats d’appels d’outils et leurs types d’entrées. OpenCode unifie ces différences sous une même interface. Un développeur peut changer de modèle dans un même projet sans migrer la session vers un autre outil.
L’équipe privilégie également les outils « terminal-first » que l’on peut inspecter. Les consignes de projet vivent dans un simple fichier nommé AGENTS.md. J’expliquerai plus loin comment OpenCode crée et utilise ce fichier.
Le projet officiel met en avant trois choix de conception. Le premier est le support des fournisseurs évoqué ci-dessus. Le second maintient les commandes principales dans le terminal. Le troisième sépare le client et le serveur. Cette distinction arrive juste après.
En janvier 2026, Anthropic a bloqué l’usage d’abonnements grand public Claude par des outils tiers via des canaux non officiels. OpenCode a alors ajouté d’autres options d’abonnement et utilisé sa propre passerelle. Les utilisateurs pouvaient toujours se connecter via d’autres fournisseurs.
Cet épisode explique pourquoi le choix du fournisseur occupe une telle place dans OpenCode. Pour voir ce que les utilisateurs en font, regardons maintenant une session.
Comment fonctionne OpenCode
OpenCode s’exécute sous forme de client et de serveur local. La TUI, l’app de bureau, les extensions d’IDE et le SDK communiquent tous avec ce serveur en HTTP. Le même serveur gère l’attachement à distance via opencode attach <url> et l’usage sans interface avec opencode serve.
Dans une session, l’agent lit les fichiers pertinents, peut ébaucher un plan, édite le code et exécute des commandes si nécessaire. Son intégration au Language Server Protocol (LSP) renvoie ensuite au modèle les diagnostics du compilateur et du linter afin qu’il réponde aux erreurs de type et de syntaxe.
Par exemple, une tâche peut commencer par glob ou grep pour localiser des fichiers. L’agent peut utiliser read pour les inspecter et edit pour modifier des lignes choisies. Il peut ensuite utiliser bash pour lancer un test ou une commande de build. La sortie alimente la requête suivante au modèle.
Je trouve la distinction Build/Plan plus claire en tant que commutateur d’autorisations. Build est le mode par défaut et peut lire, écrire et exécuter des commandes. Plan demande confirmation avant d’éditer des fichiers ou d’exécuter des commandes bash. Appuyer sur Tab permet d’alterner entre les deux.
Les contrôles d’autorisations s’appliquent lors de l’appel d’un outil. Un projet peut autoriser un outil, le bloquer ou demander une validation à chaque fois. Les règles peuvent aussi varier selon des motifs de commande. Une équipe peut, par exemple, autoriser les tests courants tout en demandant une approbation pour d’autres commandes shell.
Les sessions sont stockées localement sur disque dans le répertoire de données d’OpenCode. OpenCode compacte automatiquement les longues conversations. Les commandes /undo et /redo naviguent dans des instantanés de fichiers basés sur Git.
Fonctionnalités clés d’OpenCode
OpenCode regroupe ses fonctions principales en quatre volets : accès aux modèles, contexte de projet, exécution des tâches et usage local. Les sections ci-dessous expliquent ce que chaque volet change pendant une session de codage.
Prise en charge multi-modèles
Comme indiqué plus haut, OpenCode obtient sa liste de fournisseurs via Models.dev. En pratique, vous pouvez connecter un service hébergé, une plateforme cloud ou un endpoint compatible OpenAI. Les connexions GitHub Copilot et ChatGPT Plus/Pro évitent de gérer une clé API séparée.
Le choix du fournisseur ne signifie pas que tous les modèles se comportent de la même manière. L’usage des outils, les limites de contexte, le temps de réponse et le prix dépendent du modèle et du fournisseur retenus. Les appels à des modèles hébergés envoient également le contexte de code requis à ce fournisseur selon ses propres règles de données.
OpenCode propose également deux moyens optionnels d’accéder aux modèles. OpenCode Zen est une passerelle à l’usage avec une sélection de modèles. OpenCode Go est un abonnement à 5 $ le premier mois puis 10 $ par mois pour des modèles open-weight sélectionnés. Vous pouvez toujours fournir vos propres clés API. Les tarifs peuvent évoluer.
C’est le côté moins agréable : un outil gratuit peut quand même générer une facture côté fournisseur.
Travailler avec le contexte du dépôt
Exécutez /init et OpenCode génère un fichier AGENTS.md résumant la structure et les conventions du projet. Les équipes peuvent valider ce fichier afin que les sessions démarrent avec des consignes partagées.
Ce fichier peut inclure des commandes de test, des noms de dossiers, des règles de nommage et des notes sur le projet. Un AGENTS.md global peut contenir des consignes communes à plusieurs projets. Le fichier de projet porte les règles propres à un dépôt.
Les vérifications LSP mentionnées plus haut s’exécutent après les modifications. Le contexte du dépôt inclut aussi des références de fichiers : le symbole @ insère un fichier choisi dans une invite.
Exécuter des tâches de codage
Au-delà des agents Build et Plan décrits plus haut, OpenCode inclut des sous-agents pour les recherches en plusieurs étapes, l’analyse de codebase et la consultation de documentation externe. Des agents personnalisés peuvent avoir leur propre modèle, invite et permissions d’outils.
Chaque sous-agent fonctionne dans une session enfant, de sorte que ses messages ne saturent pas la session principale de la même façon. Un agent personnalisé peut être limité à la lecture des fichiers, se voir attribuer un modèle moins coûteux ou recevoir des consignes pour un type de tâche spécifique.
Model Context Protocol (MCP) ajoute des services externes via des serveurs définis dans opencode.json, et les vérifications d’autorisations décrites plus haut s’appliquent aussi aux outils qu’ils fournissent.
Passer de la planification aux modifications de code. Vidéo de l’auteur.
Le local-first (et ses limites)
Le terme « local-first » demande une nuance. Je ne l’interpréterais pas comme la promesse que rien ne quitte jamais la machine. Comme indiqué dans la section fournisseurs, OpenCode peut se connecter à Ollama. Cette configuration garde le code et les invites sur l’infrastructure locale. Les modèles hébergés, /share et OpenCode Zen envoient des données hors de la machine locale.
L’usage local dépend toujours du modèle. Les petits modèles peuvent renvoyer des appels d’outils invalides ou manquer des liens entre fichiers. Un serveur local a aussi besoin de suffisamment de mémoire pour le modèle choisi et d’un espace de contexte suffisant pour les fichiers envoyés à chaque requête.
Son système d’autorisations est un garde-fou de flux de travail, pas un bac à sable de sécurité. En mode serveur réseau, utilisez OPENCODE_SERVER_PASSWORD et liez-vous à localhost. Un problème antérieur d’exposition sans authentification a été corrigé, mais le mode serveur ne doit toujours pas être exposé publiquement sans authentification.
Architecture d’OpenCode
Comme indiqué plus haut, OpenCode sépare ses clients de son serveur local. Cette séparation influe sur la configuration et l’état stocké. L’API ajoute une autre façon d’utiliser le serveur.
Si vous prévoyez d’utiliser uniquement la TUI, vous pouvez ignorer les détails de l’API. Le paragraphe sur la configuration à la fin est celui que vous utiliserez.
Le serveur TypeScript + Bun communique avec les fournisseurs de modèles et exécute les outils. Il gère aussi l’état. Sa spécification OpenAPI 3.1 génère le package officiel @opencode-ai/sdk. Des scripts et clients personnalisés peuvent utiliser cette API documentée.
L’API couvre les sessions, messages, fichiers, fournisseurs, outils, agents et la configuration. C’est le même serveur que celui utilisé par les clients d’OpenCode. Un script peut créer une session ou envoyer un message sans piloter la TUI.
Clients OpenCode connectés à un même serveur. Image de l’auteur.
Les interfaces listées plus haut agissent comme clients : la TUI, l’app de bureau, l’extension d’IDE et opencode web. Toutes dialoguent avec le même processus serveur. Un autre appareil peut s’attacher à une session existante via ce processus.
Lancer opencode serve démarre le serveur sans la TUI habituelle. Lancer opencode web ajoute un client navigateur. Les deux commandes exigent une authentification si le serveur est accessible depuis un autre appareil.
La configuration vit dans un opencode.json ou opencode.jsonc au niveau du projet, avec repli global dans ~/.config/opencode/opencode.json. Elle contrôle les modèles, les permissions, les serveurs MCP et les agents personnalisés. Comme vu dans la partie flux de travail, l’historique des sessions et les journaux d’outils restent dans des fichiers locaux sauf si l’utilisateur les partage.
Flux de travail courants avec OpenCode
Les mêmes briques d’OpenCode couvrent plusieurs tâches logicielles courantes. Les exemples ci-dessous montrent où la relecture humaine reste essentielle.
Construire de nouvelles fonctionnalités
Avec le processus Plan vers Build décrit plus haut, un développeur peut demander une fonctionnalité et revoir les étapes proposées avant toute modification. Appuyer sur Tab fait ensuite passer la tâche en mode Build pour les changements de code et les tests.
Le plan peut être révisé avant toute modification de fichier. J’en profiterais pour cadrer la portée, nommer les fichiers à ne pas toucher ou ajouter des exigences de test.
Refactorer du code existant
Le même enchaînement Plan puis Build convient au refactoring. Le mode Plan peut identifier les dépendances et points d’appel avant que le mode Build applique les édits. Si le résultat est incorrect, /undo restaure l’instantané précédent. Il faut tout de même relire le diff : des tests au vert ne garantissent pas que toutes les interfaces publiques soient inchangées.
Déboguer des applications
Pour le débogage, OpenCode peut combiner une trace de pile à des informations de type fournies par le serveur de langage. Il peut proposer un correctif, rejouer les étapes à l’origine de l’erreur et vérifier le résultat. Sans étapes de reproduction claires, il peut seulement confirmer que le build passe ou que les tests existants sont au vert.
Écrire des tests
Comme vu plus haut, le mode Build peut éditer des fichiers et exécuter des commandes. Pour l’écriture de tests, cela signifie qu’il peut créer un test, lire le résultat puis effectuer une autre modification. Une suite complète apporte plus de retours mais prend plus de temps.
La qualité des tests doit toujours être validée par un humain. Un test généré peut dupliquer l’implémentation au lieu de vérifier le comportement attendu par les utilisateurs.
Comprendre de vastes bases de code
La section dépôt a expliqué comment /init crée des notes de projet. Après cette étape, une question comme « Comment fonctionne l’authentification ici ? » peut guider la recherche. Le sous-agent @general peut fouiller plusieurs parties du dépôt.
Des questions ciblées donnent généralement de meilleurs résultats que « Expliquez tout le dépôt ». Les références de fichiers avec @ peuvent encore affiner la recherche.
OpenCode vs autres agents de codage IA
Ces outils diffèrent par leur licence, le support de modèles, l’interface et la facturation. Je les compare sur ces points plutôt que de présenter un outil comme choix par défaut.
OpenCode vs Claude Code
Nous avons un article dédié à OpenCode face à Claude Code plus détaillé. Claude Code est propriétaire et s’appuie sur le modèle et le système de compte d’Anthropic. OpenCode utilise la licence MIT et laisse l’utilisateur choisir un fournisseur. Il donne également accès à son code source et à sa configuration. Comme indiqué dans l’historique, les abonnements grand public Claude ne fonctionnent plus via OpenCode : l’usage de Claude requiert une clé API Anthropic facturée à l’usage.
Les deux outils peuvent lire des fichiers, les modifier, exécuter des commandes et utiliser des serveurs MCP. L’accès aux modèles est la différence principale : Claude Code reste dans l’écosystème Anthropic, tandis qu’OpenCode peut se connecter à d’autres fournisseurs ou à un endpoint local.
OpenCode vs Cursor
Cursor est un IDE basé sur VS Code qui propose aussi des agents en CLI et dans le cloud. Son flux principal garde suggestions, modifications de fichiers et actions d’agent dans l’éditeur. OpenCode s’appuie sur le terminal, le bureau et les éditeurs cités plus haut. Cursor fonctionne via des formules d’abonnement payantes. Le logiciel OpenCode est gratuit, mais vous pouvez payer des jetons au fournisseur de modèle. Les différences majeures : l’interface de travail, le choix de modèle et la méthode de facturation.
Cursor inclut aussi la complétion en ligne pendant la saisie. OpenCode se concentre sur des tâches confiées à un agent et ne remplace pas cette forme de complétion. Certains développeurs utiliseront les deux types d’outil selon le besoin.
OpenCode vs Cline
Cline est un agent open source BYOK avec interfaces VS Code et CLI. Il dispose aussi d’un client JetBrains, non open source au moment d’écrire ces lignes. Cline comme OpenCode prennent en charge MCP et permettent de définir des règles d’approbation. Cline place ses contrôles dans une barre latérale de l’éditeur. OpenCode utilise des sessions terminal pouvant tourner indépendamment de l’éditeur. Le choix dépend surtout de l’endroit où le développeur souhaite relire et approuver les changements.
Cline est sous licence Apache 2.0. OpenCode utilise la licence MIT. Les deux autorisent la relecture et la modification du code source, mais leurs interfaces et fichiers de configuration diffèrent.
Aider et Codex CLI sont également des agents de codage orientés terminal. OpenCode couvre le terminal, le bureau et l’IDE dans un même projet et prend en charge des modèles de plusieurs fournisseurs.
Installer et démarrer avec OpenCode
Le script d’installation officiel fonctionne sur la plupart des systèmes de type Unix. Il offre une façon d’installer l’outil en ligne de commande :
La commande télécharge le binaire OpenCode et l’ajoute à l’environnement utilisateur. Un gestionnaire de paquets peut mieux convenir si les mises à jour sont gérées avec le reste du système.
curl -fsSL https://opencode.ai/install | bashLes options via gestionnaire de paquets incluent npm i -g opencode-ai@latest, brew install anomalyco/tap/opencode sur macOS et Linux, et scoop install opencode ou choco install opencode sur Windows. Une application de bureau est disponible pour macOS, Windows et Linux. Sous Windows, la documentation OpenCode recommande WSL car certaines fonctions de système de fichiers et de shell y fonctionnent mieux.
L’installation n’inclut pas l’accès à un modèle. La première session a quand même besoin d’un des modes d’accès présentés dans la section multi-modèles.
Installer OpenCode avant de créer les consignes de projet. Vidéo de l’auteur.