Le reflexe naturel d'un developpeur en 2026 quand il commence a integrer l'IA dans son workflow est de s'abonner a une API : Anthropic, OpenAI ou Google. Cette approche fonctionne, mais elle s'accompagne de quatre limitations que beaucoup de developpeurs decouvrent trop tard. Le cout qui grimpe avec l'usage. La latence reseau qui casse les flows interactifs. Les donnees envoyees sur des serveurs tiers, parfois en dehors de l'UE. La dependance a une connexion internet. Faire tourner un LLM en local resout ces quatre problemes simultanement, et l'outil qui rend cela accessible aux developpeurs ordinaires s'appelle Ollama. Cet article explique comment l'installer, choisir les bons modeles, l'integrer a vos outils de developpement, et juger honnetement de ses limites face aux frontier models.
Ollama en deux mots
Ollama est un outil open source qui simplifie radicalement le deploiement de LLM en local. Il encapsule la complexite de llama.cpp, gere le telechargement des modeles depuis un registre, expose une API HTTP compatible OpenAI, et fournit une CLI intuitive. Concretement, en deux commandes vous avez un Llama 3 ou un DeepSeek-Coder qui repond sur votre machine.
Le succes d'Ollama tient a sa philosophie. Pas de configuration complexe. Pas de fichiers de poids a telecharger manuellement. Pas de quantization a configurer. Vous tapez ollama run llama3 et trois minutes plus tard vous discutez avec le modele. Cette simplicite a fait passer les LLM locaux de hobby de chercheurs a outil mainstream pour developpeurs.
Le projet est ecrit en Go, supporte macOS, Linux et Windows, et accepte les acceleration GPU NVIDIA, AMD, Apple Silicon et Intel Arc. Il s'integre nativement avec les principaux editeurs IA, frameworks d'orchestration et outils CLI.
Installation et premier modele
Sur macOS et Windows, Ollama s'installe comme une application classique depuis le site officiel. Sur Linux, une commande shell unique fait l'installation et configure le service systemd pour un demarrage automatique.
Apres installation, le service Ollama tourne en arriere-plan et expose une API HTTP sur le port 11434. La CLI permet d'interagir avec cette API et de gerer les modeles.
Pour telecharger et lancer Llama 3, une seule commande suffit. Ollama detecte la quantization optimale pour votre machine et lance le modele en interactif. La premiere requete est un peu longue (chargement en RAM ou VRAM), les suivantes repondent en quelques centaines de millisecondes.
Pour DeepSeek-Coder, le mecanisme est identique. Vous changez juste le nom du modele dans la commande. Le registre Ollama contient en 2026 plusieurs centaines de modeles : Llama 3 et 4 dans toutes les tailles, Mistral, DeepSeek, Qwen, Phi, Gemma, et leurs derives specialises (code, math, vision, RAG).
Choisir le bon modele pour le bon usage
L'ecosysteme open source en 2026 ne se resume plus a Llama. Plusieurs familles de modeles dominent et se specialisent.
Llama 3 et Llama 4 (Meta) restent les references generalistes. Llama 3 8B est le couteau suisse des LLM locaux : suffisant pour beaucoup de cas, accessible a quasi toute machine moderne. Llama 3 70B et Llama 4 Scout offrent une qualite proche des modeles proprietaires sur les machines bien equipees.
DeepSeek-Coder et Qwen 2.5 Coder sont les references pour le code. Sur des taches de generation, completion et explication de code, ces modeles battent regulierement Llama generaliste. La version 33B de DeepSeek-Coder atteint des performances proches de GPT-4 sur HumanEval pour une fraction des ressources.
Mistral et Codestral (Mistral AI) brillent sur l'efficacite. Mistral Small et Codestral 22B offrent un excellent compromis qualite-vitesse, particulierement adaptes aux machines de developpement standard.
Phi-4 et Gemma 3 (Microsoft, Google) ciblent les modeles compacts performants. Sur des machines a faible RAM ou pour des cas d'usage embarque, ces modeles de 4 a 8 milliards de parametres rivalisent avec des modeles deux fois plus gros.
Le choix se fait sur trois criteres : la specialisation (code, generaliste, conversation), la taille (capacite RAM/VRAM disponible), la quantization (compromis qualite-vitesse). En pratique, demarrer avec un modele 8B quantize en Q4 puis monter en gamme est une trajectoire rationnelle.
Performances reelles : ce que vous obtenez
Les performances en local depend du materiel. Trois configurations typiques donnent des reperes utiles.
Sur un MacBook Pro M3 Max avec 64 Go de RAM unifiee, Llama 3 70B en Q4 tourne a 15 a 25 tokens par seconde. C'est lent pour une conversation interactive mais utilisable pour de la generation batch. Llama 3 8B en Q4 atteint 60 a 100 tokens par seconde, ce qui ressemble a une experience d'API. DeepSeek-Coder 33B en Q4 produit du code coherent a 20 a 30 tokens par seconde.
Sur un PC desktop avec une RTX 4090 (24 Go VRAM), Llama 3 70B ne tient pas sans offload partiel sur RAM CPU, ce qui ramene les performances a 5 a 10 tokens par seconde. En revanche, Llama 3 8B et DeepSeek-Coder 14B tiennent integralement en VRAM et atteignent 100 a 200 tokens par seconde.
Sur un laptop de developpeur classique (16 a 32 Go RAM, GPU integre ou modeste), Llama 3 8B en Q4 ou Q5 reste utilisable a 20 a 40 tokens par seconde. DeepSeek-Coder 7B est l'option recommandee pour le code. Les modeles plus gros sont impraticables.
La regle pratique : un modele tient en RAM (ou VRAM) si sa taille en GB est environ egale a son nombre de parametres divise par 2 pour Q4, ou par 1 pour Q8. Llama 3 8B en Q4 fait environ 4,5 GB. Llama 3 70B en Q4 fait environ 40 GB.
Integration dans votre IDE
Ollama expose une API compatible OpenAI sur localhost:11434. Cette compatibilite est la cle de son adoption : tous les outils qui supportent OpenAI fonctionnent avec Ollama en changeant juste l'URL de base.
Pour Cursor ou VS Code avec Continue.dev, la configuration prend deux minutes. Vous pointez votre client sur l'URL locale d'Ollama au lieu de l'API OpenAI, vous specifiez le modele a utiliser, et l'experience est identique. La latence devient proche de zero, les couts disparaissent.
Pour Claude Code, l'integration est moins directe (Claude Code est specifique a Anthropic) mais des forks open source comme aider et cline supportent nativement Ollama. Voir notre [comparatif des alternatives a Claude Code](/aider-pair-programming-ia-terminal/) pour des options qui combinent agents CLI et LLM locaux.
Pour les outils CLI generalistes, aider --model ollama/codellama:33b lance un agent de pair programming entierement local. Pour les frameworks d'orchestration, LangChain, LlamaIndex et Haystack supportent Ollama nativement comme backend.
Cas d'usage qui fonctionnent vraiment
Tous les cas d'usage ne sont pas adaptes au LLM local. Trois patterns donnent des resultats serieux en 2026.
Le premier est la completion de code intra-projet. Un modele code 7B a 14B en local sur un laptop developpeur produit des suggestions instantanees, de qualite suffisante pour 80 % des taches courantes. La latence proche de zero est un avantage tangible sur l'experience d'usage.
Le deuxieme est le traitement batch de donnees confidentielles. Documentation interne a indexer, logs sensibles a analyser, donnees client a categoriser. Quand les donnees ne peuvent pas sortir de l'organisation, un Llama 3 70B local devient une option realiste pour un cout d'infrastructure modeste.
Le troisieme est le prototypage et l'experimentation. Tester un nouveau prompt, valider une approche RAG, evaluer la qualite d'un dataset peut se faire en local sans facturer un centime d'API. Une fois la validation faite, le passage en production peut basculer sur un modele plus puissant si necessaire.
A l'inverse, les cas d'usage qui exigent les capacites des frontier models (raisonnement complexe, analyse de plusieurs sources, manipulation de tres longs contextes au-dela de 32k tokens) restent mieux servis par les API. Le LLM local n'est pas un remplacement universel, c'est un complement.
Les vraies limites en 2026
Trois limites importantes meritent d'etre connues avant de basculer une partie significative de son workflow en local.
La premiere limite est l'ecart de qualite avec les frontier models. Un Llama 3 70B local est tres correct, mais Claude Opus 4.7 ou GPT-5 le surpassent significativement sur les taches complexes. Cet ecart se resorbe progressivement (les modeles open source rattrapent), mais il reste mesurable en 2026. Sur les taches simples, l'ecart est anecdotique. Sur les taches qui exigent du raisonnement multi-etapes, il est notable.
La deuxieme limite est le contexte. Les LLM locaux atteignent typiquement 32k a 128k tokens de contexte effectif sur des machines de developpeur. Les frontier models proposent jusqu'a 1 million. Pour beaucoup de cas, 32k suffit. Pour analyser une grosse codebase ou un long document, les API gardent un avantage structurel.
La troisieme limite est la chaleur et la batterie. Un laptop qui fait tourner un LLM 70B chauffe et consomme. La batterie ne tient pas longtemps. Pour un usage permanent, un poste fixe ou une machine dediee devient pertinent. C'est un detail concret mais qui limite l'usage en mobilite.
Le compromis cout-controle-qualite
L'arbitrage entre LLM local et API se fait sur trois axes. Le cout (favorable au local apres amortissement materiel pour usage intensif). Le controle (favorable au local pour donnees sensibles ou conformite). La qualite (favorable a l'API pour les taches complexes ou les forts volumes de contexte).
La meilleure pratique en 2026 n'est pas de choisir mais de combiner. Llama 3 8B local pour la completion temps reel et les taches simples, Claude ou GPT pour les taches complexes. Cette hybridation tire le meilleur des deux mondes : reactivite et cout maitrise sur le quotidien, capacite et qualite sur les moments critiques.
Pour pousser cette logique plus loin, voir notre [stack complete du dev IA-first](/stack-complete-developpeur-ia-first-2026/) qui detaille comment articuler les differentes couches d'IA dans un workflow professionnel.
La discipline qui differencie les utilisateurs serieux
Installer Ollama et lancer Llama 3 prend cinq minutes. En tirer une valeur reelle dans son workflow demande davantage de discipline. Trois habitudes distinguent les utilisateurs qui obtiennent des gains durables des curieux qui abandonnent apres deux semaines.
La premiere est de mesurer. Garder trace du temps gagne, des tokens consommes, des cas d'usage qui marchent et de ceux qui echouent. Sans donnees, les biais cognitifs prennent le dessus et l'usage devient irrationnel.
La deuxieme est de specialiser. Plutot que d'utiliser un modele generaliste pour tout, charger plusieurs modeles selon la tache : code (DeepSeek), documentation (Llama), traduction (Mistral), embeddings (BGE). Ollama gere les modeles multiples sans effort.
La troisieme est de garder un pied dans les frontier models. Le LLM local est un complement, pas un substitut. Comparer reguliereement la qualite obtenue en local avec ce que produirait Claude ou GPT permet de calibrer ses attentes et de detecter les regressions invisibles autrement.
Avec ces disciplines, Ollama transforme la maniere dont un developpeur utilise l'IA au quotidien. Plus rapide, plus prive, plus economique sur le long terme. Pas un remplacement universel des API mais un levier serieux que tout developpeur IA-first devrait connaitre.
