Audit de conformité logicielle : les points critiques en RDM

Audit de conformité logicielle: les points critiques en RDM

Lors d’un audit de conformité logicielle pour un dispositif médical, l’organisme notifié cherche surtout à vérifier une chose beaucoup moins flatteuse: la cohérence entre le logiciel réellement développé, les risques identifiés et les preuves versées au dossier technique.

C’est précisément là que les dossiers se fissurent. La documentation décrit une architecture idéale, le code déployé a évolué au fil des sprints, les tests ont été conduits sur une version intermédiaire et la gestion des risques continue de parler d’un produit qui n’existe plus tout à fait. Le logiciel, lui, fonctionne. Ce qui ne fonctionne plus, c’est la démonstration de sa conformité au Règlement (UE) 2017/745.

La règle 11 du RDM: la classification n’est pas une formalité administrative

La première erreur consiste à traiter la classification comme une case à cocher au début du projet. Dans le cas d’un logiciel médical, elle conditionne directement le niveau de contrôle réglementaire, la profondeur de l’évaluation clinique, les exigences documentaires et l’intervention éventuelle d’un organisme notifié.

La règle 11 de l’annexe VIII du RDM prévoit qu’un logiciel fournissant des informations utilisées pour prendre des décisions à visée diagnostique ou thérapeutique relève au minimum de la classe IIa. La classe peut être supérieure lorsque la décision prise à partir de ces informations est susceptible d’entraîner des conséquences plus graves pour le patient.

La formulation paraît simple. Elle ne l’est pas. Tout dépend de la fonction revendiquée, de la manière dont le logiciel influence la décision médicale et du risque associé à une information erronée, absente ou retardée.

Un module qui stocke ou archive des données médicales n’est pas automatiquement classé IIa ou davantage. Ne vous y trompez pas: c’est la finalité médicale revendiquée et la fonction effectivement fournie qui structurent l’analyse, pas la présence de données de santé dans la base.

Les questions que l’auditeur posera réellement

Lors d’un audit de conformité logicielle pour un dispositif médical, la classification est examinée au regard de plusieurs éléments qui doivent se répondre sans contradiction:

• Quelle est la destination du logiciel telle qu’elle apparaît dans l’étiquetage, la notice, le dossier technique et les supports commerciaux?
• Le logiciel fournit-il une information destinée à détecter, diagnostiquer, surveiller ou traiter une pathologie?
• L’utilisateur prend-il une décision clinique à partir du résultat affiché?
• Une erreur du logiciel peut-elle conduire à un retard de prise en charge, à un traitement inadapté ou à une intervention inutile?
• Le résultat est-il seulement consultatif ou influence-t-il directement une décision médicale?
• Les fonctions revendiquées dans la documentation correspondent-elles à celles réellement disponibles dans la version mise sur le marché?

Cette dernière question est souvent sous-estimée. Une fonction ajoutée par l’équipe produit peut modifier la qualification réglementaire, même si elle est présentée en interne comme une simple amélioration ergonomique. Un indicateur supplémentaire, une alerte, une recommandation ou un classement automatisé peuvent faire évoluer le profil de risque du logiciel.

La classe de risque ne se déduit pas de la technologie utilisée. Elle se déduit de la décision médicale que le logiciel contribue à prendre.

Le fabricant doit donc établir une justification de classification argumentée, reliée à la destination du dispositif et à l’analyse de risques. Une mention générale du type « logiciel d’aide au diagnostic » ne suffit pas. Il faut montrer ce que le logiciel produit, comment cette information est utilisée et quelles conséquences sont associées à une défaillance.

La certification du logiciel: attention au mauvais vocabulaire

Parler de « certification IEC 62304 » est une simplification trompeuse. La norme IEC 62304 définit les processus du cycle de vie des logiciels de dispositifs médicaux, mais elle ne délivre pas, à elle seule, un certificat autonome comparable à un diplôme administratif du logiciel.

Son respect est évalué dans le cadre de la documentation technique, du système de management de la qualité et de l’évaluation de conformité conduite par l’organisme compétent. Cette nuance n’est pas du juridisme décoratif: elle détermine les preuves à préparer.

Un fournisseur qui annonce une « certification IEC 62304 » sans préciser le périmètre de l’évaluation, les classes de sécurité concernées et l’articulation avec le RDM et l’ISO 13485 mérite au minimum une demande d’explication. La conformité ne repose pas sur un logo, mais sur un ensemble cohérent de processus et d’enregistrements.

IEC 62304: le cycle de vie comme matière première de l’audit

La norme IEC 62304 encadre les processus du cycle de vie logiciel: développement, maintenance, gestion des risques, gestion de configuration et résolution des problèmes. Elle introduit également une approche proportionnée à la classe de sécurité du logiciel — classes A, B et C — qui ne doit pas être confondue avec la classe de risque du dispositif au sens du RDM.

Cette distinction est fondamentale. La classe de risque réglementaire du dispositif et la classe de sécurité logicielle répondent à des logiques différentes. Elles doivent néanmoins se rejoindre dans l’analyse des conséquences d’une défaillance.

Un logiciel peut contenir des fonctions de criticité différente. Le fabricant doit alors expliquer la manière dont il a déterminé les niveaux de sécurité applicables, les mesures de maîtrise associées et les éventuelles séparations entre fonctions. La formule magique consistant à attribuer une classe basse à l’ensemble du produit pour alléger la documentation ne résiste pas longtemps à un audit sérieux.

Ce que l’auditeur veut retrouver dans le cycle de développement

Un dossier logiciel exploitable ne se limite pas à un document d’architecture et à quelques captures d’écran. Il doit permettre de suivre la logique du produit depuis les exigences jusqu’à la version livrée.

Les points de contrôle se concentrent notamment sur:

1. Les exigences logicielles

Elles doivent être identifiées, formulées de manière vérifiable et reliées à la destination du dispositif, aux exigences système et aux risques applicables. Une exigence vague comme « l’application doit être fiable » ne permet ni test pertinent ni décision d’acceptation.

2. L’architecture et la décomposition fonctionnelle

L’auditeur cherche à comprendre les modules, les interfaces, les flux de données, les dépendances et les mécanismes de séparation. Une architecture décrite à un niveau abstrait, sans correspondance avec le produit déployé, ne constitue pas une preuve suffisante.

3. La gestion des risques

Les défaillances logicielles doivent être intégrées à l’analyse de risques du dispositif. Le lien entre danger, séquence d’événements, situation dangereuse, dommage et mesure de maîtrise doit rester intelligible. Il ne suffit pas d’inscrire « erreur logicielle » dans une colonne pour considérer le risque traité.

4. La vérification et la validation

Les tests doivent démontrer que les exigences sont satisfaites et que le logiciel fonctionne dans son environnement prévu. Les résultats doivent être enregistrés, examinés et reliés à la version testée. Un rapport de test sans identifiant de version est une invitation à la contestation.

5. La gestion de configuration

Le fabricant doit savoir quelle version du code, des bibliothèques, des paramètres et des composants a été utilisée pour produire la version mise sur le marché. La traçabilité ne s’arrête pas au numéro affiché dans le menu de l’application.

6. La résolution des anomalies

Les problèmes doivent être enregistrés, évalués, corrigés ou justifiés, puis vérifiés. Une anomalie clôturée parce qu’elle n’a pas été reproduite n’est pas nécessairement une anomalie traitée.

La norme IEC 62304 ne demande pas de produire de la documentation pour satisfaire un goût particulier des auditeurs. Elle impose de rendre le développement reproductible, contrôlable et explicable. La paperasse n’est pas le produit de la conformité; elle en est la trace vérifiable.

Le piège du développement agile

Le développement agile n’est pas incompatible avec le RDM. En revanche, la vitesse des itérations ne dispense pas de maîtriser les changements. Chaque évolution susceptible d’affecter une exigence, un risque, une interface, une performance ou une fonction médicale doit être évaluée.

Le problème apparaît lorsque les équipes distinguent artificiellement les « changements produit » et les « changements réglementaires ». Pour l’auditeur, une nouvelle règle de calcul, une modification de seuil ou une bibliothèque mise à jour peuvent avoir une portée réglementaire, même si la version commerciale reste présentée comme une amélioration mineure.

La question n’est donc pas de savoir si le projet utilise Scrum, Kanban ou un autre mode de gestion. La question est de savoir si le fabricant peut démontrer:

• ce qui a changé;
• pourquoi cela a changé;
• quelles exigences sont concernées;
• quels risques ont été réévalués;
• quels tests ont été rejoués;
• qui a approuvé la mise en production.

ISO 13485: valider les outils qui fabriquent la preuve

L’audit ne porte pas seulement sur le logiciel médical commercialisé. Il porte aussi sur les logiciels utilisés pour développer, produire, tester, mesurer, libérer et surveiller le dispositif.

C’est l’un des angles morts les plus fréquents. Une entreprise peut consacrer des mois à valider son application clinique tout en utilisant, dans son système de management de la qualité, des outils dont la configuration n’est pas maîtrisée: gestion documentaire, suivi des exigences, plateforme de tests, système de contrôle des versions, outil de gestion des anomalies ou solution de production.

L’ISO 13485:2016 impose la validation des logiciels informatiques utilisés dans le SMQ, la production et la mesure, notamment au titre des paragraphes 4.1.6, 7.5.6 et 7.6. Le niveau de validation doit être proportionné à l’utilisation prévue et à l’impact potentiel d’une défaillance.

Autrement dit, il ne suffit pas d’expliquer que l’outil est largement utilisé dans l’industrie ou qu’il provient d’un éditeur reconnu. La réputation du fournisseur ne remplace pas la validation dans l’environnement réel du fabricant.

Validation ne signifie pas test de bon fonctionnement

Une validation de logiciel utilisé dans le SMQ doit établir que l’outil répond à son usage prévu dans les conditions d’utilisation définies. Cette démarche comprend généralement:

• la définition de l’usage prévu;
• l’identification des fonctions critiques;
• l’analyse des risques liés à l’utilisation de l’outil;
• la définition des exigences de validation;
• les essais dans une configuration représentative;
• l’enregistrement des résultats et des écarts;
• la gestion des changements et des mises à jour.

Prenons un système de gestion des exigences. Si son rôle est uniquement de centraliser des documents non contrôlés, son impact ne sera pas le même que s’il constitue la source officielle de traçabilité entre exigences, risques et tests. Dans le second cas, une suppression, une modification non détectée ou une perte d’historique peut compromettre directement la preuve de conformité.

La validation doit donc porter sur l’usage réel, pas sur la brochure du logiciel.

Le guide ISO/TR 80002-2 est souvent utilisé pour structurer cette réflexion. Il ne transforme pas une validation faible en validation acceptable par simple invocation. Il fournit un cadre méthodologique; le fabricant reste responsable de démontrer que son outil, sa configuration et ses contrôles sont adaptés à son processus.

Un outil de qualité non validé ne produit pas une qualité traçable. Il produit des fichiers bien rangés dont la valeur probatoire reste incertaine.

Les mises à jour SaaS: le détail qui dérange

Les applications hébergées dans le nuage compliquent la validation, car le fabricant ne maîtrise pas toujours directement le calendrier, le contenu et les modalités des mises à jour. Une nouvelle version peut modifier une fonction, une interface, un export, une règle de permission ou un mécanisme d’archivage.

Le contrat fournisseur doit donc être lu avec une attention moins commerciale et davantage réglementaire. Les éléments à examiner concernent notamment:

• la notification des changements;
• la conservation des données et des historiques;
• la gestion des accès;
• la restauration après incident;
• la disponibilité des journaux;
• la séparation entre environnements;
• la possibilité de vérifier l’impact d’une mise à jour.

Dire que l’application est « automatiquement à jour » n’est pas une réponse de conformité. C’est parfois précisément le risque à documenter.

Le point de rupture: le code réel contre la documentation générique

La non-conformité la plus classique n’est pas toujours une absence totale de document. C’est une incohérence entre plusieurs documents qui semblent chacun acceptables pris séparément.

Le code a évolué. Le dossier technique non.

L’architecture mentionne trois modules alors que la version déployée en comporte cinq. La matrice de traçabilité relie les exigences à des tests portant sur une version ancienne. La gestion des risques ne mentionne pas une dépendance logicielle ajoutée depuis. Le rapport de validation décrit un environnement impossible à reproduire. Chacun de ces écarts peut paraître mineur; ensemble, ils compromettent la démonstration de conformité.

La traçabilité ne doit pas être une matrice décorative

Une matrice de traçabilité utile permet de relier, au minimum, les éléments suivants:

La matrice ne doit pas seulement démontrer qu’un lien existe. Elle doit permettre de comprendre la logique du lien. Une ligne qui relie une exigence à un test portant le même intitulé ne prouve rien si le test ne vérifie pas le comportement attendu dans les conditions d’utilisation prévues.

Le contrôle à effectuer avant l’audit

Avant de convoquer l’organisme notifié, le fabricant devrait réaliser une revue de cohérence entre le produit et le dossier, en partant de la version réellement livrée — et non du dossier que l’on espère encore défendre.

Cette revue doit notamment confronter:

• le numéro et le contenu de la version déployée;
• l’architecture décrite dans le dossier technique;
• les dépendances et composants tiers effectivement utilisés;
• les exigences et critères d’acceptation;
• les risques et mesures de maîtrise;
• les tests exécutés;
• les anomalies ouvertes ou corrigées;
• les éléments de cybersécurité;
• les notices, supports commerciaux et déclarations de destination.

Les incohérences de vocabulaire sont également révélatrices. Un document parle d’alerte, un autre de recommandation; l’un décrit une fonction automatique, l’autre une assistance à l’utilisateur. Ces différences peuvent modifier la compréhension de la fonction médicale et donc l’analyse réglementaire.

La réalité est que l’auditeur n’a pas besoin de démontrer que le logiciel est imparfait. Il lui suffit de montrer que le fabricant ne sait pas établir avec certitude ce qui a été développé, testé et mis sur le marché.

Cybersécurité: la SBOM ne remplace pas la maîtrise du produit

La cybersécurité des dispositifs médicaux n’est plus une question séparée de la conformité logicielle. Un logiciel connecté peut être cliniquement performant et néanmoins présenter une surface d’attaque mal maîtrisée, des dépendances obsolètes ou un processus de correction insuffisant.

Aux États-Unis, la section 524B du FD&C Act, introduite en 2023, impose des exigences spécifiques aux dispositifs connectés soumis à la FDA. Elles comprennent notamment une Software Bill of Materials — SBOM — et un plan de gestion des vulnérabilités.

Ce cadre américain ne se transpose pas mécaniquement à l’évaluation d’un dispositif sous RDM. Il donne néanmoins une indication claire de la direction prise par les autorités: le fabricant doit savoir de quoi son logiciel est composé et comment il réagit lorsqu’une vulnérabilité est découverte.

Une SBOM utile, pas un inventaire exporté pour la forme

Une SBOM doit permettre d’identifier les composants logiciels utilisés dans le produit, leurs versions et leurs relations pertinentes. L’export automatique fourni par un outil ne suffit pas si personne ne sait l’interpréter ni le relier au produit livré.

L’auditeur examinera plus largement:

• la méthode d’identification des composants tiers;
• la gestion des versions et des licences;
• la surveillance des vulnérabilités;
• les critères de criticité;
• le délai et le processus de correction;
• les mesures compensatoires lorsqu’un correctif immédiat est impossible;
• la vérification des mises à jour;
• la communication avec les utilisateurs ou clients concernés.

Un composant open source n’est pas un problème en soi. Un composant inconnu, non suivi ou impossible à relier à une version livrée en est un.

Le plan de gestion des vulnérabilités doit être opérationnel

Un document qui prévoit de « traiter les vulnérabilités dans les meilleurs délais » n’est pas un plan. Il faut définir les responsabilités, les canaux de signalement, les modalités d’analyse, les critères de décision et les preuves conservées.

La gestion doit couvrir tout le cycle de vie du dispositif. Une vulnérabilité découverte après la mise sur le marché ne disparaît pas parce que le développement initial est terminé. Elle peut imposer une analyse d’impact, une correction, une information des utilisateurs, voire une action corrective selon la nature du risque et les obligations applicables.

Là encore, le lien avec la gestion des risques doit être explicite. La cybersécurité n’est pas un appendice informatique ajouté au dossier technique la veille de l’audit. Une compromission de l’intégrité, de la disponibilité ou de la confidentialité peut affecter directement la sécurité du patient et la performance clinique du dispositif.

Comment préparer un audit sans fabriquer un dossier de façade

La meilleure préparation n’est pas celle qui empile les procédures. C’est celle qui réduit les contradictions entre les équipes réglementaires, qualité, développement, cybersécurité et production.

Une revue efficace peut être organisée autour de cinq questions simples, mais peu confortables:

1. Quelle version est réellement commercialisée?

Pas celle qui figure dans la présentation investisseurs, pas celle du dernier rapport de test, mais celle installée ou accessible par les utilisateurs.

2. Quelle fonction médicale est réellement revendiquée?

La destination doit être identique dans le dossier technique, l’étiquetage, la notice, le site internet et les supports de vente.

3. Quels risques sont liés aux décisions prises à partir du logiciel?

Il faut pouvoir relier les fonctions, les erreurs possibles, les mesures de maîtrise et les essais réalisés.

4. Les outils utilisés pour produire la preuve sont-ils eux-mêmes maîtrisés?

Un système de gestion des exigences, de tests ou de documents peut avoir un impact réglementaire direct.

5. Que se passe-t-il après la mise sur le marché?

La maintenance, la gestion des anomalies, les mises à jour, la surveillance des vulnérabilités et la matériovigilance doivent être intégrées au dispositif de conformité.

Le verdict est assez net. Un fabricant qui peut répondre précisément à ces questions dispose d’une base défendable, même si tout n’est pas parfait. Un fabricant qui répond par des liens vers des procédures génériques possède peut-être beaucoup de documents, mais pas nécessairement un système maîtrisé.

Le verdict: la conformité se joue dans les raccords

Un audit de conformité logicielle pour dispositif médical ne se gagne pas avec une présentation technologique séduisante. Il se gagne dans les raccords: entre la règle 11 et la destination du logiciel, entre l’IEC 62304 et le cycle de développement, entre l’ISO 13485 et les outils du SMQ, entre le code déployé et la documentation technique, entre la cybersécurité et l’analyse de risques.

Le point critique n’est donc pas de posséder un document intitulé « conformité IEC 62304 ». C’est de pouvoir démontrer, version après version, que le logiciel développé est celui qui a été évalué, que ses risques sont compris, que ses tests sont exploitables et que les outils ayant produit les preuves sont eux-mêmes validés.

La technologie peut être brillante. L’organisme notifié, lui, examinera les traces. Et dans le domaine des dispositifs médicaux, les traces incohérentes ont une fâcheuse tendance à peser davantage que les promesses du fabricant.