Glossaire de la conformité logicielle medtech

Ce glossaire couvre le vocabulaire de travail de la conformité logicielle des dispositifs médicaux : réglementation européenne (MDR), normes du cycle de vie logiciel, gestion des risques et cybersécurité. Chaque définition est autoportante et peut être lue indépendamment des autres.

0–9 et §

510(k) — Procédure d’accès au marché américain gérée par la FDA, dans laquelle le fabricant démontre qu’un dispositif est « substantiellement équivalent » à un dispositif déjà commercialisé légalement (le predicate). C’est la voie la plus courante pour les logiciels dispositifs médicaux de risque modéré aux États-Unis. Elle ne doit pas être confondue avec le marquage CE : les deux systèmes sont indépendants et un dossier ne se transpose pas automatiquement de l’un à l’autre.

§524B — Section du Federal Food, Drug, and Cosmetic Act américain, introduite en 2023, qui impose des exigences de cybersécurité aux fabricants de cyber devices soumettant un dossier à la FDA. Elle exige notamment un plan de gestion des vulnérabilités post-commercialisation, un processus de mise à jour de sécurité et la fourniture d’une SBOM. La FDA peut refuser un dossier (Refuse to Accept) si ces éléments sont absents.

A–C

Analyse de risque — Processus d’identification des dangers liés à un dispositif médical, d’estimation des risques associés (combinaison de probabilité et de gravité d’un dommage) et de leur évaluation par rapport à des critères d’acceptabilité définis à l’avance. Pour un logiciel, elle couvre les défaillances fonctionnelles, les erreurs d’usage et les atteintes à la sécurité informatique. Elle constitue le cœur de la norme ISO 14971 et alimente directement la classification de sécurité logicielle de l’IEC 62304.

Audit à blanc — Simulation d’un audit de certification, menée en interne ou par un consultant, avant le passage réel d’un organisme notifié ou d’un certificateur ISO 13485. L’objectif est d’identifier les écarts documentaires et de pratique dans les mêmes conditions que l’audit officiel, sans conséquence sur la certification. C’est l’outil le plus efficace pour éviter les non-conformités majeures lors du premier audit réel.

Classe de sécurité logicielle (A/B/C) — Classification définie par l’IEC 62304 selon la gravité du dommage qu’une défaillance du logiciel pourrait causer : classe A (aucune blessure possible), classe B (blessure non grave possible), classe C (blessure grave ou décès possibles). La classe détermine la rigueur exigée du processus de développement : documentation d’architecture, conception détaillée, tests unitaires et d’intégration. Elle est distincte de la classe réglementaire du dispositif (I, IIa, IIb, III) au sens du MDR, même si les deux sont souvent corrélées.

Cyber device — Terme défini par la loi américaine (§524B du FD&C Act) désignant un dispositif médical qui contient du logiciel, peut se connecter à Internet et présente des caractéristiques susceptibles d’être vulnérables à des menaces de cybersécurité. La quasi-totalité des SaMD et des dispositifs connectés modernes entrent dans cette définition. Un cyber device déclenche les exigences de cybersécurité de la FDA dès la soumission du dossier.

D–I

Dispositif médical logiciel (SaMD) — Software as a Medical Device : logiciel destiné à une ou plusieurs fins médicales (diagnostic, prévention, surveillance, traitement) et remplissant ces fonctions sans faire partie du matériel d’un dispositif médical. Une application mobile d’aide à la décision clinique ou un algorithme d’analyse d’images médicales sont des SaMD. La qualification dépend de l’usage revendiqué par le fabricant, pas de la technologie employée.

Dossier technique — Ensemble documentaire exigé par le MDR (annexes II et III) démontrant la conformité d’un dispositif aux exigences générales de sécurité et de performances. Pour un logiciel, il inclut notamment la description du dispositif, l’usage revendiqué, la documentation de conception et de vérification, le dossier de gestion des risques, l’évaluation clinique et le plan de surveillance post-marché. C’est le document que l’organisme notifié évalue pour délivrer le certificat CE.

État de l’art — Niveau de développement actuel des connaissances techniques et médicales généralement reconnu, que le fabricant doit prendre en compte pour concevoir son dispositif et évaluer l’acceptabilité des risques. En pratique, il se matérialise par l’application des normes harmonisées et des guides consensuels (IEC 62304, ISO 14971, guides MDCG). S’écarter de l’état de l’art est possible, mais doit être justifié et documenté.

EUDAMED — Base de données européenne des dispositifs médicaux prévue par le MDR, destinée à centraliser l’enregistrement des acteurs, des dispositifs (via l’UDI), des certificats, des investigations cliniques et de la vigilance. Son déploiement est progressif, module par module. Les fabricants doivent s’y enregistrer et y déclarer leurs dispositifs au fur et à mesure que les modules deviennent obligatoires.

IEC 62304 — Norme internationale définissant les processus du cycle de vie des logiciels de dispositifs médicaux : planification, analyse des exigences, architecture, 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 exigées. C’est la norme de référence attendue par les organismes notifiés pour tout logiciel dispositif médical ou logiciel intégré à un dispositif.

IEC 81001-5-1 — Norme définissant les activités de cybersécurité à intégrer dans le cycle de vie du logiciel de santé : gestion des risques de sécurité, exigences de sécurité, conception sécurisée, tests de sécurité, gestion des vulnérabilités et des mises à jour. Elle complète l’IEC 62304 sur le volet sécurité informatique et devient la référence attendue en Europe pour démontrer la conformité aux exigences de cybersécurité du MDR.

Intended use / usage revendiqué — Utilisation à laquelle le fabricant destine son dispositif, telle que décrite dans l’étiquetage, la notice et les supports promotionnels. C’est le point de départ de toute la conformité : il détermine si le logiciel est un dispositif médical, sa classe de risque, le contenu de l’évaluation clinique et le périmètre des revendications autorisées. Un écart entre l’usage réel du produit et l’usage revendiqué est une non-conformité classique et coûteuse.

ISO 13485 — Norme internationale spécifiant les exigences d’un système de management de la qualité (QMS) pour les organismes intervenant dans le cycle de vie des dispositifs médicaux. Elle couvre la maîtrise documentaire, la conception, les achats, la production, la traçabilité et le traitement des réclamations. La certification ISO 13485 est le moyen standard de démontrer la conformité aux exigences de QMS du MDR, même si elle n’est pas formellement obligatoire.

ISO 14971 — Norme internationale d’application de la gestion des risques aux dispositifs médicaux. Elle définit un processus complet : plan de gestion des risques, analyse, évaluation, maîtrise des risques, évaluation du risque résiduel global et activités de production et post-production. Elle s’applique à tous les dispositifs, logiciels compris, et son dossier de gestion des risques est une pièce maîtresse du dossier technique.

J–M

Marquage CE — Marquage apposé par le fabricant attestant que le dispositif est conforme aux exigences du règlement européen applicable (MDR pour les dispositifs médicaux) et peut circuler librement dans l’Union européenne. Pour les dispositifs de classe supérieure à la classe I, il suppose l’intervention d’un organisme notifié qui délivre un certificat après évaluation du dossier technique et du QMS. Le marquage CE est une déclaration de conformité du fabricant, pas une autorisation délivrée par une autorité.

MDCG — Medical Device Coordination Group : groupe d’experts des États membres institué par le MDR, qui publie des documents guides sur l’interprétation du règlement. Ses guides ne sont pas juridiquement contraignants mais font autorité auprès des organismes notifiés et des autorités compétentes. Pour le logiciel, le guide MDCG 2019-11 sur la qualification et la classification est le texte de référence.

MDR — Règlement (UE) 2017/745 relatif aux dispositifs médicaux, applicable depuis mai 2021 en remplacement des directives 93/42/CEE et 90/385/CEE. Il renforce les exigences d’évaluation clinique, de surveillance post-marché, de traçabilité (UDI) et de transparence (EUDAMED), et durcit la classification des logiciels via la règle 11. Étant un règlement, il s’applique directement dans tous les États membres sans transposition nationale.

N–R

Organisme notifié — Organisme de certification désigné par un État membre et notifié à la Commission européenne pour évaluer la conformité des dispositifs médicaux au MDR. Il audite le système qualité du fabricant, évalue le dossier technique et délivre les certificats CE nécessaires aux dispositifs de classe IIa et au-delà. Le fabricant le choisit librement parmi les organismes désignés, mais les capacités étant limitées, les délais d’accès sont un paramètre stratégique à anticiper.

PMS / surveillance post-marché — Post-Market Surveillance : processus systématique et proactif de collecte et d’analyse des données sur un dispositif après sa mise sur le marché (réclamations, incidents, retours utilisateurs, littérature, données d’usage). Le MDR exige un plan PMS et des rapports périodiques dont le format dépend de la classe du dispositif. Pour un logiciel, la PMS inclut aussi le suivi des vulnérabilités de sécurité et des composants tiers.

QMS — Quality Management System, ou système de management de la qualité : ensemble des processus, procédures et responsabilités organisant la façon dont l’entreprise conçoit, développe, maintient et surveille ses dispositifs. Le MDR impose à tout fabricant un QMS couvrant notamment la gestion des risques, l’évaluation clinique et la surveillance post-marché. En pratique, il est structuré selon l’ISO 13485 et doit être vivant : un QMS que les équipes n’appliquent pas au quotidien est un écart d’audit classique.

Règle 11 — Règle de classification de l’annexe VIII du MDR spécifique aux logiciels. Un logiciel fournissant des informations utilisées pour des décisions à visée diagnostique ou thérapeutique est au minimum de classe IIa ; la classe monte à IIb ou III selon la gravité des conséquences possibles (détérioration grave, intervention chirurgicale, décès). Sa conséquence pratique majeure : très peu de logiciels dispositifs médicaux restent en classe I sous le MDR, ce qui rend l’organisme notifié incontournable.

S–U

SBOM — Software Bill of Materials : inventaire structuré et lisible par machine de tous les composants logiciels d’un produit (bibliothèques, dépendances directes et transitives, versions, licences). Elle est exigée par la FDA pour les cyber devices et attendue en Europe au titre de la gestion des composants tiers. Les formats standards sont CycloneDX et SPDX ; une SBOM générée automatiquement dans la CI est le seul moyen réaliste de la maintenir à jour.

SOUP — Software Of Unknown Provenance : au sens de l’IEC 62304, tout composant logiciel non développé selon la norme et intégré au dispositif — typiquement les bibliothèques open source, frameworks et systèmes d’exploitation. Chaque SOUP doit être identifié, ses exigences fonctionnelles et de performance spécifiées, et ses anomalies connues évaluées au regard des risques. La gestion des SOUP est l’un des écarts les plus fréquemment relevés en audit sur les projets logiciels.

Threat model — Analyse structurée des menaces de sécurité pesant sur un système : identification des actifs à protéger, des surfaces d’attaque, des scénarios d’attaque plausibles et des contre-mesures. Pour un dispositif médical connecté, le threat model alimente l’analyse de risque sécurité exigée par l’IEC 81001-5-1 et attendue par la FDA dans les dossiers premarket. Des méthodologies comme STRIDE fournissent un cadre systématique pour le construire.

Traçabilité — Capacité à relier entre eux, de bout en bout, les exigences, les éléments de conception, le code, les tests et les risques identifiés. En pratique : chaque exigence logicielle doit être couverte par des tests, chaque mesure de maîtrise des risques doit être vérifiée, et chaque élément doit être retrouvable dans les deux sens. La matrice de traçabilité est l’un des premiers documents qu’un auditeur consulte pour évaluer la maîtrise réelle du cycle de vie.

UDI — Unique Device Identification : système d’identification unique des dispositifs imposé par le MDR, composé d’un identifiant de dispositif (UDI-DI) et d’un identifiant de production (UDI-PI). Pour un logiciel, l’UDI doit être accessible depuis le logiciel lui-même (écran « à propos » par exemple) et un changement majeur de version entraîne un nouvel UDI-DI. L’UDI alimente la base EUDAMED et la traçabilité tout au long de la chaîne de distribution.

V–Z

Vigilance — Processus réglementaire de déclaration aux autorités compétentes des incidents graves et des actions correctives de sécurité (FSCA) concernant des dispositifs mis sur le marché. Le MDR impose des délais de déclaration stricts, gradués selon la gravité de l’incident. La vigilance est le volet réactif de la surveillance post-marché : elle suppose un processus interne capable de détecter, qualifier et déclarer un incident dans les délais, y compris pour un incident d’origine logicielle ou de cybersécurité.