OpenCode — retour d'expérience 4 mois en usage quotidien (fin 2025 – début 2026)
L'outil qui colle le mieux à un workflow Neovim/terminal en multi-provider : architecture client/serveur, zéro dépendance IDE, aucun lock-in. Le 9/10 reflète ce qu'OpenCode promet — et il le tient toujours. Si je ne l'utilise plus au quotidien, c'est que j'ai choisi de payer le lock-in d'un écosystème intégré, pas parce qu'OpenCode a démérité.
Points forts
- + TUI natif en Go avec navigation vim-like — s'intègre sans friction dans un workflow Neovim/tmux
- + Multi-provider complet : Anthropic, OpenAI, Google Gemini, Groq, Ollama (local), OpenRouter — aucun lock-in
- + Architecture client/serveur : fonctionne en remote via SSH sans configuration supplémentaire
- + 100% open-source MIT — le code est lisible, le modèle de données est transparent
- + Binaire Go unique, pas de node_modules, démarrage en <1s
- + Mode non-interactif pour scripting et CI/CD
- + Custom commands en Markdown — les workflows répétitifs deviennent des commandes réutilisables
- + Gestion multi-sessions parallèles — plusieurs agents sur des tâches simultanées
Limites
- − LSP intégration limitée — ne lit pas nativement les diagnostics de ton LSP Neovim, il faut les lui passer manuellement ou via un MCP server
- − Pas de marketplace de modes comme Kilo Code — les custom commands sont puissantes mais demandent un investissement initial
- − Le TUI peut être déroutant les 3 premiers jours si tu viens d'un outil GUI — la courbe d'apprentissage existe
- − Documentation encore partielle sur certains edge cases (multi-session avancé, configuration per-project)
- − Sur Windows, l'expérience est moins fluide qu'en Linux/macOS
Mise à jour juillet 2026 : la suite de l’histoire
OpenCode n’est plus mon agent quotidien : je suis revenu à Claude Code (abonnement Max) en mai 2026 — pour l’écosystème intégré, pas parce qu’OpenCode a failli. Tout ce que cette review documente reste vrai, et OpenCode reste ma sortie de secours multi-provider testée. Le raisonnement complet de l’aller-retour est dans Anthropic, le Apple de l’IA.
Contexte de test
Version testée : OpenCode ~0.3.x (octobre 2025 → février 2026). Usage quotidien sur un projet Symfony 7 + TypeScript/React d’environ 80k lignes déployé sur GKE. Stack de dev : Neovim + tmux + SSH Mac → serveur Ubuntu. OpenCode a remplacé Claude Code dans ce workflow d’octobre 2025 à début 2026, après 2 mois de comparaison en parallèle.
Ce qu’OpenCode fait réellement
OpenCode est un agent de coding qui s’exécute dans le terminal. Il lit des fichiers, modifie du code, exécute des commandes bash, et dialogue avec toi via un TUI (Terminal User Interface) construit avec Bubble Tea en Go.
Ce qui le distingue concrètement :
L’architecture est client/serveur. Le serveur OpenCode tourne en background, le TUI est le client. Ça signifie que tu peux attacher et détacher des sessions tmux sans perdre l’état d’une conversation en cours — exactement comme screen ou tmux pour les processus shell.
La navigation est vim-like. j/k pour naviguer, / pour chercher, q pour quitter. Si tu vis dans Neovim, tu es dans ton contexte naturel dès le premier lancement.
Le multi-provider est natif et trivial. Un seul fichier de config, plusieurs providers disponibles. Changer de modèle prend 3 secondes.
// ~/.config/opencode/config.json
{
"providers": {
"anthropic": { "apiKey": "sk-ant-..." },
"google": { "apiKey": "AI..." },
"openrouter": { "apiKey": "sk-or-..." }
},
"model": "anthropic/claude-sonnet-4-5"
}Ce qui fonctionne
Le workflow SSH. OpenCode installé sur le serveur de dev, lancé depuis la machine locale via SSH + tmux. Aucune config supplémentaire, aucun tunnel, aucune extension IDE. C’est le premier outil de cette catégorie qui fonctionne vraiment bien dans un setup remote.
Les custom commands. Des fichiers Markdown qui définissent des workflows réutilisables. En 4 mois, on a construit une bibliothèque de commandes pour le projet :
# .opencode/commands/new-api-endpoint.md
Crée un endpoint API Platform pour l'entité {entity}.
- Resource class dans src/ApiResource/{entity}Resource.php
- Tests dans tests/ApiResource/{entity}ResourceTest.php
- Fixture de test dans fixtures/{entity}Fixtures.php
Respecte les conventions du projet décrites dans CLAUDE.md.Le rapport qualité/coût. Comparé à Claude Code (mono-provider Anthropic), la possibilité de router les tâches simples vers DeepSeek ou Gemini Flash réduit les coûts de 60-70% sans impact notable sur la qualité des tâches courantes.
La transparence. Le code est MIT, lisible, et les token counts sont affichés en temps réel. On sait exactement ce qu’on consomme.
Ce qui ne fonctionne pas
L’intégration LSP. OpenCode ne lit pas les diagnostics en temps réel depuis le LSP Neovim. Quand il y a des erreurs de type ou des imports manquants, il faut les lui communiquer manuellement ou lancer les tests pour qu’il les voie. Kilo Code est meilleur sur ce point via son intégration VS Code.
Le manque de modes préconfigurés. Kilo Code arrive avec des modes “Architect”, “Coder”, “Debugger” prêts à l’emploi. Avec OpenCode, il faut construire ces modes soi-même via les custom commands. C’est plus flexible à terme, mais l’investissement initial est réel — 2-3 heures pour un setup sérieux.
La documentation. Elle est suffisante pour démarrer, insuffisante pour les cas avancés. On finit souvent à lire le code source ou à demander à la communauté GitHub.
Pour qui ?
Le profil naturel d’OpenCode est le dev qui passe ses journées dans le terminal : Neovim/Vim/Emacs + tmux, ou un setup remote/SSH. L’absence de dépendance IDE est à la fois son avantage principal et sa limite — si tu travailles principalement dans VS Code, Kilo Code sera plus naturel et plus riche out-of-the-box.
Alternatives
Claude Code est plus simple à démarrer mais limite au provider Anthropic. Kilo Code offre plus de fonctionnalités out-of-the-box pour les workflows VS Code. Cursor est l’option IDE-first la plus mature si le terminal n’est pas ton environnement naturel.
Recommandé pour
- ✓Dev terminal-first : Neovim, Vim, Emacs, tmux
- ✓Setup remote / SSH — un seul binaire à installer côté serveur
- ✓Ceux qui veulent changer de provider LLM selon la tâche sans changer d'outil
- ✓Workflows où le coût API est une variable de décision
- ✓Équipes qui veulent partager des custom commands via Git
Déconseillé pour
- ✗Utilisateurs IDE-first sans confort CLI — Kilo Code ou Cursor seront plus naturels
- ✗Ceux qui ont besoin d'un marketplace de plugins prêts à l'emploi immédiatement
- ✗Windows (pas impossible, juste moins fluide)
Questions fréquentes
- OpenCode est-il vraiment gratuit ?
- Le logiciel est gratuit (MIT). Tu paies directement l'API du provider LLM que tu choisis. Avec Claude Sonnet 4.5 via l'API Anthropic, compte 15-30$/mois pour un usage quotidien intense. Avec DeepSeek ou GLM, ça tombe à 3-8$/mois. OpenCode ne prend aucune marge sur les tokens.
- Comment configurer OpenCode avec Neovim ?
- La configuration de base prend 10 minutes : installer le binaire, créer ~/.config/opencode/config.json avec tes credentials API, lancer `opencode` dans un split tmux. Pour l'intégration plus poussée (commandes custom, accès au buffer courant), le guide dédié couvre l'ensemble du setup.
- Peut-on utiliser OpenCode en équipe ?
- Oui. Les custom commands et le fichier de configuration projet (AGENTS.md / CLAUDE.md) se versionnent dans Git, ce qui partage les conventions de l'agent avec toute l'équipe. Chaque dev garde ses credentials API séparés mais les workflows sont partagés.
- OpenCode vs Kilo Code : lequel choisir ?
- OpenCode si tu travailles principalement en terminal. Kilo Code si tu préfères VS Code et veux un marketplace de modes et MCP servers prêt à l'emploi. Les deux sont multi-provider et open-source. Ce n'est pas un choix définitif — certains utilisent les deux selon le contexte.