IA en santé : conformité HDS, RGPD et cas d'usage cliniques en 2026

Données de santé et RGPD : la catégorie spéciale

Les données de santé occupent une place à part dans le RGPD. L'article 9 du règlement les classe en catégorie spéciale, aux côtés des données biométriques, génétiques, raciales, religieuses et d'orientation sexuelle. Cette classification implique une protection renforcée et des conditions de traitement bien plus restrictives que les données personnelles ordinaires.

Définition des données de santé selon le RGPD

Le RGPD définit les données de santé comme « les données à caractère personnel relatives à la santé physique ou mentale d'une personne physique, y compris la prestation de services de soins de santé, qui révèlent des informations sur l'état de santé de cette personne ». Cette définition est très large : elle couvre les diagnostics, traitements, prescriptions, antécédents médicaux, résultats d'examens biologiques et d'imagerie, mais aussi les données indirectement révélatrices d'un état de santé (fréquentation d'une pharmacie, achat de certains dispositifs médicaux).

Pour l'IA, cela signifie que tout système qui traite des transcriptions médicales, des images radiologiques, des comptes-rendus de consultation, des dossiers patients ou des données de monitoring physiologique traite des données de santé — avec toutes les implications réglementaires qui en découlent.

Les bases légales disponibles pour traiter des données de santé

L'article 9 du RGPD interdit en principe le traitement des données de santé, sauf dans les cas suivants :

• Consentement explicite de la personne concernée (consentement distinct, spécifique, éclairé et révocable)
• Intérêts vitaux de la personne (urgence médicale)
• Exercice de la médecine : traitement par un professionnel de santé soumis au secret médical
• Santé publique : intérêt public dans le domaine de la santé publique
• Recherche médicale : avec les garanties de l'article 89 RGPD

Pour les établissements de santé déployant de l'IA sur des dossiers patients, la base légale la plus couramment utilisée est l'exercice de la médecine (soins) ou l'intérêt public (hôpitaux publics). Pour les éditeurs de logiciels IA santé, le consentement ou la délégation par l'établissement de santé sont généralement requis.

L'obligation d'AIPD systématique

Tout traitement de données de santé à grande échelle doit faire l'objet d'une Analyse d'Impact relative à la Protection des Données (AIPD) avant déploiement (article 35 RGPD). Pour les systèmes IA traitant des données de santé, l'AIPD doit couvrir : la nécessité et la proportionnalité du traitement, les risques pour les droits et libertés des patients, et les mesures pour atténuer ces risques. La CNIL a publié des lignes directrices spécifiques pour les AIPD IA en santé — les consulter avant tout projet.

HDS : l'obligation d'hébergement de données de santé

La certification HDS (Hébergement de Données de Santé) est une obligation légale française créée par la loi de modernisation du système de santé de 2016, précisée par le décret du 25 mai 2018. Elle s'applique à tout prestataire qui héberge des données de santé à caractère personnel pour le compte de tiers (établissements de santé, professionnels de santé, patients).

Qui est concerné par l'obligation HDS ?

La certification HDS est obligatoire pour :

• Les hébergeurs d'infrastructure physique hébergeant des données de santé
• Les hébergeurs d'infrastructure virtuelle (cloud) hébergeant des données de santé
• Les éditeurs de logiciels de santé proposant une solution SaaS (Software as a Service)
• Les opérateurs de systèmes d'information hébergeant des données de santé

Pour les solutions IA en santé, cela signifie que tout éditeur d'une application IA traitant des données de santé en mode SaaS doit être certifié HDS. Si l'établissement de santé héberge lui-même la solution (on-premise), c'est lui qui doit s'assurer que son infrastructure respecte les critères HDS — sans nécessairement être certifié si les données ne sortent pas de son périmètre.

Les 6 activités certifiables HDS

Le référentiel HDS (basé sur ISO 27001 + exigences spécifiques) couvre 6 activités : hébergement infrastructure physique, hébergement infrastructure virtuelle, hébergement de la plateforme d'exploitation, hébergement d'applications, infogérance, et sauvegarde. Un hébergeur cloud proposant une infrastructure à un éditeur SaaS santé doit être certifié pour les 3 premières activités. L'éditeur SaaS doit être certifié pour les activités 4 et 5.

Les acteurs cloud certifiés HDS

En 2026, les principaux acteurs cloud certifiés HDS en France incluent :

• Microsoft Azure (certifié HDS pour ses datacenters France) — attention au Cloud Act
• AWS (certifié HDS pour eu-west-3 Paris) — attention au Cloud Act
• OVHcloud (certifié HDS pour ses datacenters français)
• 3DS Outscale (certifié HDS et qualifié SecNumCloud)
• Atos/Eviden (Bull Cloud, certifié HDS)
• Orange Business (Flexible Engine, certifié HDS)

Pour les établissements publics de santé (hôpitaux, GHT) soumis à NIS2 et aux recommandations ANSSI, la combinaison HDS + SecNumCloud (3DS Outscale) est la configuration la plus sécurisée. Pour une clinique privée ou un groupement de professionnels, HDS seul (OVHcloud, Azure) peut suffire selon les données traitées.

Sanctions en cas de non-conformité HDS

L'hébergement illégal de données de santé (sans certification HDS) est une infraction pénale en France : jusqu'à 3 ans d'emprisonnement et 300 000 € d'amende pour les personnes physiques, 1,5 million d'euros pour les personnes morales. La CNIL peut également sanctionner sur le fondement du RGPD. Des contrôles ont eu lieu et des sanctions prononcées, notamment contre des startups santé ayant négligé cette obligation.

EU AI Act et IA médicale : les obligations haut risque

L'EU AI Act (Règlement 2024/1689), applicable depuis 2025-2026 selon les chapitres, classe les systèmes d'IA dans le domaine médical parmi les systèmes à haut risque de l'Annexe III. Cette classification déclenche les obligations les plus strictes du règlement.

Quels systèmes IA de santé sont classés haut risque ?

L'Annexe III, point 5 de l'EU AI Act liste comme systèmes à haut risque :

• Les systèmes d'IA destinés à être utilisés comme dispositifs médicaux ou comme composants de sécurité d'un dispositif médical
• Les systèmes d'IA destinés au diagnostic, au pronostic, à la surveillance ou au traitement des maladies
• Les systèmes utilisés pour la gestion et l'exploitation des infrastructures critiques de santé

En pratique, cela couvre : les outils d'aide au diagnostic (détection de cancers sur imagerie, analyse de biopsies), les systèmes de triage aux urgences, les outils de prédiction de risques patients, et les assistants de prescription médicamenteux.

Les systèmes d'IA purement administratifs (gestion des rendez-vous, facturation, dictée médicale transcription sans aide clinique) peuvent échapper à la classification haut risque, selon l'analyse de leur finalité réelle.

Les obligations EU AI Act pour les systèmes haut risque santé

Les déployeurs et fournisseurs de systèmes IA haut risque en santé doivent :

• Système de gestion des risques : identification, analyse et atténuation des risques tout au long du cycle de vie
• Gouvernance des données d'entraînement : documentation des données utilisées pour entraîner le modèle, contrôle de la qualité et de la représentativité, absence de biais discriminatoires
• Documentation technique complète : description du système, performances attendues, limites connues, métriques d'évaluation
• Tenue de logs automatique : les systèmes haut risque doivent automatiquement enregistrer les événements pertinents pendant leur fonctionnement
• Transparence : information des utilisateurs humains sur les capacités et limitations du système
• Supervision humaine : mesures permettant aux professionnels de santé de surveiller le fonctionnement du système, de le détecter en défaut et de le mettre hors service
• Exactitude, robustesse et cybersécurité : validation des performances selon des métriques définies
• Conformité et enregistrement : avant mise sur le marché, enregistrement dans la base de données européenne EUDAMED pour les dispositifs médicaux IA

Type de système IA santé	Classement EU AI Act	Obligations principales	Délai de conformité
Aide au diagnostic par imagerie	Haut risque	Documentation + logs + supervision humaine	Août 2026
Triage urgences	Haut risque	Documentation + logs + supervision humaine	Août 2026
Prédiction risques patients	Haut risque	Documentation + logs + supervision humaine	Août 2026
Dictée médicale (transcription)	Faible risque	Transparence sur usage IA	2027
Gestion des rendez-vous	Faible risque	Transparence minimale	2027
Codage médical automatique	Faible à modéré (à analyser)	Selon finalité exacte	Variable

MDR : quand l'IA devient dispositif médical

Le règlement européen sur les dispositifs médicaux (MDR, EU 2017/745) s'applique aux logiciels destinés à des usages médicaux spécifiques. En 2026, la frontière entre un logiciel IA d'aide à la décision médicale et un dispositif médical logiciel (SaMD — Software as a Medical Device) est devenue centrale pour l'ensemble du secteur.

Quand l'IA est-elle un dispositif médical ?

Selon le MDR et les guidelines MDCG (Medical Device Coordination Group), un logiciel est un dispositif médical s'il est destiné à des fins médicales spécifiques : prévention, diagnostic, surveillance, traitement ou atténuation d'une maladie ou blessure, ou compensation d'un handicap. Le critère déterminant est la finalité médicale revendiquée par le fabricant — pas les capacités techniques du logiciel.

Exemples concrets : un LLM qui analyse des images de scanner et fournit une aide au diagnostic de tumeur = dispositif médical probable. Un LLM qui transcrit des dictées médicales sans interprétation clinique = probablement pas un dispositif médical. Un LLM qui suggère des traitements à partir de données patient = analyse à faire selon les revendications de finalité.

Les classes de dispositifs médicaux logiciels

Le MDR classe les dispositifs médicaux en 4 classes selon leur niveau de risque :

• Classe I : risque faible, auto-certification possible
• Classe IIa : risque modéré, évaluation par organisme notifié (ON)
• Classe IIb : risque modéré à élevé, évaluation renforcée par ON
• Classe III : risque élevé, essais cliniques généralement requis

Pour les logiciels IA, la grande majorité des outils d'aide au diagnostic se classent en IIa ou IIb, nécessitant l'intervention d'un organisme notifié. Quelques systèmes très directement liés à des décisions thérapeutiques critiques peuvent atteindre la classe III.

Le marquage CE médical : un processus long et coûteux

L'obtention du marquage CE médical pour un logiciel IA est un processus qui prend généralement 18 à 36 mois et coûte entre 150 000 et 500 000 euros selon la classe. Il comprend : la définition de la destination d'usage et la classification, l'analyse de risques (ISO 14971), la validation technique et clinique, la documentation technique complète (Design Dossier), l'évaluation clinique (études, données de vie réelle), l'audit par un organisme notifié, et l'enregistrement EUDAMED.

Ce processus a un impact stratégique majeur pour les éditeurs IA santé : le périmètre du marquage CE doit être défini avant le développement, car les modifications post-marquage nécessitent souvent une réévaluation complète ou partielle.

Cas d'usage cliniques concrets en 2026

Malgré la complexité réglementaire, l'IA génère des gains de productivité et des améliorations de qualité documentés dans de nombreux cas d'usage cliniques et administratifs.

1. Aide au diagnostic par analyse d'imagerie

C'est le cas d'usage IA santé le plus médiatisé, et pour cause : les performances des modèles de vision (Computer Vision) sur la détection de pathologies radiologiques et anatomopathologiques sont souvent comparables ou supérieures aux radiologues seniors sur des tâches précises.

Exemples déployés en France et en Europe : détection de nodules pulmonaires suspects sur scanner thoracique (Therapixel, Sonio), analyse de mammographies pour détection de cancers du sein (Hologic, Lunit), détection de rétinopathie diabétique sur fond d'œil (IDx-DR), analyse de lames histologiques pour cancer de la prostate (Paige Prostate).

Le cadre réglementaire : ces systèmes sont des dispositifs médicaux classe IIa/IIb marqués CE selon le MDR. Ils sont classés haut risque EU AI Act. Leur déploiement nécessite une formation des radiologues utilisateurs, une supervision humaine explicite (le radiologue valide chaque résultat), et une documentation de performance dans l'établissement.

2. Codage médical automatisé (CIM-10, CCAM)

Le codage médical — attribuer les codes CIM-10 (diagnostics) et CCAM (actes) aux séjours hospitaliers — est une activité chronophage, source d'erreurs et d'enjeux financiers importants (financement T2A). Les LLM, fine-tunés sur les comptes-rendus de séjour et les nomenclatures, atteignent des taux d'exactitude de 85-92 % sur les codes principaux.

Ce cas d'usage est particulièrement attractif car il n'a pas de finalité clinique directe (c'est un usage administratif et financier), ce qui simplifie son statut réglementaire — probablement pas dispositif médical, risque EU AI Act faible à modéré selon l'analyse. Les données traitées (comptes-rendus de séjour) restent des données de santé nécessitant l'hébergement HDS.

Gains documentés : réduction du temps de codage de 60-70 %, amélioration du taux de capture des codes secondaires (qui améliorent le financement), réduction des requêtes de l'assurance maladie.

3. Gestion intelligente des rendez-vous et du parcours patient

Les LLM permettent d'automatiser une grande partie des interactions patients : prise de rendez-vous par chat ou téléphonie (NLP vocal), rappels personnalisés, tri des demandes de consultations non programmées, orientation vers le bon spécialiste. Des établissements comme le CHU de Bordeaux ou l'AP-HP ont déployé des assistants virtuels pour la gestion des rendez-vous.

Gains : réduction de 30-40 % des appels entrants au standard, réduction du taux de rendez-vous non honorés (no-show) de 15-25 %, disponibilité 24h/24. Exigences réglementaires : données patients traitées = HDS requis pour le prestataire. Si l'assistant virtuel oriente cliniquement (« votre symptôme X nécessite une consultation urgente »), l'analyse MDR s'impose.

4. Dictée médicale et documentation clinique

La dictée médicale transcrite et structurée par IA est l'un des cas d'usage les plus déployés et les plus acceptés par les professionnels de santé. Des solutions comme Nuance DAX (Microsoft), Suki, ou des acteurs français comme Optisante permettent au médecin de dicter naturellement pendant ou après la consultation, le LLM structurant le compte-rendu dans le format attendu (SOAP, CR de consultation, lettre de sortie).

Gains documentés : réduction du temps de documentation de 50-70 %, amélioration de la qualité des dossiers (plus exhaustifs), réduction du burnout médical lié aux tâches administratives. Le Conseil National de l'Ordre des Médecins a publié en 2025 des recommandations sur l'usage de l'IA en documentation clinique, insistant sur la validation systématique du compte-rendu par le médecin.

Attention Nuance DAX : solution Microsoft, donc soumise au Cloud Act. Des alternatives françaises (hébergement HDS français) existent et doivent être préférées pour les établissements publics.

5. Analyse de prescription et aide à la pharmacovigilance

Les LLM peuvent détecter des interactions médicamenteuses potentiellement dangereuses, signaler des contre-indications selon le dossier patient, ou identifier des prescriptions hors AMM. Ces systèmes sont typiquement intégrés dans le logiciel de prescription (LAP — Logiciel d'Aide à la Prescription) et constituent des dispositifs médicaux. Ils sont déjà bien établis dans les solutions existantes (Proxicare, Pharmagest), et l'IA générative permet d'aller plus loin dans la contextualisation des alertes.

6. Analyse et synthèse des données biologiques et génomiques

Pour les laboratoires et les services d'oncologie, l'IA permet l'interprétation automatisée des résultats biologiques complexes, la détection d'anomalies, et la synthèse des données de séquençage génomique pour la médecine personnalisée. Ces applications sont parmi les plus réglementées : dispositif médical IIb ou III, validation clinique sur cohortes importantes, supervision médicale obligatoire.

Déploiement souverain de l'IA en établissement de santé

Les établissements de santé publics et privés doivent concilier des exigences parfois contradictoires : moderniser leurs pratiques avec l'IA, respecter des obligations réglementaires strictes, et maîtriser des budgets sous pression. L'architecture de déploiement est centrale.

Pourquoi le on-premise est particulièrement adapté à la santé

Le déploiement on-premise présente des avantages spécifiques pour les établissements de santé :

• Zéro transfert de données : les données patient ne quittent jamais le SI hospitalier — élimination du risque de fuite externe
• Conformité HDS simplifiée : l'établissement héberge lui-même — il maîtrise son infrastructure HDS sans dépendance à un prestataire externe
• Pas de Cloud Act : aucune entité américaine dans la chaîne — immunité totale
• Intégration native au SIH : le LLM peut accéder directement aux bases de données cliniques (DPI, PACS, LAB) via l'intranet hospitalier, sans transiter par internet
• Disponibilité offline : un LLM on-premise fonctionne même en cas de panne internet ou d'incident réseau — critique pour les urgences

Architecture recommandée pour un établissement de santé

L'architecture cible pour un établissement de 400-800 lits :

• Serveur GPU dédié : 2x A100 80 Go ou 1-2x H100 PCIe, hébergé dans la salle serveurs de l'établissement ou dans un datacenter HDS exploité par le GHT/GIP
• Isolation réseau : le serveur LLM accessible uniquement depuis le réseau interne hospitalier (VLAN dédié), sans accès internet direct
• Authentification AD/SSO : intégration à l'Active Directory hospitalier pour que chaque praticien accède avec ses identifiants habituels
• Modèle fine-tuné sur la terminologie médicale : Llama 3.1 70B ou Mistral Large fine-tuné sur des corpus médicaux français, puis adapté aux spécificités de l'établissement
• Logging complet : traçabilité de chaque interaction (utilisateur, heure, requête anonymisée) pour l'audit EU AI Act et la matériovigilance

Les GHT comme mutualisation

Les Groupements Hospitaliers de Territoire (GHT) offrent une opportunité de mutualisation des infrastructures IA entre établissements membres. Un serveur GPU partagé au niveau du GHT, hébergé dans l'établissement support, peut servir plusieurs hôpitaux du groupement via le réseau privé du GHT. Cette architecture divise les coûts par le nombre d'établissements tout en maintenant la souveraineté des données (les données de chaque établissement restent dans son périmètre, seul le modèle est partagé).

Risques spécifiques et points de vigilance

Le déploiement de l'IA en santé comporte des risques spécifiques qui justifient une prudence particulière et des garde-fous robustes.

L'hallucination médicale : le risque critique

Les LLM peuvent générer des informations médicales plausibles mais incorrectes (hallucinations). En contexte médical, une hallucination peut avoir des conséquences graves : prescription d'un médicament contre-indiqué, diagnostic erroné, interaction médicamenteuse non signalée. Les garde-fous indispensables : supervision humaine systématique (le professionnel de santé valide chaque output avant tout acte), limitation du périmètre (l'IA n'a accès qu'aux informations nécessaires à la tâche), et formation explicite des utilisateurs sur les risques d'hallucination.

Les biais algorithmiques en santé

Les modèles d'IA entraînés sur des données de santé peuvent reproduire ou amplifier des biais présents dans ces données. Des études ont montré que certains outils de détection de maladies cardiovasculaires sous-diagnostiquaient les femmes (sous-représentées dans les études d'entraînement) ou sur-diagnostiquaient certaines pathologies chez des populations spécifiques. L'EU AI Act impose une analyse de non-discrimination avant déploiement — mais la responsabilité de la validation clinique reste celle de l'établissement ou de l'éditeur.

La cybersécurité des systèmes IA en santé

Les établissements de santé sont des cibles prioritaires des ransomwares. Un serveur LLM mal sécurisé peut devenir un vecteur d'attaque ou un point d'exfiltration. Les mesures indispensables : segmentation réseau stricte du serveur IA, pas d'accès internet direct, mises à jour de sécurité régulières du système d'exploitation et des frameworks, monitoring des accès et des comportements anormaux, et intégration dans le plan de continuité d'activité (PCA/PRA) de l'établissement.

La question du secret médical

Le secret médical s'impose à tous les professionnels de santé et, par extension, aux systèmes d'information qui traitent les données couvertes par ce secret. Un LLM hospitalier ne doit pas permettre à un praticien d'accéder aux dossiers de patients qui ne sont pas dans son périmètre de soins. Les contrôles d'accès doivent être aussi granulaires que dans le DPI (Dossier Patient Informatisé) existant.

Feuille de route conformité IA santé : les 8 étapes

Étape	Action	Responsable	Délai
1	Inventaire des systèmes IA existants ou en projet	DSI + DIM	J+30
2	Analyse MDR : identification des systèmes dispositif médical	Affaires réglementaires	J+60
3	Classification EU AI Act par système	DPO + Juriste	J+60
4	AIPD pour chaque traitement de données de santé	DPO	J+90
5	Audit infrastructure HDS (interne ou prestataire)	DSI + RSSI	J+90
6	Mise en place des logs et supervision humaine	DSI + équipes médicales	J+120
7	Formation des utilisateurs (praticiens, cadres)	DRH + DSI	J+120
8	Procédure de matériovigilance et incident IA	Médecin référent IA	J+150

FAQ — IA en santé, HDS et conformité

Un hôpital public peut-il utiliser ChatGPT pour des tâches médicales ?

Non, pas pour des tâches impliquant des données patient. ChatGPT est un service d'OpenAI (entreprise américaine), soumis au Cloud Act, et non certifié HDS. Envoyer des données patient à ChatGPT constitue une violation de l'obligation d'hébergement HDS et potentiellement une violation du RGPD (données de santé transmises à un sous-traitant non habilité). Pour les tâches sans données patient (rédaction de protocoles génériques, formation, recherche bibliographique), l'usage de ChatGPT est possible avec les précautions habituelles.

La dictée médicale IA est-elle un dispositif médical ?

Selon les guidelines MDCG 2019-11 et l'analyse SNDS/HAS, la dictée médicale pure (transcription vocale en texte) n'est pas un dispositif médical car elle n'a pas de finalité médicale au sens MDR. En revanche, si la solution propose une aide à la structuration du compte-rendu avec des suggestions de diagnostics ou traitements, l'analyse MDR s'impose et peut conclure à un dispositif médical. La frontière est subtile et dépend des revendications exactes de la solution.

Quelle est la différence entre HDS et ISO 27001 pour une startup santé numérique ?

ISO 27001 certifie la qualité du système de management de la sécurité de l'information — c'est une certification généraliste. HDS est une certification spécifique au secteur santé en France, qui impose des exigences supplémentaires sur l'infrastructure physique, les contrôles d'accès aux données de santé, et les obligations contractuelles vis-à-vis des clients (établissements de santé). Pour une startup SaaS santé hébergeant des données patient en France, HDS est obligatoire légalement. ISO 27001 est un prérequis de HDS (le référentiel HDS est construit sur ISO 27001) mais ne le remplace pas.

Comment financer un projet IA en santé dans un hôpital public ?

Plusieurs financements sont disponibles pour les hôpitaux publics. Le Ségur du Numérique en Santé (jusqu'à 2 milliards d'euros mobilisés) finance la modernisation des SI hospitaliers, incluant les projets IA. Les appels à projets du Fonds d'Innovation pour le Système de Santé (FISS) ciblent spécifiquement les innovations IA. Le programme France 2030 (axe santé numérique) cofinance des projets d'IA médicale. Les GHT peuvent mutualiser les investissements. Enfin, certaines régions (Île-de-France, Auvergne-Rhône-Alpes) proposent des subventions spécifiques pour la transition numérique des établissements de santé.

L'IA peut-elle prendre des décisions médicales de façon autonome ?

Juridiquement et éthiquement, non. L'EU AI Act exige une supervision humaine pour les systèmes IA à haut risque. Le code de déontologie médicale impose que toute décision médicale reste sous la responsabilité d'un médecin. Pratiquement, les systèmes IA médicaux actuels sont conçus comme des outils d'aide à la décision — ils suggèrent, alertent, synthétisent — mais la décision finale appartient au professionnel de santé. Tout système IA qui prétendrait décider de façon autonome un diagnostic ou un traitement serait non conforme au MDR, à l'EU AI Act et au code de déontologie médicale.

Quelle est la responsabilité d'un médecin qui suit une recommandation erronée de l'IA ?

La question de la responsabilité médicale en cas d'erreur IA est tranchée par la jurisprudence émergente et l'EU AI Act : le médecin reste responsable de ses décisions cliniques, même si elles s'appuient sur une recommandation IA. L'IA est un outil, pas un décideur. En revanche, l'éditeur du système IA peut être co-responsable si le système présentait un défaut documenté ou si ses revendications de performance étaient inexactes — c'est l'articulation avec l'AI Liability Directive. La règle pratique : le médecin doit exercer son jugement clinique sur toute recommandation IA, et ne jamais la suivre aveuglément.