LLM en local : pourquoi et comment en entreprise

Un LLM en local, c'est un modèle de langage qui tourne sur du matériel que l'entreprise contrôle : serveur interne, GPU loué chez un cloud européen ou poste de développement, plutôt que sur l'infrastructure d'OpenAI, Anthropic ou Mistral. Le sujet n'est plus théorique. Selon le baromètre France Num 2025, publié en septembre 2025 par la Direction générale des Entreprises, l'usage de l'IA générative dans les TPE et PME françaises est passé de 10 % à 22 % en un an. Plus il y a d'entreprises qui branchent un LLM sur des données réelles, plus la question de savoir où tourne ce modèle et qui y a accès devient concrète, et coûteuse à mal trancher.

Le calcul qui décide vraiment, pas la souveraineté

La souveraineté numérique est l'argument qu'on entend en premier pour justifier un LLM local. C'est un vrai sujet, il revient plus bas, mais il ne détermine pas si l'opération est rentable. Le facteur qui tranche, c'est le volume de tokens traités chaque mois.

Prenons les tarifs officiels du jour. Un modèle propriétaire de taille comparable comme Mistral Small facture l'inférence entre 0,15 et 0,6 dollar par million de tokens selon le sens. Un modèle open source de taille équivalente, hébergé en France chez OVHcloud sans que l'entreprise touche à un seul serveur, revient à 0,13 euro par million de tokens, à l'entrée comme à la sortie. Louer une carte GPU dédiée pour faire tourner ce même type de modèle en propre coûte, chez Scaleway, 0,79 euro de l'heure sur une instance à 24 Go de VRAM, soit un peu plus de 570 euros par mois si elle tourne sans interruption, qu'elle traite dix requêtes ou dix millions.

Le point de bascule se situe autour de 4,3 milliards de tokens mensuels, un débit que peu d'entreprises hors des plus gros comptes technologiques atteignent avec un seul cas d'usage. En dessous, le local perd largement la bataille du prix face au cloud managé.

Sources : Mistral, tarifs API, OVHcloud, catalogue AI Endpoints, Scaleway, tarifs des instances GPU, consultées le 23 juillet 2026.

Trois raisons qui justifient le local, et une qui ne suffit pas

Trois raisons rendent le local pertinent, indépendamment du seuil de volume vu plus haut.

La première est réglementaire. La CNIL a publié en mars 2025, avec France Num et la CPME, un guide dédié à l'usage de l'IA générative dans les TPE et PME, qui pose la question de la nature des données envoyées à un prestataire avant même le choix d'un outil. Pour un dossier médical, un contrat sous secret des affaires ou un dossier RH, la réponse tranche souvent le débat : si la donnée ne doit sous aucun prétexte transiter par un serveur tiers, même situé en Europe, le local ou un hébergement dédié chez un cloud français devient la seule option, quel que soit le prix.

La deuxième tient à la disponibilité. Un LLM local continue de répondre sans connexion internet ou en cas de panne côté fournisseur cloud, ce qui compte pour un outil embarqué sur un site industriel ou un usage terrain sans réseau fiable.

La troisième est la personnalisation. Un modèle open source affiné sur des données métier internes (contrats types, historique de tickets support, jargon interne) apprend un vocabulaire et des formats qu'un modèle propriétaire générique ne reproduira jamais aussi bien, et cet affinage n'est possible qu'avec un accès complet aux poids du modèle, donc avec un modèle qu'on héberge soi-même.

Une raison ne suffit pas seule à justifier le basculement : l'économie pure. D'après le calcul précédent, à faible ou moyen volume, le local coûte plus cher que le cloud managé, pas moins. Les entreprises qui migrent uniquement pour réduire la facture, sans avoir chiffré leur volume réel de tokens, finissent souvent par payer un serveur GPU dédié à l'année pour traiter un trafic qu'une API cloud aurait facturé quelques dizaines d'euros par mois.

Les cas où mieux vaut rester sur l'API cloud

Le local n'est pas la réponse par défaut. Trois signaux indiquent qu'il vaut mieux garder l'API cloud, au moins pour l'instant.

Le premier est un volume imprévisible ou faible. Une PME qui envoie quelques centaines de milliers de tokens par mois pour résumer des comptes rendus ou générer des brouillons d'e-mails n'atteindra jamais le seuil de rentabilité calculé plus haut, même après plusieurs années de croissance normale.

Le deuxième est le besoin de rester sur la frontière des capacités. Les modèles propriétaires les plus récents avancent plus vite en raisonnement complexe et en usage d'outils que ce qu'un modèle open source de taille raisonnable peut suivre sur du matériel accessible à une PME. OpenAI facture par exemple son modèle gpt-5.4-mini 0,75 dollar le million de tokens en entrée et 4,50 dollars en sortie, un tarif dérisoire face au coût d'une équipe qui maintiendrait elle-même une infrastructure GPU pour un usage ponctuel.

Le troisième est l'absence d'équipe capable d'opérer un serveur d'inférence. Un LLM auto-hébergé qui tombe en panne un vendredi soir sans personne d'astreinte coûte plus cher en interruption de service qu'il n'a jamais économisé en tarif au token. Sans équipe ops IA ni contrat de support, une inférence gérée comme celle que propose OVHcloud reste un compromis plus sûr que le local complet.

Du prototype à la production : le chemin technique

Une fois la décision prise, le chemin technique suit trois étapes distinctes, et confondre ces trois étapes est l'erreur la plus fréquente qu'on voit sur les projets clients.

La première est le prototypage. Faire tourner un modèle en local avec Ollama sur un poste de développeur permet de tester en quelques minutes si un modèle open source, Llama, Mistral, Qwen ou le gpt-oss d'OpenAI, répond correctement aux cas d'usage visés, sans engager de budget serveur. C'est l'étape qu'on saute trop souvent : une équipe commande un serveur GPU avant même de savoir si le modèle choisi comprend le jargon métier qu'on va lui donner.

La deuxième est la mise en production. Ollama est pensé pour un usage local et mono-utilisateur, pas pour répondre à plusieurs utilisateurs à la fois. Servir un modèle en production demande un moteur d'inférence dimensionné pour ça, comme vLLM, qui traite les requêtes par lots et exploite mieux la mémoire GPU disponible. C'est le saut technique entre un modèle qui répond bien sur un poste de test et un service qui tient la charge d'un usage client réel.

La troisième option, souvent oubliée, est l'inférence gérée. Plutôt que d'opérer soi-même un serveur vLLM, on peut confier l'hébergement d'un modèle open source à un fournisseur français qui facture au token, sans exposer les données hors d'Europe et sans astreinte à organiser en interne. C'est le compromis qu'on recommande le plus souvent aux clients qui n'ont pas vocation à recruter une équipe MLOps pour une seule fonctionnalité IA.

Sur les projets où on nous demande d'évaluer un passage au local, la première question qu'on pose n'est presque jamais technique. C'est de savoir qui, aujourd'hui, a le droit de voir cette donnée en interne, et si ce droit change dès qu'elle traverse l'Atlantique. La réponse tranche souvent le débat avant même de comparer un prix de GPU.

Dimensionner le matériel sans se tromper

Le dimensionnement se joue sur trois leviers : la taille du modèle, la quantification et le choix entre matériel loué et matériel possédé.

La taille du modèle d'abord. Un modèle à quelques milliards de paramètres suffit pour du résumé, de la classification ou de l'extraction structurée, les usages les plus fréquents en entreprise. Un modèle à plusieurs dizaines de milliards de paramètres devient nécessaire pour du raisonnement à plusieurs étapes ou de la génération de code complexe, mais il réclame nettement plus de mémoire GPU. Le dimensionnement exact par taille de modèle est détaillé dans notre guide Ollama cité plus haut.

La quantification ensuite. Elle consiste à stocker les poids du modèle sur moins de bits, 8 voire 4 au lieu de 16, ce qui réduit d'autant l'empreinte mémoire au prix d'une légère perte de précision, souvent imperceptible sur des tâches de résumé ou de classification. C'est le levier le plus simple pour faire tenir un modèle plus grand sur une carte GPU plus petite, donc moins chère.

Le choix matériel enfin. Louer une instance GPU chez un cloud comme Scaleway ou OVHcloud évite l'investissement initial et permet d'arrêter la facturation dès que le projet s'arrête, ce qui convient à un pilote ou à une charge qui varie. Acheter sa propre carte devient pertinent seulement quand la charge est stable et prévisible sur plusieurs années, l'amortissement du matériel prenant alors le dessus sur la location à l'heure. Entre les deux, l'inférence gérée facturée au token, comme le catalogue OVHcloud AI Endpoints vu plus haut, reste l'option qui demande le moins d'expertise interne, au prix d'un contrôle plus limité sur la configuration du modèle.

Garder la portabilité : ne pas s'enfermer dans un choix

Le risque du local n'est pas seulement le coût, c'est aussi de se retrouver coincé sur un modèle ou un fournisseur qu'on ne peut plus changer sans réécrire toute l'application.

La parade technique est connue. Faire transiter tous les appels au modèle, cloud ou local, par une interface compatible avec le format standard OpenAI. Un LLM gateway comme LiteLLM, Portkey ou OpenRouter joue ce rôle d'intermédiaire : le code applicatif appelle toujours la même interface, et c'est la configuration de la passerelle qui décide si la requête part vers Mistral, vers une instance Ollama locale ou vers un serveur vLLM en production. Basculer d'un fournisseur à l'autre devient un changement de configuration, pas un chantier de développement.

Cette portabilité compte particulièrement pendant la phase de test. Un modèle local moins cher mais plus lent sur certaines requêtes peut cohabiter avec un modèle cloud gardé en secours pour les cas complexes, le tout piloté depuis la même passerelle. C'est aussi ce qui permet de revenir en arrière si le calcul de rentabilité change : un fournisseur cloud qui baisse ses prix, ou un volume de tokens qui explose plus vite que prévu, ne doit pas obliger à réécrire l'intégration.

Pour une entreprise qui découvre ce sujet, le chemin le plus sûr reste de partir d'un prototype avec un modèle géré, de mesurer le volume réel de tokens sur trois mois d'usage, puis de reposer le calcul du début de cet article avec ses propres chiffres plutôt qu'avec les tarifs génériques cités ici. C'est ce type d'arbitrage qu'on mène avec les entreprises qui nous confient leur projet d'agent IA sur mesure.

Ce qu'on retient avant de se lancer

Trois repères suffisent pour trancher sans refaire toute l'étude.

Si le volume mensuel reste sous quelques centaines de millions de tokens et que les données n'ont rien de réglementairement sensible, rester sur une API cloud managée est le choix le plus rentable, quasiment à tous les coups. Le calcul fait plus haut ne s'inverse qu'à des volumes que la majorité des PME n'atteignent pas avant plusieurs années de croissance.

Si une contrainte réglementaire stricte impose que la donnée ne sorte jamais d'un périmètre défini, hôpital, cabinet d'avocats, banque, la question du prix devient secondaire. Le local ou l'hébergement dédié en France s'impose, et le budget se construit autour de cette contrainte plutôt que l'inverse.

Entre les deux, la meilleure porte d'entrée reste l'inférence gérée : un modèle open source hébergé chez un fournisseur français, facturé au token, qui évite d'avoir à recruter une équipe pour opérer un serveur GPU tant que le volume ne justifie pas cet investissement. C'est l'option qui laisse le temps de mesurer, avant de s'engager sur du matériel.

Le dernier repère est le plus simple à oublier : quel que soit le chemin choisi, garder la possibilité de changer de fournisseur ou de modèle sans réécrire l'application coûte presque rien à mettre en place dès le départ, et beaucoup à rattraper une fois le projet en production.

FAQ

Faut-il un GPU pour faire tourner un LLM en local en entreprise ?

Pas systématiquement pour prototyper : un modèle de quelques milliards de paramètres, quantifié, tourne sur un poste de développeur avec du CPU seul, lentement. Pour un usage en production avec plusieurs utilisateurs simultanés, un GPU devient nécessaire pour garder des temps de réponse acceptables, que la carte soit achetée ou louée à l'heure chez un cloud comme Scaleway.

Un LLM auto-hébergé revient-il vraiment moins cher qu'une API cloud ?

Seulement au-delà d'un volume élevé. Une instance GPU dédiée facture le même prix qu'elle traite dix requêtes ou dix millions, alors qu'une API cloud ou une inférence gérée facture au token consommé. Sous quelques milliards de tokens mensuels, le pay-as-you-go reste presque toujours moins cher, calcul détaillé plus haut dans cet article.

Un LLM local suffit-il pour des données de santé, juridiques ou RH ?

Le local répond à la contrainte de ne pas faire sortir la donnée d'un périmètre défini, mais il ne dispense pas des obligations RGPD classiques : sécurisation des accès, durée de conservation, information des personnes concernées. Le guide CNIL, France Num et CPME sur l'IA générative en TPE et PME pose ces questions avant même celle du lieu d'hébergement.

Quelle différence entre Ollama et vLLM pour une entreprise ?

Ollama vise le prototypage sur un poste unique : installation en une commande, pas de configuration de charge. vLLM vise la production : il traite les requêtes de plusieurs utilisateurs en parallèle et exploite mieux la mémoire GPU. Beaucoup de projets démarrent sur Ollama puis basculent sur vLLM au moment de mettre le service à disposition de vrais utilisateurs.

Un modèle open source comme Llama ou Mistral est-il aussi bon qu'un modèle propriétaire fermé ?

Sur des tâches cadrées, résumé, classification, extraction, l'écart s'est réduit et devient rarement le facteur décisif. Sur du raisonnement complexe ou de l'orchestration de plusieurs outils, les modèles propriétaires les plus récents gardent une avance mesurable. Le bon réflexe reste de tester le modèle open source envisagé sur les cas d'usage réels de l'entreprise avant de trancher.