# Agent de code avec LLM local : Ollama et LM Studio

URL: https://agentvera.dev/fr/blog/local-llm-coding-agent/ · Publié: 2026-10-23

Faites tourner un agent de code avec un LLM local via Ollama ou LM Studio : CLI compatibles, matériel requis, gain de confidentialité, compromis et setup hybride.

**En bref:**

- Ollama expose une API compatible OpenAI sur localhost:11434 et LM Studio sur 127.0.0.1:1234 ; des CLI de code comme Codex, opencode, Aider, Goose, Qwen Code et Crush peuvent s’y connecter.
- Le contexte par défaut d’Ollama est de 4k tokens sous 24 GiB de VRAM et le surplus est ignoré sans avertissement : augmentez-le avec OLLAMA_CONTEXT_LENGTH ; Ollama demande au moins 64k pour Codex.
- Les modèles locaux gardent le code sur votre machine sans coût par token, mais sont plus lents et plus faibles sur le travail multi-fichiers : un partage hybride avec un modèle hébergé fonctionne le mieux.

Un agent de code avec LLM local est une CLI de code, comme opencode, Aider, Goose, Qwen Code, Crush ou Codex, pointée vers un modèle qui tourne sur votre propre machine via Ollama ou LM Studio plutôt que vers une API hébergée. Vous démarrez un serveur local (Ollama écoute sur `http://localhost:11434`, LM Studio sur `http://127.0.0.1:1234`), vous choisissez un modèle qui gère l’appel d’outils, vous augmentez nettement sa longueur de contexte par rapport au défaut, et vous indiquez à la CLI d’utiliser cet endpoint. Ça marche, votre code reste sur votre machine, et il n’y a aucun coût par token. C’est aussi plus lent et moins capable que les meilleurs modèles hébergés, d’où un setup hybride pour la plupart des gens.

## Ce que « local » veut vraiment dire ici

Un [agent de code](/fr/glossary/coding-agent/ "Agent de code") se compose de deux parties : la CLI qui lit les fichiers, exécute des commandes et modifie le code, et le modèle qui décide de la suite. Passer en local ne remplace que la seconde partie. La CLI exécute la même boucle ; elle envoie simplement ses requêtes à un serveur sur `localhost` au lieu de l’API d’un fournisseur.

Les deux serveurs locaux courants parlent une API compatible OpenAI :

| Serveur | Adresse par défaut | Comment le démarrer |
| --- | --- | --- |
| Ollama | `http://localhost:11434/v1` | L’application Ollama, ou `ollama serve` |
| LM Studio | `http://127.0.0.1:1234/v1` | Onglet Developer → « Start server », ou `lms server start` |

La doc d’Ollama précise que les clients OpenAI exigent une valeur de clé API mais qu’Ollama l’ignore : n’importe quel texte fait l’affaire pour un serveur local.

## Le réglage que tout le monde oublie : la longueur de contexte

Avant de choisir une CLI, réglez ceci. Les agents envoient beaucoup de contexte : un prompt système, des définitions d’outils, le contenu de fichiers et la sortie de commandes. Un serveur local avec une petite fenêtre en coupera discrètement la majeure partie.

La [fenêtre de contexte](/fr/glossary/context-window/ "Fenêtre de contexte") par défaut d’Ollama dépend de votre VRAM : 4k tokens sous 24 GiB, 32k entre 24 et 48 GiB, et 256k à partir de 48 GiB. La doc d’Aider ajoute qu’Ollama ignore sans avertissement le contexte qui dépasse la fenêtre. La doc de Goose juge trop bas un défaut de 4096 tokens, et le guide Codex d’Ollama demande au moins 64k.

Augmentez-la au démarrage du serveur, puis vérifiez :

```bash
OLLAMA_CONTEXT_LENGTH=64000 ollama serve
ollama ps   # CONTEXT column shows the allocated length
```

L’application Ollama propose dans ses réglages un curseur de longueur de contexte qui fait la même chose. Si `ollama ps` montre le modèle en partie sur le CPU dans la colonne `PROCESSOR`, le contexte ou le modèle est trop gros pour votre GPU et tout va ralentir.

## Quelles CLI prennent en charge les modèles locaux

Voici ce que la documentation de chaque outil confirme. Nous ne listons que les configurations que nous avons pu vérifier.

| CLI | Voie locale | Où se configure-t-elle |
| --- | --- | --- |
| Codex | `--oss` avec Ollama ou LM Studio | Flag, ou `oss_provider` dans `config.toml` |
| opencode | Tout provider compatible OpenAI | Section `provider` de `opencode.json` |
| Aider | `ollama_chat/<model>` ou `openai/<model>` | Variables d’environnement |
| Goose | Ollama, LM Studio et autres providers | `goose configure` |
| Qwen Code | Tout endpoint compatible OpenAI | Variables `OPENAI_*` ou `~/.qwen/settings.json` |
| Crush | Types de provider `ollama` et `lmstudio` | Sa config de provider |

### Codex

[Codex](/fr/agents/codex/ "Codex CLI") offre le chemin le plus court. Sa doc indique qu’il peut tourner avec un provider « open source » local comme Ollama ou LM Studio quand vous passez `--oss` :

```bash
codex --oss                     # default local model
codex --oss -m gpt-oss:120b     # a specific model
```

Définissez le provider par défaut dans `~/.codex/config.toml` avec `oss_provider = "ollama"` (ou `"lmstudio"`). Ollama propose aussi `ollama launch codex`, qui prépare un profil pour vous. Dans Codex, `/model` bascule entre les modèles installés capables d’appeler des outils.

### opencode

[opencode](/fr/agents/opencode/ "opencode") accepte tout serveur compatible OpenAI comme provider personnalisé dans `opencode.json` :

```json
{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": { "baseURL": "http://localhost:11434/v1" },
      "models": { "qwen3": { "name": "Qwen3 (local)" } }
    }
  }
}
```

Pour LM Studio, utilisez `http://127.0.0.1:1234/v1` comme URL de base et l’identifiant de modèle affiché dans LM Studio. La doc d’opencode donne un conseil utile : si les appels d’outils ne fonctionnent pas, augmentez `num_ctx` dans Ollama, en partant d’environ 16k à 32k.

### Aider

[Aider](/fr/agents/aider/ "Aider") dialogue directement avec Ollama. Sa doc recommande le préfixe `ollama_chat/` :

```bash
export OLLAMA_API_BASE=http://127.0.0.1:11434
aider --model ollama_chat/<model>
```

Pour LM Studio ou tout autre serveur compatible OpenAI, définissez `OPENAI_API_BASE` et `OPENAI_API_KEY`, puis utilisez `aider --model openai/<model-name>`. Une taille de contexte fixe se place dans `.aider.model.settings.yml` sous la forme `num_ctx` dans `extra_params`.

### Goose

[Goose](/fr/agents/goose/ "Goose") liste Ollama et LM Studio parmi ses providers. Lancez `goose configure`, choisissez Ollama et saisissez un nom de modèle. Il utilise `localhost:11434` sauf si `OLLAMA_HOST` indique autre chose ; LM Studio utilise par défaut `localhost:1234` sans clé API. La doc de Goose est franche sur la contrainte principale : il utilise massivement l’appel d’outils, un modèle qui en est dépourvu ne peut donc que discuter.

### Qwen Code

[Qwen Code](/fr/agents/qwen-code/ "Qwen Code") prend en charge tout endpoint compatible OpenAI, et son README cite les modèles locaux via Ollama ou vLLM. Pointez les variables standard vers votre serveur :

```bash
export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_API_KEY=ollama   # any placeholder for a local server
export OPENAI_MODEL=<model>
qwen
```

La même chose peut résider dans `~/.qwen/settings.json` sous `modelProviders`, ou se configurer de façon interactive avec `/auth`.

### Crush

Crush prend en charge `ollama` et `lmstudio` comme types de provider. Son README montre Ollama ajouté avec l’URL de base `http://localhost:11434/v1`. Choisissez le modèle dans Crush avec `Ctrl+L`.

## Quand l’agent local se comporte mal

La plupart des problèmes avec un agent de code local tiennent à quelques causes. Vérifiez-les dans cet ordre :

- **Il oublie des fichiers ou des instructions en cours de tâche.** Le contexte est trop petit et le serveur tronque. Augmentez `OLLAMA_CONTEXT_LENGTH` (ou `num_ctx`) et confirmez avec `ollama ps`.
- **Les appels d’outils échouent ou reviennent en texte brut.** Le modèle ne gère peut-être pas l’appel d’outils, ou le contexte est trop court pour les définitions d’outils. Essayez un modèle capable d’appeler des outils et une fenêtre plus grande ; la doc d’opencode suggère de commencer vers 16k à 32k.
- **La CLI dit que le modèle n’existe pas.** Le nom dans la CLI doit correspondre exactement à l’identifiant du serveur : le tag donné par `ollama list`, ou l’identifiant dans le panneau serveur de LM Studio.
- **Connexion refusée.** Le serveur ne tourne pas, ou la CLI attend une autre adresse. Ollama utilise `11434`, LM Studio `1234`, et certaines CLI veulent le suffixe `/v1` alors que `OLLAMA_API_BASE` d’Aider n’en veut pas.
- **Tout est très lent.** Le modèle ou le contexte ne tient pas sur le GPU. `ollama ps` montre la part de CPU ; choisissez un modèle plus petit ou un contexte plus court.

## La réalité du matériel

C’est là que les attentes se brisent d’habitude. Un agent de code local est une tâche plus lourde qu’un chat local :

- **Le modèle doit tenir en mémoire.** VRAM du GPU sur un PC, mémoire unifiée sur Apple Silicon. Quand il ne tient pas, des couches débordent sur le CPU et la génération ralentit fortement.
- **Le contexte coûte aussi de la mémoire.** Une fenêtre de 64k en plus des poids du modèle demande bien plus de place qu’un chat à 4k. C’est pourquoi Ollama lie sa longueur de contexte par défaut à la VRAM.
- **Les petits modèles peinent avec les outils.** Les agents dépendent d’appels d’outils fiables et du respect d’un long prompt système. Les petits modèles produisent souvent des appels mal formés, tournent en boucle ou s’arrêtent trop tôt. Goose note que certains modèles, comme le DeepSeek-R1 natif, ne gèrent pas du tout l’appel d’outils.
- **La lenteur s’accumule.** Un agent fait de nombreuses requêtes par tâche, chacune avec un gros prompt. Un modèle agréable en chat peut rendre une tâche de dix étapes très longue.

Une façon pratique de commencer : prenez le plus grand modèle de code capable d’appeler des outils qui tourne entièrement sur votre GPU avec au moins 32k à 64k de contexte, confirmez avec `ollama ps`, et testez-le sur une petite tâche réelle avant de lui confier quoi que ce soit de plus gros.

## Pourquoi passer en local : confidentialité et contrôle

La raison principale est que l’inférence reste sur votre machine :

- Vos prompts et votre code ne sont pas envoyés à un fournisseur de modèle.
- Ça marche hors ligne et dans des environnements isolés du réseau.
- Pas de facture au token ni de limites d’usage à atteindre.
- Le modèle ne change pas sous vos pieds ; vous décidez quand mettre à jour.

Deux réserves pour rester honnête. D’abord, la CLI peut quand même utiliser le réseau : Codex avec le profil de lancement d’Ollama dispose de la recherche web, et certaines CLI ont de la télémétrie. Vérifiez les réglages de chaque outil si rien ne doit sortir du tout de la machine. Ensuite, tourner en local ne rend pas l’agent lui-même plus sûr. Il exécute toujours des commandes et modifie des fichiers, donc les [bonnes pratiques de sécurité des agents de code](/fr/blog/ai-coding-agent-security/ "Sécurité des agents de code IA") habituelles s’appliquent.

## Compromis face aux modèles hébergés

| | Modèle local | Modèle hébergé de pointe |
| --- | --- | --- |
| Le code quitte la machine | Non | Oui, vers le fournisseur |
| Coût | Matériel et électricité | Au token ou par abonnement |
| Limites d’usage | Aucune | Selon l’offre |
| Qualité sur les tâches difficiles multi-fichiers | Plus faible, dépend de la taille du modèle | La meilleure disponible |
| Fiabilité des appels d’outils | Variable selon le modèle | Solide |
| Fenêtre de contexte | Limitée par votre mémoire | Très grande |
| Vitesse | Dépend de votre matériel | Rapide et constante |

L’écart est le plus faible sur des tâches circonscrites : écrire un test, expliquer une fonction, un petit refactoring, un message de commit. Il est le plus grand sur le travail long en plusieurs étapes sur de nombreux fichiers, où l’agent doit garder un plan et se rattraper après ses propres erreurs.

## Un setup hybride qui fonctionne

Un partage fonctionne généralement mieux qu’un basculement tout ou rien :

1. **Le travail sensible ou hors ligne va en local.** Du code qui ne doit pas quitter la machine, des dépôts clients aux conditions strictes, le travail dans l’avion.
2. **Les tâches courantes et circonscrites vont en local.** Tests, docs, petits correctifs et explications.
3. **Les tâches difficiles vont vers un modèle hébergé.** Changements d’architecture, bugs retors, gros refactorings.
4. **Relisez dans un contexte neuf.** Laissez un second agent contrôler le diff du premier, quel que soit le modèle qui l’a écrit.

Le plus simple pour faire cela est de lancer deux agents ou plus en même temps : un sur un endpoint local, un sur un modèle hébergé, chacun dans son propre dossier ou worktree git pour qu’ils ne modifient pas les mêmes fichiers.

## Agents locaux et hébergés côte à côte dans AgentVera

AgentVera est une application de bureau qui fait tourner de nombreux agents CLI côte à côte dans un seul [espace de travail](/fr/features/workspace/ "Espace de travail"), ce qui convient au setup hybride ci-dessus. Pour être clair sur ce qu’elle fait et ne fait pas :

- **Elle n’a pas d’intégration Ollama ou LM Studio native.** Chaque agent utilise sa propre configuration de provider : `goose configure` pour Goose, la config propre d’opencode et `/connect`, les variables d’environnement ou `.aider.conf.yml` d’Aider, la connexion ou la clé API de Qwen Code, les réglages de Crush (`Ctrl+L`).
- **Le champ « Model » est transmis à la CLI.** Pour des agents comme Qwen Code, Goose et Aider, ce que vous y saisissez est passé à la CLI en `--model`. Pour Goose, l’indication dit : « If left empty, the model chosen with `goose configure` is used. »
- **Les agents peuvent porter des variables d’environnement.** Dans Settings → Accounts → Accounts of other agents, un compte ajouté « With an API key » stocke un « Variable name » et sa valeur. Pour Qwen Code, `OPENAI_BASE_URL` fait partie des noms suggérés, et tout autre nom peut être saisi. Cela fait partie de la [bascule de comptes](/fr/features/account-switching/ "Bascule de comptes") des offres Pro et Team.
- **Les outils de contexte vont au-delà de Claude Code.** La taille du contexte est mesurée à partir de l’historique propre de chaque CLI, et l’auto-compact utilise la commande de compactage de la CLI quand elle en a une. Avec une petite fenêtre locale, cela compte encore plus.

Le tableau réaliste est donc le suivant : vous configurez le modèle local dans la CLI comme sa doc le décrit, et AgentVera vous permet de faire tourner cet agent à côté d’un agent hébergé, de surveiller les deux et de séparer leur travail.

## Questions fréquentes

**Quelles CLI d’agents de code fonctionnent avec un LLM local ?** opencode, Aider, Goose, Qwen Code, Crush et Codex documentent tous un moyen d’utiliser un endpoint local ou compatible OpenAI. Codex dispose d’un flag --oss intégré pour Ollama et LM Studio ; les autres prennent une config de provider, un préfixe de modèle ou des variables d’environnement.

**Faut-il un GPU pour faire tourner un agent de code local ?** Pas strictement, mais cela aide beaucoup. Les agents de code ont besoin d’appel d’outils et d’un long contexte, ce qui suppose un modèle assez grand et beaucoup de mémoire. Sans GPU performant ni beaucoup de mémoire unifiée, les réponses deviennent si lentes que le travail avec l’agent devient pénible.

**Pourquoi mon modèle local ignore-t-il des fichiers ou oublie-t-il des instructions ?** En général, la longueur de contexte est trop petite. Le défaut d’Ollama dépend de la VRAM et vaut 4k sur les machines de moins de 24 GiB, et ce qui ne tient pas est ignoré sans avertissement. Augmentez-la avec OLLAMA_CONTEXT_LENGTH ou un réglage num_ctx ; Ollama recommande au moins 64k pour Codex.

**Un modèle local est-il entièrement privé ?** L’inférence reste sur votre machine : prompts et code ne sont pas envoyés à un fournisseur de modèle. La CLI elle-même peut toutefois avoir de la télémétrie, de la recherche web ou d’autres fonctions réseau ; vérifiez ses réglages si rien ne doit sortir de la machine.

**AgentVera prend-il en charge les modèles locaux ?** AgentVera fait tourner côte à côte les agents CLI qui les prennent en charge, comme opencode, Aider, Goose, Qwen Code, Crush et Codex. Chaque CLI garde sa propre config de provider ; AgentVera transmet le champ Model et peut donner des variables d’environnement à un agent, mais n’a pas d’intégration Ollama native.

---

**À propos d’AgentVera.** AgentVera est une app de bureau pour macOS, Windows et Linux, développée par Solviera Teknoloji. Elle exécute 18 agents de code IA (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) côte à côte, par projet, dans de vrais terminaux avec les installations et connexions CLI de l’utilisateur. L’offre gratuite inclut des agents illimités. Télécharger: https://agentvera.dev/fr/download/ · Tarifs: https://agentvera.dev/fr/pricing/