ISO 14971 : la gestion des risques d'un logiciel médical

Si l’on ne devait retenir qu’un seul document du dossier réglementaire d’un logiciel médical, ce serait l’analyse de risques. C’est le seul qui influence à la fois la classification, l’architecture, l’effort d’ingénierie et l’argumentaire clinique.

Le processus en cinq temps

1. Identifier les dangers. Pour un logiciel, ils sont rarement du type « le code plante ». Ils sont plutôt : une valeur affichée est erronée, une alerte n’est pas déclenchée, une alerte est déclenchée à tort, une donnée est attribuée au mauvais patient, une information est affichée de façon ambiguë en situation d’urgence.

2. Estimer le risque, en combinant gravité et probabilité d’occurrence du dommage.

3. Maîtriser le risque, par la conception d’abord, par des mesures de protection ensuite, par l’information de l’utilisateur en dernier recours — cet ordre de préséance est une exigence, pas une préférence.

4. Évaluer le risque résiduel, individuellement puis globalement, au regard des bénéfices attendus.

5. Alimenter le processus en continu avec les données issues de la production et de la surveillance après commercialisation.

Pourquoi elle irrigue tout le reste

Elle justifie la classification. Le passage de la classe IIa à IIb ou III selon la règle 11 repose sur la gravité des conséquences possibles. Cette appréciation ne peut pas venir d’ailleurs que de l’analyse de risques.

Elle détermine la classe de sécurité IEC 62304. Celle-ci s’établit à partir des conséquences d’une défaillance, en tenant compte des mesures de maîtrise extérieures au logiciel.

Elle oriente l’architecture. Isoler un composant critique, ajouter une vérification indépendante, contraindre une saisie : ce sont des décisions d’architecture qui découlent de la maîtrise du risque. C’est pourquoi une analyse produite tardivement perd l’essentiel de sa valeur — elle constate au lieu d’orienter.

Elle fonde l’argumentaire bénéfice/risque du dossier technique et de l’évaluation clinique.

Les erreurs qui se repèrent immédiatement en audit

L’analyse générique. Un tableau de dangers qui pourrait s’appliquer à n’importe quel logiciel de santé signale que l’exercice n’a pas été fait à partir de l’usage clinique réel. C’est le défaut le plus courant et le plus visible.

La confusion avec la sécurité de l’information. Traiter les risques de fuite de données à la place des risques pour le patient. Les deux analyses sont nécessaires, distinctes, et articulées.

Les probabilités inventées. Attribuer une probabilité chiffrée à une défaillance logicielle sans base de calcul affaiblit le dossier plutôt qu’il ne le renforce. Mieux vaut raisonner sur la gravité et la détectabilité, et le justifier.

L’oubli des risques liés à l’utilisation. Une part importante des dommages réels vient de l’interface : information mal comprise, mauvais patient sélectionné, action irréversible trop accessible. Ces risques relèvent aussi de l’ISO 14971, en lien avec l’aptitude à l’utilisation.

L’analyse figée. Une analyse de risques qui n’a pas bougé depuis dix-huit mois, alors que le produit a évolué et que des retours terrain sont arrivés, démontre l’absence de processus.

Le bon niveau d’effort

L’analyse de risques est le seul document réglementaire dont la qualité améliore réellement le produit. Une équipe qui la mène sérieusement identifie des scénarios d’usage qu’elle n’avait pas anticipés, et corrige des choix d’interface avant qu’ils ne causent des incidents.

C’est aussi pour cette raison qu’elle ne doit pas être sous-traitée en bloc : elle suppose une connaissance fine de l’usage clinique et du fonctionnement interne du logiciel. Un tiers peut structurer la méthode, animer l’exercice et challenger les conclusions — il ne peut pas se substituer à l’équipe.