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 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 processus physiologiques vitaux et que les variations de ces processus présentent un caractère potentiellement dangereux 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 :

Logiciels d'aide à la décision diagnostique ou thérapeutique → IIa par défaut, IIb ou III selon la gravité
Logiciels de contrôle de processus physiologiques → IIa par défaut, IIb si processus vitaux dangereux
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 obligatoire pour les classes III implantables — donc rare pour le logiciel pur
Coût et délai de mise sur le marché : 12 à 24 mois supplémentaires, 50 à 200 k€ de frais d'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

Processus non vitaux : IIa
Processus vitaux non dangereux : IIa
Processus vitaux dont les variations sont dangereuses : IIb

Exemples concrets de classification

Classe IIa — exemples

Logiciel de planification radiothérapique pour cancers à pronostic favorable
Logiciel d'aide à la décision pour le suivi de l'observance d'un traitement chronique
Logiciel d'analyse d'image dermatologique pour le tri de cas suspects (suspicion non confirmée)
Logiciel de calcul de dose médicamenteuse non vitale

Classe IIb — exemples

Logiciel d'aide au diagnostic en oncologie sur biopsies (la décision oriente directement le traitement)
Logiciel de monitoring continu de paramètres respiratoires (processus vital, alerte si déviation)
Logiciel de pré-diagnostic d'AVC sur imagerie cérébrale (la décision conditionne une thrombolyse)

Classe III — exemples

Logiciel de planification de chirurgie cardiaque dont l'erreur peut être mortelle
Logiciel d'analyse d'imagerie destiné à la détection de cancers très agressifs où un faux négatif est mortel
Logiciel autonome de pilotage de pompe d'insuline en boucle fermée pour patient diabétique

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é. Le MDCG 2020-3 détaille ce qu'est une modification substantielle.

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) — voir la guidance MDCG 2025-XX en cours d'élaboration.

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 règlement (UE) 2024/2847 (Cyber Resilience Act) renforce ces exigences pour les produits avec composants numériques.

É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

Classer le plus tôt possible — la classification détermine l'architecture du projet, le budget et les délais
Documenter les hypothèses de classification — un dossier qui explique pourquoi le logiciel est IIa et pas IIb sera attaqué en audit
Anticiper le PMCF — prévoir dès le développement la collecte de données post-marché (logs, indicateurs de performance, retours utilisateurs)
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
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. Beaucoup de petits éditeurs ont disparu, faute de pouvoir absorber les coûts d'organisme notifié. 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.

VeilleMed QARA 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.