Le dossier technique MDR d'un logiciel : la structure attendue par l'organisme notifié

Le dossier technique est le livrable qui matérialise votre conformité : c’est lui que l’organisme notifié ouvre en premier, et c’est sur sa cohérence que se joue une bonne partie de l’audit. Pour un logiciel dispositif médical (SaMD), il est souvent sous-estimé — vu comme une formalité de fin de projet plutôt que comme la colonne vertébrale documentaire du produit. Voici ce qu’attend réellement l’annexe II du MDR, et comment l’organiser pour un logiciel.

Qu’est-ce que le dossier technique au sens des annexes II et III du MDR ?

Définition : le dossier technique est l’ensemble structuré des documents par lesquels le fabricant démontre la conformité de son dispositif aux exigences générales de sécurité et de performance (annexe I du MDR). L’annexe II décrit le contenu de cette documentation technique ; l’annexe III la complète sur le volet surveillance après commercialisation.

Deux idées à retenir. D’abord, ce n’est pas un document mais un dossier : un ensemble cohérent où chaque affirmation renvoie à une preuve. Ensuite, il est vivant : il évolue avec le produit et doit rester à jour tant que le dispositif est sur le marché.

Quelle structure pour un logiciel dispositif médical ?

L’annexe II fixe les rubriques ; à vous de les instancier pour un logiciel. Les grands blocs :

• Description et destination : ce que fait le logiciel, pour qui, dans quel contexte clinique — l’intended use, formulé de façon exacte et cohérente avec votre communication.
• Exigences générales de sécurité et de performance (GSPR) : la checklist de l’annexe I, chaque exigence marquée applicable/non applicable, avec le renvoi vers la preuve.
• Conception et développement : le cycle de vie logiciel au sens de l’IEC 62304 — architecture, exigences, unités, intégration, gestion des SOUP.
• Gestion des risques : le dossier ISO 14971, relié aux fonctions réelles du logiciel (pas un tableau générique).
• Vérification et validation : plans et rapports de tests, traçabilité exigences → tests.
• Évaluation clinique : la démonstration du bénéfice clinique et de la performance revendiquée.
• Cybersécurité : exigences 17.2 et 17.4 de l’annexe I, en pratique adressées via l’IEC 81001-5-1.
• Surveillance après commercialisation (annexe III) : plan de PMS et, le cas échéant, PMCF.

Le fil conducteur qu’un auditeur suit du regard : la traçabilité.

Les erreurs qui font caler un audit

Ce ne sont presque jamais des trous béants, plutôt des incohérences que l’auditeur déroule :

• Un intended use flou ou incohérent avec le marketing. Si votre site vend une « aide au diagnostic » mais que le dossier revendique un simple outil de visualisation, la contradiction se paie.
• Une traçabilité absente : des exigences qui ne descendent pas jusqu’au code et aux tests, ou des tests qui ne remontent à aucune exigence.
• Une gestion des risques déconnectée du logiciel réel : un tableau ISO 14971 générique, sans lien avec les fonctions et les défaillances effectivement possibles.
• Une cybersécurité traitée en annexe plutôt que par conception : pas d’analyse de menaces, pas de SBOM, pas de plan de gestion des vulnérabilités.
• Un dossier détaché du système qualité : le dossier technique prouve la conformité d’un dispositif ; il doit s’appuyer sur un SMQ ISO 13485 qui décrit comment vous travaillez.

Pour auto-évaluer votre dossier avant l’audit : la checklist des 20 questions d’un organisme notifié.

Un bon dossier technique ne se rédige pas à la fin : il se génère au fil du développement. Ce qui est tracé au fur et à mesure ne se reconstitue pas sous la pression de l’audit.

Combien de temps pour le constituer ?

Comptez en trimestres, pas en semaines — et la durée dépend surtout de votre point de départ. Trois facteurs pèsent : la classe du dispositif (le niveau d’exigence monte avec la classe), la maturité de votre SMQ, et la dette documentaire accumulée (du code existant sans traçabilité est le cas le plus coûteux à rattraper). Le levier qui change tout : constituer le dossier pendant le développement plutôt qu’après, en générant les artefacts depuis vos outils d’ingénierie.

FAQ

Faut-il un organisme notifié pour toutes les classes ?

Non. En Classe I autodéclarée, le fabricant établit lui-même sa déclaration de conformité sans organisme notifié (des cas particuliers — I stérile, avec fonction de mesure, réutilisable — font exception). Dès la Classe IIa, l’intervention d’un organisme notifié devient obligatoire. Or, sous la règle 11 du MDR, la plupart des SaMD sont au moins en IIa.

Peut-on réutiliser la documentation générée par la CI/CD ?

Oui, et c’est même la bonne approche. Traçabilité, rapports de tests, SBOM et journaux de release produits par votre pipeline peuvent alimenter directement les artefacts IEC 62304 du dossier — à condition d’être structurés dans ce but.

Dossier technique et SMQ ISO 13485 : quelle différence ?

Le SMQ décrit comment vous concevez et maintenez vos dispositifs (vos processus). Le dossier technique rassemble les preuves de conformité d’un dispositif donné. Ils sont distincts mais indissociables : un dossier solide s’appuie sur des processus qui produisent naturellement ses preuves.

Un dossier à cadrer ou à auditer ? Réservez un appel — on identifie ensemble les trois prochains risques à traiter.