Auto-héberger un LLM ne suffit pas à protéger vos données

Ce que l’auto-hébergement d’un LLM protège réellement

L’auto-hébergement retire un acteur de votre flux de données : le fournisseur du modèle. Les prompts, les documents récupérés et les réponses générées restent à l’intérieur d’un périmètre que vous contrôlez. Aucun sous-traitant tiers, aucun transfert transfrontalier, aucune promesse contractuelle que vous devez accepter sur parole.

C’est un véritable avantage, mais il reste limité. Cette approche corrige précisément la catégorie de risques qui se trouve à l’extérieur de votre réseau. Toutes les autres façons dont les données de l’entreprise peuvent sortir d’un système basé sur un LLM ne dépendent pas de l’emplacement du GPU.

Voici le bilan honnête.

Six lignes s’améliorent. Trois restent inchangées. Deux empirent réellement. Si vous auto-hébergez pour répondre à une exigence de conformité concernant le traitement par un tiers, le premier bloc contient votre réponse. Si vous le faites parce que vous avez le sentiment général que les données sont plus sûres sur vos propres serveurs, poursuivez votre lecture.

LLM auto-hébergé ou API entreprise : ce que disent réellement les conditions d’utilisation des données en 2026

La plupart des comparaisons entre auto-hébergement et API s’opposent encore aux conditions des services de chat grand public de 2023. Le côté API a évolué.

Anthropic supprime par défaut les entrées et sorties d’API après sept jours et ne les utilise pas pour entraîner ses modèles. Une option de 30 jours est proposée aux clients qui souhaitent conserver une piste d’audit, et la Zero Data Retention est disponible pour les comptes entreprise éligibles. OpenAI publie une position comparable et a présenté, le 19 août 2026, Private Safety Processing, son approche pour maintenir la Zero Data Retention sur les modèles frontier, tout en détectant les schémas d’abus dans des interactions connexes. Dans ce cadre, le contenu client reste sur une infrastructure contrôlée par le client.

Le point à connaître avant de bâtir un argumentaire de conformité autour de la ZDR : la garantie est propre au modèle, et non au fournisseur. Anthropic a indiqué que, pour ses modèles frontier couverts, les clients commerciaux bénéficiant de la ZDR au 9 juin 2026 sont soumis à une conservation et à un examen limités dans le cadre des travaux de sécurité. La leçon n’est pas qu’un fournisseur serait négligent : c’est que la ZDR est une propriété propre à chaque modèle et à chaque endpoint, susceptible d’évoluer à la sortie d’un nouveau modèle. Si votre DPIA cite une garantie plutôt qu’un modèle précis, elle deviendra obsolète sans que personne ne vous prévienne.

Voilà l’argument le plus solide en faveur de l’auto-hébergement, sans rapport avec les hackers : un modèle que vous hébergez ne renégocie pas ses conditions avec vous.

Relisez deux fois la dernière ligne. C’est tout l’arbitrage.

Le RGPD ou l’EU AI Act vous obligent-ils à auto-héberger un LLM ?

Non. Aucun de ces deux règlements n’impose l’inférence locale. L’auto-hébergement permet en revanche de supprimer deux des volets les plus coûteux de votre dossier de conformité.

• Obligations du sous-traitant au titre de l’article 28. Une API hébergée fait du fournisseur un sous-traitant, ce qui nécessite un contrat écrit, un contrôle des sous-traitants ultérieurs, des droits d’audit et une notification des violations. Si vous exécutez le modèle sur du matériel que vous exploitez, aucun sous-traitant n’intervient dans la relation.
• Analyse des transferts au titre du chapitre V. Acheminer des données personnelles européennes vers un endpoint hébergé aux États-Unis constitue un transfert transfrontalier qui nécessite des CCT ou le Data Privacy Framework, avec le risque résiduel issu de Schrems II qu’un DPO doit documenter chaque année. L’auto-hébergement dans votre propre région supprime le transfert au lieu de devoir le justifier.

Ce qu’il ne supprime pas : votre registre des activités de traitement, votre DPIA, votre base légale et — depuis le 2 août 2026 — les obligations de transparence de l’article 50 de l’EU AI Act, qui imposent d’indiquer à l’utilisateur qu’il interagit avec un système d’IA et de signaler les contenus générés dans un format lisible par machine. Les obligations applicables aux systèmes à haut risque ont été repoussées à décembre 2027 par le Digital Omnibus, ce qui laisse davantage de temps pour la documentation, mais ne change rien à la personne responsable.

En pratique, l’auto-hébergement permet de raccourcir votre argumentaire de conformité, pas de vous en dispenser. Les équipes qui considèrent l’achat de GPU comme le livrable de conformité sont celles qui échouent ensuite à l’audit sur la journalisation et le contrôle des accès.

Le risque dont vous héritez dès que vous auto-hébergez

Voici ce que le discours sur la confidentialité laisse de côté. La méthode la plus populaire pour exécuter un modèle en local est fournie sans authentification, et une grande partie des installations est accessible depuis Internet.

SentinelLABS et Censys ont cartographié Internet pendant environ 300 jours et trouvé près de 175 000 hôtes Ollama uniques exposés dans 130 pays, dont près de la moitié étaient configurés pour appeler des outils — autrement dit, capables d’exécuter du code et d’atteindre d’autres systèmes. En mai 2026, dans le contexte d’une vulnérabilité critique, Cyera estimait le nombre de serveurs exposés à environ 300 000. Prenez le chiffre exact avec prudence ; l’ordre de grandeur, lui, ne fait pas débat.

Ces instances ne sont pas exposées parce que leurs opérateurs seraient irresponsables. Elles le sont parce que la configuration par défaut ne correspond pas à l’usage de l’outil : aucune authentification à l’installation, puis une reconfiguration très fréquente pour écouter sur toutes les interfaces dès qu’une personne doit accéder au modèle depuis une autre machine.

Il suffit ensuite qu’une faille s’ajoute. CVE-2026-7482, surnommée Bleeding Llama, est une lecture hors limites du tas, notée CVSS 9.1, qui permet à un attaquant non authentifié d’extraire la mémoire du processus au moyen de trois appels API. Les chercheurs de Cyera qui l’ont révélée ont listé les éléments susceptibles d’être récupérés : prompts, instructions système, variables d’environnement et clés API. Il s’agit précisément des catégories de données que vous vouliez protéger en auto-hébergeant le modèle.

La couche de passerelle présente le même problème. En mars 2026, une compromission de la chaîne logistique touchant une bibliothèque de passerelle IA très utilisée (CVE-2026-33634, CVSS 9.4) a montré qu’une seule dépendance empoisonnée pouvait exposer en une fois l’ensemble des identifiants de fournisseurs IA d’une organisation. Avec une API, une clé volée limite l’impact au périmètre d’un fournisseur. Dans une stack auto-hébergée, la passerelle les détient généralement toutes.

Le résumé, peu confortable, est le suivant : auto-héberger un LLM pour protéger les données de l’entreprise ne fonctionne que si votre équipe exploite l’infrastructure d’inférence avec le même niveau d’exigence que ses bases de données. La plupart des équipes qui prennent cette décision pour des raisons de confidentialité n’ont jamais eu à le faire.

Combien coûte l’auto-hébergement d’un LLM en 2026 ?

Les capacités ne constituent plus le principal obstacle. Les modèles open-weight couvrent désormais une gamme allant de l’ordinateur portable au rack, et la règle de dimensionnement est simple : les poids doivent tenir dans une mémoire rapide, à raison d’environ 2 octets par paramètre en FP16, de la moitié en INT8 et du quart en 4 bits — avec une marge pour le cache KV, qui augmente avec la longueur du contexte et la concurrence.

C’est au moment de calculer la facture que l’intuition devient trompeuse. La capacité H100 louée coûtait environ 1,49 à 6,98 $ par heure-GPU selon le fournisseur dans les relevés tarifaires publiés en août 2026. Or le tarif affiché est le chiffre le moins intéressant de cette fourchette : à 40 % d’utilisation, une carte à 3,99 $ coûte près de 10 $ par heure de travail réellement utile. Les GPU inutilisés sont la principale source de regrets liés à l’auto-hébergement.

Voici trois postes systématiquement oubliés dans les business cases :

• Ingénierie. Prévoyez un ingénieur à mi-temps ou à temps plein pendant la première année. Pour la plupart des équipes, ce coût dépasse celui des GPU et ne disparaît pas après le lancement : les modèles, les runtimes et les CVE continuent d’évoluer.
• Taux d’utilisation. Les API facturées au token ne coûtent rien lorsque personne ne les sollicite. Un GPU réservé coûte autant à 3 heures du matin.
• Redondance. Un seul GPU est une démonstration. La production exige un second nœud, ou un plan réaliste pour gérer la panne du premier.

Pour les modèles open peu coûteux et à fort volume, servis par des fournisseurs d’inférence standard, il n’existe souvent aucun seuil de rentabilité : le tarif par token est inférieur à ce qu’une seule carte louée peut produire. L’auto-hébergement devient économiquement intéressant pour les usages de modèles de pointe, les checkpoints affinés sur mesure et les volumes élevés et réguliers. Il offre du contrôle quel que soit le volume, mais c’est un autre argument, à présenter séparément.

La fuite que votre architecture crée, quel que soit l’emplacement du modèle

En pratique, les données de l’entreprise ne sortent pas par le fournisseur du modèle. Elles sortent par trois éléments que vous construisez vous-même.

1. L’index de recherche qui a perdu ses permissions

L’incident grave le plus fréquent lors du déploiement d’une IA interne n’est pas l’exfiltration. C’est un salarié qui pose une question à un chatbot et reçoit le contenu d’un document qu’il n’avait jamais été autorisé à ouvrir. Cela se produit lorsqu’un pipeline RAG ingère un lecteur partagé sans reporter les ACL de chaque document dans le vector store et sans les revérifier au moment de la requête.

L’auto-hébergement rend ce mode de défaillance plus probable, et non moins. La phrase « nous ne pouvons pas mettre cela dans le cloud » servait discrètement de filtre de classification des données. Supprimez-la et le périmètre d’ingestion s’étend à tout, généralement dans le même sprint.

2. Vos propres journaux de prompts

Les stacks auto-hébergées journalisent généreusement par défaut. Les passerelles, les outils d’observabilité et les interfaces de chat enregistrent tous les prompts et réponses complets, qui sont ensuite stockés dans une base de données dont le chiffrement, la conservation et les contrôles d’accès sont souvent plus faibles que ceux prévus par la politique du fournisseur que vous venez de remplacer. Vous n’avez pas supprimé la conservation. Vous l’avez déplacée à un endroit sans DPA ni calendrier de suppression.

3. Le périmètre des outils de l’agent

Dès que le modèle peut appeler des outils, la question de sécurité ne porte plus sur le texte, mais sur les capacités. Près de la moitié des hôtes exposés avaient activé l’appel d’outils. Limitez chaque outil à l’identité de l’utilisateur qui effectue la demande, et non à celle du service : un agent qui interroge votre base de données avec un compte de service est une élévation de privilèges qui n’attend qu’un prompt bien formulé.

Il s’agit de décisions d’architecture, pas d’infrastructure, et elles sont identiques que l’inférence s’exécute dans votre rack ou dans celui d’un tiers. Si vous voulez les concevoir correctement dès le départ, c’est précisément le travail réalisé dans le cadre de notre service d’ingénierie des workflows et de l’automatisation IA — agents, pipelines de recherche et modèle de permissions sous-jacent.

Comment sécuriser un déploiement de LLM auto-hébergé

Si vous auto-hébergez, traitez le serveur d’inférence comme une infrastructure de production qui contient des données sensibles — parce que c’est exactement ce qu’il est. Voici les mesures, à peu près dans l’ordre de celles qui sont le plus souvent oubliées :

1. Ne liez jamais le serveur d’inférence à 0.0.0.0. Liez-le à localhost ou à une interface privée et placez un reverse proxy devant. Vérifiez depuis l’extérieur, et non depuis la machine elle-même.
2. Exigez une authentification sur chaque endpoint. Utilisez des clés API ou OAuth associés à un contrôle d’accès basé sur les rôles, et non un token partagé dans une page wiki.
3. Analysez votre exposition comme le feraient des attaquants. Vérifiez que vos ports d’inférence ne sont pas accessibles depuis Internet, puis recommencez après chaque modification de l’infrastructure.
4. Utilisez un runtime de production pour la production. vLLM, SGLang ou TensorRT-LLM pour le trafic servi ; gardez les outils locaux pratiques pour les développeurs sur leurs machines.
5. Appliquez les correctifs de la stack de serving selon un calendrier de sécurité. Les runtimes d’inférence constituent désormais une surface de CVE activement exploitée, et non une simple dépendance de loisir.
6. Validez les artefacts des modèles. Téléchargez les poids auprès d’éditeurs connus et vérifiez leurs sommes de contrôle. Un fichier de modèle malformé a déjà constitué un vecteur d’attaque exploitable.
7. Isolez les secrets de la passerelle. Stockez les clés fournisseurs dans un gestionnaire de secrets avec une portée par service, afin qu’une dépendance compromise ne livre pas toute votre chaîne d’identifiants.
8. Conservez les ACL dans le pipeline de recherche. Filtrez au moment de la requête selon les permissions réelles de l’utilisateur demandeur et réindexez lorsque les permissions changent.
9. Définissez une politique de conservation des journaux de prompts et chiffrez-les. Supprimez-les ensuite selon le calendrier prévu et prouvez que cela a été fait.
10. Journalisez les requêtes d’inférence à des fins d’audit — utilisateur, horodatage, modèle, outils appelés. Ces informations sont nécessaires à la réponse aux incidents et, de plus en plus, aux autorités de régulation.
11. Limitez le débit et surveillez les abus. Un volume inhabituel de tokens associé à une identité est le premier signal d’un mauvais usage comme d’une compromission.

Quand auto-héberger, quand utiliser une API et comment combiner les deux

La meilleure approche n’est pas forcément de choisir. Classez les données, puis acheminez le trafic : la plupart des organisations ont trois niveaux, et un seul justifie du matériel dédié.

Auto-hébergez-vous si au moins une de ces conditions est remplie : un régulateur ou un contrat client impose la localisation des données ; votre DPIA ne peut pas intégrer un sous-traitant tiers ; vous avez besoin d’un checkpoint affiné que personne ne propose en hébergement ; ou votre volume régulier est assez élevé pour que des GPU réservés soient plus avantageux que la facturation au token, avec un taux d’utilisation réaliste.

Restez sur une API lorsque votre volume est irrégulier, lorsque votre équipe n’assure aucune astreinte d’infrastructure ou lorsque la réponse honnête à la question « qui applique un correctif au serveur d’inférence à 2 heures du matin ? » est « personne ». Un modèle hébergé avec des conditions entreprise et une architecture rigoureuse protège mieux les données de l’entreprise qu’un modèle auto-hébergé dont un port est ouvert. Ce n’est même pas un arbitrage serré.

Si vous évaluez cette décision et souhaitez faire examiner l’architecture avant d’acheter du matériel — classification des données, routage, permissions de recherche et déploiement — décrivez-nous ce que vous construisez et nous vous proposerons un périmètre.