On lance Gemma 4 en local avec Ollama, puis on branche Claude Code dessus pour créer des boucles agentiques moins chères et plus privées. Le vrai sujet, c’est la config contextuelle, la VRAM, les modèles à choisir et les pièges qui font exploser une session.
Pourquoi utiliser Gemma 4 en local ?
J’utilise Gemma 4 en local quand je veux réduire les coûts d’API, garder mon code hors de serveurs tiers et lancer des agents capables de travailler longtemps sur un projet.
Le sujet devient vite concret avec les workflows agentiques. Un agent de développement ne fait pas juste une question, une réponse. Il lit des fichiers, garde un historique, appelle des outils, relance des commandes, corrige, recommence. Chaque boucle consomme des tokens, c’est-à-dire des morceaux de texte envoyés au modèle. Plus le contexte grossit, plus la facture devient floue.
Avec Claude Code, l’idée est de garder une bonne interface d’agent pour coder, naviguer dans le projet et piloter les tâches. Ollama sert alors de runtime local, le moteur qui charge le modèle sur votre machine. Au lieu d’envoyer chaque interaction vers une API distante, on fait tourner Gemma 4 localement. Ça ne rend pas tout magique, mais ça change complètement le rapport au coût et à la confidentialité.
Le problème des API, c’est rarement le prix affiché au million de tokens. C’est l’usage réel. Un agent peut multiplier les appels outils, conserver un historique très long, retenter une commande, résumer, recharger des fichiers. On peut aussi tomber sur des rate limits, donc des limites de débit imposées par le fournisseur. Et là, le workflow casse au pire moment, souvent quand l’agent est en plein milieu d’une refacto.
Gemma 4 est intéressante parce que c’est une famille de modèles open weights, donc avec des poids téléchargeables et exécutables localement. Elle est adaptée aux usages de code, et sa licence Apache 2.0 facilite l’usage business et l’intégration en production. Les variantes disponibles couvrent plusieurs besoins :
| Variante | Usage typique |
| E2B | Tests rapides, petites tâches, machine modeste. |
| E4B | Bon compromis pour scripts, automatisation et analyse de code. |
| 26B MoE | Modèle plus capable, avec architecture Mixture of Experts, où seuls certains blocs spécialisés s’activent selon la requête. |
| 31B Dense | Modèle plus lourd, plus régulier, mais plus exigeant en ressources. |
Dans mes projets d’automatisation et d’IA, le vrai gain n’est pas juste le prix au token, c’est aussi de pouvoir itérer sans se demander à chaque commande si on vient de brûler du budget.
Le choix du modèle dépend surtout de la VRAM disponible, la mémoire vidéo de votre GPU, et de la taille de contexte dont l’agent a besoin.
Quel modèle Gemma 4 choisir ?
Je choisis Gemma 4 selon ma VRAM, mon besoin de contexte et le niveau d’autonomie que j’attends de l’agent. C’est vraiment le critère le plus simple, surtout avec Claude Code en local, parce qu’un agent qui code a besoin de respirer, de lire beaucoup de fichiers, et de garder le fil sans ralentir toutes les 30 secondes.
| Modèle | Tag Ollama | Besoin VRAM | Contexte | Meilleur usage |
| Edge 4B | gemma4:e4b | Environ 6 GB | 128K | Machines modestes, tests rapides, petites automatisations |
| Gemma 4 26B MoE | gemma4:26b | 16 à 18 GB | 256K | Meilleur compromis pour un agent local de code |
| Gemma 4 31B Dense | gemma4:31b | 24 à 32 GB | 256K | Qualité maximale si la machine suit |
Le 4B, je le vois comme le modèle pratique. Il démarre vite, il consomme peu, il permet de tester Claude Code sans se battre avec la machine. Par contre, il ne faut pas lui demander le même niveau de raisonnement sur une grosse base de code.
Le 26B MoE est souvent celui que je prends pour bosser sérieusement en local. MoE veut dire Mixture of Experts, ou mélange d’experts. Le modèle contient 128 experts, mais il n’en active qu’une partie à chaque passage, avec 8 experts activés plus 1 expert partagé. En clair, il ne fait pas tourner tout le cerveau à chaque token. Il utilise seulement les morceaux utiles.
L’intérêt, c’est d’obtenir une qualité proche d’un modèle dense plus lourd, avec un coût de calcul plus bas. Dans ce cas précis, le Gemma 4 26B MoE a environ 3.8B paramètres actifs par forward pass, c’est-à-dire par passage de calcul. C’est pour ça qu’il peut rester assez fluide avec 16 à 18 GB de VRAM.
Le 31B Dense, lui, c’est le choix qualité. Dense veut dire que tout le modèle travaille à chaque passage. C’est plus lourd, mais souvent plus stable sur les tâches complexes. Si vous avez une grosse carte GPU, typiquement 24 à 32 GB de VRAM, c’est celui que je viserais pour maximiser la qualité.
Les performances changent quoi ?
Les performances changent tout parce qu’un agent de code n’a pas seulement besoin de répondre, il doit raisonner, utiliser des outils et rester cohérent sur plusieurs fichiers.
Dans Claude Code, ça se voit très vite. Un modèle moyen peut générer une fonction correcte. Mais dès qu’il faut lire trois fichiers, modifier une config, lancer un test, comprendre l’erreur, revenir dans le bon fichier et corriger sans casser le reste, là on n’est plus dans le simple chat. On est dans une boucle agentique. C’est-à-dire une boucle où le modèle observe, décide, agit avec des outils, puis réévalue.
Le chiffre qui saute aux yeux, c’est τ2-bench. Ce benchmark mesure justement la capacité à utiliser des outils dans un scénario agentique. Gemma 3 27B est à 6.6%. Gemma 4 26B MoE monte autour de 79%. Gemma 4 31B Dense arrive à 86.4%. Franchement, c’est pas un petit gain. C’est le passage d’un modèle qui décroche souvent à un modèle qui peut tenir une tâche structurée.
| Benchmark | Gemma 3 27B | Gemma 4 26B MoE | Gemma 4 31B Dense |
| τ2-bench, usage agentique des outils | 6.6% | ≈ 79% | 86.4% |
| LiveCodeBench v6, code | Score fourni dans le benchmark | Score fourni dans le benchmark | Score fourni dans le benchmark |
| GPQA Diamond, raisonnement | Score fourni dans le benchmark | Score fourni dans le benchmark | Score fourni dans le benchmark |
| AIME 2026, maths | Score fourni dans le benchmark | Score fourni dans le benchmark | Score fourni dans le benchmark |
| Arena AI ELO, préférence globale | Score fourni dans le benchmark | Score fourni dans le benchmark | Score fourni dans le benchmark |
MoE veut dire “Mixture of Experts”. En gros, le modèle active seulement certaines parties spécialisées selon la demande. Dense veut dire que tout le modèle travaille à chaque réponse. Dans la pratique, le Dense peut être plus régulier, le MoE peut être plus efficace à taille proche.
Ce que ça change pour vous, c’est assez concret. Moins d’allers-retours. Moins de moments où l’agent oublie pourquoi il a ouvert un fichier. Moins de corrections qui réparent une chose et en cassent deux autres. J’ai vu ça chez un client sur des refactos backend assez banals : le problème n’était pas d’écrire du code, c’était de garder le fil entre les fichiers, les tests et les contraintes métier.
Un benchmark ne garantit jamais qu’un agent réussira chaque refacto. Mais il donne un signal utile. Il dit si le modèle sait tenir une boucle agentique crédible, et pour lancer Gemma en local avec Claude Code, c’est exactement le point qui compte.
Comment installer la stack locale ?
J’installe d’abord Ollama, je télécharge Gemma 4, puis j’installe Claude Code avec Node.js 18 ou plus.
Ollama, c’est le petit moteur local qui va servir le modèle sur votre machine. Sur macOS ou Linux, je pars sur l’installation officielle, simple et rapide.
Commande Ollama macOS ou Linux : curl https://ollama.com/install.sh | sh
Une fois installé, Ollama tourne en arrière-plan avec une API locale sur le port 11434. C’est important, parce que Claude Code va parler à ce service local comme à une API classique.
Vérification du service : curl http://localhost:11434
Je vérifie aussi la version, parce que certaines intégrations récentes dépendent vraiment de ça. Le support de l’Anthropic Messages API demande Ollama 0.14.0 ou plus. Pour ce setup, je viserais plutôt une version 0.22.x ou plus en mai 2026, histoire d’éviter les comportements bizarres.
Vérification de version : ollama –version
Ensuite je récupère le modèle. Là, attention au poids. Avant de télécharger un modèle lourd, je vérifie toujours la VRAM disponible, parce qu’une mauvaise surprise à ce moment-là fait perdre plus de temps que lire la doc deux minutes. Je l’ai vu chez un client récemment, ils avaient tout bien configuré, mais le modèle partait en swap dès le lancement. Résultat, une machine inutilisable pendant une demi-heure.
Téléchargement du modèle : ollama pull gemma4:26b
Quand le téléchargement est terminé, je vérifie que le modèle est bien là et je regarde ce qui tourne réellement.
Voir les modèles actifs : ollama ps
Voir les modèles installés : ollama list
Pour Claude Code, il faut Node.js 18 minimum. Si votre version de Node est trop ancienne, l’installation peut passer à moitié ou planter avec des erreurs npm pas très parlantes.
Installation de Claude Code : npm install -g @anthropic-ai/claude-code
Vérification : claude –version
À ce stade, la base locale est prête : Ollama sert Gemma 4 en local, Claude Code est installé, et on peut commencer à connecter les deux proprement.
Pourquoi le Modelfile est critique ?
Le Modelfile est critique parce qu’Ollama peut lancer Gemma 4 avec une fenêtre de contexte trop petite si on ne la surcharge pas.
Le piège, il est là. Gemma 4 peut supporter de très grands contextes, souvent entre 128K et 256K tokens selon la variante. Un token, c’est grosso modo un morceau de mot, donc ça monte vite. Mais si rien n’est configuré côté Ollama, vous pouvez vous retrouver avec un contexte autour de 4K tokens. Et dans une session Claude Code, 4K, c’est minuscule.
Votre historique de conversation prend de la place. Les fichiers lus prennent de la place. Les consignes système, les instructions projet, les retours d’outils, les erreurs terminal, tout ça rentre dans la même fenêtre. J’ai déjà vu un agent “devenir bête” chez un client alors que le modèle était bon. Il oubliait juste ce qu’il venait de lire dix minutes avant.
Les symptômes sont assez faciles à repérer :
- L’agent oublie vos consignes alors qu’elles étaient claires.
- Il perd le suivi des fichiers déjà analysés.
- Il modifie un bout de code sans comprendre le reste du projet.
- Il recommence des analyses déjà faites.
- Il donne une impression d’incohérence, alors que le vrai problème vient du contexte trop court.
Le Modelfile sert justement à créer une variante locale avec les bons paramètres. Ici, je reste volontairement simple. L’idée, c’est de partir du modèle de base et de surcharger uniquement la taille de contexte.
FROM gemma4:26b
PARAMETER num_ctx 131072Ici, num_ctx 131072 correspond à 128K tokens. C’est déjà confortable pour un usage agentique avec Claude Code. Mais attention, plus de contexte veut aussi dire plus de mémoire, plus de calcul, et parfois moins de vitesse. Il faut trouver l’équilibre entre confort de travail et capacité réelle de votre machine.
| Erreur fréquente | Impact |
| Contexte par défaut trop bas | L’agent oublie vite et travaille à l’aveugle. |
| Modèle trop lourd pour la VRAM | La machine ralentit, swap, ou plante. |
| Rate limits si fallback API | Les appels distants bloquent la session. |
| Coût tokens non surveillé | La facture peut monter sans bruit. |
| Attentes trop élevées sur une machine limitée | Le setup paraît mauvais alors qu’il est juste sous-dimensionné. |
Et maintenant on le fait tourner où ?
Gemma 4 en local avec Ollama et Claude Code, c’est une piste sérieuse si vous voulez lancer des agents de code sans dépendre à chaque seconde d’une API externe. Le vrai choix se joue entre VRAM, contexte et qualité attendue. Le 26B MoE a ce côté très intéressant : beaucoup de capacité, mais un coût de calcul plus raisonnable qu’un dense lourd. Le point à ne pas rater, c’est le Modelfile, surtout la fenêtre de contexte. Avec une stack bien réglée, vous gagnez en confidentialité, en maîtrise des coûts et en liberté d’itération.
FAQ
- Gemma 4 peut-il vraiment remplacer une API LLM pour coder ?
Gemma 4 peut remplacer une API dans certains workflows de code local, surtout si vous cherchez à réduire les coûts, garder le code en interne et lancer des boucles agentiques. Ça ne veut pas dire que tous les cas seront meilleurs qu’une API distante. La machine, la VRAM, le contexte et le modèle choisi font une grosse différence. - Pourquoi utiliser Ollama avec Gemma 4 ?
Ollama sert à exécuter le modèle localement et à l’exposer sur votre machine, généralement via le port 11434. C’est la brique qui permet de télécharger Gemma 4, de le lancer et de le rendre utilisable dans une stack locale avec Claude Code. - Quelle variante de Gemma 4 choisir pour Claude Code ?
Le 26B MoE est le compromis le plus intéressant si vous avez environ 16 à 18 GB de VRAM. Il active environ 3.8B paramètres par passage, tout en visant une qualité proche d’un modèle dense plus lourd. Le 31B Dense demande plus de VRAM, autour de 24 à 32 GB, mais vise une meilleure qualité. - Pourquoi la fenêtre de contexte est-elle si importante ?
Un agent de code lit des fichiers, garde l’historique, applique des consignes et appelle des outils. Si Ollama reste sur une fenêtre de contexte trop petite, par exemple 4K tokens, l’agent perd vite le fil. Gemma 4 peut monter beaucoup plus haut selon la variante, mais il faut le configurer correctement. - Quels sont les principaux pièges d’une stack IA locale ?
Les pièges classiques sont simples : choisir un modèle trop lourd pour la VRAM, oublier de régler le contexte dans le Modelfile, sous-estimer les besoins mémoire, garder un fallback API sans surveiller les coûts, ou attendre d’un modèle local qu’il fasse parfaitement chaque refacto sans cadre clair.
A propos de l’auteur
Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des équipes sur le tracking server-side avancé, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA en entreprise et les sujets SEO/GEO. 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 mettre en place des workflows IA propres, utiles et maîtrisés côté business, vous pouvez me contacter.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, 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.