La règle 11 de l’Annexe VIII du MDR est la règle de classification qui a le plus secoué le numérique en santé. Sous la directive 93/42/CEE, la majorité des logiciels médicaux relevait de la classe I, en auto-certification, sans organisme notifié. Sous MDR, la plupart des logiciels d’aide à la décision relèvent au minimum de la classe IIa. Le changement de classe n’est pas un ajustement documentaire : il fait entrer un organisme notifié dans la vie de l’éditeur.
Ce que dit exactement la règle 11
Le texte pose une logique en trois temps, qu’il faut lire dans l’ordre.
Premier temps : la classe IIa par défaut. Les logiciels destinés à fournir des informations utilisées pour prendre des décisions à des fins thérapeutiques ou diagnostiques relèvent de la classe IIa. C’est le point de départ, pas l’exception. Tout logiciel d’aide à la décision clinique entre dans le périmètre par cette porte.
Deuxième temps : deux exceptions vers le haut. Si les décisions que le logiciel éclaire ont une incidence susceptible de causer la mort ou une détérioration irréversible de l’état de santé, le logiciel relève de la classe III. Si elles peuvent causer une grave détérioration de l’état de santé ou une intervention chirurgicale, il relève de la classe IIb. L’intervention chirurgicale est un critère à part entière : un logiciel dont une erreur peut conduire à opérer, ou à mal opérer, est IIb même sans menace vitale directe. Ces mêmes conséquences graves qui font monter la classe sont aussi celles qui, une fois le logiciel sur le marché, déclenchent les obligations de vigilance et délais de signalement.
Troisième temps : la surveillance. Les logiciels destinés à surveiller des processus physiologiques relèvent de la classe IIa. Ils passent en classe IIb uniquement s’ils surveillent des paramètres physiologiques vitaux dont les variations peuvent présenter un danger immédiat pour la vie du patient. Les deux conditions sont cumulatives : paramètre vital, et danger immédiat en cas de variation. Un logiciel qui suit la fréquence cardiaque en réanimation coche les deux cases. Une application qui trace la même fréquence cardiaque en suivi de bien-être n’en coche aucune, et n’est probablement même pas un dispositif médical.
Tous les autres logiciels relèvent de la classe I. Dans les faits, cette catégorie est devenue étroite : la révision 2025 de la guidance en donne un exemple, sous conditions strictes.
Une règle d’application complète le dispositif : le logiciel qui commande un dispositif ou agit sur son utilisation relève de la même classe que ce dispositif (Annexe VIII, règle 3.3). La règle 11 s’applique au logiciel classé en tant que tel.
Pourquoi la reclassification a été si large
Sous la directive, le critère central était la place du logiciel dans un dispositif physique. Le MDR déplace le critère vers l’impact clinique d’une erreur du logiciel lui-même. Un logiciel qui suggère un diagnostic différentiel part en IIa, monte en IIb ou III selon les conséquences d’une suggestion erronée. Un logiciel de planification de radiothérapie se retrouve en IIb ou III : une erreur de dosimétrie peut causer une détérioration irréversible. Un logiciel d’interprétation automatique d’ECG monte en IIb dès que ses sorties orientent une décision aux conséquences graves.
Le passage de classe I à IIa ou IIb change la nature de la démarche : dossier technique complet, évaluation clinique substantielle, cycle de vie logiciel selon IEC 62304, plan PMS et PMCF, et évaluation par un organisme notifié. L’éditeur qui monte en classe découvre en même temps l’ISO 13485 et doit auditer son SMQ ISO 13485. Ses logiciels, désormais classés dispositifs médicaux, sont par ailleurs soumis à l’identifiant unique et à l’enregistrement EUDAMED, y compris en distribution dématérialisée. L’éditeur ne remplit pas plus de formulaires. Il change de métier réglementaire.
MDCG 2019-11 Rev.1 : la révision de juin 2025 rebat les cartes
La guidance de référence sur la qualification et la classification des logiciels, MDCG 2019-11, a été révisée le 17 juin 2025. Ce n’est pas un toilettage. Quatre apports concernent directement les éditeurs.
La fin du « standalone software ». La révision abandonne la notion de logiciel autonome au profit d’une approche par fonction : ce qui compte est la destination de chaque fonctionnalité, pas le support qui l’héberge. Le terme européen est MDSW (Medical Device Software). SaMD reste le vocabulaire IMDRF utilisé outre-Atlantique, mais un dossier européen qui raisonne en MDSW parle la langue de son évaluateur.
L’approche modulaire. Un logiciel peut être découpé en modules, certains à destination médicale, d’autres non. Chaque module médical doit avoir une destination définie et documentée, et l’éditeur doit démontrer que les modules non médicaux ne compromettent ni la sécurité ni les performances des modules médicaux. La frontière se trace par écrit, dans la documentation technique.
L’apparition du terme MDAI. La révision nomme pour la première fois les logiciels médicaux à intelligence artificielle (Medical Device AI), sous-ensemble des MDSW soumis en parallèle au règlement IA. Les éditeurs d’algorithmes apprenants ont désormais deux textes à croiser, pas un.
La destination comme pierre angulaire. La révision martèle l’exigence d’une destination précise, non ambiguë, alignée avec les données de validation et les allégations publiques de l’éditeur, site web et fiches de stores compris. Une classification se construit sur cette destination écrite. Une destination floue produit une classification indéfendable.
La guidance distingue par ailleurs les logiciels qui créent ou modifient des informations médicales de ceux qui se contentent de les afficher ou de les stocker. Un algorithme qui traite des données pour en déduire un résultat clinique est dans la première catégorie. Un portail qui affiche des résultats de laboratoire sans traitement est dans la seconde, et la question à lui poser est d’abord celle de la qualification, avant celle de la classe.
Ce que ça implique pour un éditeur en 2026
Un éditeur qui a classé son logiciel avant juin 2025 a construit son raisonnement sur la version 2019 de la guidance. Cette version est remplacée. Les hypothèses de qualification des modules, les cas limites, les logiciels de prévention : autant de points que la Rev.1 tranche différemment ou plus finement. Une classification en classe I décidée en 2022 mérite une relecture avec le texte de 2025 sur la table, en particulier si le logiciel embarque des fonctions d’aide à la décision ajoutées au fil des versions.
Le scénario qui coûte cher est toujours le même : un logiciel classé I à sa sortie, enrichi fonctionnalité par fonctionnalité, dont la destination réelle a glissé vers l’aide à la décision sans que la classification ne suive. Le jour où un organisme notifié ou une autorité compétente pose la question, la réponse se construit dans l’urgence, avec un historique de versions contre soi.
Relire sa classification avec la Rev.1 coûte une demi-journée structurée. La découvrir obsolète en audit coûte une remise à plat sous contrainte. Le bon moment pour faire revérifier la classification de votre logiciel est celui que vous choisissez, pas celui qu’un auditeur vous impose.
Sources réglementaires :