Documentation technique d'un logiciel dispositif médical

Le dossier technique est le document qui décide de l’issue d’une évaluation, et celui que les équipes logicielles abordent avec le plus de contresens : elles le voient comme une rédaction, alors que c’est une collecte.

Ce qu’il doit contenir

Les annexes du règlement (UE) 2017/745 en fixent la structure. Pour un logiciel, les blocs déterminants sont :

La description du dispositif et sa destination. La destination revendiquée, la population cible, les indications, les contre-indications, l’environnement d’utilisation. C’est la pièce dont découle tout le reste, y compris la classification.

Les spécifications, et leur traçabilité jusqu’à la conception.

Les résultats de vérification et de validation. Preuves de tests, couverture, résultats, anomalies traitées. C’est le bloc le plus volumineux pour un logiciel.

La gestion des risques, selon l’ISO 14971, avec l’analyse, les mesures de maîtrise et les risques résiduels justifiés.

L’évaluation clinique et son plan de suivi.

Le plan de surveillance après commercialisation, et le dispositif de vigilance associé.

Les éléments propres au logiciel : architecture, classe de sécurité IEC 62304 et sa justification, inventaire et maîtrise des composants d’origine externe, cybersécurité, aptitude à l’utilisation.

Pourquoi il ne se rédige pas après coup

Chacun de ces blocs consigne une activité datée. Une vérification a eu lieu à un moment, sur une version, contre une exigence. Une décision de conception a été prise pour une raison.

Reconstituer ces éléments a posteriori produit un document qui a la forme d’un dossier technique sans en avoir la substance — et cela se voit. Un évaluateur qui constate que toutes les preuves de vérification portent la même date, ou que les décisions de conception sont formulées au passé sans traces contemporaines, en tire les conclusions qui s’imposent.

Les quatre non-conformités les plus fréquentes sur les logiciels

Traçabilité incomplète. Des exigences sans risque associé, des risques sans mesure de maîtrise vérifiée, des tests orphelins. C’est le premier point vérifié, parce qu’il révèle en quelques minutes si le processus a été suivi.

Justification insuffisante de la classe de sécurité IEC 62304. Une classe A annoncée sans démonstration que les mesures de maîtrise extérieures au logiciel rendent une défaillance sans conséquence.

Maîtrise des composants externes non démontrée. Pas d’inventaire, pas de justification d’usage, pas de suivi des anomalies publiées. Sur une application moderne, c’est un chantier réel qui suppose un outillage.

Plan de surveillance générique. Un plan copié d’un modèle, sans lien avec les risques identifiés ni avec les questions ouvertes de l’évaluation clinique.

La bonne façon de s’organiser

Faire produire le dossier par le processus de développement, pas à côté de lui. Concrètement : tracer exigences, risques, tests et revues dans les outils que l’équipe utilise déjà, et générer les vues documentaires à partir de là.

Cela demande un investissement d’outillage au démarrage. Il est sans commune mesure avec le coût d’un exercice de reconstitution — et c’est la seule approche qui reste tenable quand le produit évolue.