IA générative et données de santé : où faire tourner le modèle sans sortir du cadre HDS

« Est-ce qu'on a le droit de passer nos comptes rendus dans un LLM ? » Cette question arrive dans à peu près tous nos cadrages santé depuis deux ans, et elle est presque toujours posée à un juriste. C'est une erreur d'aiguillage : la réponse est une décision d'architecture, et elle se prend en lisant des certificats.

Nous avons fait l'exercice le 18 septembre 2026, fournisseur par fournisseur, sur les sources primaires. Le résultat contredit ce qu'on lit partout, y compris dans le sens qui arrange le discours sur la souveraineté.

La règle que presque tout le monde lit à l'envers

L'erreur de départ est de traiter la certification HDS comme un badge d'entreprise. « OVHcloud est HDS », « AWS est HDS », donc tout ce qu'ils vendent serait utilisable pour des données de santé. C'est faux, et c'est faux dans les deux sens.

Un certificat HDS se lit sur quatre dimensions :

1. Le service. Le périmètre liste des produits précis. Un fournisseur certifié peut parfaitement vendre, à côté, des services qui ne sont pas au certificat.
2. La région. Le périmètre est géographique. Depuis le décret du 24 mars 2026, le stockage doit se faire dans l'Espace économique européen, sujet que nous détaillons dans notre article sur le référentiel HDS v2 et le décret de souveraineté.
3. L'activité. Le référentiel définit six activités, du site physique à la sauvegarde externalisée, en passant par l'administration et l'exploitation. Un hébergeur peut être certifié sur les activités 1 à 4 et pas sur la 5.
4. Le contrat. La certification ne suffit pas : le code de la santé publique impose des clauses contractuelles spécifiques, qu'il faut avoir signées.

La bonne question n'est donc jamais « ce fournisseur est-il HDS ». C'est : le service que j'appelle, dans la région où je l'appelle, est-il dans le périmètre du certificat, pour l'activité concernée, et ai-je signé le contrat qui va avec ?

Ce que disent réellement les certificats sur les services d'IA

Voici l'état au 18 septembre 2026, tel qu'il ressort des documentations officielles des fournisseurs.

Fournisseur	Statut HDS	Services d'IA dans le périmètre
AWS	HDS v2 depuis le 21 avril 2026	Amazon Bedrock (hors Bedrock Marketplace), SageMaker AI, Transcribe, Comprehend Medical, HealthLake
Scaleway	HDS v2.0, activités 1 à 4 seulement	Generative APIs et Managed Inference hors périmètre, instances CPU et GPU dans le périmètre
OVHcloud	HDS certifié	AI Endpoints, AI Deploy, AI Training, AI Notebooks hors liste, Public Cloud Instances et Managed Kubernetes dedans
Microsoft	HDS v2.0, certificat émis en octobre 2025	Règle : services Azure listés conformes ISO 27001, dans 14 régions EEE. Liste par service non publique
Google Cloud	HDS v2.0, six activités	Inclusion de Vertex AI non confirmée publiquement
Mistral AI	La Plateforme non certifiée HDS	Voie conforme : poids ouverts auto-hébergés
OpenAI, Anthropic	Aucune certification HDS	Sans objet

Trois commentaires sur ce tableau, parce que les lignes ne se valent pas.

Chez AWS, la règle est publiée et elle est généreuse. AWS indique que le périmètre HDS correspond au périmètre de sa certification ISO/IEC 27001. Or Amazon Bedrock y figure, avec une seule exclusion, Bedrock Marketplace. SageMaker AI également, avec ses propres exclusions (Studio Lab, Public Workforce, Vendor Workforce). La certification couvre 27 régions, dont six dans l'EEE pour les six activités : Francfort, Irlande, Milan, Paris, Espagne et Stockholm. Les régions hors EEE ne sont couvertes que sur les activités 3 à 6.

Autrement dit : appeler Bedrock depuis la région Paris, avec le contrat HDS signé, tient debout. C'est l'inverse de ce que raconte la littérature sur le sujet.

Chez Microsoft et Google, on ne peut pas conclure publiquement. Microsoft publie clairement sa règle (les services Azure listés comme conformes ISO 27001, dans quatorze régions EEE nommées, les services en préversion étant exclus), mais la liste par service se trouve dans les annexes A et B d'un document du Service Trust Portal qui demande une authentification. Nous ne pouvons donc pas affirmer qu'Azure OpenAI est dans le périmètre, ni l'inverse. Même situation pour Vertex AI chez Google Cloud. C'est une information à demander à votre interlocuteur commercial, par écrit, avec le certificat en pièce jointe.

Chez les acteurs français, c'est le constat le plus intéressant. Scaleway est certifié sur les activités 1 à 4, donc pas sur l'activité 5, l'administration et l'exploitation du système d'information. Ses instances CPU et GPU sont au périmètre, mais ses Generative APIs et son Managed Inference n'y sont pas. Chez OVHcloud, même schéma : les Public Cloud Instances sont certifiées, la gamme AI ne l'est pas, et la certification d'AI Endpoints figure encore comme demande ouverte dans leur roadmap publique.

Le constat contre-intuitif

Résumons ce que ça donne, parce que c'est le cœur du sujet.

Chez les fournisseurs français, les APIs d'IA managées sont hors périmètre HDS, alors que les instances GPU y sont.

Ce constat change la nature du débat. Déployer un modèle à poids ouverts sur de l'infrastructure certifiée n'est pas un choix idéologique en faveur de la souveraineté : c'est, chez ces fournisseurs, la seule option couverte par le certificat. Le raccourci commercial est de vous vendre l'auto-hébergement comme une posture. La réalité est une conséquence mécanique du périmètre.

Et symétriquement, le discours « il faut fuir les hyperscalers américains » ne tient pas sur le terrain du HDS : Bedrock est au périmètre d'AWS, pas Managed Inference chez Scaleway. Le droit applicable et l'exposition aux législations extra-européennes sont un autre sujet, parfaitement légitime, mais c'est un sujet distinct qu'il faut instruire séparément.

Les trois architectures qui tiennent

1. Le modèle à poids ouverts sur infrastructure certifiée

Vous déployez un modèle (Mistral, Llama, Qwen) sur des instances GPU dans le périmètre HDS de votre fournisseur, et vous exposez votre propre point d'entrée d'inférence.

Ce que ça règle : la donnée ne quitte jamais le périmètre certifié, vous maîtrisez la rétention, les journaux et les versions de modèle.

Ce que ça coûte : des GPU qui tournent, donc une facture qui ne dépend plus du volume d'appels mais du temps de disponibilité. Et une exploitation à votre charge, avec une nuance de taille : si votre fournisseur n'est pas certifié sur l'activité 5, l'administration et l'exploitation, c'est vous qui portez cette activité, et c'est votre conformité qui est en jeu. Ce n'est pas un détail d'infogérance, c'est un écart à documenter.

Quand c'est le bon choix : volume régulier, données directement identifiantes, exigence de maîtrise complète.

2. La dé-identification en amont de l'appel

Vous conservez un service managé, mais vous supprimez ou remplacez les éléments identifiants avant l'appel, et vous les réinjectez au retour.

Ce que ça règle : si ce qui sort de votre système n'est plus une donnée de santé à caractère personnel, le cadre HDS ne s'applique pas à cet appel.

Ce que ça ne règle pas, et c'est le piège : la dé-identification de texte libre est difficile. Un compte rendu contient des dates, des noms de praticiens, des établissements, des pathologies rares, des combinaisons qui réidentifient. La CNIL distingue nettement l'anonymisation, irréversible, de la pseudonymisation, qui reste un traitement de données personnelles. Une pseudonymisation n'autorise pas à sortir du cadre. Il faut donc mesurer le risque de réidentification, pas le supposer.

Quand c'est le bon choix : données déjà structurées, champs identifiants clairement bornés, ou usages qui ne portent pas sur du texte clinique libre.

3. Le service managé dont vous avez lu le certificat

Vous utilisez une API managée qui est effectivement au périmètre, dans une région couverte, avec le contrat HDS signé.

Ce que ça règle : vous ne gérez pas de GPU, vous payez à l'usage, vous bénéficiez du niveau de service du fournisseur.

Ce que ça exige : le certificat en main, pas une plaquette. La région vérifiée dans votre configuration, pas dans la console par défaut. Le contrat signé. Et une vérification de la politique de rétention des prompts et des sorties, qui est un sujet distinct de la certification.

Quand c'est le bon choix : volumes variables, équipe réduite, et un fournisseur dont le périmètre couvre réellement le service visé.

La question préalable que personne ne pose

Avant de choisir une architecture, il y en a une plus simple : est-ce que vous envoyez vraiment des données de santé à caractère personnel ?

Beaucoup de cas d'usage n'en envoient pas, et le découvrent tard :

• une recherche sémantique dans une documentation médicale, un référentiel ou des recommandations de bonne pratique ne porte sur aucune donnée de patient ;
• un assistant qui répond sur le fonctionnement de votre logiciel non plus ;
• une génération de courrier type, avec fusion des données nominatives en local après l'appel, n'envoie rien d'identifiant ;
• un modèle qui classe des documents par catégorie peut souvent travailler sur des extraits épurés.

Découper la fonctionnalité pour que l'appel au modèle ne porte que sur ce qui est strictement nécessaire est souvent moins coûteux que de déplacer toute l'infrastructure. C'est de la minimisation, au sens du RGPD, appliquée à une frontière technique. Sur le cadre RGPD qui s'applique par ailleurs, voir notre guide RGPD et données de santé pour les éditeurs.

Les pièges contractuels, vérifiés

Quatre points qui coûtent cher et qu'on ne trouve pas dans les plaquettes.

Le périmètre figé à la signature. Chez Scaleway, le périmètre HDS est défini par le contrat au moment de la signature. Ajouter un produit ensuite n'est pas automatique, et un produit qui devient certifié après votre signature n'entre pas tout seul dans votre périmètre. Dans les deux cas il faut un avenant.

Les conditions d'éligibilité. Chez OVHcloud, l'usage des produits HDS suppose un niveau de support Business ou Enterprise, l'acceptation du Healthcare Addendum, et l'activation explicite de l'option HDS. Un compte standard qui déploie sur un produit certifié n'est pas dans le cadre pour autant.

Les préversions exclues. Microsoft précise que le certificat HDS ne s'applique pas aux services en préversion. Or les services d'IA sont précisément ceux qui restent longtemps en préversion. Vérifiez le statut du service, pas seulement son nom.

Les documentations périmées. La page de documentation HDS d'OVHcloud affiche encore « HDS v2018 » avec une mise en œuvre de la version 2024 « prévue pour 2024 ». Or, depuis le 16 mai 2026, un certificat délivré sous l'ancien référentiel ne permet plus d'héberger des données de santé. La page est en retard sur la réalité du certificat, ce qui illustre la règle générale : demandez le certificat, pas la page web.

Ce que ça change dans votre architecture

Le choix fait, il se traduit en décisions concrètes. Voici ce que nous mettons en place sur ce type de projet.

Une passerelle d'inférence unique. Tous les appels au modèle passent par un seul composant de votre système. C'est le seul endroit où vous pouvez appliquer la dé-identification, la journalisation, les quotas et le filtrage. Un appel direct depuis le front-end rend tout le reste indémontrable.

Zéro prompt dans les journaux applicatifs. Le réflexe de tracer les entrées et sorties pour déboguer transforme votre agrégateur de logs en hébergement de données de santé non déclaré. Nous appliquons le même scrubbing que pour le reste des données de santé, détaillé dans notre article sur l'architecture technique d'une application e-santé.

La rétention côté fournisseur, vérifiée par écrit. La certification dit où la donnée est traitée, pas combien de temps elle est conservée ni si elle sert à entraîner. Ce sont des clauses, et elles se lisent.

Le versionnement du modèle et du prompt. Un changement de version de modèle change les sorties. Si votre produit est un dispositif médical, c'est un changement à gérer ; s'il ne l'est pas, c'est quand même une régression fonctionnelle possible. Les deux se tracent.

La transparence de l'article 50 de l'AI Act. Si votre produit génère des contenus de synthèse, ils doivent être détectables et marqués. Cette obligation est applicable depuis le 2 août 2026, et un butoir au 2 décembre 2026 vise les systèmes déjà sur le marché. Détail dans notre article sur l'AI Act en santé.

La checklist de vérification

Avant de brancher un modèle sur des données de patients :

1. Lister ce qui sort réellement de votre système à chaque appel, champ par champ.
2. Vérifier si ces données sont identifiantes, et mesurer le risque de réidentification plutôt que le supposer.
3. Demander le certificat HDS du fournisseur, pas une page marketing, et vérifier sa version.
4. Y chercher le service précis que vous appelez, et son statut (général ou préversion).
5. Vérifier la région dans votre configuration réelle.
6. Vérifier les activités couvertes, en particulier l'activité 5 si vous comptez sur le fournisseur pour l'exploitation.
7. Signer le contrat HDS et les avenants nécessaires pour les produits ajoutés après coup.
8. Obtenir par écrit la politique de rétention et de non-utilisation pour l'entraînement.

Pour le choix de l'hébergeur lui-même, avec les périmètres et les prix, notre comparatif des hébergeurs HDS en France traite la question de façon détaillée. Cet article-ci ne traite que la couche IA qui vient se poser dessus.

FAQ : IA générative et données de santé

Peut-on utiliser ChatGPT avec des données de patients ?

Non, pas des données de patients identifiantes. OpenAI ne détient pas de certification HDS, et l'hébergement de données de santé pour le compte d'un professionnel ou d'un établissement de santé impose un hébergeur certifié. La même réponse vaut pour Anthropic. Un usage sur des données réellement anonymes ou sans lien avec un patient est un autre sujet.

OpenAI est-il certifié HDS ?

Non. Ni OpenAI ni Anthropic ne figurent parmi les hébergeurs certifiés. Des certifications comme SOC 2 ou ISO 27001 ne remplacent pas le HDS, qui est une exigence du code de la santé publique français.

Amazon Bedrock peut-il être utilisé pour des données de santé ?

AWS indique que le périmètre de sa certification HDS correspond au périmètre de sa certification ISO/IEC 27001, et Amazon Bedrock y figure, à l'exception de Bedrock Marketplace. Sous réserve d'utiliser une région couverte et d'avoir signé le contrat HDS, c'est une option à instruire sérieusement.

Les Generative APIs de Scaleway sont-elles couvertes par le HDS ?

Non, d'après le périmètre publié. Scaleway est certifié sur les activités 1 à 4 du référentiel v2.0, et ses instances CPU et GPU sont au périmètre, mais ses Generative APIs et son Managed Inference n'y figurent pas. Déployer votre propre modèle sur leurs instances GPU est en revanche couvert.

Azure OpenAI est-il dans le périmètre HDS de Microsoft ?

Nous ne pouvons pas l'affirmer publiquement. Microsoft publie sa règle (les services Azure listés conformes ISO 27001, dans quatorze régions EEE, hors préversions), mais la liste par service se trouve dans un document du Service Trust Portal accessible après authentification. À faire confirmer par écrit par Microsoft avant toute décision d'architecture.

Faut-il forcément un modèle français pour être conforme ?

Non. La conformité HDS porte sur le périmètre du certificat de l'hébergeur, pas sur la nationalité du modèle. Un modèle à poids ouverts américain déployé sur une infrastructure certifiée en France est dans le cadre, et une API française non certifiée ne l'est pas. Les questions de souveraineté et d'exposition aux législations extra-européennes sont légitimes, mais elles s'instruisent séparément.

La pseudonymisation suffit-elle pour sortir du cadre HDS ?

Non. La pseudonymisation reste un traitement de données à caractère personnel, contrairement à l'anonymisation qui doit être irréversible. Seule une anonymisation réelle, dont le risque de réidentification a été évalué, fait sortir du cadre. Sur du texte clinique libre, ce niveau est difficile à atteindre.

Ce que nous faisons chez Bob le développeur

Nous ne sommes pas hébergeur. Nous concevons et déployons des applications de santé chez des hébergeurs certifiés, en lisant les périmètres activité par activité, et c'est exactement le travail que demande une couche d'IA. Sur ce type de projet, nous instruisons le choix d'architecture à partir de la donnée qui sort réellement du système, pas à partir d'un principe.

Notre page développement d'IA en santé détaille notre approche, notre page accompagnement HDS traite la mise en conformité de l'hébergement, et vous pouvez nous décrire votre projet pour un premier ordre de grandeur.

Vérifications effectuées le 18 septembre 2026 sur les documentations officielles des fournisseurs. Les périmètres de certification évoluent : demandez le certificat en cours de validité avant toute décision.