Matériovigilance et surveillance après commercialisation d'un logiciel

C’est l’obligation qui survit à la mise sur le marché, et celle que les équipes préparent le moins — sans doute parce qu’elle commence quand tout le monde pense avoir terminé.

Deux niveaux à ne pas confondre

La vigilance — la matériovigilance pour les dispositifs médicaux — est le signalement des incidents graves aux autorités compétentes. C’est un dispositif réactif, déclenché par un événement.

La surveillance après commercialisation est plus large : un processus continu, planifié et proportionné, de collecte et d’analyse de l’expérience acquise sur les dispositifs mis sur le marché.

Beaucoup d’organisations réduisent la seconde à la première : elles disposent d’une procédure de signalement et considèrent le sujet traité. C’est l’écart le plus fréquemment relevé en audit.

Ce que la surveillance doit produire

Le point essentiel est qu’elle n’est pas une fin en soi : ses résultats alimentent en retour la gestion des risques, l’évaluation clinique et, le cas échéant, des actions correctives.

Autrement dit, une surveillance qui produit des rapports que personne ne réinjecte dans l’analyse de risques ne remplit pas son office, quelle que soit la qualité des rapports.

Ce que cela impose dans le produit

C’est ici que le sujet devient technique, et qu’il concerne l’équipe de développement.

Instrumenter ce qui compte. La surveillance doit porter sur les risques identifiés. Si votre analyse de risques retient qu’une alerte non déclenchée est un danger majeur, votre produit doit permettre de savoir si des alertes n’ont pas été déclenchées. Cela ne s’improvise pas après coup.

Distinguer les signaux du bruit. Une application produit des milliers d’événements techniques. Sans lien explicite entre ces événements et les risques, on obtient un volume ingérable dans lequel les signaux réels se perdent.

Tracer le circuit de qualification. Qui reçoit un signalement, qui décide s’il constitue un incident, sur quels critères, dans quels délais. Ce circuit doit être documenté et suivi — et il doit fonctionner un dimanche soir.

Relier le support à la vigilance. Le canal support est la première source de signaux. S’il vit dans un outil séparé, sans passerelle vers la qualification, les signaux faibles n’arriveront jamais.

Le cas particulier du logiciel

Un logiciel a une propriété que n’ont pas les dispositifs physiques : il change souvent. Chaque déploiement modifie le dispositif surveillé.

Cela impose deux disciplines : savoir quelle version était en service au moment d’un événement, et évaluer chaque modification quant à son impact sur la sécurité et les performances. Sans versionnement traçable côté production, la surveillance perd sa signification.

Par où commencer

Construire le plan de surveillance à partir de l’analyse de risques, pas à partir d’un modèle. Pour chaque risque significatif : quel indicateur permettrait de détecter qu’il se matérialise, comment le collecter, à quelle fréquence l’examiner, et qui en est responsable.

Un plan de dix lignes réellement adossé aux risques vaut mieux qu’un document générique de trente pages — et c’est exactement ce que constate un évaluateur.