IEC 62304 : structurer le cycle de vie d'un logiciel médical

L’IEC 62304 est la norme qui contraint le plus directement l’organisation d’une équipe de développement. Elle ne parle ni du produit ni du marché : elle parle de la façon dont vous fabriquez.

Les trois classes de sécurité

La norme classe le logiciel selon la gravité des conséquences d’une défaillance :

Classe	Conséquence d’une défaillance
A	Aucune blessure ni atteinte à la santé n’est possible
B	Une blessure non grave est possible
C	Le décès ou une blessure grave est possible

Plus la classe est élevée, plus le cycle de vie à mettre en œuvre est complet : la norme module les activités exigées en fonction d’elle.

Point capital : ces classes sont indépendantes des classes du dispositif au sens du règlement. Un dispositif de classe IIa peut contenir un logiciel de classe A si des mesures de maîtrise du risque extérieures au logiciel rendent une défaillance sans conséquence. C’est précisément ce raisonnement — et sa documentation — que l’organisme notifié examinera.

Ce que la norme exige, par grands blocs

Un plan de développement logiciel. Défini avant, pas reconstitué après.

Une analyse des exigences logicielles, tracées et vérifiables.

Une architecture logicielle documentée, avec une décomposition en éléments — cette décomposition est ce qui permet d’attribuer des classes de sécurité différenciées à différentes parties du logiciel, et donc de concentrer l’effort là où il compte.

La conception détaillée, exigée à partir de la classe C.

L’implémentation et la vérification, avec des preuves de couverture.

L’intégration et les tests système, planifiés et tracés.

La libération du logiciel, avec les critères associés.

À quoi s’ajoutent des processus continus : gestion des configurations, résolution des anomalies, gestion des modifications, et maintenance.

Les SOUP : le point de non-conformité le plus fréquent

La norme traite spécifiquement des SOUP — software of unknown provenance, les logiciels d’origine externe ou déjà développés que vous intégrez sans maîtriser leur processus de développement. Autrement dit : toutes vos dépendances.

Elle impose de les identifier, de justifier leur usage, de spécifier les exigences fonctionnelles et de performance que vous en attendez, et de suivre les anomalies publiées les concernant.

Pour une application moderne comptant des centaines de dépendances transitives, c’est un chantier réel qui suppose un outillage — inventaire logiciel, suivi de vulnérabilités, politique de mise à jour. C’est aussi le point sur lequel les équipes logicielles sont le plus souvent prises en défaut, parce que la pratique courante du développement est exactement l’inverse : intégrer vite, sans inventaire.

Agile et IEC 62304

La norme ne prescrit aucun modèle de cycle de vie. Elle définit des processus et des activités. Un développement itératif est parfaitement admissible dès lors que, à chaque itération, les activités requises par la classe de sécurité sont réalisées et documentées.

La difficulté n’est donc pas méthodologique, elle est outillée. Une équipe qui trace ses exigences, ses tests et ses décisions dans ses outils quotidiens satisfait la norme presque naturellement. Une équipe qui maintient une documentation séparée finit par produire deux réalités divergentes.

L’erreur de séquencement fatale

L’IEC 62304 porte sur le cycle de vie. Elle exige des traces d’activités qui doivent avoir eu lieu au bon moment : la conception avant l’implémentation, la vérification après, les décisions consignées quand elles sont prises.

Un logiciel développé pendant deux ans sans ces traces ne peut pas les produire rétroactivement de manière crédible. Il faut alors soit reprendre le processus sur une nouvelle version, soit conduire un exercice de reconstitution long, coûteux et fragile en audit.

C’est la raison pour laquelle la question du statut de dispositif médical doit être tranchée avant le premier sprint : ce n’est pas la conformité qui est chère, c’est la conformité rétroactive.