Après avoir passé de longues heures à tester différents assistants de développement, je me suis souvent heurté aux mêmes limites : la dépendance vis-à-vis d’un seul fournisseur cloud, la confidentialité de mon code et les coûts d’utilisation qui grimpent à toute vitesse. C’est ce qui m’a poussé à m’intéresser de près à OpenCode, un agent de développement IA gratuit, open-source (sous licence MIT) et totalement agnostique en matière de modèles.
Au début, je craignais que la configuration d’un agent local soit complexe. Pourtant, l’outil s’est avéré particulièrement souple. Il s’exécute dans de nombreux environnements (que ce soit via une interface de terminal (TUI), une application de bureau, ou des extensions pour VS Code et Cursor) et me laisse le choix du moteur d’intelligence artificielle.
Ce qu’il faut retenir d’OpenCode
- Indépendance totale : Il s’intègre avec plus de 75 fournisseurs de modèles, qu’ils soient commerciaux ou locaux.
- Comportement d’agent : Contrairement à un simple outil de chat, il dispose de modes “Plan” (conception) et “Build” (écriture et exécution de commandes de test).
- Confidentialité stricte : Associé à des modèles locaux, il garantit que mon code ne quitte jamais ma machine de travail.
- Extensibilité : Il prend en charge le Language Server Protocol (LSP) et le Model Context Protocol (MCP) pour se connecter à mes outils externes.
Pourquoi j’utilise OpenCode plutôt que Claude Code
Le choix s’est imposé d’abord par pragmatisme financier et technique. Claude Code est un excellent outil, mais il est conçu uniquement pour les modèles d’Anthropic et impose de faire transiter l’intégralité du code par leurs serveurs payants. Pour des projets d’entreprise soumis à des règles de conformité strictes (ou tout simplement pour éviter des factures d’API imprévues), ce fonctionnement pose problème.
Voici un comparatif rapide basé sur mes observations :
| Fonctionnalité | OpenCode | Claude Code |
|---|---|---|
| Modèles supportés | Plus de 75 fournisseurs et modèles locaux | Uniquement les modèles Anthropic |
| Capacité locale / hors-ligne | Oui (via Ollama ou LM Studio) | Non (dépend du cloud) |
| Modèles de tarification | 0 $ (local) ou 10 $ / mois (cloud avec OpenCode Go) | Abonnements de 20 $ à plus de 200 $ / mois |
| Interfaces disponibles | TUI (Terminal), App de bureau, Extensions IDE | Principalement axé Terminal (TUI) |
| Configuration d’équipe | Fichier neutre AGENTS.md | Fichier CLAUDE.md lié à leur écosystème |
Certes, Claude Code conserve une légère avance si vous avez le budget pour utiliser exclusivement Claude Sonnet et Opus, car Anthropic optimise ses modèles spécifiquement pour son interface de commande. Mais pour la liberté de choix, la maîtrise des coûts et la confidentialité, OpenCode me semble bien plus adapté.
Guide d’installation : Connecter OpenCode à un modèle local avec Ollama
Je préfère souvent exécuter mes agents localement pour m’assurer que mes données de développement ne s’échappent pas. Cette configuration n’engendre aucun frais informatique récurrent. Voici comment je procède.
Étape 1 : Installer l’application OpenCode
Pour l’interface en ligne de commande (TUI), j’ouvre mon terminal et je lance la commande d’installation globale :
# Via curl (macOS/Linux)
curl -sSL https://opencode.ai | bash
# Ou via npm si vous utilisez Node.js
npm install -g @opencodeai/cli(N’oubliez pas de redémarrer votre terminal pour que le chemin système soit bien pris en compte).
Si vous préférez une interface graphique classique, vous pouvez simplement aller sur le site officiel de OpenCode, cliquer sur “Download Now” et lancer l’installateur correspondant à votre système d’exploitation (Windows, macOS ou Linux).
Étape 2 : Installer Ollama et récupérer un modèle de code
Ollama sert de moteur local pour exécuter les modèles d’IA sur mon ordinateur. Après l’avoir téléchargé sur son site officiel, je récupère un modèle optimisé pour le développement (comme Qwen 2.5 Coder ou DeepSeek Coder) :
ollama pull qwen2.5-coder:7bJe m’assure qu’Ollama tourne bien en tâche de fond (je peux le vérifier en ouvrant l’adresse http://localhost:11434 sur mon navigateur internet).
Étape 3 : Lier OpenCode à Ollama
Il y a deux approches possibles pour lier l’agent au modèle local.
La méthode automatique (la plus rapide via le terminal) :
ollama run qwen2.5-coder:7b --init-opencodeCette commande configure automatiquement les paramètres de connexion locale dans mon fichier ~/.config/opencode/opencode.json et lance directement l’interface d’OpenCode.
La méthode manuelle (idéale pour l’application de bureau) :
- J’ouvre l’application de bureau OpenCode.
- Je me rends dans l’onglet “Settings” (le menu hamburger) puis “Providers”.
- Je clique sur “Connect Provider” et je sélectionne “Custom / Ollama”.
- J’indique l’adresse locale :
http://localhost:11434(ouhttp://localhost:11434/v1). - Dans la section des modèles, je saisis le nom exact de mon modèle (par exemple
qwen2.5-coder:7b) et je le définis par défaut.
Étape 4 : Lancer et initialiser l’agent
Je me déplace dans le dossier de mon projet de développement :
cd chemin/vers/mon/projetPuis je démarre l’agent :
opencodePour que l’agent comprenne bien l’architecture de mon projet, je lance l’initialisation en tapant la commande interne suivante directement dans l’interface de l’outil :
/initCela génère un fichier de contexte nommé agents.md. Je peux ensuite demander à l’agent de modifier des fichiers ou de lancer des commandes de test localement.
Créer mes propres commandes et compétences personnalisées
Pour adapter l’agent à mes routines quotidiennes, je crée des raccourcis et j’oriente la manière dont le modèle interagit avec mes fichiers de code. OpenCode permet de faire cela de deux façons : les commandes personnalisées (que je déclenche avec un /) et les compétences d’agent (que l’IA charge d’elle-même quand elle en a besoin).
Méthode A : Définir des commandes rapides dans opencode.json
Je peux ajouter des macros directement dans mon fichier de configuration centralisé opencode.json. Voici un exemple pour lancer une analyse de couverture de tests :
{
"command": {
"test-coverage": {
"template": "Run the full test suite with coverage report. Focus on any failing tests and suggest local fixes.",
"description": "Run tests with coverage analysis",
"agent": "build"
}
}
}Désormais, taper /test-coverage dans l’interface de mon terminal va lancer l’évaluation demandée.
Méthode B : Créer des fichiers Markdown (recommandé pour les commandes plus complexes)
Je trouve plus lisible de créer des fichiers Markdown individuels dans le dossier de mon projet (.opencode/commands/) ou de manière globale dans ~/.config/opencode/commands/. Le nom du fichier définit la commande (par exemple, review.md devient la commande /review).
Voici à quoi ressemble mon fichier .opencode/commands/review.md :
---
description: Analyze a file and check for performance issues.
agent: plan
---
Review the component file provided in @src/components/Button.tsx.
Check carefully for performance bottlenecks and suggest code optimizations.Je peux me servir de syntaxes spécifiques pour enrichir mes prompts :
- @nom_de_fichier : pour charger et lire le contenu d’un fichier spécifique.
- !commande_shell : pour injecter des résultats du terminal (par exemple
!git log --oneline -5pour fournir l’historique récent à l’agent). - $ARGUMENTS : pour passer des paramètres variables lors de l’appel d’une commande (comme
$1,$2).
Gérer les compétences (Skills) de l’agent IA
Les compétences sont des instructions spécifiques que l’IA décide d’activer à la demande lorsqu’elle fait face à un problème ciblé. Elles doivent se trouver dans un sous-dossier portant le nom de la compétence, contenant un fichier SKILL.md.
Voici un exemple de structure pour un projet : .opencode/skills/sql-optimize/SKILL.md
---
name: sql-optimize
description: Optimizes slow SQL queries, indices, and schema design for PostgreSQL.
license: MIT
compatibility: opencode
---
## What I do
- Audit SQL queries for missing indices or inefficient joins.
- Rewrite queries using optimal EXPLAIN ANALYZE execution paths.
- Enforce strict database naming conventions.
## When to use me
Use this skill whenever the developer asks to optimize an active database query or when refactoring files located inside the `/db` or `/migrations` directories.Je peux contrôler la sécurité en autorisant ou en bloquant l’exécution de ces compétences de manière automatique ou conditionnelle dans mon fichier opencode.json :
{
"permission": {
"skill": {
"sql-optimize": "allow",
"internal-*": "deny",
"experimental-*": "ask"
}
}
}Avec le paramètre ask, l’outil me demande une confirmation explicite dans mon terminal avant de lancer la compétence (ce qui m’évite de mauvaises surprises sur mes bases de données de test).
Cas pratique 1 : Automatiser la relecture et la rédaction de mes messages de commits Git
J’ai configuré une commande personnalisée qui analyse mes modifications Git prêtes à être commitées (staged), vérifie qu’aucun secret ou clé d’API ne s’y cache, puis me génère un message de commit conforme au standard Conventional Commits.
Pour cela, j’ai créé le fichier .opencode/commands/gitlint.md :
---
description: Generates a Conventional Commit message from staged git changes and audits for privacy leaks.
agent: plan
---
You are an expert Git hook and release manager.
First, look at the output of the current staged git diff:
!git diff --cached
Using this diff, perform the following tasks:
1. Scan the diff to ensure no private API keys, secrets, or unencrypted `.env` data are being accidentally committed. If found, stop and warn me.
2. Generate a valid commit message strictly matching the **Conventional Commits 1.0.0** specification (e.g., `feat(scope): description` or `fix(abc): short summary`).
3. Ensure the first line is under 72 characters and uses the imperative mood.
Output ONLY the final commit message block. Do not wrap it in additional markdown code fences.Pour l’exécuter, j’ajoute mes fichiers au suivi Git de manière habituelle, puis je lance la commande dans OpenCode :
git add .
opencode
# Dans l'interface de l'agent, je saisis :
/gitlintCas pratique 2 : Connecter des outils tiers grâce au protocole MCP
Le protocole MCP (Model Context Protocol) permet à l’agent local d’agir sur mon environnement plutôt que de simplement me répondre par du texte. Je l’utilise par exemple pour lui donner accès à mon système de fichiers ou pour interagir avec mon compte GitHub.
J’ouvre mon fichier de configuration globale (~/.config/opencode/opencode.json) pour déclarer ces serveurs MCP :
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/chemin/vers/mon/dossier/autorise"
]
},
"github": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-github"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "votre-jeton-ici"
}
}
}
}Après avoir redémarré ma session d’agent, l’assistant détecte ces passerelles et je peux lui demander directement :
« Analyse l’architecture de mon projet avec l’outil filesystem pour localiser mes configurations serveur principales. »
« Parcours les tickets ouverts sur mon projet GitHub et écris un correctif pour corriger le problème numéro 12. »
Créer mon propre serveur MCP local pour surveiller mes ressources système
Pour éviter de lancer des compilations ou des builds Docker trop lourds quand mon ordinateur est saturé de tâches (ce qui m’arrive plus souvent qu’à mon tour…), j’ai développé un petit service local MCP en Node.js/TypeScript. Il expose un outil appelé get_system_metrics à mon instance OpenCode.
Étape 1 : Initialiser le projet
mkdir opencode-mcp-server
cd opencode-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk
npm install -D typescript @types/node tsxJe génère ensuite mon fichier de configuration TypeScript (tsconfig.json) :
{
"compilerOptions": {
"target": "ES2022",
"module": "NodeNext",
"moduleResolution": "NodeNext",
"esModuleInterop": true,
"strict": true,
"outDir": "./dist"
}
}Étape 2 : Écrire le serveur MCP (src/index.ts)
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { ListToolsRequestSchema, CallToolRequestSchema } from "@modelcontextprotocol/sdk/types.js";
import os from "os";
// 1. Déclarer le serveur et ses métadonnées
const server = new Server(
{
name: "my-local-metrics-server",
version: "1.0.0",
},
{
capabilities: {
tools: {},
},
}
);
// 2. Présenter l'outil disponible à l'agent
server.onRequest(ListToolsRequestSchema, async () => {
return {
tools: [
{
name: "get_system_metrics",
description: "Retrieves the local machine's available memory, total memory, and CPU count.",
inputSchema: {
type: "object",
properties: {},
},
},
],
};
});
// 3. Exécuter l'action demandée par l'agent
server.onRequest(CallToolRequestSchema, async (request) => {
if (request.params.name === "get_system_metrics") {
const totalMem = (os.totalmem() / (1024 ** 3)).toFixed(2);
const freeMem = (os.freemem() / (1024 ** 3)).toFixed(2);
const cpus = os.cpus().length;
return {
content: [
{
type: "text",
text: `System Metrics:\n- Free Memory: ${freeMem} GB\n- Total Memory: ${totalMem} GB\n- CPU Cores: ${cpus}`,
},
],
};
}
throw new Error(`Tool ${request.params.name} not found.`);
});
// 4. Lancer la communication via les entrées/sorties standards (stdio)
async function main() {
const transport = new StdioServerTransport();
await server.connect(transport);
console.error("Local Metrics MCP Server running on stdio!");
}
main().catch((error) => {
console.error("Server crashed:", error);
process.exit(1);
});Étape 3 : Associer le serveur MCP local à mon fichier opencode.json
J’ajoute mon script de métriques à la configuration système d’OpenCode pour lui indiquer comment le lancer :
{
"mcpServers": {
"my-metrics-tool": {
"command": "npx",
"args": [
"tsx",
"/chemin/absolu/vers/votre/opencode-mcp-server/src/index.ts"
]
}
}
}Après avoir relancé l’agent, je peux lui demander : « Regarde mes ressources système et dis-moi si j’ai assez de mémoire disponible pour lancer un conteneur Docker. » L’agent appellera mon script TypeScript et adaptera sa stratégie en fonction de la mémoire vive restante.
Comprendre le modèle de tarification d’OpenCode
Le logiciel de base est entièrement gratuit et libre d’accès sous licence MIT. Néanmoins, un outil d’agent de développement nécessite une puissance de calcul pour faire tourner ses modèles IA. La question du coût dépend donc uniquement de l’infrastructure que l’on décide de connecter à l’agent.
Voici les différentes options disponibles que j’ai identifiées pour alimenter l’agent en calcul :
| Option | Coût logiciel | Coût du modèle IA | Idéal pour |
|---|---|---|---|
| Totalement local | 0 $ | 0 $ (sur sa propre machine) | Ceux qui cherchent une confidentialité totale et aucun coût mensuel. |
| Zen Free Tier | 0 $ | 0 $ (modèles gratuits distants) | Les développements ponctuels s’appuyant sur des modèles hébergés gratuits (ex: DeepSeek V4 Flash Free, MiniMax M2.5, Laguna S, Nemotron 3 Ultra). |
| Abonnements existants | 0 $ | Inclus dans vos frais actuels | Les utilisateurs disposant déjà d’un abonnement ChatGPT Plus ou GitHub Copilot actif à lier à l’outil. |
| Bring Your Own Key (BYOK) | 0 $ | Facturation au jeton (token) | Les développeurs utilisant des clés d’API commerciales payantes (Anthropic Claude, OpenAI GPT-4o, Google Gemini). |
| OpenCode Go | 0 $ | Abonnement fixe de 10 $ / mois (5 $ le premier mois) | Accéder à des modèles distants haut de gamme (DeepSeek V4 Pro, Grok 4.5, Qwen Max) à tarif fixe sans configurer plusieurs comptes cloud individuels. |