Logiciel de santé et MDR : qualification, règle 11 et preuves d’ingénierie
Ce que l’équipe de développement doit tracer avant le code : destination médicale, MDCG 2019-11 rev.1, branches de la règle 11, IEC 62304 et inventaire SOUP — distinct du guide MDR anglophone.
Ala Ben Aicha
Réponse directe
Qualifiez le logiciel avant de le classer. MDCG 2019-11 rev.1 (17 juin 2025) opérationnalise l'article 2 et la règle 11. Une user story n'est pas une destination médicale. Ce n'est pas un avis d'organisme notifié.
Le ticket n'est pas le dossier technique
La page anglaise SaMD under EU MDR déroule qualification, règle 11, 62304 et marquage CE. Celle-ci est le contrat d'équipe de dev : quels artefacts d'ingénierie peuvent alimenter un dossier, et lesquels n'en sont pas. Service associé : développement HealthTech, pas un tampon réglementaire.
Texte : règlement (UE) 2017/745. Guide : MDCG 2019-11 rev.1, publié le 17 juin 2025. Si votre copie date d'octobre 2019, arrêtez-vous et rechargez. La rev.1 clarifie la destination, les modules, des exemples de traitement, et ajoute un point d'articulation avec les systèmes DPI de l'EHDS (annexe I.c.1 du guide) : un système DPI n'est pas automatiquement un dispositif ; un module d'interprétation peut l'être.
Qualification avant classification
Quatre tests, dans cet ordre (lecture opérationnelle du guide, pas un substitut) :
- Est-ce du logiciel ?
- Agit-il sur des données au-delà du stockage, de l'archivage, de la communication simple ou de la recherche ?
- L'action est-elle au bénéfice de patients individuels ?
- La destination entre-t-elle dans l'art. 2(1) (diagnostic, prévention, surveillance, prédiction, pronostic, traitement…) ?
Un module de prise de rendez-vous qui n'interprète rien reste généralement hors qualification. Un module qui recommande une conduite thérapeutique doit être évalué séparément, même s'il vit dans la même app. La rev.1 insiste : rédigez une destination claire, par fonction. « Notre plateforme AI-powered » n'est pas une destination.
La classification ne commence que si la qualification est positive. La règle 11 (annexe VIII) n'a rien à dire sur un logiciel non dispositif.
Règle 11 : branches, pas un label de repo
Paraphrase de l'annexe VIII, règle 11 — d'autres règles peuvent s'appliquer ; un nom de produit ne classe pas :
| Branche | Classe | Signal pour l'équipe | Ce que ce n'est pas |
|---|---|---|---|
| Information utilisée pour des décisions de diagnostic ou de thérapeutique, sans les conséquences plus graves ci-dessous | IIa | La majorité des CDS « d'aide » atterrit ici | « On est Classe I parce que c'est du SaaS » |
| Ces décisions peuvent causer une détérioration grave ou une intervention chirurgicale | IIb | La destination et le mal potentiel comptent | Une classe IEC 62304 |
| Décès ou détérioration irréversible | III | Rare ; ne pas l'auto-attribuer pour « avoir l'air sérieux » | Un score de risque GitHub |
| Surveillance de processus physiologiques | IIa | Monitoring ≠ alerte vitale | Un dashboard wellness |
| Paramètres vitaux dont la variation peut créer un danger immédiat | IIb | Définir quel paramètre | Un widget de fréquence cardiaque loisir |
| Autre logiciel dans la règle | I | L'exception, pas le défaut | Un moyen d'éviter l'organisme notifié |
Classe IIa et au-delà : organisme notifié. Je n'en suis pas un. Je n'estime pas vos délais d'évaluation : ce n'est pas un SLA Commission.
IEC 62304 (classes A/B/C de sécurité logicielle) est un processus de cycle de vie, pas un mapping 1:1 vers I / IIa / IIb / III. Vous pouvez avoir un logiciel MDR IIa et 62304 classe B. Deux tableaux, deux propriétaires.
Matrice sprint → preuve (et ce qui ne passe pas)
| Artefact d'ingénierie | Ce qu'il peut alimenter | Ce que ce n'est pas |
|---|---|---|
| Énoncé de destination versionné (intended purpose) | Art. 2(1), MDCG 2019-11 | Une user story « en tant que clinicien, je veux… » |
| Décision de qualification par module | Frontière dispositif / non-dispositif | Un label ai sur le service Node |
| Branche règle 11 argumentée | Annexe VIII | Un vote Slack |
| Inventaire SOUP (npm, images, modèles) | IEC 62304 | npm audit tout seul |
| Exigences ID unique → conception → tests | 62304 + ISO 14971 | Une couverture Jest à 80 % |
| Analyse de risques (sévérité × probabilité) | ISO 14971 | Un CSV d'erreurs 500 |
| Journal des changements de destination | Revue réglementaire | Un changelog marketing |
SOUP : chaque paquet npm de l'arbre est, au sens 62304, du logiciel d'origine inconnue. L'inventaire (nom, version, usage prévu, risque si le paquet ment, maintenance, CVE) est un livrable. Dependabot aide la veille ; il ne rédige pas l'évaluation.
Changer la destination (« on ajoute un score de sepsis ») rouvre qualification et classification, même si le diff Git tient en dix lignes. Le propriétaire réglementaire tranche ; l'équipe de dev ne « reclasse » pas dans un ticket.
EHDS, IA, IVDR : d'autres portes
- Un système DPI sous EHDS chapitre III peut coexister avec un module SaMD. Deux audits, deux dossiers. Voir EHDS fabricants.
- Un modèle d'IA n'assigne pas une classe. L'AI Act est un régime distinct.
- Un logiciel qui agit sur des données de diagnostic in vitro peut relever de l'IVDR (2017/746), pas seulement du MDR.
Ce que cette page n'est pas
Ce n'est pas une qualification, pas une classification, pas un avis d'organisme notifié, pas un SMQ ISO 13485, pas un rapport d'évaluation clinique, pas un conseil juridique ou clinique. Je ne signe pas votre déclaration UE. Implémenter de la traçabilité Git n'est pas un marquage CE.
Si vous construisez le logiciel et devez relier exigences, interfaces et tests sans prétendre au tampon, c'est le développement HealthTech. Pour un spike borné, utilisez le contact avec intention projet.