# 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. Auteur: Ala Ben Aicha Page de référence: https://alabenaicha.me/fr/insights/mdr-logiciel-sante-equipes-dev Mise à jour: 2026-09-17 ## 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](https://alabenaicha.me/fr/insights/eu-mdr-software-medical-device-guide) 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](https://alabenaicha.me/fr/services/healthtech-development), pas un tampon réglementaire. Texte : [règlement (UE) 2017/745](https://eur-lex.europa.eu/eli/reg/2017/745/oj). Guide : [MDCG 2019-11 rev.1](https://health.ec.europa.eu/latest-updates/update-mdcg-2019-11-rev1-qualification-and-classification-software-regulation-eu-2017745-and-2025-06-17_en), 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) : 1. Est-ce du **logiciel** ? 2. Agit-il sur des données **au-delà** du stockage, de l'archivage, de la communication simple ou de la recherche ? 3. L'action est-elle au bénéfice de **patients individuels** ? 4. 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](https://eur-lex.europa.eu/eli/reg/2017/745/oj) — 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](https://alabenaicha.me/fr/insights/ehds-readiness-for-ehr-manufacturers). * Un modèle d'IA n'assigne pas une classe. L'[AI Act](https://alabenaicha.me/fr/insights/eu-ai-act-healthcare-compliance) 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](https://alabenaicha.me/fr/services/healthtech-development). Pour un spike borné, utilisez le [contact avec intention projet](https://alabenaicha.me/fr/contact?intent=project).