Cyber Resilience Act : ce que l’open source et les PME doivent savoir dès septembre 2026

Le règlement européen sur la cyber-résilience (Cyber Resilience Act, CRA) impose des exigences de sécurité aux « produits comportant des éléments numériques » mis sur le marché de l’Union : objets connectés, logiciels, micrologiciels. Son premier volet est entré en application le 11 septembre 2026, et il concerne directement l’écosystème open source — y compris les PME qui le consomment.

Ce qui s’applique depuis le 11 septembre 2026

Selon la page de la Commission européenne, les fabricants doivent désormais notifier les vulnérabilités activement exploitées et les incidents graves affectant la sécurité de leurs produits : une alerte précoce sous 24 heures, une notification complète sous 72 heures, puis un rapport final au plus tard 14 jours après la disponibilité d’un correctif (un mois après la notification pour un incident grave). Tout passe par une plateforme unique de signalement gérée par l’ENISA, opérationnelle depuis cette même date.

Les obligations de fond (conception sécurisée, documentation, gestion des vulnérabilités sur la durée de vie du produit) arrivent plus tard, en décembre 2027. Le signalement est donc la première marche — et celle qui force à avoir un processus avant d’en avoir besoin.

Et l’open source ?

Le règlement distingue le logiciel libre développé hors activité commerciale, qui reste hors champ, des « stewards » de logiciels libres, c’est-à-dire des structures qui soutiennent de manière durable un projet destiné à un usage commercial. Ces stewards sont soumis à un régime allégé, avec leurs obligations de signalement qui démarrent plus tard (décembre 2027). En revanche, l’entreprise qui intègre un composant libre dans un produit qu’elle commercialise en devient responsable : elle est le fabricant, et elle doit exercer une diligence raisonnable sur ses composants, libres ou non.

Êtes-vous concerné ?

Trois situations, du plus au moins direct :

• Vous vendez un produit numérique (appareil connecté, logiciel embarqué, application distribuée) : vous êtes un fabricant, le calendrier ci-dessus vous vise.
• Vous utilisez des logiciels libres en interne (ERP, messagerie, outils collaboratifs) sans les vendre : le règlement ne vous impose rien directement.
• Vous intégrez ou revendez des solutions à des clients : vos clients vous demanderont des garanties sur vos composants, car eux-mêmes en répondent.

Dans le doute, faites vérifier votre cas par un conseil juridique : la qualification de « produit » et de « fabricant » est le point délicat.

Ce qui vaut pour tout le monde : maîtriser ses dépendances

Même hors champ, le CRA fixe une bonne pratique qui deviendra une attente commerciale :

• Un inventaire des composants (une nomenclature logicielle, ou SBOM) : savoir ce qui tourne, dans quelle version, d’où cela vient.
• Un processus de mise à jour : qui surveille les avis de sécurité, sous quel délai on applique un correctif, comment on teste.
• Une veille sur le cycle de vie : un composant abandonné par ses mainteneurs est une dette de sécurité qui s’accumule.
• Un point de contact et une procédure pour traiter un signalement de vulnérabilité, entrant comme sortant.

C’est aussi ce que nous retrouvons dans les bases d’une infrastructure PME sécurisée. Le logiciel libre a ici un avantage réel — le code est inspectable et les correctifs sont publics — mais cet avantage ne vaut que si quelqu’un surveille activement ces correctifs.

Sources

• Commission européenne — CRA, obligations de signalement
• BCLP — CRA et logiciels libres
• Greenbone — Cyber Resilience Act et open source