Comment utiliser Claude Code avec un modèle local ?

Résumer ce contenu avec :

Perplexity

ChatGPT

Claude

Grok

Mistral

Claude Code peut piloter un modèle local si le backend parle le format Anthropic Messages API. L’intérêt est simple : moins de coûts en tokens, moins de limites de taux, moins de dépendance à une API tierce. Je vous montre le principe, les backends utiles et les réglages qui évitent les prises de tête.

Pourquoi passer Claude Code en local ?

Passer Claude Code en local sert surtout à réduire les coûts, éviter les limites de taux et garder plus de contrôle sur ses sessions de codage agentique.

Quand j’utilise un outil comme Claude Code, je ne lui envoie pas juste “corrige ce fichier” et terminé. L’outil lit le contexte, explore le dépôt, propose des changements, analyse les erreurs, relance des commandes, récupère les sorties, puis rediscute avec le modèle pour ajuster. C’est ça, le codage agentique : le modèle ne répond pas une seule fois, il enchaîne plusieurs actions pour avancer vers un objectif.

Le souci, c’est que tout ça consomme beaucoup de tokens. Un token, pour faire simple, c’est un petit morceau de texte facturé par l’API. Plus le modèle lit de fichiers, plus il échange, plus la facture monte. Sur une session courte, ça passe. Sur une grosse base de code, pendant deux heures, avec plusieurs essais ratés, ça peut vite piquer. Et bizarrement, les bugs ne choisissent jamais les sessions les moins chères.

Il y a aussi la dépendance au service tiers. Rien de dramatique, mais c’est réel :

Vous dépendez de la disponibilité de l’API.
Vous pouvez tomber sur des quotas ou des limites de taux.
Vous ajoutez de la latence à chaque aller-retour.
Vous devez gérer des clés d’API proprement.
Vous pouvez subir un changement de modèle ou de comportement.

Je ne dis pas que le cloud est mauvais. Au contraire, les gros modèles cloud sont souvent excellents. Mais pour beaucoup de tâches de développement, le local a vraiment du sens.

Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?

Les modèles locaux quantifiés sont devenus assez bons pour le travail courant. Un modèle quantifié, c’est un modèle compressé pour tourner avec moins de mémoire, souvent sur une machine perso ou un petit serveur. Il peut faire de la complétion de code, de la refactorisation, du débogage simple, de l’explication de code, des petites migrations, lire un fichier, générer des tests basiques. Pas besoin de sortir l’artillerie lourde pour renommer une fonction ou comprendre pourquoi un test casse.

La limite reste claire : pour les tâches très complexes, les gros modèles cloud restent souvent meilleurs. C’est une histoire de bon outil au bon moment, pas de religion, heureusement.

Le point clé maintenant, c’est que Claude Code peut être redirigé vers un serveur local compatible avec le format Anthropic Messages API. Et c’est là que ça devient intéressant.

Comment Claude Code parle au modèle ?

Claude Code échange avec le modèle via le format Anthropic Messages API, et on peut rediriger ses appels vers un serveur local compatible.

Le principe est assez simple. Claude Code ne “parle” pas directement à un modèle comme Qwen, Llama ou Mistral. Il envoie des requêtes HTTP dans un format précis, celui attendu par l’API Anthropic. Dedans, on retrouve les messages, le modèle demandé, les paramètres de génération, bref tout ce qu’il faut pour que le backend réponde comme Claude le ferait.

Si votre backend local comprend ce format, Claude Code peut lui parler directement, sans proxy de traduction au milieu. Le réglage central, c’est ANTHROPIC_BASE_URL. Au lieu de pointer vers l’API Anthropic distante, je le fais pointer vers mon serveur local. C’est un peu comme changer l’adresse de livraison, sauf que là le colis c’est du JSON.

Variable	Rôle
ANTHROPIC_BASE_URL	Définit l’URL du serveur à appeler, par exemple un backend local au lieu de l’API Anthropic.
ANTHROPIC_API_KEY	Définit une clé API. Elle peut rester nécessaire même en local, selon ce que Claude Code ou le backend attend.
ANTHROPIC_AUTH_TOKEN	Définit un token d’authentification alternatif. Certains montages l’utilisent à la place d’une clé API classique.
ANTHROPIC_DEFAULT_SONNET_MODEL	Définit le modèle utilisé quand Claude Code demande un modèle de type Sonnet.
ANTHROPIC_DEFAULT_HAIKU_MODEL	Définit le modèle utilisé quand Claude Code demande un modèle de type Haiku.
ANTHROPIC_DEFAULT_OPUS_MODEL	Définit le modèle utilisé quand Claude Code demande un modèle de type Opus.

Un exemple minimal pourrait ressembler à ça.

export ANTHROPIC_BASE_URL=http://localhost:11434

export ANTHROPIC_API_KEY=local

export ANTHROPIC_DEFAULT_SONNET_MODEL=qwen3-coder

Ces valeurs ne sont pas universelles. Il faut les adapter au backend que vous utilisez, au port exposé, et surtout au nom exact du modèle installé. Le petit piège classique, c’est de mettre un nom “marketing” au lieu du nom réellement déclaré côté serveur. Oui, ça arrive souvent.

Dans ce montage, trois options ressortent souvent : Ollama, LM Studio et llama.cpp. Elles peuvent servir des modèles localement et supporter le protocole attendu, avec plus ou moins de configuration selon les cas. Pour démarrer sans se battre avec trop de plomberie, Ollama est souvent le point de départ le plus simple.

Pourquoi commencer avec Ollama ?

Ollama est souvent le plus simple pour démarrer parce qu’il gère le téléchargement des modèles, le service local et l’exécution CPU ou GPU avec peu de configuration.

Pour tester Claude Code avec un modèle local, c’est une bonne porte d’entrée. Je n’ai pas besoin de monter toute une stack d’inférence, de choisir un runtime obscur ou de passer deux heures à comprendre pourquoi un modèle refuse de démarrer. Ollama lance un serveur local, télécharge les modèles, et expose une API utilisable depuis d’autres outils.

Par défaut, Ollama écoute sur le port 11434. Je peux vérifier que le service répond avec cette commande :

curl http://localhost:11434

Côté prérequis, je pars sur quelque chose de raisonnable : macOS, Linux ou Windows, avec WSL2 conseillé sur Windows. Pour la mémoire, 16 à 32 Go de RAM est un bon minimum, parfois plus selon les modèles. Un GPU est recommandé, idéalement avec 8 Go de VRAM ou plus. La VRAM, c’est la mémoire dédiée de la carte graphique. Et je vérifie aussi que j’ai Ollama v0.14.0 ou plus.

Les commandes utiles pour installer, vérifier et récupérer des modèles sont simples :

curl https://ollama.com/install.sh | sh
ollama --version
curl http://localhost:11434
ollama pull glm-4.7-flash
ollama pull qwen3-coder
ollama pull devstral-small-2:24b
ollama list

Pour le code, le “meilleur” modèle dépend surtout de votre machine et du niveau attendu. Un petit modèle sera plus rapide. Un modèle plus gros comprendra mieux un projet complexe. Un modèle quantifié prendra moins de RAM, parce qu’il utilise une représentation plus compacte des poids du modèle. C’est moins sexy à dire, mais souvent c’est ça qui décide si ça tourne ou pas.

Le lien avec Claude Code est assez direct. Une fois le modèle présent dans Ollama, je configure ANTHROPIC_BASE_URL vers le serveur local, puis les variables de modèle par défaut vers le nom du modèle disponible. Selon la version d’Ollama et le modèle, je vérifie toujours le nom exact avec ollama list, histoire d’éviter une erreur bête.

Point fort	Simplicité
Limite	Dépend des ressources locales
Cas d’usage	Codage quotidien, refactorisation, explication, debug

Quand choisir LM Studio ou llama.cpp ?

LM Studio et llama.cpp sont intéressants quand on veut plus de contrôle sur le modèle, l’interface ou les paramètres d’inférence.

LM Studio, je le vois comme l’option confortable. On installe, on cherche un modèle local, on le charge, on teste dans une interface visuelle, puis on peut lancer un serveur local sans passer sa soirée dans le terminal. C’est pratique si vous voulez comparer plusieurs modèles de code avant de décider lequel brancher à Claude Code.

Le gros avantage, c’est qu’on peut ajuster des paramètres sans tout faire en ligne de commande. Température, contexte, modèle chargé, comportement général… On reste dans quelque chose de lisible. Pour tester vite, c’est franchement agréable.

llama.cpp, c’est une autre ambiance. C’est plus bas niveau, très utilisé pour faire tourner des modèles quantifiés localement. Un modèle quantifié, pour faire simple, c’est un modèle compressé pour consommer moins de mémoire et tourner plus facilement sur une machine classique. C’est souvent le nerf de la guerre quand on veut faire du local sans transformer son bureau en datacenter.

Avec llama.cpp, vous maîtrisez plus finement les performances, la mémoire, les paramètres et le serveur. C’est moins “plug and play” qu’Ollama ou LM Studio, mais c’est très solide quand on aime comprendre ce qui tourne sous le capot. Oui, il faut parfois aimer les drapeaux de commande, chacun ses loisirs.

Le critère décisif reste toujours le même : le backend doit exposer un serveur compatible avec le format Anthropic Messages API pour que Claude Code puisse l’utiliser directement via ANTHROPIC_BASE_URL. Avant de brancher quoi que ce soit, je vérifie toujours la documentation officielle de la version installée pour l’URL, le port et le nom exact du modèle. C’est moins sexy qu’une commande copiée-collée, mais ça évite les bugs idiots.

Backend	Meilleur usage	Niveau de simplicité	Point à surveiller
Ollama	Lancer vite un modèle local avec peu de configuration	Simple	Compatibilité exacte avec l’API attendue par Claude Code
LM Studio	Tester et comparer plusieurs modèles avec une interface visuelle	Très confortable	URL, port, serveur activé et format API exposé
llama.cpp	Optimiser finement les performances, la mémoire et les modèles quantifiés	Plus technique	Paramètres serveur, modèle chargé et compatibilité Anthropic Messages API

Mon choix est simple. Je prends LM Studio quand je veux explorer vite. Je prends llama.cpp quand je veux contrôler finement. Et je garde Ollama quand je veux aller droit au but sans trop bricoler.

Comment éviter les bugs de configuration ?

La plupart des bugs viennent d’une URL locale incorrecte, d’un modèle mal nommé, d’une variable d’environnement absente ou d’un modèle trop lourd pour la machine.

Je commence toujours par le plus bête, parce que c’est souvent là que ça casse. Est-ce que le serveur local tourne vraiment ? Avec Ollama, je teste déjà ça :

curl http://localhost:11434

Si ça ne répond pas, Claude Code n’a aucune chance de parler au modèle. Il faut relancer le serveur local, puis vérifier le port. Le port par défaut d’Ollama, c’est souvent 11434, mais si vous avez changé la config ou si un autre outil fait proxy entre Claude Code et le modèle, il faut aligner tout le monde.

Ensuite, je vérifie les modèles installés :

ollama list

Le nom du modèle doit être copié exactement. Pas “llama”, si le modèle s’appelle “llama3.1:8b”. Pas “qwen”, si le vrai nom est “qwen2.5-coder:7b”. C’est idiot, mais une faute ici donne parfois des erreurs qui ressemblent à autre chose.

Après ça, je contrôle les variables d’environnement. ANTHROPIC_BASE_URL doit pointer vers votre backend local. ANTHROPIC_API_KEY ou ANTHROPIC_AUTH_TOKEN doit correspondre à ce que ce backend attend. Si Claude Code renvoie une erreur d’authentification, ce n’est pas forcément “Claude” le problème. C’est souvent la clé ou le token attendu par le proxy local, LiteLLM, Open WebUI, Ollama compatible API, ou votre passerelle maison.

Je regarde aussi les variables de modèle par défaut, par exemple ANTHROPIC_MODEL ou ANTHROPIC_SMALL_FAST_MODEL selon votre setup. Si elles pointent vers un modèle absent ou trop gros, ça part vite en vrille.

Pour le choix du modèle, je fais simple. Je démarre petit pour valider la connexion. Un modèle léger, une petite tâche de code, et seulement après je monte en taille. C’est plus sain que de lancer directement un énorme modèle qui fait fondre la RAM, la VRAM, et votre patience avec.

Si le modèle ne répond pas, ou répond comme s’il tapait avec des moufles, je regarde la RAM, la VRAM, la taille du modèle et la quantification. La quantification, c’est une version compressée du modèle, souvent en 4 bits ou 8 bits, qui consomme moins de mémoire avec parfois une petite perte de qualité.

Serveur démarré.
URL correcte.
Port correct.
Modèle installé.
Nom du modèle exact.
Variables exportées.
Ressources suffisantes.
Test sur une petite tâche de code.

Et si le bon compromis était simplement hybride ?

Utiliser Claude Code avec un modèle local, ce n’est pas remplacer tous les modèles cloud par principe. C’est reprendre la main sur les coûts, les quotas et une partie de la dépendance à une API externe. Le principe est assez propre : Claude Code parle le format Anthropic Messages API, et ANTHROPIC_BASE_URL permet de le diriger vers un serveur local compatible. Ollama est souvent le plus simple pour démarrer, LM Studio aide à tester visuellement, llama.cpp donne plus de contrôle. Le bénéfice pour vous est clair : coder plus librement, tester plus souvent, et garder les gros modèles cloud pour les vrais sujets difficiles.

FAQ

Claude Code peut-il vraiment fonctionner avec un modèle local ?
Oui, si le backend local expose un serveur compatible avec le format Anthropic Messages API. Le réglage clé consiste à rediriger Claude Code avec ANTHROPIC_BASE_URL vers l’URL locale du serveur.
Quel est l’intérêt d’utiliser Claude Code en local ?
L’intérêt principal, c’est de réduire les coûts liés aux tokens, éviter les limites de taux et dépendre moins d’une API tierce. C’est surtout utile pour les longues sessions de refactorisation, debug, lecture de code ou génération de tests.
Quel backend choisir pour commencer ?
Ollama est souvent le choix le plus simple pour démarrer. Il gère le téléchargement des modèles, le service local et l’exécution sur CPU ou GPU. LM Studio est pratique avec une interface visuelle, et llama.cpp convient mieux si vous voulez un contrôle plus fin.
Quelles variables d’environnement faut-il configurer ?
La variable centrale est ANTHROPIC_BASE_URL. Selon le backend, il faut aussi gérer ANTHROPIC_API_KEY ou ANTHROPIC_AUTH_TOKEN. Les variables ANTHROPIC_DEFAULT_SONNET_MODEL, ANTHROPIC_DEFAULT_HAIKU_MODEL et ANTHROPIC_DEFAULT_OPUS_MODEL servent à indiquer les modèles par défaut.
Un modèle local suffit-il pour coder sérieusement ?
Pour beaucoup de tâches, oui : complétion, refactorisation, debug simple, explication de code, génération de tests. Pour les problèmes très complexes, un gros modèle cloud peut rester meilleur. Le meilleur usage est souvent hybride : local pour le quotidien, cloud pour les cas vraiment exigeants.

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent passer de l’idée sympa au système qui tourne vraiment, sans usine à gaz. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez intégrer l’IA, automatiser vos workflows ou fiabiliser vos données, contactez-moi.

Franck Scandolera

⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.

Pourquoi passer Claude Code en local ?

Gemini Omni peut-il créer des vidéos par IA ?

Quels articles lire pour comprendre les LLM ?