Faire tourner des agents de code en local avec Ollama

Peut-on faire tourner un agent de code en local avec Ollama pour réduire le coût d'API ?

Oui — vous pouvez pointer un agent de code vers un modèle servi par Ollama sur votre propre machine et ne rien payer par token, mais l'inférence locale est un scalpel, pas un remplacement d'une API frontière. Elle gagne nettement sur le travail à fort volume et à faible enjeu qui domine discrètement votre facture — le boilerplate, les messages de commit, le triage de logs, les éditions répétitives — et perd sur le raisonnement difficile, là où un modèle 7B vous servira volontiers des absurdités avec aplomb. La vraie stratégie n'est pas « le local au lieu de l'API » ; c'est router chaque tâche vers le moteur le moins cher capable de réellement l'exécuter. Je dirige une entreprise d'outillage autour des tokens, donc je passe beaucoup de temps à observer où part l'argent des agents de code. La vérité dérangeante, c'est qu'une grande part des tokens que vous payez au prix frontière sont dépensés sur des tâches qu'un modèle local gère très bien. C'est la version agnostique vis-à-vis de l'agent de l'argument développé dans Comment réduire l'usage de tokens d'un agent de code IA ; ici je le resserre sur un levier précis — sortir complètement du travail du compteur.

Qu'est-ce qu'Ollama et pourquoi l'utiliser pour des agents de code ?

Ollama est un runtime de modèles local : il télécharge des modèles à poids ouverts et les sert derrière une API HTTP sur votre propre matériel. Vous l'installez, vous lancez ollama pull qwen2.5-coder:7b, et vous disposez d'un endpoint compatible OpenAI à http://localhost:11434 que n'importe quel outil parlant ce protocole peut interroger. L'attrait pour les agents de code est sans détour : chaque token traité en local est un token que vous ne payez à aucune API. Pas de facturation par MTok, pas de rate limit imposé par un fournisseur, et rien ne quitte votre machine. Pour les bases de code sensibles à la confidentialité, ce dernier point suffit à lui seul à justifier l'approche. L'inconvénient est tout aussi sans détour : un modèle que vous pouvez faire tourner sur un portable n'est pas Claude Opus. Le terrain des modèles de code ouverts est devenu vraiment bon — Qwen2.5-Coder, DeepSeek-Coder, Codestral, la famille Llama 3.x — mais un modèle 7B–14B quantisé tournant sur du matériel grand public se situe quelque part entre le « stagiaire utile » et le « stagiaire qui hallucine de temps en temps ». Savoir quelles tâches tombent dans cette fourchette, c'est toute la compétence.

Quelles tâches de code faut-il exécuter en local plutôt que sur l'API ?

Exécutez en local les tâches à fort volume, vérifiables et à faible raisonnement ; gardez sur l'API frontière le travail difficile, ambigu, à forme architecturale. La ligne de partage est en gros : « un junior compétent peut-il faire ça en une passe, et puis-je vérifier le résultat à moindre coût ? » Bons candidats pour un modèle Ollama local :

Messages de commit et descriptions de PR. Un diff en entrée, une phrase en sortie. Facile à vérifier, et un modèle 7B s'en sort bien.
Boilerplate et scaffolding. Handlers CRUD, stubs de tests, fichiers de config, définitions de types à partir d'un schéma. De la complétion de motif, pas de l'invention.
Triage de logs et d'erreurs (première passe). Résumer une stack trace de 2 000 lignes jusqu'à l'assertion qui échoue. Cela recoupe directement l'output filtering — l'essentiel de ce log n'a jamais été du signal.
Éditions mécaniques répétitives. Renommer à travers plusieurs fichiers, refactos mécaniques, génération de docstrings.
Recherche et classification locales. « Lesquels de ces fichiers touchent à l'auth ? » est une tâche qu'un modèle d'embedding plus un petit classifieur font gratuitement.

À garder sur l'API frontière :

Décisions d'architecture et de conception. Où placer une frontière, comment modéliser l'état, quel compromis prendre. Un modèle 7B n'a pas le modèle du monde nécessaire pour cela.
Débogage subtil. Conditions de course, off-by-one dans du code concurrent, « pourquoi ça n'échoue qu'en CI ». Le raisonnement difficile est exactement là où les petits modèles bluffent.
Tout ce qui touche à l'argent, à l'auth ou à l'intégrité des données. Le coût d'une mauvaise réponse écrase n'importe quelle économie de tokens.

Ma règle empirique : si je serais à l'aise de merger la sortie après un coup d'œil de 10 secondes, ça peut tourner en local. Si je devais vraiment réfléchir à sa justesse, ça part sur l'API.

Combien fait-on réellement d'économies en faisant tourner les agents de code en local ?

Vous économisez ce que vous dépensiez sur le travail que vous sortez du compteur — et pour beaucoup d'équipes c'est une part étonnamment grande. Pour rendre cela concret, regardez les prix d'API que vous évitez. Le haut de gamme du code se situe autour de Claude Opus 4.8 à 5 $ / 25 $ par million de tokens d'entrée/sortie, Sonnet 5 à 2 $ / 10 $, et GPT-5.5 à 5 $ / 30 $. Même les petits modèles frontière — Claude Haiku 4.5 à 1 $ / 5 $ — ne sont pas gratuits. Imaginez maintenant une journée normale d'usage d'agent. Une fraction non négligeable, ce sont des messages de commit, des résumés de logs et du boilerplate — du travail riche en sortie et pauvre en raisonnement. Les output tokens, c'est là que le compteur s'emballe vraiment (voyez les lignes à 25 $ et 30 $ de sortie ci-dessus), et c'est précisément le genre de travail qu'un modèle local peut absorber. Sortez-le, et vous cessez complètement de payer les prix de sortie pour cela. Je ne vais pas vous servir un faux chiffre « économisez 70 % » — votre répartition dépend entièrement de votre charge de travail, et quiconque cite un pourcentage universel devine. Le cadrage honnête : instrumentez d'abord, décidez ensuite. Si vous n'avez jamais mesuré où vont vos tokens, commencez par Comment mesurer l'usage de tokens de votre agent ou le calculateur de coût de tokens d'API LLM avant de supposer que le local va aider. Vous pourriez découvrir que la part des tâches bon marché est déjà minuscule — auquel cas l'inférence locale résout un problème que vous n'avez pas. Une subtilité que les gens manquent : les API frontière remisent déjà fortement le contexte répété. Avec le prompt caching, les cache reads tournent autour de 10 % du prix d'entrée normal, donc la « coûteuse » relecture d'un system prompt ou d'un fichier stable est bien moins chère que ne le suggère le tarif d'entrée affiché. L'inférence locale n'est pas en concurrence avec l'entrée mise en cache — elle est en concurrence avec la génération fraîche et riche en sortie. Visez-la là.

Comment configurer Ollama avec un agent de code ?

Vous le configurez en servant un modèle de code avec Ollama, puis en pointant votre agent vers son endpoint compatible OpenAI. La mécanique est courte :

Installez Ollama et téléchargez un modèle de code dimensionné à votre matériel. Sur une machine de 16 Go, qwen2.5-coder:7b est un défaut raisonnable ; avec plus de VRAM, montez aux variantes 14B ou 32B. La quantisation (les tags q4/q5) échange un peu de qualité contre beaucoup de marge mémoire.
Lancez le serveur. Ollama expose http://localhost:11434/v1 dans une forme compatible OpenAI, donc la plupart des agents qui vous laissent surcharger l'URL de base et le nom du modèle s'y connecteront directement.
Pointez un second profil d'agent vers lui. Ne remplacez pas votre configuration frontière — ajoutez-en une locale à côté. Gardez votre bon modèle pour le travail difficile ; routez les tâches bon marché vers le profil local.
Décidez de la règle de routage. C'est la partie que tout le monde saute. « Utiliser le modèle local pour les messages de commit et les résumés de logs » n'économise de l'argent que si quelque chose l'applique réellement. Un simple wrapper, un git hook pour les messages de commit, ou une étape explicite « résume avec le modèle local » suffit pour commencer.

Les outils diffèrent dans leur manière d'accepter un endpoint personnalisé — certains supposent un seul fournisseur — alors consultez la doc de votre agent spécifique pour la surcharge de l'URL de base. Si vous choisissez votre outillage de zéro, les meilleurs outils de code IA comparent les principales options.

Qu'est-ce qui tourne mal quand on passe les agents en local ?

Trois modes de défaillance expliquent l'essentiel des déceptions, et les trois sont prévisibles. Vous routez du travail à fort raisonnement vers un petit modèle et vous lui faites confiance. C'est le gros piège. Un modèle 7B produira une réponse fluide, confiante et fausse à une question de conception subtile, sans jamais signaler sa propre incertitude. Le dommage n'est pas la mauvaise réponse — c'est que vous l'avez mergée. Les modèles locaux sont pour le travail que vous pouvez vérifier à moindre coût ; si vous ne pouvez pas le vérifier à moindre coût, ça n'a pas sa place en local. Vous oubliez que l'inférence locale coûte quand même du contexte. Déplacer une tâche vers Ollama supprime la facture d'API, mais si vous nourrissez le modèle local d'un prompt boursouflé — un fichier de 4 000 lignes quand 40 lignes comptaient — il est lent, il peut dépasser le context window plus réduit du modèle, et la sortie se dégrade. La même hygiène qui économise les tokens d'API (envoyer moins, filtrer la sortie) est ce qui fait fonctionner tout court les modèles locaux. Le context engineering s'applique des deux côtés du compteur. Vous le traitez comme du tout-ou-rien. « J'ai essayé de tout faire tourner en local et la qualité s'est effondrée, alors je suis revenu à l'API pour tout. » Les deux extrémités de cette phrase sont fausses. Le gain, c'est la répartition, et la répartition doit être imposée par l'outillage, pas par le fait de penser à le faire manuellement à 18 h un vendredi.

Comment appliquer cela dès aujourd'hui

Mesurez avant de déplacer quoi que ce soit. Découvrez quelle fraction de vos tokens part vers des tâches bon marché et vérifiables. Si c'est petit, arrêtez-vous là — le local ne bougera pas votre facture.
Téléchargez un modèle de code dimensionné à votre matériel et confirmez que votre agent peut atteindre localhost:11434.
Déplacez exactement un type de tâche en local — les messages de commit sont le départ le moins risqué — et faites-le tourner pendant une semaine.
Gardez le modèle frontière pour tout le reste et laissez le prompt caching faire son travail sur le contexte stable.
Imposez le routage automatiquement pour que le chemin bon marché soit le défaut, pas quelque chose que vous activez à la main.

Le point plus profond : l'inférence locale est un levier, et elle ne traite que la part bon marché de votre dépense. La part chère — le modèle frontière qui fait du vrai travail — reste là où se trouve l'essentiel de l'argent, et vous la réduisez celle-là en lui envoyant moins. C'est là que Tokenade s'insère : il se place entre votre agent et le modèle et taille dans le gaspillage qui ne dépend pas du moteur utilisé — semantic code search au lieu de lectures gloutonnes de fichiers entiers, output filtering sur les logs de commandes bruyants, skeleton compression des gros fichiers, et chargement paresseux des MCP pour que les manifestes d'outils inutilisés cessent de voyager à chaque tour. Un dashboard d'économies vous montre exactement ce qui est sorti de la facture. C'est source-available et sous licence MIT, le palier gratuit couvre environ 10M de tokens par mois, et Pro est à 24,90 $/mois (HT), postes illimités. Local-first ou API-first, envoyer moins est le levier qui fonctionne sur les deux. Voyez comment Tokenade réduit l'usage de tokens pour le tableau complet.

À voir aussi :