Les éditeurs pour coder avec l'IA en 100% local : Cline, OpenCode & compagnie
Choisir un modèle de code local n'est que la moitié du chemin. Le modèle est le moteur ; il vous faut encore un poste de pilotage — l'éditeur ou l'agent qui lit vos fichiers, propose des changements et les applique. La bonne nouvelle : vous n'êtes pas obligé de confier ce rôle à un produit cloud. Tout un écosystème d'outils se branche désormais directement sur un serveur Ollama local, de sorte que votre code, vos prompts et votre contexte ne quittent jamais votre machine.
Ce guide passe en revue les meilleurs d'entre eux, avec une configuration concrète pour chacun. Ils se répartissent en trois groupes : les extensions d'IDE, les agents terminal et une catégorie hybride pour le cas le plus surprenant — faire tourner Claude Code d'Anthropic sur un modèle local.
Tout ce qui suit suppose que vous avez déjà installé Ollama et récupéré un modèle capable de coder.
La voie IDE : les extensions VS Code
Si vous vivez dans VS Code, vous ne changez pas d'éditeur — vous ajoutez une extension qui parle à Ollama.
Cline — l'agent polyvalent
Cline est l'option local-first la plus complète. C'est une extension agentique : elle ne se contente pas d'autocompléter, elle planifie un changement sur plusieurs fichiers, les édite, lance des commandes et itère — le tout piloté par votre modèle local. Elle prend en charge Ollama nativement, fonctionne dans VS Code comme dans JetBrains et parle MCP, ce qui vous permet de lui donner des outils et un accès aux données en direct.
Configuration :
- Installez Cline depuis la marketplace VS Code.
- Ouvrez les réglages de Cline, choisissez Ollama comme fournisseur d'API.
- Pointez-le vers
http://localhost:11434et sélectionnez un modèle récupéré (un modèle capable — l'édition agentique exige un modèle qui suit bien les instructions d'appel d'outils).
La première cause d'échec de Cline en local n'est pas le modèle, c'est la fenêtre de contexte laissée à sa valeur par défaut : un agent autonome la sature en quelques appels d'outils, puis boucle ou échoue sans rien dire. Montez-la à 16k au minimum (voir l'encadré sur OpenCode plus bas pour la méthode) avant de conclure quoi que ce soit sur votre modèle.
Cela dit, l'ambition de la tâche compte vraiment ici. Un modèle 7-14B suffit pour de l'édition ciblée et des refactorisations légères ; viser une autonomie réelle sur plusieurs fichiers demande plutôt un 22-30B, avec la VRAM correspondante. Voir notre guide de choix de modèle.
Twinny — l'autocomplétion en ligne rapide
Là où Cline est un agent poids lourd, Twinny excelle dans l'autre métier : la complétion en ligne en temps réel pendant que vous tapez — le texte fantôme au clavier qu'on associe à Copilot. C'est une extension VS Code réglée spécifiquement pour Ollama.
Configuration :
- Installez Twinny depuis la marketplace.
- Pointez-le vers votre instance Ollama locale.
- Choisissez un modèle petit et rapide, compatible FIM, pour l'autocomplétion (la latence compte ici — un modèle de code 7B est un bon équilibre).
Twinny et Cline cohabitent sans souci : Twinny pour les complétions instantanées, Cline pour les tâches « refactore tout ce module ».
Un mot sur Continue
Continue a longtemps été l'assistant open-source de référence pour les modèles locaux. Sachez qu'il a été racheté par Cursor en juin 2026 et que la v2.0 est sa dernière version indépendante. Il fonctionne toujours avec Ollama aujourd'hui, mais son avenir est incertain — c'est précisément pour cela que nous orienterions les nouvelles configurations vers Cline.
La voie terminal : OpenCode
Tout le monde ne veut pas travailler dans un éditeur. OpenCode est un agent de code open-source qui vit dans votre terminal : il lit votre projet, planifie des changements, édite les fichiers et lance des commandes — la même boucle agentique que Cline, mais en ligne de commande. Associé à Ollama, rien ne quitte votre machine : pas de cloud, pas de télémétrie, pas de limites d'usage.
Configuration — la voie facile :
ollama launch opencode
Cette unique commande (fournie par Ollama) lance OpenCode câblé à votre serveur Ollama local.
Configuration — manuelle :
Configurez Ollama comme fournisseur dans opencode.json, avec l'URL de base pointant vers http://localhost:11434/v1 et le modèle de votre choix.
Avant d'accuser votre modèle, vérifiez votre fenêtre de contexte. Ollama ne donne pas à un modèle la fenêtre qu'il sait gérer : il applique un défaut prudent, calculé d'après votre VRAM, qui retombe très souvent sur 4 096 tokens. Sur notre machine (Ollama 0.30, GPU pourtant capable de bien plus), un Qwen 3 annonçant 40 960 tokens tourne en pratique avec 4 096 : un facteur 10 perdu, sans le moindre avertissement. C'est la première cause d'appels d'outils qui échouent et d'agents qui perdent le fil et ça n'a rien à voir avec la taille du modèle.
Vérifiez le contexte réellement alloué avec ollama ps (colonne CONTEXT) et relevez-le globalement via OLLAMA_CONTEXT_LENGTH=32768. Comptez 16k au strict minimum pour du travail agentique, 32k et plus pour être confortable — la documentation d'Ollama, elle, recommande 64k pour OpenCode. Attention, ce n'est pas gratuit : la fenêtre est allouée en mémoire et un contexte trop grand pour votre VRAM fait basculer le modèle sur le processeur — donc lent.
Constatez-le vous-même : ollama show qwen3 annonce une capacité de 40 960 tokens, mais ollama ps affiche 4 096 dans la colonne CONTEXT une fois le modèle chargé — dix fois moins. Relancez avec OLLAMA_CONTEXT_LENGTH=32768 et la même colonne indique enfin 32 768.
Surveillez alors la colonne SIZE : sur ce même modèle, passer de 4k à 32k a fait grimper l'empreinte de 5,6 à 9,8 Go. Voilà la raison d'être de ce plafond — relevez-le en connaissance de cause plutôt qu'au maximum. L'écart est encore plus net sur les modèles à très long contexte : un Gemma annonçant 262 144 tokens démarre lui aussi à 4 096, soixante-quatre fois moins que sa capacité.
Ce budget se remplit aussi plus vite qu'on ne croit : l'agent y empile l'historique, les fichiers lus et la définition de chaque outil disponible. Sur les configurations chargées en serveurs MCP, ces définitions peuvent à elles seules occuper 30 à 50 % du contexte avant la première ligne de code. Ne branchez que les outils dont la tâche a besoin.
Quant à la taille du modèle, elle joue sur la fiabilité par étape, pas sur le fait que ça fonctionne ou non. Un modèle 7-8B tient très bien une modification ciblée dans un projet cadré ; ce qui le met en difficulté, c'est la tâche vague enchaînant dix appels d'outils sans supervision, où une dérive à l'étape trois se paie à l'étape neuf. Une exigence reste ferme, en revanche : le modèle doit avoir été entraîné au tool calling et produire du JSON valide, sinon l'agent hallucine ses éditions de fichiers. Commencez avec le modèle que vous avez : c'est la nature de la tâche, pas une barre en milliards de paramètres, qui vous dira s'il faut monter en gamme.
La voie hybride : Claude Code sur un modèle local
Voici le cas qui surprend. Claude Code est l'agent terminal d'Anthropic — un outil propriétaire, normalement pointé vers le cloud d'Anthropic. Mais depuis Ollama v0.14, Ollama parle l'API Anthropic Messages. Cela signifie que vous pouvez conserver l'excellente UX agentique de Claude Code tout en remplaçant le cerveau par un modèle open-source tournant en local.
Configuration :
export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL=http://localhost:11434
claude --model qwen3.5
Remplacez qwen3.5 par n'importe quel modèle local que vous avez récupéré. Avec ANTHROPIC_BASE_URL pointé vers Ollama, Claude Code envoie ses requêtes à votre machine plutôt qu'aux serveurs d'Anthropic — votre code reste chez vous.
C'est un véritable hybride : le modèle et votre code sont locaux, mais l'outil lui-même est propriétaire. C'est un compromis différent de Cline ou OpenCode, qui sont open source de bout en bout. Si votre priorité est le workflow soigné de Claude Code et que le client fermé ne vous dérange pas, c'est une excellente option. Si vous voulez une pile entièrement ouverte, tenez-vous-en aux outils ci-dessus. Notez aussi que Claude Code jongle en interne avec plusieurs « slots » de modèles — le pointer sur un seul modèle local peut perturber ses slots de tâches en arrière-plan, attendez-vous à quelques aspérités.
Et Claude Desktop ?
Pour être complet : Claude Desktop est l'application de chat d'Anthropic et elle prend en charge MCP pour connecter des outils — mais son inférence tourne dans le cloud d'Anthropic. Il n'y a pas de bascule vers un modèle local comme le permet Claude Code. C'est une bonne application ; ce n'est simplement pas un outil d'IA locale, elle sort donc de la configuration souveraine dont parle ce site.
Lequel choisir ?
| Outil | Type | Tourne sur Ollama | Open source | Idéal pour |
|---|---|---|---|---|
| Cline | Extension VS Code / JetBrains | ✅ natif | ✅ | Édition agentique multi-fichiers avec MCP |
| Twinny | Extension VS Code | ✅ natif | ✅ | Autocomplétion en ligne rapide |
| OpenCode | Agent terminal | ✅ (ollama launch opencode) |
✅ | Code agentique en ligne de commande |
| Claude Code | Agent terminal | ✅ (via ANTHROPIC_BASE_URL) |
❌ client propriétaire | UX soignée, prêt à utiliser un outil fermé |
| Claude Desktop | App de chat | ❌ inférence cloud | ❌ | Pas un outil local |
Un point de départ raisonnable pour la plupart des gens : Cline dans VS Code pour le travail agentique, Twinny pour l'autocomplétion — les deux entièrement ouverts, les deux sur votre propre modèle. Passez à OpenCode si vous préférez le terminal et n'essayez l'astuce Claude Code que si vous voulez spécifiquement ce workflow et acceptez le client fermé.