IEC 81001-5-1 : par où commencer quand on a déjà 100k lignes de code

Votre organisme notifié vient de vous demander votre conformité à l’IEC 81001-5-1. Votre produit existe déjà, il est marqué CE ou en passe de l’être, et personne dans l’équipe n’a écrit une ligne de « threat model » de sa vie. Cet article décrit un plan de rattrapage réaliste, tel que je l’applique chez mes clients, sans réécrire le produit ni geler la roadmap.

Qu’est-ce que l’IEC 81001-5-1 ?

Définition : l’IEC 81001-5-1:2021 est la norme qui spécifie les activités de cybersécurité à intégrer dans le cycle de vie d’un logiciel de santé — de la conception à la fin de vie — pour garantir la sécurité, l’efficacité et la sûreté du produit. Elle est construite comme un miroir « sécurité » de l’IEC 62304 : là où la 62304 structure le développement logiciel, la 81001-5-1 y injecte les activités de sécurité (analyse de menaces, gestion des vulnérabilités, tests de sécurité, réponse aux incidents).

Concrètement, elle couvre huit processus : gestion de la sécurité, spécification des exigences de sécurité, conception sécurisée, implémentation, vérification et validation sécurité, gestion des défauts liés à la sécurité, gestion des mises à jour, et documentation/accompagnement des utilisateurs.

Pourquoi les organismes notifiés la réclament-ils maintenant ?

Le MDR exige depuis 2017 (annexe I, exigences 17.2 et 17.4) que le logiciel soit développé selon l’état de l’art en matière de sécurité de l’information. Le problème : « état de l’art » n’était pas défini. La guidance MDCG 2019-16 sur la cybersécurité a posé les attentes, puis l’IEC 81001-5-1 a été publiée fin 2021 et progressivement harmonisée comme référence. Résultat : depuis 2024, la plupart des organismes notifiés la citent explicitement dans leurs listes de questions, et en 2026 un dossier SaMD sans stratégie 81001-5-1 documentée repart quasi systématiquement avec une non-conformité.

Vous n’avez pas besoin de réécrire votre code. Vous avez besoin de prouver que vous savez ce qu’il contient et ce qui peut mal tourner.

La norme prévoit d’ailleurs explicitement ce cas dans son annexe dédiée au logiciel existant (legacy) : on n’exige pas de vous que le produit ait été développé sous 81001-5-1, mais que vous exécutiez un rattrapage documenté par analyse d’écart.

Le plan de rattrapage en 5 étapes

Étape 1 — Inventaire : générez votre SBOM

Impossible de sécuriser ce qu’on ne connaît pas. Commencez par un SBOM (Software Bill of Materials) exhaustif :

• Générez un SBOM au format CycloneDX depuis vos lockfiles (package-lock.json, poetry.lock, go.sum…) — des outils comme cyclonedx-cli, Syft ou Trivy le font en une commande.
• Incluez les dépendances transitives, les images de base Docker, les runtimes.
• Rapprochez ce SBOM de votre liste SOUP au sens 62304 : chaque composant SOUP doit avoir ses exigences fonctionnelles et ses anomalies connues documentées.

Comptez une à deux journées pour un premier SBOM propre. C’est le meilleur ratio effort/valeur de tout le plan.

Étape 2 — Threat model : une demi-journée, pas un mois

Un threat model n’est pas une thèse. Pour un SaMD typique (app + API + base de données) :

1. Dessinez le diagramme de flux de données : acteurs, composants, frontières de confiance.
2. Passez chaque flux au crible STRIDE (usurpation, altération, répudiation, divulgation, déni de service, élévation de privilèges).
3. Priorisez : quelles menaces ont un impact patient ou sur des données de santé ?
4. Reliez chaque menace retenue à une mesure existante ou à un ticket.

Faites-le en atelier avec le tech lead et une personne qualité. Une demi-journée suffit pour une première version exploitable — et auditable.

Étape 3 — Gestion des vulnérabilités : un processus, pas un outil

L’organisme notifié veut voir un processus vivant :

• Veille : scan automatique du SBOM contre les bases de vulnérabilités (Dependabot, Renovate, Trivy, OSV) à chaque build et au minimum chaque semaine.
• Triage : une règle écrite qui dit qui évalue, sous quel délai, et comment on décide si une CVE est exploitable dans votre contexte d’utilisation.
• Lien avec le risque : toute vulnérabilité exploitable avec impact patient entre dans le dossier de gestion des risques ISO 14971.
• Trace : chaque décision (corriger, accepter, non applicable) est justifiée et archivée.

Étape 4 — Tests de sécurité proportionnés

Pas besoin d’une red team. Le socle attendu :

Documentez les résultats et surtout le traitement des findings : un rapport de pentest sans plan d’action est une pièce à charge, pas une preuve.

Étape 5 — Documentez les activités, pas des romans

La 81001-5-1 demande des enregistrements, pas de la littérature. Un plan de sécurité de 10 pages qui référence vos outils réels vaut mieux qu’un classeur de 80 pages copié d’un template. Contenu minimal : rôles et responsabilités, processus de gestion des vulnérabilités, threat model, résultats de tests, politique de mise à jour et de fin de vie, et l’analyse d’écart legacy qui justifie votre rattrapage.

Les erreurs classiques

• Acheter un template et le remplir sans l’exécuter. Les auditeurs demandent maintenant des preuves d’exécution : montrez un ticket de CVE triée, pas une procédure théorique.
• Traiter le SBOM comme un livrable ponctuel. Il doit être régénéré à chaque release, automatiquement.
• Confondre sûreté et sécurité. L’ISO 14971 couvre le risque patient ; la 81001-5-1 couvre la menace intentionnelle. Les deux dossiers doivent se référencer mutuellement.
• Tout faire porter par la qualité. Sans le tech lead dans la boucle, le threat model sera faux et les développeurs ne suivront pas.

Comment ça s’articule avec l’IEC 62304 et le MDR ?

Retenez la chaîne : le MDR exige la sécurité selon l’état de l’art → l’IEC 81001-5-1 définit les activités de sécurité qui constituent cet état de l’art → l’IEC 62304 fournit le cycle de vie dans lequel ces activités s’insèrent. Si votre documentation 62304 est propre, la 81001-5-1 s’y greffe : mêmes revues, mêmes releases, mêmes enregistrements, avec une dimension sécurité en plus. Si elle ne l’est pas, commencez par là — c’est le sujet d’un autre article.

En pratique, pour une équipe de 5 à 10 développeurs avec un produit existant, ce rattrapage se mène en deux à trois mois en parallèle de la roadmap. L’essentiel est de démarrer par l’inventaire : tout le reste en découle.