IA et données de santé : le cadre réglementaire que chaque éditeur HealthTech doit connaître

Temps de lecture : 5-6 min

Mis à jour le 8 novembre 2026

Une startup de la santé lance un outil d’aide au diagnostic. L’algorithme analyse des images médicales, croise des antécédents, et produit une recommandation clinique en quelques secondes. L’outil est d’une précision redoutable, les premiers partenaires s’intéressent au projet et les discussions commerciales avancent, qu’il s’agisse de s’implanter dans des structures de soins, d’équiper des réseaux de médecine de ville ou de signer avec des plateformes de télésanté.

Le premier filtre incontournable : le piège du règlement MDR et l’Annexe I de l’AI Act

Avant même d’examiner la gouvernance des données ou la conformité de l’intelligence artificielle, une question juridique préalable s’impose : votre logiciel bascule-t-il en dispositif médical au sens du règlement (UE) 2017/745 (MDR) ?

Le critère déterminant réside dans la finalité médicale revendiquée. Un logiciel qui se limite à archiver ou transmettre des dossiers patients relève du simple outil informatique. En revanche, dès lors qu’il analyse des données de santé pour guider un diagnostic, un choix thérapeutique ou un pronostic, et même sous l’appellation d' »aide à la décision », il est qualifié de Software as a Medical Device (SaMD).

En vertu du MDR, un tel logiciel ne peut être mis sur le marché sans un marquage CE valide. Déployer un outil d’aide au diagnostic sans cette certification constitue une infraction lourde, applicable indépendamment de toute considération liée à l’AI Act.

C’est ici qu’intervient une connexion technique majeure de l’AI Act : son Annexe I. L’article 6 de l’AI Act dispose en effet qu’un système d’IA est classé comme étant à haut risque dès lors qu’il constitue un produit (ou un composant de sécurité d’un produit) soumis à une législation d’harmonisation de l’Union européenne listée à l’Annexe I, une catégorie qui inclut précisément le règlement MDR. Autrement dit, pour un SaMD, la qualification de haut risque sous l’AI Act découle directement de son statut de dispositif médical.

Le double verrou des données : interdiction de l’article 9 du RGPD et contraintes de l’HDS

Traiter la santé d’un individu par le biais d’un algorithme expose immédiatement l’entreprise aux exigences les plus strictes du droit européen de la protection des données.

Le verrou de l’article 9 du RGPD : L’article 9 pose une interdiction de principe du traitement portant sur les « catégories particulières de données » (ce que le langage courant qualifie de données sensibles, incluant les données concernant la santé). Y déroger exige de fonder l’opération sur l’une des exceptions strictes du paragraphe 2 (par exemple : consentement explicite et univoque, ou nécessité pour des motifs d’intérêt public dans le domaine de la santé publique sur la base du droit de l’Union ou d’un État membre), adossée à une documentation rigoureuse et au respect des référentiels de la CNIL.

L’impératif de l’hébergement de santé (HDS) et le piège du Cloud Act : En France, l’article L. 1111-8 du Code de la santé publique impose que toute donnée de santé à caractère personnel soit hébergée par un prestataire agréé. Si l’éditeur recourt à des fournisseurs d’infrastructure majeurs (tels qu’AWS ou Microsoft Azure), ces derniers obtiennent bien la certification HDS via l’audit de leurs centres de données. Cependant, en tant qu’entités de droit américain, ils restent soumis au Clarifying Lawful Overseas Use of Data (CLOUD) Act, qui permet à une juridiction fédérale des États-Unis d’émettre des injonctions de communication de données, y compris stockées en Europe. Pour contourner cette exposition, les éditeurs de santé les plus exigeants s’orientent vers des infrastructures souveraines européennes ou imposent un chiffrement de bout en bout dont les clés de déchiffrement demeurent exclusivement sous contrôle de l’UE.

L’AI Act et le mur du haut risque : traçabilité et supervision humaine

Lorsque l’outil HealthTech intègre des briques d’intelligence artificielle, l’AI Act (Règlement UE 2024/1689) vient structurer la conformité opérationnelle.

La qualification de haut risque (via l’Annexe III ou l’Annexe I liée au MDR) emporte des obligations techniques et organisationnelles contraignantes :

• La traçabilité des données (Articles 10 et 11) : Exigence d’une gouvernance irréprochable des jeux de données d’entraînement pour prévenir les biais algorithmiques et garantir la robustesse clinique du modèle.
• La journalisation automatique (Article 12) : Obligation de consigner par des logsinaltérables le parcours décisionnel de l’algorithme, permettant d’auditer les raisons d’une recommandation.
• La supervision humaine effective (Article 14) : C’est le nœud gordien en milieu clinique. Dans un contexte de soins ou d’exercice de la médecine, la validation par un professionnel de santé ne peut se résumer à un clic machinal (rubber-stamping). Le praticien doit disposer de l’autorité, des informations et de la capacité technique pour infirmer, modifier ou écarter la recommandation de la machine.

À noter : si les obligations de fond pour les systèmes à haut risque s’appliqueront pleinement en décembre 2027, les règles de transparence de l’article 50 (informer explicitement le patient ou le professionnel lorsqu’il interagit avec une IA) sont d’ores et déjà en vigueur depuis août 2026.

À cela s’ajoute désormais la nécessité d’anticiper le référentiel d’évaluation des logiciels d’IA de la Haute Autorité de Santé (HAS), passage obligé pour tout outil visant l’intégration dans les parcours de soins publics ou le remboursement.

Trajectoire d’alignement : comment structurer sa conformité HealthTech ?

Face à ce mille-feuille réglementaire (MDR, RGPD, HDS, AI Act), la pire des stratégies consiste à cloisonner les sujets entre équipes techniques, qualité et affaires réglementaires. La maîtrise de ces risques passe par une méthode intégrée :

1. Auditer la qualification du produit (MDR et Annexe I de l’AI Act) : S’assurer que le statut de dispositif médical (SaMD) est purgé, que le dossier technique du marquage CE est en ordre, et cartographier les briques d’IA selon leur exposition au haut risque.
2. Sécuriser l’architecture des données (RGPD et HDS) : Valider l’adéquation de la base légale de traitement des catégories particulières de données (Article 9 du RGPD), auditer les contrats d’hébergement au regard des risques liés au Cloud Act et formaliser les accords de sous-traitance en aval.
3. Bâtir la gouvernance de la décision clinique : Documenter les procédures de supervision humaine, paramétrer la journalisation technique des modèles et structurer la traçabilité des décisions pour répondre aux exigences des autorités de contrôle et des partenaires de santé.

Enfin, pour les éditeurs envisageant un développement transfrontalier, l’articulation future avec l’Espace Européen des Données de Santé (EHDS), qui encadre le partage secondaire des données, viendra compléter cette matrice aux côtés du RGPD et du Data Act.

Qualifier la nature réglementaire de votre logiciel, sécuriser l’architecture de vos contrats d’hébergement HDS face aux lois extra-territoriales, et concevoir un dossier de conformité inattaquable : c’est là qu’intervient l’accompagnement juridique spécialisé pour sécuriser le développement de votre HealthTech et accélérer sa mise sur le marché.

Vous souhaitez cartographier vos obligations au regard du RGPD, de la certification HDS, du MDR et de l’AI Act ?

Celestial Guardian propose des formations et un accompagnement sur mesure pour les éditeurs HealthTech.

Voir les Formations → | Prendre contact →

Questions fréquentes : HealthTech, IA et Données de Santé

Cadrer votre besoin avant de décider