Logiciel de laser médical : bilan de notre test de conformité

Logiciel de laser médical: bilan de notre test de conformité

Sur les logiciels qui pilotent les lasers médicaux — qu’il s’agisse d’un laser chirurgical, dermatologique, ophtalmique ou de physiothérapie — la norme IEC 62304 sert trop souvent de paravent marketing. On lit « logiciel conforme à l’IEC 62304 » sur des plaquettes, on entend parler de « processus de développement validé » lors de salons professionnels, et l’on ressort avec l’impression que le marquage CE est déjà presque acquis.

La réalité est moins confortable. La conformité logicielle n’est qu’un étage de la démonstration réglementaire. Elle doit s’articuler avec l’analyse de risques, la conception du dispositif, les essais, la validation clinique et le système qualité du fabricant. Une lacune sur ce maillon peut rendre la démonstration incomplète ou difficile à défendre au moment de l’évaluation par l’organisme notifié. C’est précisément pour cela qu’un audit de conformité du logiciel de laser médical selon l’IEC 62304 ne consiste pas à vérifier la présence d’un certificat ou d’une phrase dans une brochure: il faut reconstituer la logique qui relie le besoin clinique au logiciel livré.

La classification de sécurité logicielle: au-delà du marquage CE

Premier point sur lequel il convient de remettre les pendules à l’heure: la norme IEC 62304, publiée en 2006 et amendée en 2015, définit un cycle de vie logiciel applicable aux logiciels embarqués dans un dispositif médical — SiMD, pour Software in a Medical Device — comme aux logiciels autonomes, les SaMD. Elle impose notamment de déterminer la classe de sécurité du logiciel en fonction de sa contribution possible à une situation dangereuse.

Trois classes sont utilisées:

La dernière ligne mérite une précision. La Classe C ne signifie pas qu’il faudrait contrôler de manière exhaustive tous les comportements imaginables du logiciel, ce qui serait une formulation excessive et techniquement impraticable. Elle implique en revanche un niveau de maîtrise plus élevé: architecture suffisamment détaillée, exigences mieux décomposées, vérifications adaptées à la criticité, traitement documenté des anomalies, maîtrise des interfaces et justification des décisions prises. La vérification doit être renforcée et proportionnée aux risques identifiés, non présentée comme une exploration exhaustive de tous les états possibles du système.

Le piège classique — et il revient régulièrement dans les dossiers examinés — consiste à confondre cette classification logicielle avec la classification réglementaire du dispositif médical. Les Classes I, IIa, IIb et III du règlement européen (UE) 2017/745, dit MDR, répondent à une autre logique. Elles concernent le dispositif dans son ensemble et tiennent compte de règles de classification propres au produit, à sa destination et à son niveau de risque. La classe A, B ou C de l’IEC 62304 concerne, elle, la sécurité du logiciel et les conséquences possibles d’une défaillance logicielle.

Un laser médical classé IIb au sens du MDR peut ainsi intégrer un logiciel de Classe C si une erreur de commande est susceptible d’entraîner une brûlure grave, une lésion oculaire irréversible ou une autre atteinte sévère. À l’inverse, la classe réglementaire du dispositif ne suffit pas à déduire mécaniquement la classe logicielle. Un logiciel qui calcule un paramètre secondaire, affiche une information sans piloter directement l’émission et dont la défaillance ne peut pas provoquer de blessure grave ne sera pas analysé de la même manière qu’un logiciel qui commande la puissance, la durée d’exposition ou le déclenchement du faisceau.

La bonne question n’est donc pas: « Quelle est la classe du laser? » Elle est plutôt: « Que peut-il se passer si cette fonction logicielle se trompe, si elle ne répond pas, si elle reçoit une donnée erronée ou si elle transmet une commande incorrecte au sous-système concerné? »

La classe de sécurité IEC 62304 n’est pas la classe du dispositif au sens du MDR. Lorsque les deux semblent coïncider par principe, la justification mérite d’être reprise depuis l’analyse de risques.

La classification doit être documentée à partir du dispositif réel, de sa destination et de ses mesures de maîtrise des risques. Il faut notamment distinguer les fonctions qui influencent directement le traitement de celles qui ne font qu’accompagner l’utilisateur. Une interface graphique peut sembler secondaire, mais elle devient pertinente si une mauvaise présentation des unités, des limites ou de l’état du système peut conduire à une commande dangereuse. De la même manière, une fonction de journalisation n’a pas le même rôle selon qu’elle sert uniquement à l’historique ou qu’elle conditionne la décision de poursuivre une séance.

Cycle de vie et traçabilité: les piliers de la norme IEC 62304

La norme structure le développement logiciel autour d’activités de planification, d’analyse des exigences, de conception architecturale, de conception détaillée, d’implémentation, de vérification et de maintenance. Chacune doit laisser des éléments de preuve suffisamment clairs pour qu’un tiers puisse comprendre ce qui a été décidé, pourquoi cela l’a été et comment le résultat a été vérifié.

La traçabilité bidirectionnelle entre les exigences, l’architecture logicielle, le code, les risques et les tests n’est pas un détail de procédure. Elle permet de suivre le raisonnement dans les deux sens. À partir d’une exigence, on doit pouvoir identifier la fonction qui la met en œuvre et les essais qui démontrent son respect. À partir d’un test ou d’un élément logiciel, on doit pouvoir retrouver l’exigence et le risque auquel il se rattache.

Cette chaîne devient particulièrement importante lorsqu’un événement de matériovigilance ou une anomalie de fonctionnement est signalé. Le fabricant doit pouvoir remonter de l’événement clinique à la fonction concernée, à l’exigence qui la définissait, à l’analyse de risques correspondante et, si nécessaire, à la modification logicielle introduite dans une version donnée. Une documentation qui ne permet pas cette remontée ne rend pas automatiquement tout le dossier invalide, mais elle peut constituer une non-conformité sérieuse et fragiliser la démonstration de maîtrise du produit.

Pour chaque exigence logicielle importante, le dossier devrait permettre d’identifier au minimum:

• l’origine de l’exigence, qu’elle soit clinique, réglementaire, système ou issue d’une analyse de risques;
• l’élément d’architecture qui la met en œuvre;
• les interfaces concernées, notamment avec le générateur laser, les capteurs, les dispositifs de sécurité et l’interface utilisateur;
• le ou les tests qui vérifient son comportement;
• les résultats obtenus, les anomalies observées et leur traitement;
• le lien avec l’analyse de risques selon l’ISO 14971;
• la version du logiciel et la configuration matérielle auxquelles la preuve se rapporte.

Dans un dossier solide, la traçabilité ne se réduit donc pas à une matrice remplie en fin de projet. Elle accompagne les décisions de conception. Une exigence modifiée doit entraîner l’examen de ses liens avec l’architecture, le code, les tests et les risques. Une anomalie détectée au cours d’un essai doit conduire à vérifier si d’autres fonctions ou scénarios sont concernés. Une mise à jour d’une bibliothèque doit être évaluée en fonction des interfaces et des fonctions de sécurité qu’elle peut affecter.

La méthode agile n’est pas incompatible avec cette exigence. La norme IEC 62304 ne demande pas qu’un fabricant renonce aux itérations courtes, aux revues fréquentes ou à l’intégration continue. Elle demande que les livrables nécessaires au cycle de vie soient identifiables et maîtrisés. Un sprint peut parfaitement produire une évolution conforme à condition que ses exigences, ses critères d’acceptation, ses tests, ses anomalies et ses décisions de revue soient conservés dans un système contrôlé.

Le problème ne vient pas de l’agilité en elle-même. Il apparaît lorsque le fabricant confond rapidité d’itération et absence de formalisation. Un développement peut être très réactif tout en restant auditable. À l’inverse, un projet conduit selon un cycle en V peut présenter une traçabilité médiocre si les exigences sont vagues, si les tests sont rédigés après coup ou si les versions réellement évaluées ne sont pas clairement identifiées.

Une lacune de traçabilité doit être traitée avec mesure. Elle peut concerner une exigence isolée, une version particulière ou une famille de fonctions. Il faut en évaluer l’étendue, le lien avec la sécurité et la possibilité de reconstituer la preuve. La conclusion ne sera pas toujours l’invalidation de l’ensemble du dossier, mais rarement l’absence de conséquence. Selon sa portée, la lacune peut nécessiter une analyse complémentaire, une reprise des essais, une mise à jour documentaire ou une action corrective intégrée au système qualité.

Gestion des risques et criticité: éviter le piège de la Classe C par défaut

Voilà le point que les fabricants ne veulent surtout pas voir inscrit dans leur procédure interne. Lorsqu’une classification de sécurité n’est pas établie conformément à la logique de la norme, le fabricant s’expose à l’application de la classe la plus élevée pour les éléments concernés. En pratique, une absence de classification argumentée peut donc conduire à devoir traiter le logiciel comme un logiciel de Classe C, avec les activités de développement et de vérification correspondantes.

Cette règle n’est pas un détail pédagogique. Elle vise à éviter qu’un fabricant choisisse une classe moins exigeante sans démontrer que les conséquences possibles d’une défaillance ont réellement été analysées. Un argument du type « notre logiciel est de Classe B car nous estimons qu’aucune blessure grave n’est possible » ne suffit pas. Il faut montrer sur quels scénarios cette conclusion repose, quelles fonctions sont impliquées, quelles mesures de maîtrise sont prévues et pourquoi elles réduisent effectivement le risque.

Une analyse de risques selon l’ISO 14971 appliquée au dispositif complet doit servir de point d’ancrage. Elle ne doit pas être ajoutée après la conception logicielle comme une annexe indépendante. Pour un laser médical, elle doit notamment examiner les fonctions liées à l’énergie délivrée, à la durée d’exposition, au profil et au positionnement du faisceau, à la surveillance des paramètres, aux alarmes, aux dispositifs de commande et aux conditions d’arrêt.

Le « contrôle de l’aimantation » ne constitue pas un paramètre générique à intégrer par principe dans l’analyse d’un laser médical. Selon l’architecture du dispositif, les sujets pertinents pourront plutôt concerner la puissance ou l’énergie délivrée, la durée d’émission, le refroidissement, la température, le positionnement, la détection d’un défaut capteur, l’état des interverrouillages, la commande au pied ou les conditions de déclenchement. La liste exacte dépend du produit et de ses sous-systèmes; elle doit être établie à partir de l’architecture et de la destination médicale, pas copiée depuis une matrice générique.

C’est là que se joue la qualité d’un dossier. Une fonction de surveillance thermique, par exemple, ne doit pas être seulement mentionnée dans une analyse de risques. Il faut comprendre ce qu’elle mesure, avec quelle tolérance, comment le logiciel réagit à une valeur hors plage, ce qui se passe en cas de perte de communication et comment l’opérateur est informé. Pour une fonction de commande du faisceau, il faut également examiner les états transitoires: démarrage, interruption, reprise après défaut, arrêt d’urgence et redémarrage du système.

Le fabricant qui classe « au feeling » se condamne à défendre une conclusion fragile. Il risque soit de devoir compléter son dossier avec des activités de Classe C qui n’avaient pas été planifiées, soit de présenter une classification de Classe B insuffisamment étayée. Dans les deux cas, le problème ne tient pas seulement au volume de documents à produire. Il peut toucher la cohérence entre les exigences, l’architecture, les essais et les preuves de sécurité déjà disponibles.

Une classification correctement argumentée doit répondre à plusieurs questions:

• Quelle est la fonction médicale ou de sécurité considérée?
• Quelle défaillance logicielle est envisageable?
• Quelle situation dangereuse peut en résulter?
• Quelles sont les conséquences possibles pour le patient, l’utilisateur ou un tiers?
• Quelles mesures de maîtrise sont indépendantes, redondantes ou complémentaires?
• Comment ces mesures ont-elles été vérifiées?
• La conclusion reste-t-elle valable après l’intégration de composants tiers ou après une modification de l’architecture?

La réponse n’a pas besoin d’être spectaculaire. Elle doit être cohérente, compréhensible et reliée aux autres documents du dossier technique. C’est cette continuité qui permet de défendre une Classe B lorsque le risque le justifie, plutôt que de choisir cette classe pour réduire artificiellement la charge documentaire.

Ne pas classifier son logiciel, c’est laisser la décision la plus pénalisante s’imposer par défaut. Une classification argumentée vaut mieux qu’un silence documentaire que l’auditeur devra interpréter.

Intégration des composants tiers (SOUP) dans votre dossier technique

Le laser médical moderne n’est plus un monolithe logiciel. Il peut intégrer des bibliothèques d’imagerie, des systèmes d’exploitation, des middlewares de communication, des piles logicielles open source, des pilotes matériels, des composants de journalisation ou des modules d’aide au paramétrage. La norme IEC 62304 les désigne sous l’acronyme SOUP, pour Software of Unknown Provenance. Il ne s’agit pas nécessairement de logiciels inconnus ou douteux: le terme vise surtout les composants qui n’ont pas été développés selon le cycle de vie du fabricant du dispositif ou dont la documentation de développement n’est pas entièrement disponible.

Le traitement des SOUP est l’un des angles morts fréquents des dossiers techniques. Une bibliothèque largement utilisée n’est pas automatiquement sûre pour le dispositif considéré. Son comportement dépend de la version retenue, de sa configuration, de ses interfaces et de la manière dont le logiciel médical l’utilise. Un composant banal dans un outil bureautique peut devenir pertinent pour la sécurité s’il intervient dans l’affichage d’une valeur de traitement, la communication avec un module de puissance ou la gestion d’un état d’alarme.

Pour chaque composant SOUP, le fabricant doit pouvoir documenter:

• son identité précise, sa version, son fournisseur ou sa source et les conditions de licence applicables;
• sa fonction dans l’architecture du dispositif;
• les interfaces qu’il expose et les données qu’il reçoit ou transmet;
• les risques connus liés à son fonctionnement ou à ses limites;
• les vulnérabilités publiées et la manière dont elles sont surveillées;
• la stratégie de mise à jour, de correction et de retour à une version antérieure si nécessaire;
• les essais d’intégration réalisés dans la configuration effectivement mise sur le marché;
• les mesures prises lorsque le comportement du composant ne peut pas être entièrement caractérisé.

Une simple mention du type « le logiciel utilise la bibliothèque X, version Y » ne suffit généralement pas. Elle identifie le composant, mais ne démontre ni son intégration maîtrisée ni son influence sur les risques du dispositif. Le fabricant doit surtout montrer ce qu’il a vérifié lui-même. Il n’a pas à reproduire tout le cycle de développement du fournisseur du composant, mais il doit évaluer l’usage concret qu’il en fait et les conséquences d’un comportement inattendu.

La question des mises à jour est également centrale. Modifier une bibliothèque peut changer un format de données, un comportement aux limites, une gestion de mémoire ou une interface de communication. Même lorsqu’une mise à jour corrige une vulnérabilité, elle ne doit pas être introduite directement dans le produit sans analyse d’impact. La version corrigée doit être qualifiée dans son environnement réel, et les documents concernés — matrice de traçabilité, analyse de risques, rapport d’essai, dossier de configuration — doivent être actualisés.

Le cas des composants d’intelligence artificielle demande une vigilance supplémentaire lorsque ceux-ci interviennent dans l’aide au paramétrage ou dans l’interprétation d’une image. Le statut du composant ne dispense pas le fabricant de décrire ses entrées, ses sorties, ses limites d’utilisation, les conditions dans lesquelles il peut produire une recommandation erronée et le rôle laissé à l’utilisateur. Il faut aussi distinguer une fonction d’aide à la décision d’une fonction qui commande directement l’émission laser. Les conséquences réglementaires et la stratégie de maîtrise ne seront pas identiques.

Enfin, le dossier doit rester cohérent avec la cybersécurité. Une vulnérabilité dans un composant tiers n’est pas seulement un sujet informatique abstrait si elle peut modifier une commande, empêcher l’affichage d’une alarme ou perturber l’intégrité d’un historique de traitement. L’évaluation doit relier la menace au fonctionnement clinique du dispositif et aux mesures de protection effectivement déployées.

Articulation entre conformité logicielle et exigences du règlement MDR

Dernier point — et non des moindres —: la conformité à l’IEC 62304, à elle seule, ne donne pas le marquage CE. Une formule commerciale qui laisse entendre le contraire est au mieux incomplète. Le règlement MDR exige une évaluation globale du dispositif, qui croise les exigences générales de sécurité et de performance, la gestion des risques, les essais, l’évaluation clinique, la surveillance après commercialisation et le système de management de la qualité du fabricant.

L’IEC 62304 couvre le cycle de vie du logiciel. L’ISO 14971 encadre la gestion des risques. L’ISO 13485 concerne le système de management de la qualité. La série IEC 60601 peut s’appliquer à la sécurité électrique et à la compatibilité électromagnétique des équipements électromédicaux. Pour un laser, la série IEC 60825 intervient sur les aspects de sécurité liés au rayonnement laser. Selon la destination médicale et la configuration du produit, d’autres normes ou spécifications peuvent également entrer en jeu.

Il ne faut pas lire cette liste comme une collection de certificats indépendants. Le dossier technique doit montrer les relations entre ces référentiels. Une exigence de sécurité issue de l’analyse de risques peut conduire à une exigence logicielle. Cette exigence logicielle doit être mise en œuvre dans l’architecture, vérifiée par un essai approprié et reliée à la preuve de sécurité du système. Si la mesure de maîtrise dépend aussi d’un composant matériel ou d’un dispositif d’interverrouillage, la vérification doit couvrir l’interface entre les deux.

C’est cette articulation qui distingue un dossier réellement défendable d’un empilement de documents. Un rapport d’essais logiciel peut conclure que le logiciel réagit comme prévu dans les conditions testées. Il ne démontre pas, à lui seul, que le dispositif complet délivre l’énergie attendue, qu’il reste sûr en cas de défaut de communication, que l’utilisateur comprend les alarmes ou que les bénéfices cliniques sont suffisamment étayés.

L’organisme notifié cherchera donc à comprendre la cohérence d’ensemble. Il examinera notamment:

• la destination du dispositif et les fonctions logicielles qui contribuent à cette destination;
• les risques identifiés au niveau du système et leur traduction dans les exigences logicielles;
• les limites de fonctionnement et les conditions d’utilisation prévues;
• les interfaces entre le logiciel, la source laser, les capteurs, les commandes et les mécanismes de sécurité;
• la gestion des anomalies et des modifications;
• la validation du logiciel dans son environnement d’utilisation prévu;
• la cohérence entre la version évaluée, la version documentée et la version effectivement fournie.

La validation mérite ici d’être distinguée de la vérification. La vérification cherche à établir que le logiciel a été développé conformément à ses exigences spécifiées. La validation cherche à déterminer si le logiciel, dans son environnement prévu, répond bien aux besoins de l’utilisateur et à la destination médicale du dispositif. Dans un laser médical, cela peut impliquer des scénarios représentatifs d’utilisation, des essais avec les accessoires prévus, l’examen de l’ergonomie des commandes et l’évaluation de situations anormales pertinentes.

Un logiciel peut donc passer ses tests unitaires et d’intégration tout en restant insuffisamment validé pour l’usage clinique prévu. Une commande peut fonctionner conformément à sa spécification et se révéler ambiguë pour l’opérateur. Une alarme peut être déclenchée au bon moment mais présentée d’une manière qui ne permet pas une réaction appropriée. Ces questions ne sont pas périphériques: elles participent à la démonstration de sécurité et de performance du dispositif.

Le dossier technique doit également expliquer comment les modifications postérieures à la mise sur le marché sont évaluées. Une correction de vulnérabilité, l’ajout d’un protocole de traitement, la modification d’un écran ou le remplacement d’une bibliothèque peuvent avoir une portée très différente. Le fabricant doit disposer d’une méthode pour analyser l’impact de chaque changement, déterminer les essais nécessaires et décider si une nouvelle évaluation réglementaire ou une information de l’organisme notifié est requise.

C’est pourquoi la « conformité IEC 62304 » ne devrait jamais être présentée comme un état figé. Elle dépend d’un cycle de vie: maintenance, gestion de configuration, résolution des anomalies, surveillance des composants tiers et prise en compte des retours terrain. Le logiciel qui était correctement documenté lors de sa première mise sur le marché peut devenir plus difficile à défendre si les versions successives ne sont pas reliées aux analyses de risques et aux résultats d’essais.

La conformité du logiciel de laser médical ne se joue donc pas dans un document isolé. Elle se joue dans la capacité du fabricant à raconter, preuves à l’appui, l’histoire complète du produit: pourquoi la fonction existe, quel risque elle maîtrise, comment elle a été conçue, comment elle a été vérifiée, comment elle a été validée et comment elle sera maintenue.

Un audit interne mené avec la grille de l’IEC 62304 avant la soumission à l’organisme notifié permet de repérer les incohérences les plus coûteuses: classification non justifiée, exigences orphelines, tests sans lien clair avec les risques, composants tiers mal documentés ou version logicielle impossible à rattacher aux rapports d’essais. Il ne garantit pas l’absence de questions lors de l’évaluation, mais il évite de découvrir trop tard que les pièces du dossier ont été produites séparément sans véritable chaîne de preuve.

La conformité IEC 62304 d’un logiciel de laser médical n’est donc ni un argument marketing ni un ticket automatique vers le marquage CE. Elle repose sur trois décisions structurantes: classifier le logiciel à partir des risques du dispositif complet, maintenir une traçabilité bidirectionnelle entre exigences, architecture et essais, et traiter les composants SOUP comme des éléments intégrés à part entière dans la démonstration de sécurité.

La rigueur documentaire n’a rien d’un luxe administratif. Elle permet de savoir ce que le logiciel fait, ce qu’il ne fait pas, dans quelles limites il fonctionne et quelle réponse est prévue lorsqu’une hypothèse de conception cesse d’être valable. Pour un fabricant de laser médical, c’est cette maîtrise — renforcée, proportionnée et maintenue dans le temps — qui transforme une promesse de conformité en dossier réellement défendable.