Auto-scan conformité : les 20 questions qu’un organisme notifié posera en premier

Cette checklist reprend les questions qu’un auditeur d’organisme notifié pose en priorité lors d’une première évaluation d’un logiciel dispositif médical. Elle est conçue pour une auto-évaluation en une quinzaine de minutes.

Le principe de scoring est simple. Pour chaque question, répondez honnêtement :

• Oui (1 point) : l’élément existe, est documenté et vous pouvez le montrer en moins de cinq minutes.
• Partiel (0,5 point) : l’élément existe dans les têtes ou dans un document obsolète, mais ne résisterait pas à un audit.
• Non (0 point) : l’élément n’existe pas.

Le critère « montrable en cinq minutes » n’est pas anecdotique : en audit réel, une preuve introuvable équivaut à une preuve inexistante.

Stratégie et classification

1. Avez-vous formalisé par écrit l’usage revendiqué (intended use) de votre logiciel ? L’auditeur cherche un document unique, daté et approuvé, décrivant la finalité médicale, la population de patients, les utilisateurs visés et le contexte d’utilisation. Le piège classique : un intended use qui existe en plusieurs versions contradictoires entre le site web, le pitch commercial et le dossier technique — l’auditeur comparera.

2. Avez-vous documenté la qualification de votre logiciel comme dispositif médical (ou non) ? Il s’agit d’une analyse argumentée, appuyée sur le MDCG 2019-11, concluant que le logiciel est ou n’est pas un dispositif médical. Le piège : les entreprises qui « décident » que leur produit n’est pas un DM sans analyse écrite, alors que la revendication marketing (aide au diagnostic, alerte clinique) dit le contraire.

3. Avez-vous déterminé et justifié la classe de risque selon la règle 11 du MDR ? L’auditeur attend un raisonnement de classification explicite : quelle règle s’applique, pourquoi, et quelle classe en résulte. Le piège : viser la classe I par optimisme alors que la règle 11 place en IIa minimum tout logiciel dont les informations servent à des décisions diagnostiques ou thérapeutiques.

4. Avez-vous une stratégie réglementaire écrite couvrant vos marchés cibles ? Un document qui liste les marchés visés (UE, États-Unis, autres), les voies d’accès correspondantes (marquage CE, 510(k)) et le séquencement. Le piège : découvrir après la levée de fonds que le calendrier d’accès à un organisme notifié se compte en mois et n’a jamais été intégré à la roadmap produit.

Système qualité

5. Disposez-vous d’un QMS documenté et réellement appliqué, aligné sur l’ISO 13485 ? L’auditeur ne cherche pas un classeur de procédures achetées sur étagère, mais des processus que les équipes utilisent : il croisera les procédures avec les enregistrements réels. Le piège : le QMS « de façade » rédigé en quelques semaines avant l’audit, trahi par des enregistrements inexistants ou tous datés du même mois.

6. La responsabilité réglementaire est-elle clairement attribuée dans l’organisation ? Le MDR exige une personne chargée de veiller au respect de la réglementation (PRRC), et l’auditeur vérifiera que cette personne a la qualification et l’autorité réelles. Le piège : nommer un PRRC sur le papier sans lui donner ni temps ni pouvoir de blocage sur les livraisons.

7. Maîtrisez-vous vos documents et enregistrements (versions, approbations, archivage) ? Toute procédure et tout enregistrement doit avoir une version, un auteur, un approbateur et une date, avec un historique des modifications. Le piège : des documents de travail sur un drive partagé, modifiables par tous, sans état approuvé identifiable — l’auditeur y verra une perte de maîtrise documentaire globale.

8. Vos fournisseurs et sous-traitants critiques sont-ils évalués et surveillés ? Hébergeur cloud, prestataires de développement, fournisseurs de composants : l’auditeur attend des critères de sélection, des accords qualité et une surveillance périodique. Le piège : l’externalisation du développement sans accord qualité, qui laisse le fabricant responsable d’un cycle de vie qu’il ne maîtrise pas.

Cycle de vie logiciel — IEC 62304

9. Avez-vous attribué et justifié une classe de sécurité logicielle (A, B ou C) ? La classe doit découler de l’analyse de risque : quel dommage une défaillance du logiciel peut-elle causer ? Le piège : choisir la classe A par défaut pour alléger la documentation, sans justification écrite — c’est l’un des premiers points que l’auditeur attaque.

10. Votre plan de développement logiciel est-il documenté et suivi ? L’IEC 62304 exige un plan couvrant les activités, les livrables, les outils et les responsabilités du cycle de vie. Le piège : un plan générique jamais mis à jour, en contradiction avec la pratique réelle de l’équipe (outils différents, étapes sautées).

11. Vos exigences logicielles sont-elles documentées et tracées jusqu’aux tests ? Chaque exigence doit être identifiable, vérifiable et couverte par au moins un test, avec une matrice de traçabilité navigable dans les deux sens. Le piège : des user stories fermées dans l’outil de ticketing qui tiennent lieu d’exigences, sans lien exploitable vers les résultats de vérification.

12. Votre architecture logicielle est-elle documentée, avec la ségrégation des éléments critiques ? L’auditeur veut comprendre le découpage en éléments logiciels, les interfaces, et comment les éléments de classe supérieure sont ségrégués du reste. Le piège : un schéma d’architecture marketing qui ne correspond ni au code réel ni aux classes de sécurité attribuées.

13. Vos SOUP (composants tiers) sont-ils inventoriés et évalués ? Chaque bibliothèque, framework ou OS intégré doit être listé avec sa version, ses exigences et une évaluation de ses anomalies connues. Le piège : l’inventaire manuel obsolète dès la sprint suivante — sans génération automatisée depuis le gestionnaire de dépendances, la liste est fausse le jour de l’audit.

14. Votre processus de gestion des anomalies et des modifications est-il formalisé ? Toute anomalie doit être enregistrée, évaluée au regard de la sécurité, et toute modification doit passer par une analyse d’impact avant implémentation. Le piège : des hotfixes poussés en production sans analyse d’impact ni mise à jour de la documentation de risque.

15. Vos activités de vérification sont-elles documentées avec des critères d’acceptation définis à l’avance ? L’auditeur attend des plans de tests, des critères de succès définis avant exécution, et des rapports de résultats archivés par version. Le piège : une CI verte présentée comme seule preuve — sans lien entre les tests exécutés, les exigences couvertes et une revue des résultats, la vérification n’est pas démontrée.

Gestion des risques — ISO 14971

16. Disposez-vous d’un dossier de gestion des risques vivant, conforme à l’ISO 14971 ? Plan de gestion des risques, analyse, évaluation, maîtrise et évaluation du risque résiduel global doivent exister et être tenus à jour à chaque évolution du produit. Le piège : le dossier de risque rédigé une fois avant la certification puis jamais rouvert, alors que le logiciel a connu vingt releases depuis.

17. Vos mesures de maîtrise des risques sont-elles implémentées et vérifiées ? Chaque mesure décidée dans l’analyse de risque doit être tracée jusqu’à son implémentation dans le code et jusqu’au test qui prouve son efficacité. Le piège : des mesures « déclarées » dans le dossier de risque, introuvables dans les exigences logicielles et donc jamais vérifiées.

18. Les erreurs d’utilisation sont-elles couvertes par votre analyse de risque ? L’auditeur vérifie que l’analyse ne se limite pas aux défaillances techniques : mauvaise interprétation d’un résultat, saisie erronée, contournement d’une alerte relèvent de l’ingénierie de l’utilisabilité (IEC 62366-1). Le piège : considérer que l’UX est un sujet produit et non un sujet de sécurité, et n’avoir aucune donnée d’évaluation de l’utilisabilité.

Cybersécurité

19. Avez-vous un threat model et une analyse de risque cybersécurité articulée avec l’ISO 14971 ? L’auditeur attend une identification structurée des surfaces d’attaque et des scénarios de menace, dont les conséquences cliniques sont évaluées dans le processus de gestion des risques. Le piège : un pentest annuel présenté comme seule démarche de sécurité — un test ponctuel ne remplace ni le threat model ni le processus de conception sécurisée exigé par l’IEC 81001-5-1.

20. Pouvez-vous produire une SBOM à jour et gérez-vous les vulnérabilités en continu ? Une SBOM générée automatiquement à chaque build, une veille sur les CVE affectant vos composants, et un processus de qualification et de correction avec des délais définis. Le piège : la SBOM générée une fois pour un dossier puis oubliée, alors que la FDA (§524B) comme les organismes notifiés attendent un processus de gestion des vulnérabilités continu et démontrable.

Interprétation de votre score

0 à 10 points — Fondations à construire. Votre produit est exposé : en l’état, un audit se solderait par des non-conformités majeures, et une mise sur le marché conforme n’est pas atteignable sans un chantier structurant. La bonne nouvelle : partir tôt d’une feuille quasi blanche permet de construire un système proportionné, sans dette documentaire à rattraper. Priorisez la qualification, la classification et la mise en place du socle QMS.

11 à 16 points — Structuration en cours. Le socle existe, mais les écarts restants sont exactement ceux qu’un auditeur relève : traçabilité incomplète, dossier de risque non tenu à jour, cybersécurité traitée en périphérie. Un audit à blanc ciblé sur vos points « partiel » est le meilleur investissement à ce stade : il transforme une liste d’intuitions en plan d’action priorisé.

17 à 20 points — Maturité d’audit. Votre système est proche de l’état attendu par un organisme notifié. Le travail restant porte sur la robustesse des preuves : cohérence entre les documents, fraîcheur des enregistrements, capacité des équipes à répondre en entretien. À ce niveau, la préparation consiste à répéter l’exercice de l’audit, pas à produire de nouveaux documents.