• OpenCode ? Mais… Pourquoi ?
• Prise en main d’OpenCode
• Mon retour d’expérience, et ce qui m’a aidé

Cela fait maintenant près de 4 ans que je suis devenu Product Owner. Avant cela, j’étais développeur, et j’avais mes petites habitudes…

• Développement sous Vim, avec plein de plugins pour la navigation de fichier, l’intégration Git, la validation de code, etc.
• Mes petits environnements Python et Javascript pour la qualité de code.
• Mes pipelines avec tests unitaires, etc.
• …

Bref, nous n’allons pas passer en revue tout ce que j’ai déjà décrit dans mes précédents articles, notamment R2PL.

Quatre ans, c’est long. Surtout dans le monde des « nouvelles » technologies (plus si nouvelles, vu qu’on nage dedans depuis plus d’une génération). Et c’est encore pire, quand nous voyons tout le chamboulement apporté par l’intelligence artificielle : aujourd’hui, un développeur qui n’est pas capable d’orchestrer des agents IA ou de piloter son développement sans Cursor, Claude Code ou CodeX sera forcément pénalisé. Le nombre même d’articles d’experts sur le sujet conforte cette opinion :

• « À Anthropic, par exemple, les ingénieurs ont tellement adopté Claude Code qu’aujourd’hui, près de 90% du code de Claud Code est écrit par Claud Code lui-même. » (Addy Osmani, dans My LLM coding workflow going into 2026)
• « Toute mini-intégration OpenAI sur un side project est valorisée car chaque startup veut intégrer de l’IA. » (The Product Crew - Devs : Le Playbook pour réussir tes entretiens tech)
• Un article du blog de Github mentionne que « plus de 11 millions de dépôts public utilisent les SDK LLM » : 80% des nouveaux développeurs utilisent Copilot dès leur première semaine.
• …

Nous pourrions continuer longtemps cette liste, mais ce n’est plus un mystère.

Alors à mon petit niveau, j’ai voulu tester. Et pour tester, je cherchais une solution un peu particulière, et mes recherches m’ont mené vers OpenCode.

§OpenCode ? Mais… Pourquoi ?

Cursor, Claude Code et CodeX sont réputés dans les milieux de développeurs. Cependant, je voulais débuter sur une solution simple, sécurisée et peu coûteuse.

OpenCode offre la possibilité d’exécuter des modèles en local : en alternative aux LLM (Large Language Model), il est possible d’utiliser des SLM (Small au lieu de Large). Ceux-ci sont conçus pour s’exécuter en local, sur notre propre machine (d’ailleurs, on les appelle parfois des modèles locaux). Les SLM offrent ainsi quelques avantages :

• Une meilleure maîtrise des coûts, car il n’est pas nécessaire d’investir dans des API qui débitent notre compte en fonction du nombre de tokens que nous échangeons avec l’IA.
• Une meilleure sécurité, car oui, si le modèle s’exécute en local, le code traité reste en local. Ainsi, nous réduisons drastiquement le risque de fuite de données, et si notre confiance envers les ténors de l’IA est limitée, OpenCode devient un allié très attractif.

Bon, manque de pot, mon ordinateur manque de puissance pour ça… La plupart des SLM demandent une bonne carte graphique, et 8Go de RAM est le strict minimum… Si rien d’autre ne tourne sur la machine (en tout cas, pas de navigateur web : j’ai déjà crashé mon petit Linux Mint plusieurs fois, comme ça).

OpenCode offre une certaine indépendance : il ne permet pas seulement d’utiliser des SLM, mais aussi n’importe quel LLM. Si nous voulons utiliser Chat GPT, Claude, Grok, Mistral (cocorico), ou n’importe quel autre, c’est possible.

OpenCode permet de faire des économies, même si je n’utilise pas de modèle local, OpenCode n’impose pas d’abonnement fixe ou des jetons API coûteux, et nous pouvons choisir des LLM en ligne peu coûteux… Voire gratuit.

OpenCode offre donc une certaine liberté, mais nécessite un peu plus de travail de configuration. D’autres parts, il faut être conscient que les modèles locaux peuvent s’essouffler sur des contextes volumineux, et n’offrent pas nativement de fonctionnalités avancées, comme l’indexation automatique du projet, qui permet à des solutions comme Cursor de retrouver rapidement n’importe quelle information du projet.

§Prise en main d’OpenCode

La page d’accueil d’OpenCode est claire, l’installer est très rapide, mais se fait en ligne de commande :

curl -fsSL https://opencode.ai/install | bash
# et pour ceux qui ont NPM :
npm i -g opencode-ai

Mais rassurez-vous : OpenCode lui-même peut s’utiliser autant en ligne de commande que via son interface graphique (personnellement, j’ai un petit faible pour la CLI).

Lorsque vous démarrez OpenCode pour la première fois, il se passe un truc magique : il propose de base quelques modèles gratuits, en ligne (ils sont disponibles dans l’option « OpenCode Zen ». Alors habitué à Grok, j’ai rapidement testé « Grok Code Fast 1 »).

Il est donc possible de démarrer instantanément et faire nos premiers tests.

L’interface nous propose deux modes :

• Le mode Plan est interactif et nous permet de définir les spécifications de ce que nous voulons ensuite implémenter ;
• Le mode Build, à son tour, sert à exécuter les instructions sur notre système. Et ça va des commandes Bash jusqu’aux manipulations du code.

De la sorte, j’ai pu tester en moins d’une heure un premier petit script en Python : J’ai demandé à OpenCode de me créer un agent capable de récupérer l’état de ma pipeline de CI (sur Gitlab), de récupérer les logs d’un job qui aurait échoué, d’investiguer les erreurs, pour ensuite les corriger.

Tout cela m’a pris moins d’une heure. OpenCode m’a généré un code fonctionnel dès la première itération : Pour cela, je lui avais fourni des identifiants de pipeline et de jobs, avec les informations qu’il devait être en mesure de retrouver (succès ou échec, avec accès aux logs du job), et il m’a rendu la main une fois que l’API renvoyait bien les données des jobs.

Bon, j’ai vu après coup que j’aurais pu intégrer le MCP de Gitlab (« Model Context Protocol », standard pour connecter une application externe à une IA), mais ce n’est pas trop grave, c’était pour l’exercice…

Si vous souhaitez aller plus loin dans la prise en main d’OpenCode, le quickstart est disponible en français.

§Mon retour d’expérience, et ce qui m’a aidé

Ce n’est pas pour rien que nous avons choisi de créer un agent capable de récupérer l’état de ma pipeline de CI… Grâce à ça, OpenCode s’est vu forcé de lire et traiter les erreurs remontées par mes jobs. Ceux-ci contiennent tous nos checks de qualité :

• pylint pour s’assurer du respect des normes de codage (comme PEP8) ;
• mypy pour détecter des erreurs de typage avant l’exécution du code via les annotations ;
• bandit en mode intransigeant pour forcer un style strict et cohérent au code.

OpenCode a ainsi nettoyé le code généré de manière efficace : il a itéré jusqu’au moment où tous les jobs sont passés au vert, avant de considérer son travail comme satisfaisant.

Avant même son premier commit, OpenCode avait déjà été confronté à notre configuration de pre-commit. Celle-ci exécute Black pour assurer une sortie déterministe et des différences Git minimales. Cette configuration a imposé à OpenCode un minimum de lisibilité avant tout commit.

Cette expérience reste modeste : j’ai utilisé un modèle gratuit (Grok Code Fast 1), et donc pas très « intelligent ». Du coup j’ai dû lui détailler pas mal de choses, car il n’a pas été chercher de lui-même de solution optimisée (par exemple, il n’a pas tenté de récupérer une bibliothèque comme GitPython pour interagir avec Git, ou d’investiguer le MCP de Gitlab). Pourtant, ce test rapide illustre bien la puissance d’un développeur expérimenté et bien outillé.

Pour ma part, je continuerai d’utiliser OpenCode sur mes projets (mais avec une machine plus puissante, dès que possible).

Pour en savoir plus, nous vous proposons les ressources suivantes :

• Mon article R2PL
• Mon article sur l’automatisation de la qualité de code)
• Vous pouvez également retrouver le code source de mes pipelines git, et le code généré pour l’agent, sur Framagit.

NB : à la date de mise au propre de cet article (11 mars 2026), Grok Code Fast 1 n’est plus gratuit.