Règle 11 du MDR : pourquoi votre app est probablement Classe IIa

Sous les directives pré-MDR, la majorité des logiciels médicaux étaient en Classe I : auto-certification, pas d’organisme notifié, mise sur le marché rapide. La règle 11 du MDR a fermé cette porte. Si vous développez un SaMD (Software as a Medical Device) destiné au marché européen, partez du principe que vous êtes en Classe IIa — et vérifiez ensuite si vous êtes l’exception. Voici pourquoi.

Que dit exactement la règle 11 ?

Définition : la règle 11 (annexe VIII, MDR 2017/745) classe tout logiciel destiné à fournir des informations utilisées pour prendre des décisions à des fins diagnostiques ou thérapeutiques au minimum en Classe IIa. Le texte prévoit ensuite deux aggravations :

• Classe III si ces décisions peuvent causer la mort ou une détérioration irréversible de l’état de santé ;
• Classe IIb si elles peuvent causer une détérioration grave de l’état de santé ou une intervention chirurgicale.

Second volet, souvent oublié : un logiciel destiné à surveiller des processus physiologiques est en Classe IIa, et passe en IIb si les paramètres surveillés sont vitaux et que leurs variations peuvent entraîner un danger immédiat pour le patient. Tout autre logiciel dispositif médical est en Classe I.

Comment dérouler l’arbre de décision ?

Trois questions, dans l’ordre :

1. Mon logiciel fournit-il des informations utilisées pour une décision diagnostique ou thérapeutique ? Score de risque, aide au diagnostic, recommandation de dosage, priorisation de patients, seuil d’alerte clinique : oui. Si oui → au moins Classe IIa.
2. Quelle est la gravité potentielle d’une décision erronée fondée sur cette information ? Mort ou détérioration irréversible → Classe III. Détérioration grave ou chirurgie → Classe IIb. Sinon → Classe IIa.
3. À défaut, mon logiciel surveille-t-il des processus physiologiques ? Oui → Classe IIa ; paramètres vitaux avec danger immédiat → IIb.

Pourquoi presque tout SaMD tombe-t-il en IIa minimum ?

Parce que la notion d’« information utilisée pour prendre des décisions » est interprétée largement. La guidance MDCG 2019-11 est explicite : dès que le logiciel a une finalité médicale propre — qu’il calcule, filtre, interprète ou hiérarchise des données pour un usage clinique — il fournit ce type d’information. Le clinicien reste dans la boucle ? Peu importe : le texte ne parle pas de décision automatique, mais d’information utilisée pour décider.

Si votre logiciel n’influençait aucune décision clinique, personne ne le paierait. C’est précisément cette valeur qui le classe.

Un simple raisonnement commercial suffit souvent : votre pitch deck affirme que le produit « améliore la prise en charge » ou « aide au diagnostic ». Difficile ensuite de soutenir devant un organisme notifié que l’information fournie n’est pas utilisée à des fins diagnostiques ou thérapeutiques.

La MDCG 2019-11 précise aussi la frontière de la qualification : un logiciel qui se contente de stocker, archiver, communiquer ou effectuer une recherche simple sans interprétation n’est pas un dispositif médical du tout. Mais entre « pas un DM » et « DM Classe IIa », la zone Classe I est devenue étroite.

La Classe I est-elle encore possible ?

Rarement, mais oui. Exemples plausibles : un logiciel avec finalité médicale qui ne fournit pas d’information pour des décisions diagnostiques ou thérapeutiques et ne surveille pas de processus physiologique — par exemple certaines applications de suivi de rééducation sans interprétation clinique, ou des outils de planification sans impact diagnostique. En pratique, chaque cas Classe I doit être solidement argumenté par rapport à la règle 11 et à la MDCG 2019-11, car c’est le premier point que l’autorité compétente contestera. Mon retour d’expérience : la plupart des dossiers qui arrivent chez moi en « Classe I autodéclarée » repartent en IIa après analyse.

Quelles conséquences pratiques une fois en IIa ?

Le passage de I à IIa change la nature du projet :

• Organisme notifié obligatoire : audit de votre SMQ et revue du dossier technique. Comptez des délais d’engagement souvent longs — contactez-en un tôt.
• SMQ ISO 13485 complet : pas une option, un prérequis à l’audit.
• Dossier technique conforme aux annexes II et III du MDR : évaluation clinique, gestion des risques ISO 14971, surveillance après commercialisation.
• IEC 62304 avec classe de sécurité justifiée : pour un logiciel dont les défaillances peuvent conduire à une décision clinique erronée, la classe B est un plancher réaliste ; la classe C se discute selon la gravité. La classe A devient difficile à défendre pour un SaMD IIa.
• Cybersécurité : exigences 17.2/17.4 de l’annexe I, en pratique IEC 81001-5-1.

Budget et calendrier : pour une première certification IIa, prévoyez un horizon en trimestres, pas en semaines, entre la mise à niveau du SMQ, la constitution du dossier et les délais de l’organisme notifié.

Sur la constitution de ce dossier — sa structure et les pièges qui font caler un audit — voir : le dossier technique MDR d’un logiciel.

Et les cas IIb / III ?

Montez d’un cran dès que la décision alimentée par votre logiciel peut entraîner une détérioration grave (IIb) : par exemple un algorithme qui propose des doses de médicaments à marge thérapeutique étroite, ou un tri de patients où un faux négatif retarde une prise en charge urgente. La Classe III vise les décisions à conséquence potentiellement fatale ou irréversible — typiquement certains logiciels d’aide à la décision en oncologie ou en cardiologie interventionnelle. La classification se justifie toujours par le pire scénario raisonnablement prévisible lié à l’usage revendiqué, pas par le cas nominal.

FAQ

Mon logiciel a un professionnel de santé dans la boucle : est-ce que ça le déclasse ?

Non. La règle 11 vise l’information utilisée pour décider, pas l’automatisation de la décision. La présence d’un clinicien peut réduire le risque au sens ISO 14971, mais ne change pas la classe.

Puis-je restreindre mon intended use pour rester en Classe I ?

C’est possible en théorie, mais l’intended use doit refléter l’usage réel et votre communication commerciale. Restreindre l’étiquette tout en vendant une aide à la décision est le plus court chemin vers une non-conformité — et vers une requalification par l’autorité compétente.

Une app de bien-être échappe-t-elle au MDR ?

Si elle n’a aucune finalité médicale au sens de l’article 2 du MDR, elle n’est pas un dispositif médical et la règle 11 ne s’applique pas. Mais dès que vous revendiquez un bénéfice sur une pathologie, un diagnostic ou un traitement, vous basculez dans la qualification — et la règle 11 vous attend.