En bref
Les logiciels médicaux intègrent de plus en plus de composants tiers (SOUP), tandis que les attentes en matière de cybersécurité et de transparence de la chaîne logicielle (SBOM) se renforcent, notamment avec le Cyber Resilience Act (CRA) européen. Pour beaucoup de fabricants de dispositifs médicaux (DM), le sujet n’est pas seulement le SaMD marqué CE : une app wellness, un portail patient ou un SDK vendu à part peut relever du CRA alors que le DM reste sous MDR. Deux réglementations, un même dépôt Git, une seule équipe produit.
Ce guide propose une approche pratique : inventaire, classification, preuves et routines d’équipe, plus une lecture produit par produit du CRA et du portefeuille mixte DM + wellness. L’objectif est d’opérationnaliser SOUP et SBOM dans votre flux existant, avec une couche de conformité qui s’appuie sur vos outils plutôt qu’une migration ALM forcée. Ce texte ne remplace pas le CRA, IEC 62304 ni IEC 81001-5-1 ; vérifiez toujours les textes officiels pour vos obligations.
SOUP : de quoi parle-t-on ?
SOUP (Software of Unknown Provenance) désigne, dans le cadre de l’IEC 62304, un logiciel déjà développé et disponible, ou un logiciel précédemment développé, pour lequel le fabricant ne dispose pas des éléments suffisants permettant de démontrer que son développement a été réalisé selon le cycle de vie logiciel applicable au dispositif. Bibliothèques open source, SDK, middleware, runtimes, composants cloud : beaucoup d’éléments du produit SaMD tombent dans cette catégorie ou dans des notions proches (OTS, dépendances tierces).
Le point critique n’est pas le label « SOUP » lui-même, mais la maîtrise du risque : tous les SOUP doivent être identifiés et maîtrisés, avec une profondeur d’évaluation proportionnée au risque. Team-NB demande également la vérification des SOUP et la surveillance continue de leurs vulnérabilités. Sans inventaire fiable, impossible de démontrer cette maîtrise lors d’un audit ou d’une revue de conception. Pour un mapping opérationnel dans des outils courants, voir IEC 62304 avec Jira et GitHub.
Périmètre de ce guide
Ce texte ne remplace pas IEC 62304, IEC 81001-5-1 ni le règlement CRA. Pour les obligations juridiques et les dates d’application, vérifiez toujours les textes officiels et, le cas échéant, l’accompagnement d’un conseil réglementaire. Ici, nous partageons des pratiques d’équipe pour réduire l’écart entre « politique écrite » et « ce qui se passe dans le dépôt Git ».
SBOM : transparence de la nomenclature logicielle
Un SBOM (Software Bill of Materials) est un inventaire structuré des composants logiciels d’un produit ou d’une version : noms, versions, origines, licences, parfois relations de dépendance. Des formats comme SPDX ou CycloneDX facilitent l’échange et l’automatisation. Le SBOM n’est pas une fin en soi : c’est un artefact qui alimente l’analyse de vulnérabilités, la gestion des licences, la réponse à incident et la démonstration de connaissance de sa supply chain.
Pour une équipe SaMD, le SBOM utile est celui qui est généré à chaque build ou release significative, versionné avec le produit, et relié aux décisions (accepter un risque, mettre à jour, remplacer un composant). Un SBOM figé une fois par an dans un PDF non maintenu a peu de valeur opérationnelle.
Bonnes pratiques de départ : générer le SBOM depuis la CI ; stocker l’artefact avec la release ; croiser avec une base de vulnérabilités ; remonter les écarts dans le même outil que le backlog (pas dans une boîte mail isolée) ; lier les composants critiques à une fiche SOUP / évaluation de risque.
CRA : ce qui s’applique (et ce qui ne s’applique pas)
Le Cyber Resilience Act (CRA) vise à renforcer les exigences de cybersécurité pour certains produits avec éléments numériques mis sur le marché de l’Union européenne. Le CRA impose aux produits relevant de son champ des exigences de conception sécurisée, de gestion des vulnérabilités et de documentation. La procédure d’évaluation de conformité varie selon la catégorie du produit. Les obligations de notification prévues à l’article 14 s’appliquent à compter du 11 septembre 2026. L’application pleine des exigences essentielles intervient à partir du 11 décembre 2027 (calendrier tel qu’inscrit dans le règlement ; les actes d’application peuvent préciser certains détails).
Pourquoi cela concerne les fabricants de DM, même avec un SaMD déjà marqué CE ? Parce que le CRA ne se substitue pas au MDR sur le DM, mais il peut s’appliquer à d’autres offres numériques du même fabricant. Et parce que les attentes cyber sur les DM évoluent aussi : la révision proposée du MDR (package « MDR + IVDR » en discussion, pas encore loi adoptée) prévoit un renforcement explicite de la cybersécurité. Même sans application du CRA au SaMD, les pratiques issues de l’IEC 81001-5-1 pour le cycle de vie cybersécurité, articulées avec l’IEC 62304 pour la maîtrise des SOUP, restent pertinentes pour répondre aux attentes MDR et à l’état de l’art.
Pour les produits auxquels s’appliquent le MDR ou l’IVDR, l’article 2(2) du CRA les exclut du champ d’application du CRA : pas de double marquage CE CRA sur ce dispositif médical. La cybersécurité du SaMD / DM reste cadrée par le MDR (ou l’IVDR), le guide MDCG 2019-16 et des normes comme IEC 81001-5-1. Voir aussi cybersécurité IEC 81001-5-1 et MDR.
Cette exclusion vaut produit par produit, pas entreprise par entreprise. Un fabricant SaMD peut conserver des offres wellness, de l’admin hospitalier, des composants / SDK vendus séparément ou des wearables non médicaux qui, eux, peuvent entrer dans le champ du CRA. Ne présumez pas « nous sommes sous MDR, donc le CRA ne nous touche pas » pour tout le portefeuille : c’est une analyse juridique et produit, pas un slogan RA.
Impact concret pour l’équipe : cartographiez chaque SKU / application / module vendu séparément, identifiez le régime (MDR, CRA, les deux, ni l’un ni l’autre), puis alignez les preuves. Les pratiques SBOM et de gestion des vulnérabilités restent utiles opérationnellement même pour un SaMD 100 % MDR (état de l’art, audits, anticipation des convergences), sans confondre ces routines avec des obligations CRA sur le produit MDR.
Deux réglementations, un portefeuille : DM + wellness
Le piège le plus fréquent chez les fabricants DM avec une ligne wellness : « Notre SaMD est marqué CE, donc notre app bien-être est couverte. » En réalité, ce sont souvent deux produits distincts, deux classifications, deux cadres de conformité. Le SaMD relève du MDR et est donc exclu du champ du CRA. L’app wellness, si elle n’est pas un DM, peut être un produit avec éléments numériques soumis au CRA. Partager du code, une équipe ou une CI ne fusionne pas automatiquement les régimes.
Scénarios typiques à auditer explicitement : app compagnon non médicale ; portail patient sans fonction DM ; SDK ou API vendus à des tiers ; version « consumer » d’un produit clinique ; wearable sans intention médicale revendiquée. Chaque cas demande une qualification produit (MDR, CRA, ou autre) avant de calibrer le dossier et les release gates.
Du côté MDR, l’organisme notifié attend des preuves cyber dans le dossier technique (MDCG 2019-16, IEC 81001-5-1). Du côté CRA, les chemins de conformité, de marquage et de notification diffèrent. Gérer les deux en parallèle sans tronc commun d’ingénierie, c’est dupliquer l’effort et multiplier les risques d’incohérence lors d’un audit ou d’un incident.
Tronc commun vs ce qui change
L’objectif n’est pas deux usines logicielles, mais un socle d’ingénierie partagé et des couches de conformité adaptées par ligne produit. Voici une grille de lecture utile en atelier RA / tech.
| Domaine | Tronc commun (tout le portefeuille) | À adapter par produit / ligne |
|---|---|---|
| Inventaire SOUP / SBOM | Même CI, formats SPDX ou CycloneDX, versioning par release | Périmètre composants, profondeur transitive selon exposition |
| Processus vulnérabilités | Même tooling, SLA de triage, traçabilité des décisions | Criticité, acceptation de risque, délais de patch selon usage patient |
| Release gates | SBOM à jour, alertes triées, changements SOUP tracés | Profondeur doc, signatures, critères « go » réglementaires |
| Security by design | Threat modeling, secrets, durcissement, revue architecture | Menaces, assets et impact selon contexte clinique ou grand public |
| Dossier de conformité | Preuves exportables, lien exigences ↔ tests ↔ releases | Dossier technique MDR/IVDR vs dossier CRA (structure, contenu) |
| Marquage et reporting | Traçabilité post-market, gestion incidents cyber | Organisme notifié (MDR) vs autorités CRA selon catégorie produit |
En pratique, investir une fois dans le tronc commun (SBOM automatisé, registre SOUP, processus vulnérabilités, gates CI) amortit le coût des deux régimes. Les écarts se concentrent sur la couche documentaire et les interlocuteurs réglementaires, pas sur la discipline d’ingénierie du dépôt.
Routine pratique : de l’inventaire au contrôle
Étape 1 · Inventaire
Identifiez les dépendances directes et, autant que possible, transitives. Outillez la CI pour produire un SBOM et bloquez ou alertez si la génération échoue. Sans inventaire, le reste est cosmétique.
Étape 2 · Classification
Distinguez composants critiques (impact patient, sécurité, confidentialité) et non critiques. Reliez les critiques à une évaluation documentée (risque, exigences, tests). Ne traitez pas toutes les dépendances avec la même profondeur : priorisez selon le risque.
Étape 3 · Preuves
Pour chaque composant critique : source, version, justification d’usage, anomalies connues pertinentes, tests de vérification réalisés, décision de mise à jour. Ces preuves doivent être retrouvables, pas dispersées dans des dossiers personnels.
Étape 4 · Surveillance
Abonnez-vous aux alertes CVE / advisories pour les composants critiques. Définissez un SLA interne de triage. Documentez les décisions « pas de patch immédiat » avec justification de risque.
Étape 5 · Release gate
Avant une release réglementairement significative, vérifiez : SBOM à jour, composants critiques évalués, vulnérabilités ouvertes triées, changements SOUP tracés. Ce gate peut vivre dans la CI et être consolidé dans la couche de conformité.
IEC 81001-5-1 : socle utile, même sans CRA sur le DM
IEC 81001-5-1 fournit un cadre pour le processus de cybersécurité du logiciel de santé. Même lorsque le CRA ne s’applique pas à votre SaMD (exclusion MDR art. 2), suivre ses bonnes pratiques reste une stratégie solide : inventaire des composants, exigences de sécurité, vérification, surveillance post-market. C’est l’état de l’art attendu par les organismes notifiés via MDCG 2019-16, et probablement le cap des évolutions réglementaires à venir.
La révision proposée du MDR (package en discussion au niveau européen, pas encore loi adoptée) vise notamment à renforcer les exigences cyber sur les DM. Sans présumer du calendrier ni du texte final, la direction est claire : converger vers des attentes proches de ce que le CRA impose aux produits numériques grand public. Investir aujourd’hui dans SOUP, SBOM et processus vulnérabilités, c’est préparer le dossier MDR de demain autant que couvrir une éventuelle ligne CRA.
Beaucoup d’équipes tentent de recopier la norme chapitre par chapitre dans des SOP de 80 pages. Effet fréquent : documents illisibles et peu appliqués. Mieux vaut mapper vos activités existantes (architecture, vérification, gestion de configuration, post-market) aux attentes de la norme, combler les trous, et garder des procédures courtes reliées à des preuves automatisées. Pour approfondir le mapping MDR, voir IEC 81001-5-1 et MDR.
SOUP et SBOM s’insèrent naturellement dans ce mapping. Votre eQMS conserve la politique ; votre ALM / CI produit le travail ; une infrastructure de conformité (comme Qapsule) aide à garder le lien et les preuves sans forcer un changement d’ALM. Pour démêler ces catégories, voir eQMS vs ALM vs infrastructure de conformité.
Qapsule comme overlay
Plutôt que de migrer l’équipe hors de GitHub, GitLab ou Azure DevOps « pour le CRA », connectez une couche qui capture SBOM, statuts de composants et contrôles de release. QARA PULSE / Qapsule se positionnent sur cette infrastructure de conformité : preuves et contrôles sur l’existant.
Checklist SOUP / SBOM opérationnelle
- SBOM généré automatiquement à chaque build ou tag de release (format machine-readable).
- Inventaire de tous les SOUP et dépendances pertinentes, avec une profondeur d’évaluation proportionnée à leur impact et au risque.
- Évaluation documentée de chaque SOUP ; niveau de détail adapté à sa criticité et à son rôle dans le dispositif.
- Processus de triage des vulnérabilités avec délais internes documentés.
- Lien explicite entre mise à jour de dépendance et change control / évaluation d’impact.
- Gate de release : pas de « go » sans SBOM + revue des alertes ouvertes pertinentes.
- Preuves exportables pour audit (pas uniquement des captures d’écran).
- Revue de la liste SOUP à chaque changement de configuration affectant les dépendances et, a minima, à chaque release, avec surveillance périodique des vulnérabilités en post-market.
- Formation courte des développeurs : pourquoi le SBOM n’est pas « un truc RA ».
- Vérification du champ d’application CRA via textes officiels pour votre produit.
Conclusion
SOUP et SBOM deviennent des routines d’ingénierie autant que des sujets RA/QA. Le CRA redessine le paysage cyber européen pour les produits numériques hors MDR, tandis que les fabricants DM doivent penser portefeuille, pas slogan. L’approche durable : un tronc commun automatisé (inventaire, vulnérabilités, release gates), des couches de conformité calibrées par produit (MDR vs CRA), et IEC 81001-5-1 comme baseline cyber même lorsque le CRA ne s’applique pas au SaMD.
Pour aller plus loin
Si vous souhaitez clarifier votre cartographie outils (eQMS, ALM, CI/CD, SBOM) et identifier où une couche de conformité peut s’appuyer sur l’existant sans migration forcée, l’équipe Qapsule peut échanger avec vous sur un cas d’usage concret. QARA PULSE et Qapsule positionnent la conformité comme une infrastructure transversale : preuves, traçabilité et contrôles, branchés sur vos outils déjà en place. Contactez QARA PULSE pour démarrer.
FAQ
Faut-il un SBOM pour chaque commit ?
Pas nécessairement. Visez au minimum chaque release candidate et chaque version commercialisée ou déployée. Plus fréquemment si votre cadence de delivery et votre exposition aux vulnérabilités le justifient.
SOUP et open source, est-ce la même chose ?
Non. Beaucoup de SOUP sont open source, mais le critère SOUP porte sur la provenance et la maîtrise du développement, pas sur la licence. Un composant propriétaire tiers peut aussi être SOUP.
Le CRA remplace-t-il le MDR pour la cybersécurité ?
Pour un produit auquel s’applique le MDR/IVDR, l’article 2(2) du CRA l’exclut du champ d’application du CRA : pas de double régime cyber CRA sur ce DM. La cybersécurité reste sous MDR + MDCG 2019-16 + IEC 81001-5-1. D’autres produits du même fabricant (wellness, admin, composants vendus séparément) peuvent toutefois entrer dans le CRA. Analysez produit par produit et vérifiez les textes officiels.
Notre app wellness partage du code avec le SaMD : le CRA s’applique-t-il ?
Produit par produit. Un code partagé ou une CI commune ne fusionne pas les régimes réglementaires. Qualifiez chaque application (intention médicale, claims, mode de distribution) et déterminez si elle est un DM (MDR), un produit CRA, ou autre. L’app wellness peut entrer dans le CRA même si le SaMD est exclu. Documentez la séparation ou la mutualisation des preuves en conséquence.
Doit-on tout documenter comme dans IEC 81001-5-1 mot à mot ?
Non. Mappez, comblez les écarts, gardez des procédures applicables. La preuve vivante dans le delivery vaut mieux qu’une SOP encyclopédique non suivie.
Guide QARA PULSE sur SOUP, SBOM et le CRA pour un portefeuille DM + wellness. Ce n’est pas une certification, ni un avis juridique personnalisé. Vérifiez toujours les textes officiels et adaptez les pratiques à votre produit, à votre SMQ et aux attentes de votre organisme notifié.