En 2026, l'auto-hébergement d'un grand modèle de langage n'est plus une curiosité de laboratoire. C'est devenu une option mature, performante et économiquement défendable pour une partie croissante des projets que nous cadrons. Les modèles ouverts comme Mistral Large 2, Llama 3.3 70B, Qwen 2.5 72B ou DeepSeek V3 atteignent désormais 90 à 95 % des performances de GPT-4 Turbo ou Claude 3.7 Sonnet sur la majorité des cas standards : extraction, classification, synthèse, génération assistée, RAG. Cet écart de qualité, qui était rédhibitoire en 2023, s'est resserré au point que la question n'est plus « est-ce assez bon ? » mais « quel est le bon arbitrage pour notre métier ? ».

Cet article s'adresse aux CTO, DSI et lead engineers qui évaluent sérieusement l'option du LLM auto-hébergé. Nous y détaillons les six décisions structurantes : critères de souveraineté, choix du modèle, dimensionnement GPU, stack de serving, sécurité et observabilité, FinOps. Nous nous appuyons sur ce que nous voyons concrètement dans nos projets, sans céder au discours marketing ambiant. Souveraineté ne veut pas dire « tout self-host à tout prix » : la question est de savoir où placer la frontière, et avec quelle exigence d'ingénierie.

Pourquoi cette question revient en force en 2026

Trois forces convergent. D'abord, la réglementation se durcit : RGPD pour toute donnée personnelle, HDS pour le secteur santé, NIS2 pour les opérateurs essentiels, AI Act pour les systèmes à risque, sans compter les exigences contractuelles spécifiques que les grands comptes imposent désormais à leurs prestataires. Beaucoup de ces clauses interdisent explicitement le transfert vers une API IA non européenne, ou exigent une traçabilité complète impossible à garantir sur une API tierce.

Ensuite, l'écosystème open-weight a rattrapé son retard. Mistral Large 2 (123B paramètres), Llama 3.3 70B, Qwen 2.5 72B et DeepSeek V3 (671B en MoE, ~37B actifs) sont aujourd'hui des modèles industriels. Couplés à des serveurs comme vLLM ou TensorRT-LLM et à du matériel NVIDIA H100, A100 ou L40S, voire AMD MI300X, ils délivrent des débits réels de 30 à 80 tokens par seconde par requête, avec un batching dynamique qui permet d'absorber plusieurs centaines d'utilisateurs simultanés sur un seul serveur correctement dimensionné.

1. Définir les critères de souveraineté avant tout le reste

L'erreur la plus fréquente consiste à choisir un modèle puis à habiller le projet d'un discours de souveraineté. La démarche rigoureuse est inverse : qualifier d'abord la sensibilité des données, les obligations réglementaires et les engagements contractuels, puis dérouler les implications techniques. Une donnée de santé identifiante impose un hébergement HDS et bloque toute API hors UE. Un document classifié par un client défense impose un cloisonnement réseau total. Un secret d'affaires de R&D impose au minimum un chiffrement en transit et au repos, et idéalement une infrastructure dont l'opérateur du LLM n'a pas la main.

Dans nos audits, nous séparons systématiquement trois niveaux : données publiques ou banalisées (API propriétaire acceptable), données confidentielles internes (API européenne avec DPA strict ou self-host cloud souverain), données sensibles ou réglementées (self-host obligatoire, idéalement on-prem ou cloud SecNumCloud / HDS). Cette grille permet d'objectiver le besoin et d'éviter le « tout ou rien » qui plombe la plupart des comités IA.

2. Choisir le modèle open-weight adapté

Le choix du modèle dépend de quatre critères : qualité sur vos cas, qualité spécifique en français, taille (donc coût d'infra), et licence. Mistral Large 2 reste notre référence pour les cas francophones exigeants : qualité de raisonnement, instruction-following, génération naturelle. Llama 3.3 70B offre un excellent rapport qualité/taille mais sa licence (Acceptable Use Policy) reste contraignante pour certains usages et exclut les très grandes plateformes. Qwen 2.5 72B est étonnamment fort en code et en mathématiques. DeepSeek V3, en MoE, offre une qualité proche de GPT-4 avec un coût de serving paradoxalement modéré grâce aux 37B paramètres actifs.

Notre méthode : nous ne croyons jamais les classements génériques type MMLU ou Chatbot Arena. Nous construisons un benchmark interne de 50 à 200 prompts représentatifs du métier client, et nous mesurons faithfulness, format, ton, latence et coût sur chaque modèle candidat. C'est la seule façon de trancher honnêtement.

  • Mistral Large 2 (123B) : excellent français, licence MRL claire, déploiement 2-4×H100
  • Llama 3.3 70B : meilleur rapport qualité/taille, attention à l'AUP
  • Qwen 2.5 72B : fort en code et raisonnement, licence Apache 2.0 partielle
  • DeepSeek V3 (671B MoE) : qualité top-tier, coût serving raisonnable malgré la taille

3. Dimensionner l'infrastructure GPU

Le dimensionnement n'a rien d'intuitif. Trois variables comptent : la VRAM disponible, la latence cible (time to first token et tokens/seconde par utilisateur) et la concurrence (utilisateurs simultanés). Pour un Llama 3.3 70B quantifié en INT4, un seul H100 80GB suffit en POC mais sature vite au-delà de 5-10 utilisateurs simultanés. En FP8, il faut deux H100. Pour Mistral Large 2 en production, nous partons typiquement sur 2 à 4×H100 ou un nœud 8×L40S selon le profil de charge.

Côté infrastructure, deux options dominent : achat direct (1×H100 80GB autour de 30 à 40 k€ HT, amortissable sur 24-36 mois) ou location cloud GPU chez Scaleway, OVHcloud, Lambda Labs ou RunPod, entre 2,5 et 4 € de l'heure selon le fournisseur et l'engagement. Le cloud GPU européen reste pertinent quand on cherche à concilier souveraineté et flexibilité, à condition de vérifier la juridiction réelle du fournisseur et son statut SecNumCloud le cas échéant.

4. Choisir la stack de serving

Quatre options structurent le marché. vLLM est devenu la référence open-source : PagedAttention, continuous batching, support OpenAI-compatible, communauté massive. C'est notre choix par défaut. TGI (text-generation-inference de Hugging Face) reste très solide, particulièrement intégré à l'écosystème HF, légèrement moins performant que vLLM en débit mais très mature en production. TensorRT-LLM de NVIDIA délivre les meilleures performances brutes sur matériel NVIDIA, au prix d'une complexité de compilation et de maintenance bien plus élevée — pertinent à grande échelle uniquement. NVIDIA NIM propose une approche managée on-prem, avec des microservices conteneurisés prêts à l'emploi : intéressant quand l'équipe interne n'a pas de profil MLOps senior, moins flexible et plus cher à terme.

Pour des projets jusqu'à quelques centaines d'utilisateurs concurrents, vLLM derrière un reverse proxy (Traefik, NGINX) avec un client OpenAI-compatible côté application est la combinaison la plus simple, la plus performante et la plus maintenable. C'est elle que nous déployons dans la majorité de nos projets d'auto-hébergement.

5. Sécuriser et observer le LLM en production

Un LLM auto-hébergé n'est jamais une simple API à exposer. C'est un composant critique qui manipule potentiellement des données sensibles et qui constitue une nouvelle surface d'attaque. Nous imposons systématiquement quatre lignes de défense : isolation réseau stricte (VPC privé, pas d'accès direct internet), authentification applicative forte (JWT signés, rotation), journalisation complète des prompts et réponses avec rétention contrôlée, et garde-fous métiers (filtres d'entrée, validation de sortie, détection de prompt injection).

L'observabilité technique compte autant : monitoring GPU (utilisation, mémoire, température), métriques de serving (TTFT, tokens/sec, taille de queue), traçabilité applicative (Langfuse, OpenLLMetry, ou solution maison). Sans cette télémétrie, vous ne saurez ni quand votre infra sature, ni quand un modèle dérive, ni d'où vient une régression de qualité.

6. FinOps : modéliser le TCO honnêtement

La question financière ne se résume pas au prix du GPU. Le TCO réel d'un LLM auto-hébergé intègre l'amortissement matériel ou la location, l'électricité et le refroidissement si on-prem, les compétences MLOps internes ou externes, la maintenance des modèles (mises à jour tous les 3-6 mois sur l'open-weight), l'observabilité, la sécurité, et les phases d'upgrade. Sur nos projets, nous bâtissons toujours un comparatif sur 24 mois entre trois scénarios : API propriétaire pure, hybride (API pour le pic, self-host pour le récurrent), full self-host.

À titre indicatif : Mistral Large 2 sur 1×H100 80GB en serving vLLM optimisé délivre environ 50 tokens/seconde par requête et 1500 à 2500 tokens/seconde en débit agrégé selon le batching. Sur 30 jours pleins, cela représente un volume théorique de plusieurs milliards de tokens, à comparer à une facture API équivalente qui se compte en dizaines de milliers d'euros par mois sur les mêmes volumes.

Les pièges qui font échouer les projets d'auto-hébergement

Quatre pièges reviennent dans nos audits de rattrapage. Premièrement, sous-estimer l'observabilité : sans télémétrie, l'équipe pilote à l'aveugle et toute panne devient un sinistre. Deuxièmement, négliger la sécurité réseau : trop de POC partent en production avec un endpoint vLLM exposé en clair. Troisièmement, oublier le coût récurrent de mise à jour des modèles : un LLM open-weight de 2026 sera obsolète en 2027, il faut prévoir la cadence d'upgrade dès le cadrage. Quatrièmement, ne pas former l'équipe : un LLM self-host ne se pilote pas comme un microservice classique, les compétences MLOps et ML engineering sont indispensables.

À ces pièges techniques s'ajoute un piège stratégique : confondre souveraineté et performance. Auto-héberger ne rend pas un mauvais cas d'usage bon. Si le besoin métier est mal cadré, si le RAG est négligé, si l'évaluation est absente, le projet échouera avec ou sans souveraineté. L'auto-hébergement est un moyen, pas une fin.

Et maintenant ?

Si vous évaluez sérieusement l'auto-hébergement d'un LLM, la première étape est de qualifier honnêtement votre besoin de souveraineté, votre volume cible et la criticité du cas d'usage. C'est précisément ce que nous faisons sur nos cadrages chez DevHighWay : trancher entre API, hybride et self-host avec des chiffres, pas des slogans.

  • Prenez contact pour un cadrage projet souveraineté (atelier 2 jours, livrable décisionnel)
  • Notre audit couvre aussi la dimension visibilité de votre plateforme IA
  • Consultez nos tarifs pour les forfaits incluant l'infogérance LLM

L'auto-hébergement d'un LLM est aujourd'hui une option crédible, parfois la seule, pour les organisations qui doivent garder la main sur leurs données. Mais c'est un projet d'ingénierie sérieux qui se traite comme tel : objectifs clairs, modèle benchmarké, infrastructure dimensionnée, sécurité et observabilité au cordeau, FinOps documenté. C'est exactement la posture que nous adoptons sur nos projets, et celle qui sépare durablement les déploiements pérennes des POC qui meurent au premier incident de production.