MDR ou AI Act : comment gérer la double conformité d’un logiciel dispositif médical intégrant de l’IA ?

La question « MDR ou AI Act ? » repose sur un faux dilemme. Pour un logiciel dispositif médical (SaMD) qui embarque de l’intelligence artificielle, il ne s’agit pas de choisir un régime, mais d’articuler deux textes qui s’empilent. La guidance conjointe MDCG 2025-6 / AIB 2025-1, publiée le 19 juin 2025 par le Medical Device Coordination Group et l’AI Board (portail de la Commission européenne), clarifie comment ces exigences convergent. Décryptage comparatif à destination des fabricants, éditeurs de dispositifs médicaux logiciels et directions réglementaires.

Un logiciel à finalité médicale : d’abord un dispositif médical au sens du MDR

Avant même de parler d’IA, la première qualification à poser est celle du dispositif médical. Un logiciel autonome doté d’une finalité médicale — diagnostiquer, prévenir, prédire, traiter ou surveiller une pathologie — est un dispositif médical au titre du Règlement (UE) 2017/745 (MDR).

Sa classe de risque est déterminée par la règle 11 de l’Annexe VIII du MDR, qui place la grande majorité des logiciels destinés à fournir des informations utilisées à des fins de décision médicale en classe IIa, voire supérieure. Concrètement, cela signifie l’intervention d’un organisme notifié pour l’évaluation de conformité et l’apposition du marquage CE.

Cette qualification MDR n’est pas un détail administratif : c’est elle qui va conditionner l’analyse au titre de l’AI Act. Tant qu’on ne sait pas si le logiciel est un dispositif médical et de quelle classe, on ne peut pas déterminer son statut au regard du règlement sur l’intelligence artificielle.

Pourquoi l’IA fait basculer le logiciel en « haut risque » au sens de l’AI Act

L’article 6(1) de l’AI Act qualifie de système d’IA à haut risque tout système qui remplit deux conditions cumulatives :

1. il est un composant de sécurité d’un produit, ou est lui-même un produit, couvert par une législation d’harmonisation listée à l’Annexe I du règlement ;
2. ce produit est soumis à une évaluation de conformité par un organisme tiers (organisme notifié).

Or l’Annexe I, section A de l’AI Act cite explicitement le MDR (point 11) et l’IVDR (point 12) parmi les législations d’harmonisation concernées. Le raisonnement se boucle donc de lui-même :

• La règle 11 du MDR classe la plupart des SaMD en IIa ou plus.
• Ces classes exigent un organisme notifié.
• Cette intervention d’un tiers déclenche l’article 6(1).
• Le logiciel devient un système d’IA à haut risque.

Attention toutefois : ce basculement n’est pas automatique pour tous les logiciels. Un dispositif de classe I autocertifié, qui ne requiert pas d’organisme notifié, ne remplit pas la seconde condition de l’article 6(1). La qualification « haut risque » se joue donc au cas par cas, en fonction de la classe et du parcours de conformité.

MDR et AI Act : deux régimes qui s’additionnent

Le message central de la guidance MDCG 2025-6 est sans ambiguïté : l’AI Act complète le MDR/IVDR, il ne le remplace pas. Le règlement IA ne redéfinit pas les obligations existantes de sécurité et de performance clinique ; il ajoute une couche d’exigences propres aux risques de l’IA (biais, robustesse, supervision humaine, transparence). Le tableau ci-dessous synthétise l’articulation des deux textes.

La lecture est donc cumulative : un SaMD à IA doit satisfaire simultanément aux exigences du MDR/IVDR et à celles de l’AI Act.

Une documentation technique unique plutôt que deux dossiers

C’est probablement l’apport le plus opérationnel de la guidance : il ne faut pas constituer deux dossiers séparés ni subir deux audits parallèles.

MDCG 2025-6 recommande d’incorporer les éléments propres à l’AI Act — gouvernance des données, transparence, supervision humaine — directement dans la documentation technique MDR/IVDR existante. Cette intégration s’appuie sur la flexibilité prévue à l’article 8 de l’AI Act, qui permet de mutualiser les exigences lorsqu’un produit relève déjà d’une législation d’harmonisation sectorielle.

Sur le plan de l’évaluation de conformité, la logique est la même : l’appréciation se fait via la route MDR/IVDR, par un seul organisme notifié, à condition que celui-ci soit également désigné au titre de l’AI Act (article 43). L’objectif affiché est d’éviter la duplication : un dossier unique, un interlocuteur unique, une procédure intégrée.

En pratique, cela suppose d’anticiper dès la conception la cartographie entre les exigences des deux règlements, pour identifier là où les preuves MDR (évaluation clinique, gestion des risques) peuvent être réutilisées et là où des éléments strictement IA doivent être ajoutés.

Ce que l’AI Act ajoute concrètement au système qualité MDR

Pour un logiciel déjà marqué CE, l’AI Act n’invalide rien de l’existant : il greffe des exigences supplémentaires sur le système de management de la qualité et le processus de gestion des risques déjà en place. Parmi les principales :

• Gouvernance des jeux de données d’entraînement, de validation et de test : ils doivent être pertinents, suffisamment représentatifs et aussi exempts d’erreurs que possible.
• Détection et atténuation des biais, notamment ceux susceptibles d’affecter la sécurité ou l’équité de traitement des patients.
• Supervision humaine effective : le système doit être conçu pour rester sous contrôle humain réel, pas seulement théorique.
• Transparence vis-à-vis des utilisateurs sur les capacités, les limites et le fonctionnement du système.
• Journalisation automatique (logs) permettant la traçabilité du fonctionnement.
• Surveillance après commercialisation renforcée, articulée avec le suivi post-marché déjà exigé par le MDR.

Ces exigences ne remplacent pas la robustesse ni la cybersécurité attendues côté MDR : elles s’y ajoutent et doivent être documentées dans le même cadre qualité.

Quel calendrier d’application ? 2027, avec un report proposé au 2028

Le calendrier est un point de vigilance majeur, car il évolue encore.

• L’article 113 de l’AI Act reporte l’application de l’article 6(1) — donc des dispositifs médicaux à IA relevant de l’Annexe I — au 2 août 2027, soit 36 mois après l’entrée en vigueur du règlement (1er août 2024). Ce délai vise à laisser le temps aux normes harmonisées de mûrir.
• Un report supplémentaire au 2 août 2028 est envisagé via le paquet « Digital Omnibus », présenté par la Commission le 19 novembre 2025. Un accord politique provisoire de mai 2026 prévoit de décaler les obligations « haut risque » des produits de l’Annexe I (dont les DM). Ce report reste à confirmer : la procédure législative n’était pas finalisée à mi-2026.

Autrement dit, la date cible de référence demeure le 2 août 2027, avec une possibilité sérieuse de glissement au 2 août 2028. Il est prudent de piloter le projet de conformité sur l’échéance la plus rapprochée tout en surveillant l’avancement du Digital Omnibus.

Réentraînement et mises à jour : anticiper la gestion des changements

Un système d’IA n’est pas figé : réentraînements, mises à jour de modèle, évolutions de performance rythment son cycle de vie. Or une modification significative de la conception ou de la performance peut déclencher de nouvelles obligations de conformité, au titre du MDR comme de l’AI Act.

D’où l’intérêt d’intégrer dès la conception un cadre de gestion des changements :

• Change control documenté et tracé ;
• versioning rigoureux des modèles et des jeux de données ;
• plan de modification prédéterminé permettant de distinguer les évolutions déjà couvertes par le dossier de conformité des changements nécessitant une réévaluation.

Cette anticipation évite de repartir de zéro à chaque itération et sécurise la trajectoire réglementaire du produit dans la durée.