La réponse en bref
L'obligation de signalement du Cyber Resilience Act est désormais en vigueur. Depuis le 11 septembre 2026, tout fabricant d'un « produit comportant des éléments numériques » vendu dans l'UE doit signaler à l'ENISA et à son CSIRT national les vulnérabilités activement exploitées et les incidents graves — une alerte précoce sous 24 heures, une notification plus complète sous 72 heures et un rapport final sous 14 jours. Le compte à rebours démarre dès que vous avez connaissance des faits, et non lorsque vous avez terminé votre vérification, et la règle atteint les produits déjà sur le marché ainsi que les éditeurs établis hors de l'UE.
Pour les responsables techniques, la difficulté tient à ce qu'il s'agit d'une obligation de processus assortie d'un délai serré, arrivant plus d'un an avant les exigences de conception et de documentation du CRA. Savoir qu'une faille exploitée existe n'est plus seulement une appréciation interne de gravité ; c'est le point de départ d'un calendrier réglementaire. Les équipes qui géreront cela sereinement sont celles qui traitent la détection et la divulgation des vulnérabilités exploitées comme une capacité éprouvée — le muscle même que nous développons dans un test d'intrusion et audit de sécurité, où trouver et trier les problèmes réels et exploitables est tout l'objet.
Ce qui est entré en vigueur le 11 septembre
Le Cyber Resilience Act (règlement (UE) 2024/2847) est la loi horizontale de cybersécurité de l'UE pour les « produits comportant des éléments numériques » — en pratique tout logiciel ou matériel pouvant se connecter à un appareil ou à un réseau, du firmware et des systèmes d'exploitation aux applications mobiles, composants proches du SaaS et équipements connectés grand public. La plupart de ses obligations — conception sécurisée, documentation, conformité — ne s'appliquent qu'à partir du 11 décembre 2027. Mais le règlement a avancé une obligation, entrée en vigueur le 11 septembre 2026 : l'obligation de signalement.
À compter de cette date, un fabricant qui a connaissance qu'une vulnérabilité de son produit est activement exploitée, ou d'un incident grave affectant la sécurité du produit, doit notifier l'Agence de l'Union européenne pour la cybersécurité (ENISA) et le Computer Security Incident Response Team (CSIRT) national compétent. Le calendrier est échelonné et serré : une alerte précoce sous 24 heures après connaissance des faits, une notification technique plus complète sous 72 heures et un rapport final sous 14 jours après la mise à disposition d'une mesure corrective pour les vulnérabilités exploitées — ou sous un mois pour les incidents graves.
Deux choix de conception rendent cela plus lourd qu'il n'y paraît. D'abord, le déclencheur est la connaissance, non la confirmation : des analyses juridiques indépendantes soulignent que le compte à rebours démarre dès que le fabricant a connaissance du problème ; une équipe ne peut donc pas mener une enquête interne tranquille et commencer à compter ensuite. Ensuite, les signalements transitent par la nouvelle plateforme unique de signalement de l'ENISA, mise en service le même jour ; au lancement, c'est un portail web manuel, sans API publique ni canal de signalement volontaire, si bien que la soumission ne peut pas encore être scriptée dans un pipeline d'incident. Le CSIRT qui reçoit le signalement le partage avec les autres équipes nationales concernées.
Qui est concerné — y compris en France
Le contresens le plus fréquent est de croire que c'est un problème d'entreprises de l'UE. Ce n'est pas le cas. L'obligation est attachée à la mise sur le marché de l'UE d'un produit ; un fabricant américain, britannique ou autre, établi hors UE, qui livre des logiciels, un composant délivré en SaaS ou un appareil connecté à des clients de l'UE entre pleinement dans le champ. Un éditeur dont le siège est à Austin ou à Londres avec des utilisateurs européens hérite du même compte à rebours de 24 heures qu'un éditeur berlinois. Cette portée extraterritoriale est délibérée, et le levier de mise en œuvre est réel : les amendes administratives peuvent atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu.
La deuxième surprise est la portée sur le parc installé. L'obligation de signalement est la seule partie du CRA qui s'applique aux produits déjà sur le marché, et pas uniquement aux nouveaux mis à disposition après une échéance future. Un firmware livré il y a des années, une bibliothèque intégrée à un appareil ou une application publiée bien avant l'entrée en vigueur du CRA relèvent tous de l'obligation à partir du 11 septembre si une vulnérabilité qu'ils contiennent est activement exploitée. Pour les équipes qui construisent des produits durables — et pour quiconque livre du logiciel sur mesure qui s'intègre au produit connecté d'un client — la conséquence pratique est que du code hérité que vous ne développez plus activement peut malgré tout générer un événement de signalement le jour même.
Les mainteneurs open source disposent de plus de marge : leurs obligations spécifiques s'appliqueront plus tard, le 11 décembre 2027, en reconnaissance de la différence entre les mainteneurs non commerciaux et les fabricants. Mais les éditeurs commerciaux qui intègrent des composants open source dans un produit ne peuvent pas différer — si le produit livré comporte une faille exploitée, c'est le fabricant qui le met sur le marché qui signale.
Ce que cela signifie pour les équipes logicielles
Le premier changement, c'est que la gestion des vulnérabilités devient un calendrier réglementé, et non une préférence interne. Beaucoup d'équipes appliquent déjà un processus de divulgation coordonnée, mais à leur propre rythme. Le CRA fixe le rythme pour le pire des cas : l'exploitation dans la nature. Cela suppose une définition interne sans ambiguïté de « connaissance » et d'« activement exploité », un décideur désigné capable de trancher hors des heures ouvrées, et un rapport que vous pouvez compléter sans une semaine de rédaction. Ancrez cela dans la même discipline de sécurité que celle appliquée à votre pipeline cloud et DevOps — inventaire des actifs, visibilité des dépendances et du SBOM, supervision — car vous ne pouvez pas signaler sous 24 heures au sujet d'un produit dont vous ne savez pas énumérer les composants.
Le deuxième changement est la preuve et la traçabilité. Un rapport échelonné à 24 heures, 72 heures et 14 jours est, de fait, une exigence de chronologie reconstituable : quand vous avez appris le problème, ce que vous saviez à chaque étape, quelle a été la mesure corrective et quand elle a été livrée. Les équipes qui consignent détection, tri et décisions de correctif comme des événements de premier ordre produiront ce récit presque gratuitement ; celles qui traitent la sécurité comme un savoir informel devront le reconstituer dans l'urgence sous le délai d'un régulateur. C'est la posture même que récompensait la notification de violation sous 72 heures du RGPD — le CRA étend simplement ce réflexe des incidents de données personnelles à la sécurité des produits.
Le troisième changement est le chevauchement et la déconfliction. Une seule faille exploitée peut désormais déclencher à la fois un signalement CRA, une notification de violation RGPD et, pour les opérateurs d'infrastructures critiques, des obligations d'incident NIS2 ou DORA — chacune avec son destinataire et son horloge. Pour les acteurs de la FinTech et de la HealthTech en particulier, la réponse n'est pas de mener des processus parallèles et improvisés, mais de concevoir un unique flux d'incident qui se ramifie vers les bons régulateurs avec le bon contenu et le bon calendrier. Câbler cela correctement en amont coûte bien moins cher que de découvrir les conflits en plein incident.
Quoi faire maintenant
- Confirmez votre exposition au marché. Recensez chaque produit comportant des éléments numériques que vous mettez à disposition dans l'UE — y compris les composants livrés en SaaS et embarqués, et les éléments existants encore déployés. Si l'un d'eux atteint des utilisateurs de l'UE, vous êtes dans le champ, quel que soit votre lieu d'établissement.
- Définissez « connaissance » et « activement exploité ». Consignez les critères et le responsable désigné qui décide. L'ambiguïté ici consume la fenêtre de 24 heures, car le compte à rebours démarre à la connaissance des faits, non à la fin de votre enquête.
- Préparez les rapports à l'avance. Rédigez dès maintenant les modèles à 24 heures, 72 heures et 14 jours, et préparez un compte et un flux de travail sur la plateforme unique de signalement de l'ENISA. Sans API au lancement, le dépôt est manuel — répétez-le pour qu'il devienne un automatisme, non une improvisation.
- Intégrez-le à l'ingénierie. Assurez-vous que détection, visibilité des dépendances et du SBOM, et décisions de correctif sont consignées comme des événements, afin que la chronologie du rapport se compose d'elle-même. Vous ne pouvez pas notifier rapidement au sujet de composants que vous ne voyez pas.
- Déconflictez avec le RGPD, NIS2 et DORA. Cartographiez quels incidents déclenchent quelles obligations, et concevez un flux unique qui route vers chaque régulateur avec le contenu et l'horloge corrects, plutôt que des procédures séparées et concurrentes.
Foire aux questions
Qu'est-ce qui a changé le 11 septembre 2026 ?
Les obligations de signalement du Cyber Resilience Act de l'UE (règlement (UE) 2024/2847) sont devenues applicables. Les fabricants de produits comportant des éléments numériques vendus dans l'UE doivent désormais signaler à l'ENISA et au CSIRT national compétent les vulnérabilités activement exploitées et les incidents graves. Les exigences de cybersécurité plus larges du CRA s'appliquent plus tard, le 11 décembre 2027, mais l'obligation de signalement est déjà en vigueur.
Quel est le calendrier de signalement ?
Pour une vulnérabilité activement exploitée : une alerte précoce sous 24 heures après connaissance des faits, une notification plus complète sous 72 heures et un rapport final au plus tard 14 jours après la mise à disposition d'une mesure corrective. Les incidents graves suivent les étapes de 24 et 72 heures avec un rapport final sous un mois. Le compte à rebours démarre à la connaissance des faits, non à la fin de la confirmation interne.
S'applique-t-il aux entreprises hors UE ?
Oui. L'obligation est attachée à la mise à disposition d'un produit sur le marché de l'UE ; un fabricant américain, britannique ou autre, hors UE, qui vend des logiciels, un composant SaaS ou un appareil connecté à des clients de l'UE, entre dans le champ. Les amendes peuvent atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu.
Les produits existants sont-ils couverts ?
Oui. L'obligation de signalement atteint les produits déjà sur le marché de l'UE, pas seulement les nouveaux. Un routeur, une image firmware, une bibliothèque ou une application livrés avant l'entrée en vigueur du CRA relèvent de l'obligation à partir du 11 septembre 2026 s'ils contiennent une vulnérabilité activement exploitée. C'est la partie du CRA qui touche le parc installé en premier.
Comment déposer un signalement ?
Via la plateforme unique de signalement (SRP) de l'ENISA, en service depuis le 11 septembre 2026. Elle achemine la notification vers le CSIRT de votre État membre principal, puis vers les autres équipes nationales concernées. Au lancement, c'est un portail web manuel sans API publique ni option de signalement volontaire ; le geste pratique est donc de préparer modèles, responsables et règles de décision avant un incident plutôt que de chercher à automatiser la soumission.
Sources
Commission européenne — Cyber Resilience Act : obligations de signalement
TechHQ — EU Cyber Resilience Act reporting : ce qui a changé le 11 septembre
Crowell & Moring — EU CRA : échéance de signalement incident/vulnérabilité au 11 septembre 2026