LLM et données de santé : ce que le HDS ne couvre pas

IA et données de santé : ce que vous avez le droit de faire

Le périmètre du certificat, la chaîne de sous-traitance et la réversibilité sont détaillés dans les 8 points à vérifier dans un contrat d’hébergement HDS. On va partir du principe que vous savez déjà ce qu'est un hébergement HDS.

3 conditions, qui n'ont rien à voir avec le fournisseur ni avec le modèle.

1
Savoir exactement ce qui quitte votre périmètre au moment de l'appel, champ par champ.
2
Avoir une base légale pour ce qui sort, pas seulement un contrat d'hébergement.
3
Pouvoir montrer après coup ce qui a été envoyé, par qui, et ce qui a été renvoyé.

Première question : s'agit-il vraiment de données de santé ?

Posez-la avant tout le reste, parce que c'est la seule qui fait tomber le problème au lieu de le déplacer. Reposez-la champ par champ, à chaque nouvelle fonctionnalité. Presque personne ne le fait, et on arbitre des architectures pendant 6 semaines pour un flux qui, après vérification, ne transporte aucune donnée de santé.

Ces 2 erreurs sont symétriques, et la première se rencontre bien plus souvent que la seconde.

Se croire bloqué

Travailler dans la santé ne teinte pas toute votre base. Les plannings de ressources, la facturation, les stocks, les tickets support, la documentation produit, les données RH : rien de tout cela n'est une donnée de santé. Un éditeur santé s'interdit souvent l'IA sur 80 % de son système d'information par un réflexe de prudence que rien n'impose.

Se croire libre

Une donnée devient une donnée de santé par déduction. Une liste de rendez-vous rattachée à un service d'oncologie en est une, même sans diagnostic écrit nulle part. Le nom du service suffit. Le croisement avec ce qui est déjà dans la base suffit.

Posez-vous une seule question : peut-on déduire une information sur l'état de santé d'une personne identifiable, y compris en croisant avec le reste de la base ? Si oui, le champ est dedans. Si non, il est dehors, et il ne doit pas supporter la contrainte des autres.

Cherchez le piège dans le texte libre : il se trouve toujours là. Un motif de contact, un commentaire de planification, une note de suivi contiennent plus que ce que le nom du champ annonce. Un champ « commentaire » dans un logiciel de rendez-vous est un champ de données de santé en puissance, et vous ne pouvez pas le qualifier sans en lire un échantillon réel. C'est 5 minutes de travail, et c'est la seule façon honnête de trancher.

Faites ce tri, et vous récupérez du budget. Le classement de tickets, la recherche dans un référentiel interne, l'aide à la rédaction documentaire, la génération de jeux de tests : autant de cas d'usage qui sortent du périmètre contraint et se traitent avec les outils du marché, en quelques jours. Reste un noyau dur, beaucoup plus petit, sur lequel vous concentrez l'effort d'architecture. Faites ce tri avant d'ouvrir la moindre discussion avec un fournisseur.

Le chemin de la donnée compte plus que le choix du modèle

La règle qui s'applique ne parle jamais d'IA ni de modèles. Elle pose 3 questions :

Qui envoie ?
Qu'est-ce qu'il envoie ?
Où se trouve celui qui reçoit ?

Rien sur l'architecture du modèle, sa taille, son éditeur ou ses performances. Vous pouvez choisir le modèle le plus vertueux du marché, ça ne changera rien à la réponse.

De son côté, le périmètre du certificat de votre hébergeur couvre des activités d'hébergement et une localisation de stockage. On n'y trouve rien sur l'inférence, rien sur les appels sortants de votre application, rien sur le contenu d'une requête. Ce n'est pas un oubli, c'est un autre objet.

Alors ouvrez le code et suivez la requête. Regardez de quel service elle part et quels champs elle embarque. Puis regardez vers quel nom de domaine elle sort, et à qui appartient ce domaine. Une demi-journée sur un projet existant, et vous saurez ce qu'aucun contrat ne vous dira.

Pourquoi la promesse « on ne conserve rien » ne suffit pas

Relisez les 3 questions du dessus : aucune ne porte sur ce que le fournisseur fait de vos données une fois qu'il les a reçues. Tout se joue au moment où vous envoyez, pas dans les conditions générales. Sa promesse de ne rien garder reste utile, elle réduit le risque et elle pèsera dans les garanties que vous négociez. Elle n'empêche pas vos données de partir.

Prenez le cas inverse. Si l'entreprise avec qui vous signez traite réellement vos données depuis l'Europe, vous ne transférez rien. 2 choses peuvent tout faire basculer : les prestataires auxquels elle sous-traite, et les techniciens qui administrent ses serveurs depuis l'étranger. Listez-les avec la checklist HDS, et vérifiez où se trouve chacun.

Sur ce dernier point, le régulateur européen ne laisse pas de place au doute :

Un accès à distance depuis un pays hors d'Europe, même s'il consiste seulement à afficher des données personnelles sur un écran, par exemple en situation de support, de dépannage ou d'administration, est également considéré comme un transfert, dès lors que les trois critères sont réunis.

« Et si je demandais son consentement au patient, pour envoyer ses données à l'étranger ? »

Ça ne marche pas. Un consentement valable doit être libre, et un patient qui vient se faire soigner n'est pas en position de refuser. Il doit aussi viser cet envoi précis, et pouvoir être retiré du jour au lendemain. Sur une fonctionnalité qui tourne en continu, vous ne pouvez pas tenir ça. Reste l'accord qui autorise aujourd'hui les échanges de données avec les États-Unis. Il est en vigueur, et il est attaqué. Si vous construisez une architecture santé dessus, sachez d'avance ce que vous basculez, et en combien de jours, le jour où cet accord tombe à l'eau.

Le trilemme de l'utilisation de modèles IA en santé

Les 3 éléments qui impactent votre projet :

Obtenir des réponses fiables de la part des modèles (la qualité)
Maîtriser la donnée envoyée aux modèles (open source, hébergé chez vous)
Maîtriser le coût de mise en place (la simplicité)

Vous en aurez 2 sur 3. Ce n'est pas un manque de maturité du marché ni un problème de fournisseur mal choisi, c'est la forme du problème.

Réponses fiables + coût maîtrisé

L'API d'un fournisseur américain

Les meilleurs modèles du marché, ceux qu'on appelle les modèles frontière : branchés en 2 jours, payés à l'usage. En échange, vos données sortent à chaque appel.
Réponses fiables + maîtrise de la donnée

Un gros modèle open-weight chez vous, ou une offre santé clé en main

Le modèle chez vous, c'est un open-weight, parfois un open source, que vous installez sur votre infrastructure. Les 2 options tiennent le niveau sans laisser sortir vos données, et les 2 se paient : l'une en cartes graphiques et en exploitation qui ne s'arrête jamais, l'autre en facture.
Coût maîtrisé + maîtrise de la donnée

Un petit modèle open-weight, chez vous

Il tourne sur du matériel raisonnable et rien ne sort. Sur des tâches simples, classer, extraire, reformuler court, il fait le travail. Sur du compte rendu libre, long et ambigu, il décroche face aux gros modèles.

Chaque paire s'obtient en renonçant au troisième sommet. Pour vous en sortir, ne cherchez pas à mieux arbitrer : réduisez le volume de données réellement soumis à la contrainte.

Chaque paire correspond à une architecture réelle. Voici les 3, sur les critères qui décident vraiment.

A

Vous appelez l'API d'un fournisseur américain

Soumis au droit américain

Ce qui sort: Tout ce que vous envoyez part chez le fournisseur, à chaque appel.
Pourquoi: Ses serveurs peuvent très bien être en Europe, ça ne change rien : une société américaine relève du droit américain, et sa maison mère peut être contrainte de donner accès à ce qu'elle héberge.
À produire: C'est aussi le cas quand vous passez par un hébergeur certifié HDS mais américain, AWS par exemple : le certificat couvre l'hébergement, il n'empêche pas la maison mère de relever du droit américain. Il vous faut les clauses types signées, une analyse écrite du risque réel, les protections que vous en tirez, et la liste tenue à jour de ce qui part.

Le bon choix : quand rien d'autre ne couvre le besoin, et que vous avez réduit au minimum ce qui sort.

B

Vous passez par un fournisseur européen

Pas de transfert direct

Ce qui sort: Rien par la grande porte. Tout dépend de qui travaille pour lui, et depuis où.
Pourquoi: Le problème revient par ses propres prestataires et par les techniciens qui administrent ses serveurs depuis l'étranger.
À produire: La liste écrite de ses prestataires et de leur pays, que vous demandez noir sur blanc. L'interdiction de réutiliser vos données sans votre accord écrit. Et la liste de qui peut se connecter à l'infrastructure, depuis où.

Le bon choix : par défaut, pour la plupart des produits.

C

Vous faites tourner le modèle chez vous

Pas de transfert

Ce qui sort: Rien.
Pourquoi: Il faut être deux pour transférer. Tout le reste du RGPD continue de s'appliquer.
À produire: Des cartes graphiques, quelqu'un pour tenir la machine en production, le suivi des versions du modèle, la trace de chaque appel. Vous portez tout.

Le bon choix : du texte médical libre, un volume prévisible, et l'exigence que rien ne sorte.

Posez les 3 sur la table, nommez celle qui se défend le mieux en audit, et détaillez celle que vous retenez. Le coût d'inférence ne tranche presque jamais. Ce qui tranche, c'est la charge d'exploitation, et sur le dossier que vous devrez sortir devant celui qui porte le RGPD, le responsable sécurité ou un auditeur. Une architecture moins chère à faire tourner mais impossible à documenter vous coûtera plus cher, plus tard, et au pire moment.

Réduisez plutôt le volume de données réellement soumis à la contrainte, autrement dit refaites le tri du début : la vraie sortie ne se trouve dans aucune de ces 3 options. Une fonctionnalité qui n'a besoin que de 3 champs structurés ne pose pas le même problème qu'une fonctionnalité qui avale des comptes rendus entiers.

Héberger le modèle ne suffit pas : toute la chaîne IA compte

C'est l'erreur la plus fréquente, et des équipes sérieuses la commettent. On installe un modèle ouvert sur une infrastructure certifiée, on coche la case, on passe à la suite. Sauf que le modèle, c'est la brique que tout le monde regarde. La donnée s'échappe presque toujours ailleurs.

Quand vous montez une recherche ou une synthèse documentaire, vous n'installez pas un modèle. Vous branchez une dizaine de composants qui voient tous le texte en clair, chacun avec son fournisseur et son pays. Un seul suffit à annuler tout votre travail d'hébergement.

Conversion et OCR des documents: Service d'OCR en ligne. Le document entier part, y compris les pages que vous n'aviez pas prévu d'indexer.
Calcul des vecteurs, ou embeddings: Souvent confié à un service américain. Convertir toute la base, c'est l'envoyer en entier, en une nuit, par une opération technique que personne ne regarde tourner.
Base vectorielle: Service hébergé aux États-Unis. Et un index de vecteurs n'est pas une donnée anonyme, seulement une donnée illisible à l'œil.
Réordonnancement des résultats: API tierce, retenue parce que ce n'est pas le modèle. Elle voit pourtant les passages en clair.
Traces, évaluation, suivi technique: Outil de suivi spécialisé. Les questions envoyées à l'IA et ses réponses y sont conservées en clair, par conception : c'est le produit.
Logs applicatifs et supervision: Agrégateur externalisé. La question envoyée à l'IA finit dans une ligne de journal, et cette ligne part avec toutes les autres.
Cache et files de traitement: Service managé dont la région n'a jamais fait l'objet d'un choix explicite.
Sauvegardes: Réplication vers une seconde région, parfois hors d'Europe, souvent active par défaut.

2 de ces composants méritent qu'on s'y arrête, parce qu'ils expliquent la plupart des cas.

Prenons le calcul des vecteurs. Avant qu'une IA puisse chercher dans vos comptes rendus, il faut les convertir en nombres, dans un format qu'elle sait manipuler. Beaucoup d'équipes installent le modèle chez elles, ce qui demande du travail et coûte cher, puis confient cette conversion à un service en ligne, parce que c'est plus simple. Résultat : le modèle n'a rien laissé sortir, mais tous vos documents sont partis, en une nuit. Et ça n'a pas l'allure d'une fuite. Ça a l'allure d'une opération de mise en route, que personne ne pense à vérifier.

Même chose avec les outils de suivi. Pour corriger une IA qui répond mal, il faut relire ce qu'on lui a demandé et ce qu'elle a répondu : les outils faits pour ça enregistrent donc tout, en clair. Prenez-en un hébergé aux États-Unis, et le contenu médical ressort par cette porte-là sans que personne s'en aperçoive. Un outil de suivi technique, ça ne se range pas mentalement dans la case « données de santé ».

La bonne question n'est donc pas « où tourne le modèle ». C'est « quels sont tous les composants qui voient le texte en clair, et où est établi chacun d'eux ». La liste tient sur une page, chaque ligne porte un nom de fournisseur et un pays. Tant que cette page n'existe pas, personne ne peut affirmer que la chaîne reste dans le périmètre, et surtout pas un certificat.

Le vrai coût se trouve aussi ici. Tout le monde compare le prix de l'inférence, qui est la partie la moins déterminante. Maintenir 8 composants dans un périmètre contraint, avec les mises à jour, les sauvegardes et la supervision qui vont avec, voilà la dépense réelle. Elle est prévisible, et vous pouvez la chiffrer avant de commencer.

Ce qu'il faut coder avant le premier appel au modèle

Masquer les noms réduit ce qui sort, sans changer les règles

Remplacer les noms et les identifiants avant l'envoi est utile, et vous devez le faire. Mais ça ne vous fait pas sortir du RGPD, et ça n'empêche pas l'envoi d'être un transfert. Ce qui compte, c'est ce que vous, vous envoyez.

La Cour de justice a jugé le 4 septembre 2025, dans une affaire relative au règlement applicable aux institutions européennes, que des données pseudonymisées ne sont pas, dans tous les cas et pour toute personne, des données personnelles. N'en faites pas une règle générale : la qualification est relative à chaque acteur. Ce qui n'est plus identifiable chez le destinataire l'est toujours chez vous, qui gardez la table de correspondance.

Et sur du texte clinique en format libre, la pseudonymisation naïve casse vite. L'histoire de la maladie d'un patient peut devenir une donnée identifiante, en cas de maladie rare notamment. Un compte rendu pseudonymisé ne devient pas anonyme pour autant. Ce que vous retirez, où vit la table de correspondance et qui peut la lire sont 3 décisions à prendre avant la première ligne de code.

Les traces de l'hébergeur ne couvrent pas ce que l'IA a lu

Votre hébergeur enregistre qui s'est connecté à ses serveurs, et quand. C'est son métier, et vous le vérifiez avec la checklist des 8 vérifications HDS. Mais il n'enregistre pas ce que votre application a envoyé au modèle, ni ce que le modèle a répondu. Cette trace-là, c'est à vous de la créer, dans votre code. Et si l'un de vos salariés pose la question depuis son compte personnel, il n'existe aucune trace nulle part.

3 questions, à poser au fournisseur et à votre propre code :

La question envoyée à l'IA part-elle dans un journal technique ?
La réponse du modèle est-elle conservée pour analyse, et où ?
Que retient le fournisseur, contrat en main, et pendant combien de temps ?

La CNIL a publié une recommandation sur le sujet en 2021. Elle ne vous dispense pas de répondre aux 3 questions. Le montage se voit sur un dispositif médical numérique sous HDS :

Offuscation des données patient dans les logs
Isolation stricte entre l'environnement de test et la production
Hébergement HDS sous contrôle du client

Le principe est le même pour une brique d'inférence, avec un objet de plus à protéger.

Aucune donnée patient réelle en dehors de la production

La règle est simple : les vraies données patient ne sortent jamais de la production. Vos développeurs et vos testeurs travaillent sur des jeux où les noms sont remplacés, les journaux masquent les identifiants et les dates de naissance, et personne ne fait d'export brut ni de copie sur son poste. La CNIL et la Haute Autorité de Santé recommandent la même chose dans un guide qu'elles préparent.

Un problème neuf apparaît alors. Une IA validée sur des données de test ne prouve rien sur la production : le texte réel est plus sale, plus long, plus ambigu, et c'est sur lui que la qualité de sortie se joue. Le jeu d'évaluation se fabrique alors au lieu d'être prélevé, et la méthode est détaillée dans tester une IA sans accès aux données réelles. Il vous faut aussi une procédure de validation en production :

Un périmètre restreint pour commencer
Une revue humaine des sorties
Une trace de ce qui a été jugé acceptable, et par qui

Ça se règle à la conception, pas en recette.

AI Act : ce que le report change, et ce qu'il ne change pas

Depuis le 2 août 2026, vous devez déjà 2 choses :

Prévenir la personne qu'elle a affaire à une IA, sauf quand c'est évident
Marquer les contenus que l'IA produit, pour qu'une machine puisse les reconnaître

L'obligation de marquage tombe quand l'IA se contente de mettre en forme ce que quelqu'un a déjà écrit ou dicté. Une dictée qui retranscrit la parole du médecin ne produit rien de neuf : rien à marquer. Une synthèse qui rédige un résumé à partir du dossier produit bien un texte : il faut le marquer. Regardez laquelle des 2 décrit votre fonctionnalité.

Les obligations lourdes, celles des IA à haut risque, sont repoussées à décembre 2027, et à août 2028 pour les dispositifs médicaux.

Reste à savoir si votre IA entre dans cette catégorie. C'est le cas si elle fait partie d'un dispositif médical qui doit passer devant un organisme certificateur, et qu'elle y joue un rôle critique. Une dictée qui retranscrit, ou une synthèse qu'un soignant relit et valide avant de l'envoyer, n'en fait pas partie : le texte européen les écarte explicitement. Vérifiez de quel côté vous tombez, et faites-le écrire dans votre dossier.

Ne confondez pas ce report avec un sursis. Le report s'applique à tout le monde. Le sursis, lui, ne vaut que pour les produits déjà vendus avant l'échéance, et il disparaît dès que vous modifiez sérieusement le produit. Si vous construisez maintenant, vous n'y avez pas droit : votre date est ferme, et vous avez jusque-là pour construire proprement. Les autres contraintes d'un produit régulé sont décrites dans le guide du CTO externalisé en santé.

Comment décider : la séquence, dans l'ordre

La séquence, dans cet ordre.

1
Qualifier champ par champ, échantillon de texte libre à l'appui : ce qui est vraiment une donnée de santé, et ce qui n'a rien à faire dans le périmètre contraint.
2
Écrire le chemin de la donnée sur une page : quel champ part, depuis quel service, vers quelle entité, établie où.
3
Lister tous les composants qui voient le texte en clair, pas seulement le modèle, avec le fournisseur et le pays de chacun.
4
Choisir l'architecture parmi les 3, en pesant la charge d'exploitation et non le prix de l'inférence.
5
Poser la pseudonymisation, l'offuscation des logs et l'environnement de recette avant le premier appel, pas après le pilote.
6
Faire relire ce chemin par celui qui porte le RGPD chez vous et par votre responsable sécurité, sur ce document, pas sur une intention. C'est aussi ce document qui débloque une DSI qui refuse.

Reste à savoir qui doit porter ce sujet dans l'organisation, parce qu'un chemin de donnée sans propriétaire se dégrade dès la première évolution du produit. Ce n'est pas un sujet de conformité. C'est un sujet d'architecture, et il se tranche avant d'écrire du code.

Faire relire l'architecture Parler de mon contexte

Questions fréquentes

Un hébergeur certifié HDS suffit-il pour brancher une IA générative sur des données de santé ?

Non. Le certificat couvre l'hébergement et l'endroit où vos données sont stockées. Il ne dit rien de l'endroit où votre application les envoie quand elle appelle un modèle. Le premier est détaillé dans la checklist des 8 vérifications HDS, le second commence au chemin de la donnée.

Comment savoir si une donnée est une donnée de santé ?

Posez la question champ par champ, pas application par application : peut-on déduire une information sur l'état de santé d'une personne identifiable, y compris en croisant avec le reste de la base ? Un rendez-vous rattaché à un service spécialisé en est une. Une facture, un stock ou un ticket support, non. Les champs de texte libre se qualifient en lisant un échantillon réel, jamais sur le nom du champ.

Qu'est-ce qu'un modèle frontière (frontier model) ?

Ce sont les modèles les plus avancés du moment, ceux que produisent les grands laboratoires. Ils donnent les meilleures réponses, en particulier sur du texte long et ambigu comme un compte rendu médical. Un modèle, c'est un énorme fichier de valeurs numériques appelées paramètres, calculées pendant l'entraînement. Les laboratoires qui produisent les modèles frontière ne publient pas ce fichier : vous ne pouvez pas les installer chez vous, vous y accédez uniquement par leur API, en leur envoyant vos données.

Qu'est-ce qu'un modèle open source ?

Au sens strict, un modèle dont tout est public : les paramètres, le code d'entraînement, les données utilisées pour l'entraîner, et une licence qui vous laisse libre de l'utiliser. C'est beaucoup plus rare qu'on ne le croit. Dans les discussions courantes, open source désigne le plus souvent des modèles qui sont seulement open-weight, parfois avec une licence qui limite l'usage commercial. Lisez la licence avant de vous engager.

Qu'est-ce qu'un modèle open-weight ?

Un modèle dont le fichier de paramètres est publié et téléchargeable, sans que le code et les données d'entraînement le soient forcément. C'est ce qui compte pour vous : vous téléchargez le fichier, vous faites tourner le modèle sur vos propres serveurs, et vos données ne sortent plus de chez vous. Llama, Mistral et Qwen fonctionnent ainsi. Le nombre de paramètres donne l'échelle : quelques milliards pour un petit modèle qui tient sur du matériel modeste, plusieurs centaines de milliards pour les plus gros, qui demandent une vraie infrastructure et un budget qui va avec.

Auto-héberger le modèle suffit-il à garder les données dans le périmètre ?

Non, et c'est l'erreur la plus fréquente. Le modèle n'est qu'un composant parmi une dizaine qui voient le texte en clair : conversion des documents, calcul des vecteurs (transformer vos textes en nombres pour pouvoir les rechercher), base de vecteurs, réordonnancement des résultats, cache, journaux techniques, traces d'évaluation, sauvegardes. Faire convertir une base entière par un service américain revient à lui envoyer cette base. La chaîne complète doit rester dans le périmètre, pas seulement l'inférence.

Un appel API vers un fournisseur de LLM établi hors d'Europe est-il un transfert de données ?

Oui, dès que 3 choses sont réunies : vous êtes soumis au RGPD, vous mettez la donnée à disposition d'une autre entreprise, et cette entreprise est installée hors d'Europe. Même un technicien qui se connecte de l'étranger pour dépanner, et qui ne fait qu'afficher des données à l'écran, compte comme un transfert.

Peut-on se fonder sur le consentement du patient pour utiliser un modèle non européen ?

Pas pour un service en production. Un consentement valable doit être donné librement, viser précisément cet envoi à l'étranger, et pouvoir être retiré du jour au lendemain. Un patient qui vient se faire soigner n'est pas en position de refuser, et une fonctionnalité qui tourne en continu ne peut pas tenir ces promesses. Pseudonymiser avant l'envoi ne change rien non plus : ça réduit le risque, ça ne change pas les règles.

Une dictée ou une synthèse de comptes rendus est-elle une IA à haut risque pour l'AI Act ?

Pas automatiquement. Le haut risque suppose que votre logiciel soit un dispositif médical, ou un élément de sécurité d'un dispositif médical, contrôlé par un organisme extérieur avant sa mise sur le marché. Le texte européen qui a reporté les échéances en 2026, le règlement (UE) 2026/1744, écarte du haut risque les IA servant uniquement à assister l'utilisateur, à automatiser une tâche ou à lui simplifier la vie. Écrivez cette qualification noir sur blanc, ne recopiez pas une date.

Le report de l'AI Act me laisse-t-il jusqu'en 2028 pour garder des traces ?

Non. Le report repousse ces obligations au 2 décembre 2027 ou au 2 août 2028 selon le cas. Mais l'obligation de garder la trace de ce qui se passe, ce qu'on appelle la journalisation, repose aujourd'hui sur d'autres bases : le RGPD, le référentiel de votre hébergeur et, pour un dispositif médical, la documentation technique et la surveillance après commercialisation.

Sources officielles

Cadre consulté pour cette version du 13 août 2026. La qualification d'un cas particulier reste attachée à son architecture, à ses contrats et à ses flux réels.