# LLM auto-hébergé sur infrastructure propre > Catégorie : **IA souveraine** · Slug : `llm-auto-heberge` · Source canonique : **Définition courte** : Modèle de langage large (Mistral, Llama, Qwen…) déployé et exécuté sur infrastructure du fournisseur, sans appel à une API externe (OpenAI, Anthropic, Google). ## Statistiques sur les 404 hébergeurs HDS - ✓ Vérifiés sur source publique : **0** - ◆ Revendiqués sur source publique : **1** ## Définition Un **LLM auto-hébergé** est un **modèle de langage large** (Llama, Mistral, Qwen, Gemma, etc.) déployé et exécuté sur l'infrastructure du fournisseur de service — typiquement sur GPU dédiées en datacenter souverain — **sans aucun appel à une API externe** (OpenAI, Anthropic, Google). Concrètement, cela suppose : - Une **infrastructure GPU** dimensionnée pour l'inférence du modèle (V100, A100, H100, L40S selon génération). - Un **moteur d'inférence** (vLLM, TGI, SGLang, llama.cpp) déployé en local. - Une **gestion du modèle** — téléchargement, quantification éventuelle (GPTQ, AWQ, GGUF), versionning. - Une **API OpenAI-compatible** ou propriétaire exposée aux applications client en réseau privé. Le LLM auto-hébergé s'oppose au **LLM en SaaS** (où le prompt et le contexte client transitent vers les serveurs d'un fournisseur tiers, généralement aux États-Unis). ## Pourquoi c'est important pour un hébergeur HDS Trois enjeux distincts justifient le LLM auto-hébergé dans un contexte HDS : 1. **Confidentialité absolue.** Aucune donnée client ne sort de l'infrastructure souveraine. Pas de risque de fuite par la fenêtre de contexte du modèle, pas de risque de réutilisation par le fournisseur (entraînement, statistiques), pas de risque d'interception sur Internet. 2. **Conformité RGPD + HDS de bout en bout.** Les données de santé ne peuvent pas, par RGPD strict, transiter par un sous-traitant non HDS — y compris un sous-traitant LLM. Auto-héberger résout structurellement le problème. 3. **Indépendance opérationnelle.** Le service ne dépend ni de la disponibilité d'OpenAI/Anthropic/Google, ni de leurs CGU, ni de leur grille tarifaire, ni de leur politique de modération. L'auto-hébergement implique un investissement matériel significatif (cluster GPU à plusieurs centaines de milliers d'euros pour les modèles de tier 1) et opérationnel (équipe MLOps capable de servir l'inférence en production). C'est pour cette raison que ce critère reste **différenciant** sur le marché HDS — peu d'acteurs ont fait le pas. ## Comment ce critère est attribué dans le comparateur - **✓ Vérifié** — l'acteur documente publiquement (page service, blog technique, communiqué) son LLM auto-hébergé, en précisant le modèle et l'infrastructure ; OU vidéo de démonstration produit ; OU communication presse sur les GPU déployées. - **◆ Revendiqué** — mention "IA locale" ou "LLM interne" sans détail vérifiable. - **— Non documenté** — pas de mention publique. ## Pour quel profil c'est critique | Profil | Niveau d'exigence | |---|---| | Hôpital ou groupement de cliniques souhaitant déployer un copilote médical | **Critique** — le copilote ne peut pas envoyer les dossiers patient à OpenAI | | Éditeur SaaS santé intégrant l'IA pour transcription, résumé, aide au codage CCAM | **Critique** | | Plateforme de recherche clinique avec analyse augmentée | **Important** — pseudonymisation forte exigée si recours à API externe ; auto-hébergement simplifie | | Hébergeur HDS classique sans IA | **Hors champ** | ## Comment un hébergeur peut se conformer Le déploiement d'un LLM auto-hébergé suppose **3 à 12 mois** selon le niveau de partance : 1. **Sélection du modèle** — Mistral Large, Qwen 3.6 (35B A3B), Llama 4, Gemma 3. Le choix dépend du compromis qualité ↔ coût d'inférence. 2. **Dimensionnement GPU** — pour Qwen 3.6 35B en INT4 : 1 GPU V100 32GB ou A100 40GB par instance, 100-200 tokens/s en inférence simple. Pour des modèles tier-1 dense 70B+, A100 80GB ou H100 nécessaires. 3. **Sécurisation** — réseau privé strict (pas d'exposition internet de l'inférence), authentification (token), traçabilité (logs sans verbatim sensible). 4. **MLOps** — monitoring (latence, débit, erreurs), versionning, capacity planning, mise à jour modèles. 5. **Conformité contractuelle** — DPA mis à jour pour décrire le traitement IA et garantir l'absence de fuite. ## Plus-value vs coût **Coût indicatif (2026)** : - Investissement initial GPU : **300 k€ à 2 M€** pour un cluster mutualisé de 4-8 GPU haut de gamme. - Coût d'inférence par 1M tokens (TCO incluant amortissement + énergie + ops) : **~0,30 € à 1,20 €** selon le modèle et le taux d'utilisation. À comparer aux **~3 € à 30 €** chez les API externes pour les modèles équivalents. - ROI mesurable dès **~100-500 M tokens / mois** sur la durée d'amortissement. **Plus-value commerciale** : positionnement différenciant fort sur le marché santé sensible. Plusieurs grands comptes publics (CHU, INSERM, AP-HP) ont fait du LLM auto-hébergé une **exigence contractuelle** dans les marchés 2024-2026. ## Sources officielles - **CNIL** — [Recommandation IA](https://www.cnil.fr/fr/intelligence-artificielle). - **AI Act** (UE 2024/1689) — [eur-lex.europa.eu/eli/reg/2024/1689/oj](https://eur-lex.europa.eu/eli/reg/2024/1689/oj). - **ANS** — recommandations IA santé en cours (2026). - **Hugging Face Hub** — [huggingface.co](https://huggingface.co/) (catalogue des modèles open weights). ## Hébergeurs satisfaisant ce critère ### ◆ Revendiqué sur source publique (1) - [Guardis](https://www.hebergeurs-de-donnees-de-sante.fr/hebergeurs/guardis/) ## Méthodologie et limites - ✓ **Vérifié** = source publique citée (registre officiel, verbatim site acteur). - ◆ **Revendiqué** = mention déclarative non vérifiée indépendamment. - ◐ **En cours** = démarche datée publiquement. - — **Non documenté** = information non trouvée. **N'implique pas l'absence du service**. - Méthodologie complète : - Équité Guardis vs concurrents : --- _Comparateur édité par Hasgard SARL. Publication éditoriale indépendante. Licence CC BY-SA 4.0._ _Variante Markdown brut : ajoutez `.md` à l'URL de n'importe quelle page._