IA en santé : AI Act, RGPD et dispositif médical, le triple cadre

Aide au diagnostic, priorisation des urgences, analyse d'imagerie, prédiction de décompensation, assistants de prescription : l'IA en santé est passée du laboratoire à la routine clinique. Juridiquement, c'est le cas d'usage le plus dense qui soit : un même logiciel peut relever simultanément du règlement sur les dispositifs médicaux, de l'AI Act, du RGPD et de règles françaises propres au secteur. Voici comment démêler ce triple cadre, que vous soyez fabricant, éditeur ou établissement utilisateur.

Première question : votre logiciel est-il un dispositif médical ?

Tout part de là. Un logiciel est un dispositif médical dès lors que son fabricant lui assigne une destination médicale : diagnostic, prévention, contrôle, prédiction, pronostic, traitement ou atténuation d'une maladie. Peu importe qu'il n'agisse pas physiquement sur le corps : le logiciel autonome (Software as a Medical Device) est pleinement couvert par le règlement européen 2017/745 sur les dispositifs médicaux (MDR).

Les critères de qualification tiennent en trois questions :

• Le logiciel fait-il autre chose que stocker, archiver, communiquer ou rechercher des données ? Un simple DPI qui affiche des résultats n'est pas un dispositif médical ; un module qui les interprète peut l'être.
• Réalise-t-il une action sur les données au bénéfice d'un patient individuel ? Un outil de statistiques de service n'est pas un DM ; un score calculé pour un patient donné, oui.
• Sa finalité revendiquée est-elle médicale ? La documentation commerciale compte autant que la notice : promettre une aide au diagnostic dans une plaquette suffit à revendiquer une destination médicale.

Côté classification, la règle 11 du MDR est sévère pour les logiciels : un logiciel destiné à fournir des informations utilisées pour des décisions à des fins diagnostiques ou thérapeutiques relève au minimum de la classe IIa, et monte en classe IIb ou III si ces décisions peuvent entraîner des conséquences graves ou irréversibles. Concrètement, la quasi-totalité des logiciels d'IA clinique sont au moins en classe IIa, ce qui impose l'intervention d'un organisme notifié pour le marquage CE : évaluation clinique, gestion des risques, surveillance après commercialisation.

Le piège classique des startups : se positionner en "simple outil d'aide" ou en "bien-être" dans la notice tout en promettant une performance diagnostique dans le discours commercial. Les autorités qualifient d'après la destination réelle, et une requalification après mise sur le marché est un scénario noir : retrait, responsabilité, parfois infraction pénale.

Deuxième couche : l'AI Act

Le règlement 2024/1689 sur l'IA ajoute sa propre grille. Pour la santé, le mécanisme central est l'article 6, paragraphe 1 : un système d'IA est classé à haut risque lorsqu'il constitue un dispositif médical (ou un composant de sécurité d'un tel produit) soumis à une évaluation de conformité par un organisme notifié. Autrement dit : IA + dispositif médical de classe IIa ou plus = haut risque au sens de l'AI Act, presque mécaniquement.

Les obligations qui en découlent pour le fabricant s'ajoutent à celles du MDR : système de gestion des risques propre à l'IA, gouvernance des données d'entraînement (représentativité, biais), documentation technique, journalisation, transparence vers l'utilisateur, contrôle humain, robustesse et cybersécurité. La bonne nouvelle : le législateur a prévu l'articulation. L'évaluation de conformité AI Act s'intègre dans celle du MDR, avec un dossier technique unique possible et les organismes notifiés en pivot. L'échéance pour ces produits embarqués est fixée à août 2027, après la vague générale d'août 2026, ce qui donne un peu d'air aux fabricants, pas aux retardataires : un cycle de certification DM se compte en années.

Pour les établissements utilisateurs, l'AI Act crée le rôle de déployeur : utilisation conforme à la notice, surveillance humaine confiée à des professionnels formés, contrôle des données d'entrée, conservation des journaux, information des professionnels concernés. Un hôpital qui déploie une IA de triage ne peut plus se contenter d'acheter : il doit organiser l'usage.

Troisième couche : le RGPD et les données de santé

L'IA en santé se nourrit de données de santé, catégorie particulière de l'article 9 du RGPD dont le traitement est interdit sauf exceptions. Trois moments du cycle de vie concentrent les enjeux :

• L'entraînement : constituer une base de données de santé pour développer un modèle suppose une base juridique solide (recherche scientifique avec garanties, consentement, ou réutilisation encadrée), une information adaptée des personnes, une minimisation réelle et le plus souvent une analyse d'impact. La pseudonymisation est une garantie, pas une échappatoire : les données pseudonymisées restent des données personnelles. L'espace européen des données de santé ouvrira un canal d'accès organisé à ces données pour l'entraînement, dans des environnements sécurisés : c'est une opportunité majeure, à condition d'en maîtriser la procédure.
• L'inférence : en production, le logiciel traite les données du patient pour produire son résultat. Responsabilités entre éditeur et établissement, DPA de l'article 28, hébergement certifié HDS si l'éditeur héberge pour le compte de tiers, sécurité de l'article 32 : le socle classique s'applique intégralement.
• L'amélioration continue : réutiliser les données de production pour réentraîner le modèle est un nouveau traitement, avec sa propre base juridique et son encadrement contractuel. C'est le point le plus souvent oublié dans les contrats, et le plus sensible pour les établissements.

La touche française : information du patient et garantie humaine

Le droit français ajoute une exigence propre. L'article L4001-3 du Code de la santé publique, issu de la loi de bioéthique de 2021, impose au professionnel de santé qui utilise un dispositif médical embarquant un traitement de données algorithmique d'en informer le patient, et prévoit que le professionnel est informé du recours à ce traitement, que les données du patient utilisées sont accessibles et que les résultats qui en sont issus lui sont expliqués. Les concepteurs doivent veiller à l'explicabilité du fonctionnement pour les utilisateurs.

C'est la traduction juridique du principe de garantie humaine : l'algorithme éclaire, le professionnel décide. En pratique, cela impose aux éditeurs de concevoir des interfaces qui rendent le raisonnement du système intelligible (facteurs pris en compte, niveau de confiance, limites), et aux établissements d'intégrer l'information du patient dans les parcours. Un logiciel opaque, même marqué CE, expose son utilisateur français à un manquement.

Responsabilité : qui paie en cas d'erreur de l'IA ?

La question arrive dans toutes les négociations. L'état du droit tient en quelques repères : la décision médicale reste celle du professionnel, qui répond de ses fautes dans les conditions habituelles ; le fabricant répond des défauts de son produit, et le régime européen de responsabilité du fait des produits défectueux a été modernisé pour couvrir explicitement les logiciels et l'IA, avec des règles facilitant la preuve pour les victimes ; entre les acteurs, le contrat répartit la charge finale : garanties de performance, plafonds, assurances. Trois réflexes contractuels : définir précisément la performance promise (sensibilité, spécificité, population de référence), documenter les limites d'utilisation pour cadrer la faute d'usage, et calibrer plafonds et assurances sur le risque corporel, pas sur le prix de la licence.

Checklist fabricant et checklist établissement

Vous développez une IA en santé :

1. Qualifiez la destination médicale et la classe MDR avant d'écrire la première ligne de la plaquette commerciale.
2. Construisez un dossier technique unique MDR + AI Act : gestion des risques, données d'entraînement, évaluation clinique, explicabilité.
3. Sécurisez la chaîne des données : base juridique d'entraînement, HDS si vous hébergez, DPA, clause d'amélioration continue.
4. Intégrez la garantie humaine dans le produit : explicabilité, traçabilité, information du professionnel.
5. Anticipez août 2027 comme une date de mise en production réglementaire, pas comme un horizon lointain.

Vous déployez une IA en santé :

1. Exigez le marquage CE, la classe, la documentation AI Act et la notice complète avant tout pilote.
2. Organisez la surveillance humaine : qui valide, avec quelle formation, quelle procédure d'écart.
3. Contractualisez la performance, les responsabilités et le sort des données de production.
4. Mettez à jour vos analyses d'impact et l'information des patients au titre de l'article L4001-3.
5. Tracez l'usage réel : les journaux du système sont aussi votre preuve en cas de litige.

Trois cas pratiques de qualification

La théorie prend son sens sur des cas réels, anonymisés de notre pratique :

• Le chatbot de pré-tri : un assistant conversationnel qui interroge le patient sur ses symptômes et oriente vers le bon niveau de prise en charge. Il interprète des données individuelles et son résultat influence une décision d'orientation médicale : la qualification de dispositif médical est très difficile à écarter, et le niveau de risque dépend des scénarios d'erreur (rater une urgence vitale pousse vers le haut). Beaucoup d'éditeurs de ce segment se croient encore en "simple information".
• L'IA d'imagerie : détection de lésions sur des radiographies avec score de suspicion à destination du radiologue. Cas d'école du dispositif médical de classe IIa minimum, IIb si les conséquences d'un faux négatif sont graves. IA + organisme notifié = haut risque AI Act par l'article 6, paragraphe 1 : le dossier doit être unique et cohérent.
• L'optimiseur de planning de bloc : un algorithme qui ordonnance les interventions selon les ressources. Pas d'action sur les données au bénéfice d'un patient individuel à des fins médicales : hors MDR en principe. Mais s'il intègre des critères cliniques de priorisation des patients, la frontière se rapproche, et le RGPD s'applique dans tous les cas. La nuance se joue dans le paramétrage réel, pas dans la plaquette.

Moralité : la qualification se fait fonctionnalité par fonctionnalité, sur la base de ce que le produit fait et de ce que vous en dites. Un même logiciel peut contenir un module dispositif médical et des modules qui ne le sont pas, à condition de les délimiter proprement dans l'architecture et la documentation.

L'évaluation clinique : ce que l'organisme notifié attend

Le marquage CE d'une IA clinique passe par la démonstration de la performance et du bénéfice clinique. Concrètement, l'organisme notifié attend : une définition précise de la destination (population, indication, contexte d'utilisation, utilisateur cible), des données de validation distinctes des données d'entraînement, représentatives de la population française ou européenne visée, des métriques justifiées (sensibilité, spécificité, valeurs prédictives) avec leurs intervalles de confiance, une analyse des cas d'échec et des populations où la performance se dégrade, et un plan de suivi clinique après commercialisation. Le point d'achoppement récurrent des dossiers d'IA : des performances démontrées sur des données étrangères ou anciennes, non transposables à la population d'usage. Anticipez la constitution de vos jeux de validation comme un chantier réglementaire à part entière, avec sa propre conformité RGPD.

Les modèles qui apprennent : le problème des mises à jour

Une spécificité de l'IA percute de plein fouet la logique de certification : le modèle évolue. Or une modification substantielle d'un dispositif médical certifié impose en principe de repasser par l'évaluation de conformité, et l'AI Act raisonne de même pour les systèmes à haut risque. Trois conséquences opérationnelles :

• le réentraînement d'un modèle en production n'est pas une simple mise à jour logicielle : il doit être qualifié, documenté et, selon son ampleur, soumis à l'organisme notifié ;
• la solution passe par des protocoles de modifications prédéterminées : décrire à l'avance, dans le dossier de certification, les évolutions prévues du modèle, leurs bornes et les tests de validation associés, pour pouvoir les déployer sans nouvelle procédure complète ;
• côté contrats, l'établissement utilisateur doit être informé des évolutions du modèle et de leur impact sur les performances : une clause de gel de version pour les usages critiques et un journal des versions font désormais partie des standards de négociation.

Les éditeurs qui industrialisent cette gestion des versions transforment une contrainte en argument : la maîtrise documentée du cycle de vie du modèle est exactement ce que les acheteurs hospitaliers ont appris à exiger.

Le budget réglementaire : ce qu'il faut provisionner

Parlons chiffres, car c'est là que les projets déraillent. Le coût réglementaire d'une IA clinique combine plusieurs postes : la constitution et la qualification des jeux de données d'entraînement et de validation (souvent le poste le plus lourd, entre l'accès aux données, l'annotation et la conformité RGPD), le système de management de la qualité et la documentation technique, l'évaluation clinique, les frais d'organisme notifié avec des délais d'instruction qui se comptent en trimestres, puis la surveillance après commercialisation et la gestion des versions. Pour une startup, l'ordre de grandeur global se chiffre en centaines de milliers d'euros et en 18 à 36 mois entre la conception et le marquage CE d'une classe IIa. Deux implications stratégiques : le sujet réglementaire doit figurer dans le plan de financement présenté aux investisseurs, qui le demandent désormais systématiquement en due diligence ; et l'arbitrage entre développer une fonction dispositif médical ou intégrer une brique déjà certifiée d'un tiers est autant une décision juridique et financière que technique.

Ce qu'il faut retenir

Une IA en santé se conforme en trois couches : MDR pour la qualification de dispositif médical et le marquage CE, AI Act pour le régime haut risque avec échéance en août 2027 pour les produits certifiés, RGPD pour chaque étape de la vie des données, le tout complété en France par l'information du patient et la garantie humaine de l'article L4001-3. La conformité se construit produit par produit, en un seul dossier cohérent, et elle commence par une qualification honnête de la destination médicale.

Le cabinet Mirabile Avocat accompagne fabricants, éditeurs et établissements : qualification MDR et AI Act, stratégie de données d'entraînement, contrats de déploiement, dossiers de responsabilité. Testez la qualification de votre logiciel avec le simulateur ci-dessous, puis venez en discuter.