LLM auto-hébergé en HDS : cas d’usage, preuves et limites

Publié le 26 août 2026

Un grand modèle de langage peut traiter des données de santé dans un environnement certifié HDS. Cela ne signifie pas que son seul auto-hébergement rende le service conforme. Lorsqu’il est réellement confiné, l’auto-hébergement peut fermer certaines voies de transfert et redonner à l’organisation la maîtrise de ses données. Celle-ci doit alors démontrer que le périmètre HDS est correctement qualifié, que les contrôles ISO/IEC 27001 sont appliqués et que les réponses du modèle restent vérifiables.

Cet article part de cas d’usage concrets : masquage d’identifiants, extraction structurée, classification documentaire, aide à la qualification d’incidents et interrogation d’une politique de sécurité. Il met en regard les textes applicables et les résultats d’une campagne interne. Tous les documents, personnes et établissements utilisés pour ces essais sont fictifs. Les résultats éclairent une méthode ; ils ne préjugent pas du comportement du système sur des données réelles.

Ce que les essais permettent de dire

Aucune fuite d’identifiant n’a été observée sur 1 408 décisions. Le risque n’est pas nul pour autant : avec cet échantillon, sa borne haute reste proche de 0,21 % avec un niveau de confiance de 95 %.

Sur 107 champs absents des documents sources, une modification du schéma de réponse a ramené les valeurs inventées de 65,4 % à 26,2 %. Une réponse « aucune de ces catégories » a aussi supprimé les douze classements forcés de documents hors périmètre, sans rejet injustifié parmi 48 documents légitimes.

Tous les jeux d’essai étaient entièrement synthétiques. Aucun patient, client, établissement ou identifiant réel n’a été traité.

Le référentiel HDS v2.1 parle-t-il d’intelligence artificielle ?

La version en concertation consultée le 26 août 2026 ne comporte pas de chapitre propre aux grands modèles de langage, à la génération augmentée par recherche documentaire ou aux agents d’IA. Cette absence ne crée ni exemption ni vide juridique. Le référentiel décrit des activités d’hébergement, des responsabilités et des exigences de sécurité qui s’appliquent quelle que soit la technologie employée.

La bonne question n’est donc pas « le modèle est-il HDS ? », mais « quelles données le service reçoit-il, où sont-elles traitées, qui peut y accéder, que conserve-t-il et pour le compte de qui ? ». C’est à partir de ces réponses que l’on détermine les activités HDS concernées, les obligations contractuelles et les mesures de sécurité attendues. La page consacrée à la définition de la certification HDS rappelle ce raisonnement par activité.

Le constat peut être reproduit à partir du référentiel HDS v2.1 publié pour concertation par l’ANS. Il reste attaché à cette version et à sa date de consultation. Le texte définitif devra être relu lors de sa publication.

À quelles activités HDS rattacher un service fondé sur un LLM ?

Il n’existe pas de qualification unique pour « l’IA ». La réponse dépend du service réellement rendu.

• Un traitement ponctuel sans conservation, limité à une requête et à sa réponse, conduit notamment à examiner les activités 3 et 4 : mise à disposition de l’infrastructure virtuelle et de la plateforme qui héberge l’application. L’absence de conservation doit être démontrée, journaux compris.
• Un dispositif de recherche documentaire enrichie, ou RAG, ajoute un index persistant. Si cet index représente des comptes rendus médicaux, son stockage, sa sauvegarde, son effacement et sa réversibilité entrent dans l’analyse.
• Un entraînement complémentaire fait apparaître d’autres objets à protéger : corpus d’apprentissage, jeux d’évaluation, états intermédiaires et modèle obtenu. Leur provenance, leur séparation et leur purge doivent être documentées.
• Un agent autorisé à écrire dans un dossier patient ou dans un outil métier change encore la nature du risque. Les habilitations, l’administration et l’exploitation du système, la séparation des rôles, le journal des actions et la validation humaine doivent alors être étudiés, notamment au regard de l’activité 5.

Cette grille constitue une lecture d’architecture, non une doctrine officielle propre aux LLM. L’ANS indique par ailleurs que des travaux se poursuivent sur le périmètre de l’activité 5. La chaîne Guardis est certifiée HDS pour les activités 2 à 6 ; ce périmètre exact doit accompagner toute affirmation publique. Pour éviter de confondre les deux cadres, voir aussi pourquoi ISO 27001 et HDS ne couvrent pas les mêmes exigences.

Un accès distant peut-il constituer un transfert de données de santé ?

Le lieu de stockage ne suffit pas à trancher. Un accès distant depuis un pays tiers peut constituer un transfert alors même que les données restent enregistrées en France. L’article R.1111-9-1 du Code de la santé publique, créé par le décret n° 2026-209, vise expressément le transfert « y compris un accès à distance ». Ces dispositions entrent en vigueur le 26 septembre 2026.

La règle concerne des situations très ordinaires : télémaintenance par un éditeur, diagnostic réalisé par un fournisseur, télémétrie susceptible de contenir une requête ou ouverture temporaire d’un accès à un sous-traitant. Affirmer que le fournisseur « n’héberge pas les données » ne répond donc pas à la question s’il peut lire une consigne, une réponse, un journal ou un extrait de base.

Avant la mise en service, il faut dresser la carte des flux et des accès : identité et localisation des intervenants, données visibles, motif de l’accès, durée de conservation, sous-traitants ultérieurs et procédure de révocation. Le cadre légal de l’hébergement des données de santé s’apprécie sur toute cette chaîne, pas uniquement sur le stockage principal.

Un index vectoriel de comptes rendus médicaux est-il une donnée de santé ?

Par prudence, il faut le traiter comme tel tant que son caractère anonyme n’est pas démontré. L’avis 28/2024 du Comité européen de la protection des données ne vise pas spécifiquement les index vectoriels. Il rappelle toutefois qu’un modèle ne peut être considéré comme anonyme que si la probabilité d’extraire ou d’obtenir des informations personnelles est négligeable, compte tenu des moyens raisonnablement susceptibles d’être employés. Un index dérivé de comptes rendus médicaux ne bénéficie donc d’aucune présomption d’anonymat.

Notre campagne n’a comporté aucun essai d’inversion de représentations vectorielles. Elle montre seulement qu’un masquage d’identifiants directs ne suffit pas à établir une pseudonymisation. Les étiquettes produites n’étaient ni cohérentes d’un document à l’autre ni reliées à une information additionnelle conservée séparément. Surtout, la ré-identification par croisement de quasi-identifiants n’a pas été testée.

La conséquence pratique est claire : l’index doit être chiffré, sauvegardé dans le périmètre prévu, soumis à des habilitations, journalisé et intégré aux procédures d’effacement et de réversibilité. Des attaques adaptées au corpus doivent compléter l’évaluation. L’article sur l’anonymisation automatique de documents par IA détaille la différence entre anonymisation, pseudonymisation et simple masquage. Pour la conception d’ensemble, voir également l’architecture d’un RAG sécurisé.

Quels contrôles ISO 27001 faut-il traduire dans le service ?

ISO/IEC 27001 ne certifie pas la justesse d’un modèle. Elle impose en revanche une organisation capable d’identifier ses actifs, de traiter ses risques, de surveiller ses mesures et de maîtriser ses changements. Les correspondances suivantes relient les contrôles mobilisés pendant nos essais à des éléments de preuve concrets. Elles ne remplacent pas la déclaration d’applicabilité, et les intitulés français doivent être contrôlés contre l’édition officielle de la NF EN ISO/IEC 27001:2022.

Masquage — A.8.11. Aucune fuite d’identifiant n’a été observée sur 1 408 décisions, et aucun des 912 segments cliniques suivis n’a été altéré. La borne haute de 0,21 % interdit néanmoins de présenter le premier résultat comme une garantie. Pour une donnée de santé, le modèle ne peut être l’unique filtre.

Inventaire et classification — A.5.9 et A.5.12. Lors d’une extraction structurée, 65,4 % des 107 champs absents ont d’abord reçu une valeur inventée. Un schéma autorisant explicitement l’absence a ramené ce taux à 26,2 %. Dans un essai distinct, le type documentaire a été correctement reconnu dans 47 cas sur 48 et aucune sous-classification n’a été observée sur 120 décisions. Ici encore, l’échantillon borne la portée de la conclusion.

Incidents et enregistrements — A.5.24 à A.5.28 et A.5.33. La qualification d’incidents a produit les 50 réponses attendues, résultat retrouvé lors de trois répétitions. Pourtant, avec seulement 23 cas positifs, la borne haute du taux de faux négatifs reste de 13,0 %. Sur le classement documentaire, une catégorie de sortie explicite a supprimé douze rattachements forcés à un dossier qui ne correspondait pas.

Procédures documentées — A.5.37. L’assistant interrogé à partir d’une politique de sécurité fournie n’a inventé aucune information sur 45 pièges. La borne haute demeure de 7,9 %. Une absence d’erreur observée ne devient donc pas une preuve d’absence d’erreur.

Journalisation et gestion des changements — A.8.15 et A.8.32. Des variations ont été constatées entre des exécutions comparables. Il faut conserver la version du corpus, la consigne, le schéma attendu, la réponse, les outils appelés et la décision humaine. Toute évolution du modèle, des règles ou des documents de référence impose une nouvelle évaluation.

La clause 9.1 impose enfin de surveiller, mesurer, analyser et évaluer. Le protocole doit donc être daté, expliciter son dénominateur et son incertitude, puis soumettre l’outil d’évaluation à un contrôle humain. L’article sur les agents IA en environnement régulé approfondit les exigences de traçabilité et de changement.

ISO 42001 apporte-t-elle quelque chose de plus ?

ISO/IEC 42001 peut structurer la gouvernance propre au système d’IA. Elle ne remplace ni ISO/IEC 27001, ni HDS, ni l’analyse requise par le RGPD. Sa structure commune avec d’autres normes de management facilite toutefois la réutilisation des rôles, des processus de risque, des audits et des mécanismes d’amélioration continue.

Elle peut servir d’ossature à un inventaire des systèmes d’IA, à la désignation des responsables, aux critères d’acceptation, au suivi des incidents, à la supervision humaine et à la gestion du cycle de vie. La certification reste volontaire et ne rend pas une réponse juridiquement ou médicalement exacte. Pour aller plus loin, voir le dossier consacré à la conformité de l’IA entre ISO 42001, RGPD et NIS2.

Que change le référentiel HDS v2.1, et quand ?

Depuis le 16 mai 2026, seuls les certificats conformes au référentiel HDS v2.0 permettent de poursuivre légalement une activité d’hébergement de données de santé pour compte de tiers. Au 26 août 2026, la version 2.1 reste en concertation.

L’ANS prévoit sa publication en octobre 2026 et annonce une application trois mois après celle-ci ; sa page d’information vise actuellement décembre 2026. Comme il s’agit d’une échéance future, la date exacte devra être contrôlée dans le texte définitif. L’évolution porte notamment sur la transparence relative aux transferts, aux accès distants et à la soumission à des législations de pays tiers. Les contrats existants peuvent devoir être adaptés.

L’ANS ne demande pas d’audit supplémentaire consacré à cette seule évolution : le contrôle doit intervenir lors de l’audit initial, de surveillance ou de renouvellement concerné. Attendre cet audit serait toutefois une mauvaise stratégie. L’inventaire des fournisseurs, des accès distants, des flux, des journaux et des lieux de conservation peut être constitué dès maintenant.

Le règlement européen sur l’IA vise-t-il déjà un assistant interne ?

Un assistant interne n’échappe pas au règlement du seul fait qu’il n’est pas proposé au public. Il n’est pas davantage classé à haut risque par nature. Sa qualification dépend de sa finalité, de ses utilisateurs et de l’effet concret de ses réponses.

Le règlement (UE) 2026/1744, entré en vigueur le 27 juillet 2026, a modifié ce calendrier. Depuis le 2 août 2026, le règlement européen sur l’intelligence artificielle est applicable dans son principe. Les fournisseurs de systèmes générant du contenu synthétique déjà mis sur le marché avant cette date disposent jusqu’au 2 décembre 2026 pour prendre les mesures nécessaires au marquage prévu par l’article 50, paragraphe 2. Certaines dispositions applicables aux systèmes à haut risque sont reportées au 2 décembre 2027 pour ceux relevant de l’article 6, paragraphe 2, et de l’annexe III, puis au 2 août 2028 pour ceux relevant de l’article 6, paragraphe 1, et de l’annexe I.

Ces dates ne remplacent pas l’analyse du cas d’usage. Un assistant qui prépare une note sans décider n’a pas le même effet qu’un outil qui oriente un patient, classe une priorité clinique ou déclenche une action. Dans tous les cas, l’organisation gagne à documenter la traçabilité, l’information des utilisateurs, les compétences du superviseur et son pouvoir réel de corriger ou d’arrêter le traitement.

SecNumCloud 3.2 ou HDS : lequel choisir pour un projet d’IA en santé ?

Les deux référentiels n’ont pas le même objet. HDS encadre l’hébergement de données de santé à caractère personnel pour compte de tiers. SecNumCloud qualifie des services d’informatique en nuage selon des exigences de sécurité et de protection, notamment face aux lois extraterritoriales. L’un ne se substitue donc pas automatiquement à l’autre.

Le référentiel SecNumCloud 3.2 date du 8 mars 2022. L’arrêté du 12 août 2026, publié le 14 août et entré en vigueur le lendemain, a approuvé cette version pour l’application du décret n° 2026-272 aux données d’une sensibilité particulière de l’État. Il n’a pas créé une nouvelle version du référentiel.

Pour un projet d’IA en santé, l’analyse commence par l’obligation HDS et se complète par le niveau de souveraineté recherché. Il faut notamment déterminer si les données d’entrée, les réponses, les journaux et les traces d’outils peuvent être soumis à une juridiction tierce. Le cadre juridique du cloud souverain aide à distinguer ces questions.

Pourquoi les usages d’IA non autorisés créent-ils un risque HDS ?

Lorsqu’un professionnel copie un compte rendu, une note clinique ou un identifiant dans un service en ligne non approuvé, l’organisation perd la maîtrise du sous-traitant, de la localisation, de la conservation et des accès. Une interdiction isolée résout rarement le besoin métier qui a provoqué cet usage.

L’auto-hébergement peut participer à la réduction du risque s’il offre une solution autorisée, utile, observable et correctement accompagnée. Il faut y ajouter des règles d’usage, une formation, un mécanisme de signalement et des contrôles adaptés. Guardis peut traiter les modèles localement et assurer un transport privé sans passage par l’Internet public, dans le périmètre déclaré de ses activités HDS 2 à 6. Voir l’hébergement HDS proposé par Guardis et notre approche de la souveraineté physique de bout en bout.

Quels enseignements d’exploitation tirer d’un LLM auto-hébergé ?

La campagne menée avec Qwen ne définit pas un niveau de service transposable : documents, consignes et règles de sortie varient trop d’un projet à l’autre. Ses enseignements utiles sont opérationnels.

Le premier est de mesurer chaque cas d’usage avant de fixer ses règles d’exploitation. Masquage, recherche documentaire et action dans un outil métier n’ont ni la même criticité ni le même besoin de supervision. Les essais doivent reproduire les documents et l’usage attendus, puis fixer les limites d’admission, les délais et le comportement de repli. Ces valeurs appartiennent au dossier d’exploitation ; elles ne se déduisent pas d’une fiche commerciale.

Le deuxième enseignement concerne la maîtrise des entrées et des sorties. Un schéma qui oblige le modèle à remplir chaque champ favorise les inventions lorsque l’information manque. Autoriser explicitement l’absence et proposer une réponse hors périmètre ont amélioré les résultats sans changer les documents testés. La conception de l’interface compte donc autant que le choix du modèle.

Le troisième porte sur la preuve reproductible. Chaque campagne doit associer une version du corpus, des réponses de référence rédigées à l’avance, la consigne, les paramètres fonctionnels, les règles de validation et la décision humaine. Sans cet ensemble, un résultat ne peut être ni expliqué à un auditeur ni comparé après une évolution.

Enfin, l’absence de service externe ne suffit pas à établir l’isolement. Il faut encore maîtriser les accès d’administration, les mises à jour, la télémétrie, les sauvegardes, les outils appelés et les journaux. Aucune donnée réelle n’a été utilisée dans cette campagne : tous les corpus étaient synthétiques. Pour un examen plus opérationnel de ces choix, lire notre retour d’expérience sur Qwen auto-hébergé.

Comment prouver à un auditeur que le modèle n’a pas halluciné ?

Un pourcentage isolé ne constitue pas une preuve. Il faut pouvoir relier le résultat à un corpus daté, à des réponses de référence écrites avant l’essai, à un nombre de cas, à une borne d’incertitude, à une condition de comparaison et à un outil d’évaluation lui-même contrôlé.

Notre campagne montre pourquoi. Sur l’assistant interrogé à partir d’une politique de sécurité, aucune information inventée n’a été relevée parmi 45 pièges. La borne haute reste pourtant de 7,9 % avec un niveau de confiance de 95 %. Un premier outil d’évaluation avait signalé à tort 6,7 % d’hallucinations ; la relecture manuelle a révélé l’erreur de mesure. Nous avons également retiré un indicateur de rappel du masquage, car l’alignement échouait sur 11 à 15 % des emplacements dans trois campagnes sur quatre.

Une preuve sérieuse doit donc montrer autant ses échecs que ses succès. Elle conserve les consignes et les réponses, publie le dénominateur, explicite les exclusions, compare au moins deux conditions et prévoit une relecture humaine de l’évaluation. Un indicateur produit par un programme non contrôlé ne rassure pas l’auditeur : il ajoute un second système opaque au premier.

Combien coûte réellement un LLM auto-hébergé en HDS ?

Notre campagne n’avait pas pour objet de mesurer le coût complet, et nous ne publions donc aucun montant. Un calcul sérieux doit distinguer l’acquisition ou l’amortissement, l’énergie, le refroidissement, l’exploitation, la sécurité, les audits, le maintien en conditions opérationnelles, la constitution des jeux d’évaluation, leur révision, la supervision humaine, la réversibilité et le secours.

Le dimensionnement dépend ensuite du cas d’usage : volume et longueur des documents, concurrence des demandes, délai acceptable, taux d’abstention, niveau de redondance et durée de conservation. Une moyenne globale masque souvent les périodes de pointe et les traitements longs.

Le poste le plus souvent oublié est celui de la preuve. Il comprend une méthode plus simple à titre de comparaison, un second annotateur, un corpus métier, des essais d’attaque, le contrôle des outils d’évaluation et une nouvelle évaluation après chaque changement. Un coût unitaire apparemment bas peut ainsi déplacer une dépense bien réelle vers le DPO, le RSSI et les équipes d’exploitation.

FAQ : que faut-il retenir avant de déployer ?

Comment les mesures ont-elles été produites et quelles sont leurs limites ?

Les campagnes internes ont été réalisées le 26 août 2026 dans un environnement isolé, avec Qwen. Tous les corpus étaient entièrement synthétiques : textes rédigés à la main ou produits par des générateurs déterministes, personnes inventées et établissements fictifs. Aucun patient, client, document métier ou identifiant réel n’a été traité.

Le même opérateur a conçu les corpus, les annotations et les outils d’évaluation. Aucun jeu n’a été réannoté par un DPO, un auditeur ou un second annotateur indépendant. Aucune méthode de référence n’a été mesurée, qu’il s’agisse d’expressions régulières, de reconnaissance d’entités nommées, de classement par mots-clés ou d’une revue par un opérateur débutant. Nous ne pouvons donc pas chiffrer la valeur ajoutée du LLM face à une solution plus simple.

Le tableau suivant doit se lire comme une mesure d’incertitude. Lorsqu’aucune erreur n’est observée, la borne haute rappelle ce que la taille de l’échantillon permet encore de ne pas voir.

Événement non observé	Nombre de cas	Borne haute à 95 %
Fuite d’identifiant	1 408	≈ 0,21 %
Hallucination sur une information absente	45	7,9 %
Acceptation d’une prémisse fausse	20	16,1 %
Faux négatif pour la qualification « violation »	23 cas positifs	13,0 %
Faux positif pour la qualification « violation »	27 cas négatifs	11,1 %

Les 2 552 requêtes retenues n’ont produit aucune erreur de traitement. Ce résultat confirme que les mesures rapportées ont pu être menées à leur terme ; il ne démontre ni une disponibilité contractuelle ni une tenue durable en production.

Avant tout déploiement, le protocole doit être rejoué sur le corpus cible, dans un environnement isolé, avec une méthode de référence et un second annotateur. Le schéma de réponse, la possibilité de s’abstenir, les erreurs connues et le contrôle de l’outil d’évaluation doivent rejoindre le dossier de preuve au même titre que les mesures de sécurité.

Conclusion

L’auto-hébergement apporte une maîtrise utile : les données peuvent rester dans un périmètre défini, les accès deviennent contrôlables et l’organisation choisit ses règles de conservation. Il ne transforme pas pour autant un LLM en service conforme. La conformité se construit à partir du cas d’usage, des activités HDS effectivement rendues, des contrôles ISO 27001, des contrats, des flux et de la supervision humaine.

Les essais synthétiques mettent surtout en évidence le poids de la conception. Sur 107 informations absentes, un schéma autorisant explicitement l’absence a ramené les valeurs inventées de 65,4 % à 26,2 %. Une réponse hors périmètre a, de son côté, supprimé douze rattachements abusifs. Ces améliorations sont importantes, mais les taux résiduels et les bornes d’incertitude empêchent toute promesse générale.

Ce qui reste à établir doit demeurer visible : comportement sur des corpus réels, comparaison avec des méthodes plus simples, réannotation indépendante, résistance aux attaques et qualité dans la durée. Pour un DSI, un RSSI ou un DPO, la bonne décision n’est donc pas de faire confiance à un chiffre flatteur. Elle consiste à organiser une preuve reproductible, proportionnée au risque et réexaminée à chaque changement.