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, mais il obéit à une méthode précise, celle de la matrice de risques. 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.

Cinq étapes pour huit processus : est-ce que ça couvre ?

C’est la question que pose tout lecteur attentif, et la réponse honnête est non, pas entièrement — et c’est voulu. Un plan de rattrapage traite ce qui se rattrape sur un produit déjà écrit. Deux processus de la norme échappent par nature à cet exercice : ils ne se rattrapent pas, ils s’appliquent à ce que vous construirez ensuite.

Les deux lignes marquées « non rattrapable » sont celles qui inquiètent le plus les équipes, et à tort. Personne ne vous demandera de prouver que du code écrit en 2022 l’a été sous un processus de conception sécurisée qui n’existait pas chez vous. Ce qu’on attend, c’est que votre analyse d’écart les constate honnêtement et engage la suite : à partir de quand vos revues de conception intègrent la sécurité, à partir de quelle version vos revues de code la couvrent.

C’est exactement le rôle de l’analyse d’écart legacy. Elle n’est pas un aveu de faiblesse, c’est le document qui transforme un retard en trajectoire — et c’est la première chose qu’un organisme notifié ouvre.

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.

FAQ

L’IEC 81001-5-1 est-elle obligatoire ?

Pas au sens où une loi la nommerait. Ce qui est opposable, ce sont les exigences 17.2 et 17.4 de l’annexe I du MDR, qui imposent un développement selon l’état de l’art en sécurité de l’information sans dire lequel. L’IEC 81001-5-1 est la norme qui définit cet état de l’art, et la guidance MDCG 2019-16 la cite comme moyen de conformité. En pratique la distinction est théorique : un organisme notifié vous demandera votre stratégie 81001-5-1, et un dossier sans rien de documenté repart avec une non-conformité.

Quelle différence avec l’IEC 62304 ?

Elles ne traitent pas du même risque. L’IEC 62304 structure le cycle de vie du logiciel et couvre la défaillance — ce qui casse tout seul. L’IEC 81001-5-1 y ajoute les activités de sécurité et couvre la menace intentionnelle — ce qu’un adversaire provoque. Elles ne se remplacent pas et ne se dupliquent pas : la 81001-5-1 se greffe sur le cycle de vie 62304, avec les mêmes revues et les mêmes enregistrements. Si votre documentation 62304 n’est pas propre, c’est par là qu’il faut commencer.

S’applique-t-elle à un logiciel déjà développé ?

Oui, et la norme prévoit explicitement ce cas dans son annexe dédiée au logiciel existant. On ne vous demande pas d’avoir développé le produit sous 81001-5-1 — ce serait absurde pour un dispositif déjà sur le marché — mais de conduire un rattrapage documenté par analyse d’écart. C’est ce document qui justifie votre trajectoire : il constate ce qui manque, et engage un plan. Sans lui, votre rattrapage ressemble à des activités éparses ; avec lui, c’est une démarche.