Blog · IA
Faire tourner l'IA chez soi : quand c'est justifié, quand c'est un piège
Un modèle local n'est pas une version économique du cloud. C'est un arbitrage différent, avec ses propres factures. Voici les raisons qui tiennent, celles qui ne tiennent pas, et ce qui tourne réellement sur une machine aujourd'hui.
La mauvaise raison, d'abord
« On va héberger le modèle nous-mêmes, ça coûtera moins cher. » C'est l'argument qui revient le plus souvent, et c'est presque toujours le plus faible.
Une carte graphique capable de faire tourner un modèle sérieux se compte en milliers d'euros, elle se déprécie, elle consomme, et elle passe ses nuits et ses week-ends à ne rien faire. En face, une API se facture à l'usage : zéro euro le mois où personne ne s'en sert. Pour un usage occasionnel ou une preuve de concept, le cloud gagne, et de loin.
Le local devient intéressant à partir d'un certain volume — quand la machine tourne vraiment — ou, bien plus souvent, quand une contrainte l'impose. Ce sont ces contraintes qui méritent le débat.
Les arguments qui tiennent
Quatre raisons sérieuses
La donnée ne sort pas
Ce n'est pas « chiffré en transit », ni « le fournisseur s'engage à ne pas entraîner dessus ». C'est : les documents ne quittent pas la machine, il n'y a pas de sous-traitant à déclarer, pas de transfert hors UE à justifier, pas de clause contractuelle à négocier.
Le modèle ne change pas sous vos pieds
C'est l'argument le plus sous-estimé. Un modèle d'API est mis à jour, réglé, puis un jour retiré. Vos prompts, eux, ne changent pas — mais leurs résultats, si. Personne ne vous prévient, et le jour où un comportement dérive, vous n'avez rien à comparer.
Un modèle local est un fichier. Vous le figez, vous l'archivez, vous notez son empreinte. Deux ans plus tard, la même entrée redonne la même sortie.
Pas de quota, pas de panne fournisseur, pas de réseau
Aucune limite de débit à négocier, aucune coupure à subir, et un fonctionnement possible sur un site isolé ou un réseau industriel fermé.
Un coût qui devient prévisible
Le cloud facture au jeton. Tant que le volume est faible, c'est un avantage. Quand l'usage se généralise, la facture suit — et elle suit une courbe que personne n'a budgétée au départ.
L'autre côté
Quatre raisons de ne pas le faire
L'écart de qualité existe encore
Les modèles ouverts ont énormément progressé et suffisent largement pour l'extraction, la classification, la reformulation, le résumé, la recherche documentaire. Sur les tâches les plus dures — raisonnement long, code complexe sur un dépôt entier — les modèles propriétaires de premier plan gardent une avance.
Vous devenez l'exploitant
Pilotes GPU, quantification, serveur d'inférence, supervision, montées de version, sauvegardes. Ce n'est pas insurmontable, mais c'est un métier, et il faut quelqu'un pour le faire — y compris pendant ses congés.
Le matériel se déprécie, et vite
Le GPU acheté aujourd'hui sera dépassé dans deux ans, alors que le cloud, lui, se met à jour tout seul. Ajoutez l'électricité, le refroidissement et le bruit : un serveur sous un bureau n'est pas un centre de données.
Vous portez seul la responsabilité
Plus de fournisseur vers qui se tourner. Le choix du modèle, sa licence, ses biais, ce qu'il produit : tout cela devient le vôtre, y compris devant un client ou un régulateur.
La règle que j'applique
Le local n'est pas de l'IA moins chère. C'est de l'IA sous contrainte. On le choisit parce qu'une contrainte l'impose — confidentialité, reproductibilité, isolement, volume stable — et on l'assume avec son coût d'exploitation. Si aucune de ces contraintes n'existe dans votre dossier, le cloud est probablement le bon choix, et ce n'est pas un aveu de faiblesse.
La liste
Ce qui tourne vraiment sur une machine
Relevé le 15 septembre 2026 dans la bibliothèque Ollama, qui a l'avantage de refléter ce qui s'installe réellement plutôt que ce qui s'annonce. Les tailles indiquées sont celles des fichiers à télécharger : c'est le bon ordre de grandeur pour estimer la mémoire vidéo nécessaire, à laquelle il faut ajouter le contexte.
| modèle | tailles | empreinte | contexte | pour quoi |
|---|---|---|---|---|
| Qwen 3.6 | 27B, 35B | 18 à 23 Go | 256K | Le généraliste le plus capable du moment en local. Codage agentique, raisonnement conservé d'un message à l'autre, entrée image. |
| Gemma 4 | E2B, E4B, 12B, 26B, 31B | 7,2 à 20 Go | 128K à 256K | La gamme la mieux étagée. Texte et image partout, audio sur les deux plus petits. Le 26B est un modèle à experts : 4 milliards de paramètres actifs seulement. |
| gpt-oss | 20B, 120B | 14 Go / 65 Go | 128K | Publié par OpenAI sous licence Apache 2.0. Le 20B tient sur une machine à 16 Go de RAM, le 120B sur un seul GPU de 80 Go. Raisonnement visible et réglable. |
| Qwen3-Coder | 30B, 480B | selon variante | long | Spécialisé code. Le 30B est le seul réaliste sur une machine unique. |
| DeepSeek-R1 | 1,5B à 671B | très variable | long | Raisonnement explicite. Les petites déclinaisons distillées tournent sur un portable, la 671B non. |
| Llama 3.1 / 3.2 | 1B, 3B, 8B, 70B, 405B | de 1 à 200+ Go | 128K | La famille la plus déployée, donc la mieux outillée et documentée. Plus la plus performante, mais la plus sûre à intégrer. |
| Mistral 7B | 7B | ~4 Go | moyen | Européen, très léger, tourne à peu près partout. Le bon point de départ pour un premier essai. |
| Phi-4 | 14B | ~9 Go | moyen | Petit et étonnamment solide sur les tâches structurées. |
| nomic-embed-text bge-m3 |
très petits | < 1 Go | — | Ce ne sont pas des modèles de discussion mais des modèles d'embedding, pour chercher dans vos documents. Voir ci-dessous : c'est souvent le vrai besoin. |
Deux avertissements sur cette liste
Le classement par téléchargements ment. Llama 3.1 domine les compteurs parce qu'il est disponible depuis longtemps, pas parce qu'il est le meilleur aujourd'hui. Lisez ces chiffres comme de l'histoire, pas comme un palmarès.
La taille du fichier n'est pas la mémoire nécessaire. Elle en est le plancher. Le contexte occupe de la place en plus, et il en occupe d'autant plus que vous lui donnez de longs documents. Une carte de 24 Go fait tourner confortablement un modèle de 27 à 31 milliards de paramètres quantifié — pas davantage.
Le conseil qui change le dossier
Votre problème n'est probablement pas la taille du modèle
Ce sont vos documents
La plupart des besoins internes ressemblent à ceci : « je voudrais interroger nos procédures, nos contrats, nos comptes rendus ». Aucun modèle, si gros soit-il, ne connaît vos procédures. La réponse n'est donc pas un modèle plus puissant, mais un petit modèle bien alimenté : vos documents découpés, indexés par un modèle d'embedding, puis fournis au modèle au moment de la question.
C'est la configuration qui coûte le moins cher, qui tourne sur du matériel modeste, et dont les réponses sont vérifiables — puisqu'on peut afficher le passage source. On revient au critère de la vérifiabilité : une réponse qu'on ne peut pas remonter à un document est une réponse qu'on ne peut pas utiliser.
Sources : bibliothèque Ollama (relevé du 15 septembre 2026 pour les familles disponibles et les compteurs de téléchargement), et les fiches Qwen 3.6, Gemma 4 et gpt-oss pour les tailles de fichiers, fenêtres de contexte et licences. Les tailles évoluent vite : vérifiez la fiche du modèle au moment de votre choix. Les conditions de licence varient d'une famille à l'autre — cet article ne remplace pas leur lecture.
Local ou cloud : lequel pour votre cas ?
La réponse dépend de trois choses — vos données, votre volume, et ce que vous devrez prouver un jour. C'est une heure de discussion, pas un comparatif de fiches techniques.
Demander un premier échange