Vendredi, 19 h. Un client signale un comportement étrange sur son application, et l'analyse des journaux confirme qu'une bibliothèque tierce est attaquée en ce moment même. Avant le 11 septembre 2026, le studio aurait corrigé le week-end et prévenu ses clients lundi. Désormais, le Cyber Resilience Act lui laisse 24 heures après la prise de connaissance pour alerter les autorités. Cela vaut pour toute vulnérabilité activement exploitée et tout incident grave touchant la sécurité d'un produit.
Le dispositif est déjà opérationnel. Le jour même, l'agence européenne de cybersécurité ENISA a ouvert sa Single Reporting Platform, le guichet unique des signalements. Une seule déclaration suffit : elle part vers l'équipe nationale de réponse aux incidents (CSIRT) du pays où l'entreprise a son établissement principal, et vers ENISA en parallèle.
24 heures, 72 heures, 14 jours : que faut-il envoyer ?
L'alerte de 24 heures reste volontairement courte : elle signale que la faille est exploitée et indique, si on le sait, dans quels États membres le produit est distribué. Rien de plus n'est exigé à ce stade. La notification de 72 heures ajoute une description de la vulnérabilité, sa nature et les premières mesures prises. Le rapport final arrive au plus tard 14 jours après la mise à disposition d'un correctif, ou dans le mois qui suit la notification de 72 heures pour un incident grave.
Reste le vendredi soir : le délai court même quand l'équipe est au repos. Un studio de trois personnes doit donc savoir à l'avance qui décide que la faille est bien « exploitée », qui a accès à la plateforme et quels éléments tenir prêts.
Un studio est-il vraiment concerné ?
Oui, dès qu'il vend. Le CRA vise tout fabricant qui place sur le marché de l'UE un SaaS, une application mobile, un plugin ou un firmware dans le cadre d'une activité commerciale. Le logiciel libre non monétisé reste hors champ, tout comme le simple contributeur à un projet dont il n'a pas la charge. Un thème WordPress premium, une extension vendue sur une marketplace ou une app livrée à un client entrent dans le périmètre.
Savoir ce que contient son produit
Déclarer en 24 heures suppose de savoir quels composants tournent dans son produit, et dans quelle version. Un exemple parlant : lors de la faille Log4Shell, fin 2021, de nombreuses équipes ont passé des jours à chercher où la bibliothèque Log4j se cachait dans leurs applications. Le SBOM (Software Bill of Materials) répond à ce problème : c'est l'inventaire des composants logiciels et de leurs versions, qu'on peut générer automatiquement à chaque build.
ENISA a publié en juin 2026 une enquête, SBOM Adoption State of Play, selon laquelle le CRA agit comme un accélérateur : les organisations investissent dans la génération et l'automatisation de leurs SBOM. En juillet 2026, le CISA américain et plusieurs agences, dont l'ANSSI, ont publié des 2026 Minimum Elements for a Software Bill of Materials, qui fixent le contenu minimal d'un tel inventaire.
Le texte n'impose pas le SBOM partout de façon explicite. Mais sans lui, répondre en heures plutôt qu'en semaines relève du pari.
Open source : le 11 décembre 2027
Le CRA a créé une catégorie à part, les stewards de logiciels libres : des personnes morales qui soutiennent durablement un projet destiné à des usages commerciaux. Leurs obligations prennent effet au 11 décembre 2027, en même temps que les exigences principales du texte. Le régime est allégé (politique de cybersécurité, coopération avec les autorités, signalement) et les stewards échappent aux amendes administratives. Allégé ne veut pas dire optionnel.
Déclarer, est-ce être en règle ?
Non : le signalement sous 24 heures est une obligation, pas un certificat de sécurité. Un studio peut très bien déclarer à temps un produit qui ne respecte pas les exigences de fond du CRA, attendues en décembre 2027. Autre piège : croire qu'un dossier de conformité bien tenu suffit. Les autorités regarderont le processus réel, c'est-à-dire qui surveille les vulnérabilités, qui tranche et qui déclare.
Ce qui peut encore bouger
Le calendrier est écrit, mais trois points restent ouverts. D'abord le Digital Omnibus, le paquet de simplification présenté par la Commission en novembre 2025 : il traduit une volonté d'alléger certaines règles numériques, sans que l'on sache s'il touchera aux délais du CRA. Ensuite l'application réelle : la Commission a publié des lignes directrices non contraignantes, avec 67 exemples pratiques orientés PME et microentreprises, mais leur portée devant une autorité de contrôle reste à voir. Enfin les sanctions : aucune n'a encore été prononcée et on ignore à quel rythme les autorités nationales contrôleront les petites structures.
En attendant, un studio gagne à poser trois choses : un SBOM généré à chaque livraison, une veille sur les vulnérabilités de ses dépendances et une procédure de signalement écrite, avec un nom derrière chaque étape. Cela prend quelques jours, bien moins qu'un vendredi soir sans plan.