Logiciel dispositif médical : la règle 11 du MDR expliquée

La règle 11 de l'annexe VIII du règlement (UE) 2017/745 (MDR) est l'une des dispositions les plus impactantes du nouveau cadre européen. Elle a fait basculer en classe supérieure la quasi-totalité des logiciels en tant que dispositif médical (SaMD — Software as a Medical Device), avec des conséquences majeures sur les coûts, les délais de mise sur le marché et les obligations cliniques.

Pour les éditeurs de logiciels médicaux, comprendre la règle 11 dans son détail n'est pas optionnel — c'est ce qui détermine la viabilité économique d'un projet.

Qu'est-ce qu'un logiciel dispositif médical ?

Avant de parler classification, il faut savoir si un logiciel est un dispositif médical au sens du MDR. La définition de l'article 2.1 s'applique : un logiciel est un DM s'il est destiné par son fabricant à une finalité médicale spécifique pour l'humain — diagnostic, prévention, surveillance, prédiction, pronostic, traitement, atténuation d'une maladie, d'une blessure, d'un handicap.

Le MDCG 2019-11, dont la révision 1 a été publiée en juin 2025, est le guide de référence qui aide à distinguer :

• SaMD — logiciel autonome qui répond à la définition de DM
• SiMD — Software in a Medical Device, logiciel intégré qui pilote un DM mais ne fonctionne pas seul (exemple : firmware d'une pompe à perfusion)
• MDSW non concerné — logiciels purement administratifs, de gestion (ERP hospitalier, planification de rendez-vous), de bien-être (compteur de pas) sans finalité médicale

Une application qui calcule un IMC ou rappelle de boire de l'eau n'est pas un DM. Une application qui propose une dose d'insuline ajustée à un profil patient est un DM.

Le texte de la règle 11

« 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, sauf si ces décisions ont une incidence susceptible :

— de causer la mort ou une détérioration irréversible de l'état de santé d'une personne, auquel cas ils relèvent de la classe III, ou

— de causer une détérioration grave de l'état de santé d'une personne ou une intervention chirurgicale, auquel cas ils relèvent de la classe IIb.

Les logiciels destinés à contrôler des processus physiologiques relèvent de la classe IIa, sauf s'ils sont destinés à contrôler des paramètres physiologiques vitaux, lorsque des variations de certains de ces paramètres peuvent présenter un danger immédiat pour le patient, auquel cas ils relèvent de la classe IIb.

Tous les autres logiciels relèvent de la classe I. »

Décrypté, cela donne trois sous-règles :

1. Logiciels d'aide à la décision diagnostique ou thérapeutique → IIa par défaut, IIb ou III selon la gravité
2. Logiciels de contrôle de processus physiologiques → IIa par défaut, IIb si processus vitaux dangereux
3. Tous les autres logiciels → classe I

Les changements par rapport à l'ancienne directive 93/42/CEE

Sous la directive, beaucoup de logiciels étaient en classe I par application des règles classiques (instrument actif, durée d'usage limitée). Sous le MDR, la majorité bascule en classe IIa minimum.

Conséquences immédiates :

• Intervention obligatoire d'un organisme notifié (alors qu'en classe I, l'auto-déclaration suffisait)
• Documentation technique étoffée (annexe II)
• Évaluation clinique formalisée avec PMCF par défaut
• PSUR à produire périodiquement
• SSCP (résumé des caractéristiques de sécurité et des performances cliniques, article 32) pour les dispositifs de classe III et les implantables : un logiciel de classe III y est soumis
• Coût et délai de mise sur le marché nettement plus lourds, du fait de l'évaluation par l'organisme notifié

Comment classer concrètement ?

Le MDCG 2019-11 propose un arbre de décision structuré. Voici les principales étapes :

Étape 1 — Le logiciel est-il un DM ?

Si non, hors champ MDR.

Étape 2 — Le logiciel fournit-il une information utilisée pour une décision thérapeutique ou diagnostique ?

Si oui, on entre dans la première branche de la règle 11.

Si non, on regarde s'il contrôle des processus physiologiques. Si encore non, c'est classe I.

Étape 3 — Évaluer la gravité de l'impact

Pour les logiciels d'aide à la décision, deux critères croisés :

Critère A — Situation clinique : sévérité de la condition de santé.

Critère B — Impact de l'information fournie : décision majeure (chirurgie, traitement à risque) ou décision avec marge de correction ?

Sévérité de la situation \ Impact de l'info	Information moteur de décision majeure (cause directe)	Information contributive
Critique (risque de mort / détérioration irréversible)	III	IIb
Sérieuse (intervention chirurgicale, dégradation grave)	IIb	IIa
Non sérieuse	IIa	IIa

Étape 4 — Logiciels de contrôle de processus physiologiques

• Contrôle de processus physiologiques : IIa
• Contrôle de paramètres physiologiques vitaux dont les variations peuvent présenter un danger immédiat pour le patient : IIb

Un logiciel qui pilote un autre dispositif, ou en influence l'utilisation, relève de la même classe que ce dispositif (annexe VIII, règle d'application 3.3).

Exemples concrets de classification

Ces exemples illustrent le raisonnement ; la classe réelle dépend toujours de la destination déclarée par le fabricant.

Classe IIa — exemples

• Application qui analyse le rythme cardiaque d'un utilisateur, détecte des anomalies et en informe le médecin
• Logiciel de tri de lésions cutanées dont chaque résultat est revu par un dermatologue, dans une situation non critique
• Logiciel qui contrôle des paramètres physiologiques hors soins critiques

Classe IIb — exemples

• Logiciel de surveillance de paramètres vitaux en soins critiques, lorsque leurs variations peuvent présenter un danger immédiat
• Logiciel dont le résultat fonde le choix, par le spécialiste, d'une thérapie cognitive
• Logiciel d'aide au diagnostic dont une erreur pourrait conduire à une intervention chirurgicale ou à une détérioration grave

Classe III — exemples

• Logiciel d'analyse d'images qui fonde la décision de traitement d'un AVC aigu
• Logiciel qui classe les chimiothérapies disponibles pour une patiente porteuse d'une mutation BRCA
• Plus généralement, tout logiciel dont une décision erronée peut entraîner la mort ou une détérioration irréversible

Cas spéciaux

Modules d'un même logiciel

Si un logiciel comporte des modules indépendants avec des finalités différentes, chaque module est classé séparément. La classe globale est celle du module le plus élevé. Mais un module non DM peut être hors champ.

Mise à jour vs nouvelle version

Une mise à jour qui modifie la finalité ou les performances cliniques peut être une modification substantielle nécessitant une nouvelle évaluation par l'organisme notifié. Une telle modification se signale à l'organisme notifié, qui décide si une nouvelle évaluation est nécessaire. Pour un logiciel encore couvert par un certificat délivré sous la directive, le MDCG 2020-3 précise quels changements sont « significatifs » et font perdre le bénéfice de la période de transition.

Algorithmes d'apprentissage automatique

Les logiciels intégrant de l'apprentissage automatique (machine learning) doivent être traités selon le MDCG 2019-11 mais aussi selon les principes émergents de l'AI Act (règlement (UE) 2024/1689). Un logiciel qui se met à jour automatiquement après mise sur le marché soulève des questions spécifiques (lock vs continuous learning) — le MDCG 2025-6, publié en juin 2025, traite de l'articulation entre MDR, IVDR et AI Act.

Implications pour les développeurs

Standards à connaître

• IEC 62304 — cycle de vie du logiciel embarqué dans les DM (classes A/B/C selon le risque)
• IEC 82304-1 — logiciels en tant que DM (SaMD), exigences générales pour la sécurité
• IEC 62366-1 — aptitude à l'utilisation et facteurs humains
• EN ISO 14971 — gestion des risques
• EN ISO 13485 — système qualité
• AAMI TIR45 / TIR57 — guidance sur les méthodes agiles et la cybersécurité

Cybersécurité

Le MDR (annexe I 17.2) et la guidance MDCG 2019-16 imposent une démarche structurée de cybersécurité : analyse de menaces, gestion des vulnérabilités, mise à jour de sécurité, communication avec les utilisateurs. Le Cyber Resilience Act (règlement (UE) 2024/2847), lui, exclut de son champ les dispositifs relevant du MDR et de l'IVDR : la cybersécurité d'un logiciel dispositif médical reste régie par l'annexe I du MDR et le MDCG 2019-16.

Évaluation clinique d'un SaMD

Les principes du MDCG 2020-1 s'appliquent : on démontre la validité scientifique (l'algorithme mesure ce qu'il prétend mesurer), la performance analytique (précision, rappel, spécificité), et la performance clinique (impact sur la décision médicale et le résultat clinique).

Conseils pratiques pour les éditeurs

1. Classer le plus tôt possible — la classification détermine l'architecture du projet, le budget et les délais
2. Documenter les hypothèses de classification — un dossier qui explique pourquoi le logiciel est IIa et pas IIb sera attaqué en audit
3. Anticiper le PMCF — prévoir dès le développement la collecte de données post-marché (logs, indicateurs de performance, retours utilisateurs)
4. Construire un cycle de vie qualité robuste dès le départ — corriger une architecture non conforme à IEC 62304 en cours de route est très coûteux
5. Veiller à la cohérence avec l'AI Act si le logiciel utilise de l'IA — la classification AI Act se cumule à la classification MDR

Conclusion

La règle 11 du MDR a recadré le marché du logiciel médical en Europe. Pour les petits éditeurs, le passage obligatoire par un organisme notifié a profondément changé l'équation économique. Pour ceux qui restent, la maîtrise de la règle 11 — et plus largement de la chaîne IEC 62304, ISO 14971, MDCG 2019-11 — est un avantage compétitif clair.

MedQara suit les évolutions des Common Specifications, des notes MDCG et des décisions d'organismes notifiés relatives aux logiciels médicaux. C'est un domaine où la réglementation évolue trimestre par trimestre.

À lire également : Tout comprendre au MDR 2017/745 · Comment se préparer à un audit ISO 13485 · Glossaire QARA