Les normes essentielles du logiciel dispositif médical, annotées

Le référentiel applicable à un logiciel dispositif médical tient en une dizaine de textes : un règlement européen, un socle de normes harmonisées ou consensuelles, un guide d’interprétation et, pour le marché américain, une exigence légale de cybersécurité. Cette bibliographie les présente dans l’ordre où ils interviennent dans un projet, avec pour chacun son périmètre, son moment d’application et le piège le plus fréquemment observé.

Règlement (UE) 2017/745 — MDR

Ce qu’il couvre. Le MDR est le texte juridiquement contraignant qui régit la mise sur le marché des dispositifs médicaux dans l’Union européenne. Il définit la qualification et la classification des dispositifs (dont la règle 11 pour les logiciels), les exigences générales de sécurité et de performances, le contenu du dossier technique, les obligations des opérateurs économiques, l’évaluation clinique, la surveillance post-marché et la vigilance. Tout le reste du référentiel — normes et guides — vient outiller la démonstration de conformité à ce règlement.

Quand il s’applique. Dès qu’un logiciel répond à la définition d’un dispositif médical et qu’il est destiné au marché européen, sans exception ni seuil d’entreprise.

Le piège classique. Traiter le MDR comme un sujet de fin de projet : la classification (règle 11) et le niveau d’exigence qui en découle conditionnent l’architecture, la documentation et le budget dès les premiers sprints, et un organisme notifié ne se réserve pas en quelques semaines.

IEC 62304:2006+A1:2015 — Cycle de vie du logiciel

Ce qu’elle couvre. Cette norme définit les processus du cycle de vie du logiciel de dispositif médical : planification du développement, exigences, architecture, conception détaillée, implémentation, vérification, gestion des anomalies, gestion de configuration et maintenance. Elle introduit les classes de sécurité logicielle A, B et C, qui modulent la profondeur des activités et de la documentation exigées. Elle encadre aussi la gestion des composants tiers (SOUP).

Quand elle s’applique. À tout logiciel qui est lui-même un dispositif médical ou qui est intégré dans un dispositif médical, dès le début du développement — et rétroactivement, via un gap assessment, pour du code hérité.

Le piège classique. Sous-classer le logiciel en classe A pour alléger la charge documentaire : la classe doit découler de l’analyse de risque, et un auditeur qui invalide la classification invalide en cascade toute la documentation produite.

ISO 14971:2019 — Gestion des risques

Ce qu’elle couvre. La norme de référence pour la gestion des risques des dispositifs médicaux : identification des dangers, estimation et évaluation des risques, mesures de maîtrise, évaluation du risque résiduel global, et poursuite du processus en production et post-production. Elle fournit le cadre dans lequel s’inscrivent aussi bien les risques fonctionnels que les risques d’utilisabilité et, par articulation, les risques de cybersécurité.

Quand elle s’applique. Pendant toute la vie du dispositif, de la conception initiale au retrait du marché ; le dossier de gestion des risques doit être révisé à chaque modification significative du produit.

Le piège classique. Le dossier de risque « photographie » : rédigé une fois pour la certification, jamais rouvert ensuite, alors que chaque release modifie potentiellement le profil de risque du logiciel.

ISO 13485:2016 — Système de management de la qualité

Ce qu’elle couvre. Les exigences d’un système de management de la qualité adapté aux dispositifs médicaux : maîtrise documentaire, responsabilités de la direction, gestion des ressources, maîtrise de la conception et du développement, achats et sous-traitance, production, mesure et amélioration. C’est l’ossature organisationnelle sur laquelle s’appuient les processus techniques de l’IEC 62304 et de l’ISO 14971.

Quand elle s’applique. Dès que l’entreprise assume un rôle de fabricant ; le MDR exige un QMS, et la certification ISO 13485 en est le moyen de démonstration standard, y compris pour une équipe de dix personnes.

Le piège classique. Acheter un QMS générique sur étagère et le laisser diverger de la pratique réelle : l’auditeur ne compare pas les procédures à la norme, il les compare aux enregistrements et à ce que font réellement les équipes.

IEC 81001-5-1:2021 — Cybersécurité du cycle de vie

Ce qu’elle couvre. Les activités de sécurité à intégrer au cycle de vie du logiciel de santé : gestion des risques de sécurité, spécification des exigences de sécurité, conception et implémentation sécurisées, tests de sécurité, gestion des vulnérabilités, des mises à jour et de la fin de vie. Elle se structure en parallèle de l’IEC 62304, dont elle est le pendant cybersécurité.

Quand elle s’applique. À tout logiciel de santé connecté ou exposé à des menaces informatiques ; elle s’impose comme la référence attendue par les organismes notifiés pour démontrer la conformité aux exigences de sécurité informatique du MDR.

Le piège classique. Réduire la cybersécurité à un pentest annuel : la norme exige un processus continu — threat model, exigences, tests, veille sur les vulnérabilités — et un test d’intrusion ponctuel n’en couvre qu’une fraction.

IEC 62366-1:2015 — Ingénierie de l’aptitude à l’utilisation

Ce qu’elle couvre. Le processus d’ingénierie de l’utilisabilité appliqué aux dispositifs médicaux : spécification du contexte d’utilisation, identification des tâches critiques, analyse des erreurs d’utilisation liées à la sécurité, et évaluations formative et sommative de l’interface. Elle traite l’erreur d’usage comme un risque à part entière, articulé avec l’ISO 14971.

Quand elle s’applique. À tout dispositif avec lequel un humain interagit — ce qui, pour un SaMD, signifie systématiquement : l’interface est le dispositif.

Le piège classique. Confondre travail UX produit et dossier d’utilisabilité : des maquettes soignées et des tests utilisateurs informels ne remplacent pas l’identification documentée des tâches critiques et une évaluation sommative tracée.

MDCG 2019-11 rev.1 — Qualification et classification des logiciels

Ce qu’il couvre. Le guide du Medical Device Coordination Group sur la qualification (le logiciel est-il un dispositif médical ?) et la classification (quelle classe de risque ?) des logiciels sous MDR et IVDR. Il fournit des arbres de décision, l’interprétation de la règle 11 et des exemples concrets, notamment pour les logiciels d’aide à la décision et les modules multiples d’une même application.

Quand il s’applique. En tout début de projet, avant toute décision d’architecture réglementaire ; c’est le texte de travail pour rédiger la justification de qualification et de classification du dossier technique.

Le piège classique. L’ignorer au motif qu’il n’est pas juridiquement contraignant : les organismes notifiés et les autorités compétentes l’appliquent comme s’il l’était, et une classification qui s’en écarte sans justification solide sera contestée.

FDA — §524B et guidance premarket cybersecurity (2023)

Ce qu’ils couvrent. La section 524B du FD&C Act impose aux fabricants de cyber devices des obligations légales : plan de surveillance et de correction des vulnérabilités post-marché, processus de développement sécurisé, et fourniture d’une SBOM. La guidance premarket de 2023 détaille les attentes de la FDA dans les dossiers : threat modeling, architecture de sécurité, tests, étiquetage de sécurité et plans de gestion des vulnérabilités.

Quand ils s’appliquent. À toute soumission à la FDA (510(k), De Novo, PMA) d’un dispositif contenant du logiciel connectable ; la FDA peut refuser d’instruire un dossier incomplet sur ces points.

Le piège classique. Considérer le marché américain comme un simple portage du dossier CE : les exigences cybersécurité de la FDA sont plus prescriptives et plus détaillées que la pratique européenne courante, et s’y conformer a posteriori coûte plus cher que de concevoir la documentation pour les deux marchés dès le départ.

RGPD — Règlement (UE) 2016/679 pour les données de santé

Ce qu’il couvre. Le cadre européen de protection des données personnelles, avec un régime renforcé pour les données de santé, qui sont une catégorie particulière de données : base légale spécifique, analyse d’impact (AIPD) quasi systématique, minimisation, sécurité des traitements, droits des personnes et encadrement des transferts hors UE. Il s’applique en parallèle du MDR, avec ses propres autorités de contrôle et son propre régime de sanctions.

Quand il s’applique. Dès qu’un logiciel traite des données de santé de personnes situées dans l’UE, quel que soit le lieu d’établissement du fabricant ou d’hébergement des données.

Le piège classique. Traiter le RGPD et le MDR en silos : l’hébergement, les sous-traitants, la pseudonymisation et la journalisation sont des choix d’architecture communs aux deux référentiels, et les arbitrer séparément produit des incohérences coûteuses — sans oublier les exigences nationales comme la certification HDS pour l’hébergement de données de santé en France.

Tableau récapitulatif