L'essentiel en bref
À partir du 11 septembre 2026, l'article 14 du Cyber Resilience Act de l'UE oblige les fabricants de produits comportant des éléments numériques à signaler les vulnérabilités activement exploitées à l'ENISA et aux équipes nationales de réponse aux incidents de sécurité informatique (CSIRT) dans les 24 heures suivant leur découverte. Un rapport de triage comprenant une voie de résolution doit suivre dans les 72 heures ; un rapport de remédiation final est exigé dans les 14 jours. L'obligation s'applique à tout fabricant qui distribue des logiciels ou du matériel connecté dans l'UE, y compris les entreprises établies aux États-Unis.
Le CRA est entré en vigueur le 11 décembre 2024. Ses exigences complètes de conformité — marquage CE, évaluations de conformité, nomenclatures logicielles — ne s'appliquent qu'à partir du 11 décembre 2027. La date limite du 11 septembre 2026 constitue le premier jalon opérationnellement significatif, et il arrive dans quelques jours seulement. Les équipes qui n'ont pas encore mis en place des flux de travail de gestion des vulnérabilités et d'audit de sécurité alignés sur les délais du CRA devraient considérer cela comme le signal d'action immédiate.
Ce qui change le 11 septembre
Le Cyber Resilience Act (Règlement (UE) 2024/2847) a instauré un cadre d'exigences de cybersécurité pour tout produit doté d'une composante numérique vendu dans l'UE. Le règlement est structuré en vagues : les obligations les plus lourdes — évaluations de conformité, marquage CE, maintenance de nomenclatures logicielles — ne s'appliquent qu'à partir de décembre 2027. La vague des signalements arrive en premier, et elle arrive ce mois-ci.
L'article 14 couvre deux catégories d'événements. Premièrement, les vulnérabilités activement exploitées : des failles de sécurité dans le produit d'un fabricant que des acteurs malveillants exploitent actuellement, dans tout contexte de déploiement, et pas seulement contre les propres clients du fabricant. Deuxièmement, les incidents de sécurité graves : des événements ayant un impact significatif sur la sécurité d'un produit, notamment ceux susceptibles d'affecter la protection des données, d'introduire du code malveillant dans une chaîne d'approvisionnement ou de compromettre un environnement de développement ou de production. Dans les deux cas, le déclencheur est le moment où le fabricant prend connaissance — il n'y a aucun délai de grâce pour une enquête interne avant que l'horloge de 24 heures ne commence.
L'ENISA exploitera une plateforme unique de signalement qui acheminera chaque soumission vers l'ENISA elle-même et vers le CSIRT national de l'État membre où le fabricant est établi ou, pour les fabricants non européens, l'État membre désigné comme point de contact unique. La plateforme est conçue pour accepter des notifications lisibles par machine et éviter que les fabricants n'aient à soumettre quatre rapports distincts dans quatre portails différents pour un seul incident.
L'horloge 24 h / 72 h / 14 jours
Le calendrier est précis. Dès qu'un fabricant a connaissance d'un événement qualifié :
- 24 heures — Alerte précoce. Une notification préliminaire à l'ENISA et au CSIRT national. Le règlement n'exige pas d'analyse technique complète à ce stade, mais la notification doit confirmer l'événement, le produit affecté et l'évaluation préliminaire de l'impact. L'objectif est de donner aux autorités une visibilité avant que l'information ne se propage, non d'exiger un rapport complet d'incident du jour au lendemain.
- 72 heures — Rapport de triage. Une soumission plus détaillée comprenant une évaluation de la gravité, les premières mesures d'atténuation prises et une voie de résolution. Si un correctif est déjà disponible, cela doit être mentionné ; sinon, le plan pour en produire un doit être décrit.
- 14 jours — Rapport final (vulnérabilités) / 30 jours (incidents). Un compte rendu complet de la vulnérabilité ou de l'incident, des mesures correctives appliquées et de leur efficacité. Pour les incidents, le délai est porté à 30 jours à compter du moment où le fabricant en a pris connaissance.
Pour les équipes habituées à la fenêtre de notification de violation de 72 heures du RGPD, le rapport initial de 24 heures du CRA est sensiblement plus court. Pour les équipes habituées aux délais de divulgation coordonnée de vulnérabilités (CVD) de 90 jours ou plus, le contraste est encore plus marqué. La conséquence pratique est que la détection des vulnérabilités et l'escalade interne ne peuvent pas être des processus lents : dès que l'équipe de sécurité confirme une exploitation active, les équipes juridiques et conformité doivent être impliquées en quelques heures, et non en quelques jours.
Qui doit se conformer — y compris les éditeurs américains
Les obligations du CRA incombent aux fabricants : les entreprises qui conçoivent, développent ou fabriquent des produits comportant des éléments numériques — ou les font concevoir, développer ou fabriquer — et commercialisent ensuite ces produits sur le marché européen sous leur propre nom ou marque. La définition est intentionnellement large. Elle couvre les logiciels commerciaux sur étagère, les plateformes SaaS, les applications mobiles, les appareils IoT grand public, les systèmes de contrôle industriels, les micrologiciels embarqués et les équipements réseau.
Les importateurs et distributeurs ont des obligations plus légères mais réelles : ils doivent vérifier la conformité du fabricant et, dans certaines circonstances, agir en tant qu'entité responsable si un fabricant en dehors de l'UE ne peut être identifié. Mais l'obligation principale de signalement de l'article 14 repose sur le fabricant.
Le déclencheur géographique est le marché européen, non l'établissement dans l'UE. Un éditeur de logiciels basé aux États-Unis dont le produit est accessible à des clients entreprises ou particuliers en Allemagne, en France ou dans tout autre État membre est un fabricant au sens du CRA. Il en va de même pour les entreprises britanniques post-Brexit, les fournisseurs canadiens de SaaS et toute autre entité non européenne. Si votre produit est vendu ou distribué dans l'UE, vous êtes dans le champ d'application, et vous avez besoin d'un chemin de signalement vers la SRP de l'ENISA avant le 11 septembre.
Interactions avec le RGPD, NIS2 et DORA
Le CRA est le quatrième grand cadre de conformité numérique européen, aux côtés du RGPD, de NIS2 et de DORA, et les quatre partagent suffisamment d'ADN architectural — alertes précoces à 24 heures, rapports de suivi échelonnés, notification aux autorités désignées — pour créer des risques de coordination s'ils sont traités comme des programmes distincts.
Une attaque par rançongiciel sur un appareil connecté pourrait par exemple déclencher simultanément : un rapport CRA article 14 à l'ENISA (dans les 24 heures, en tant qu'incident grave) ; une notification RGPD article 33 à l'autorité de contrôle (dans les 72 heures, si des données personnelles sont affectées) ; un rapport d'incident significatif NIS2 (dans les 24 heures, si le fabricant est une entité essentielle ou importante) ; et, pour les fournisseurs SaaS du secteur financier, un rapport d'incident majeur DORA (dans les 4 heures pour les événements à haute criticité). Chaque notification va à une autorité différente, suit un modèle légèrement différent et a des délais de suivi différents.
Le risque concret n'est pas que les équipes oublient de signaler ; c'est qu'elles construisent quatre silos indépendants et ratent soit une fenêtre de signalement parce que la mauvaise équipe était responsable de la notification, soit transmettent des informations contradictoires sur le même événement à différents régulateurs. La bonne architecture est un processus de triage d'incident unifié qui prend en entrée le fait confirmé d'un incident et produit en sortie les bonnes notifications aux bonnes autorités dans les bons délais. Ce processus doit être cartographié, documenté et testé avant le 11 septembre — car le premier vrai incident est un mauvais moment pour découvrir que le processus ne fonctionne pas. La mise en place d'un programme de conformité RGPD et multi-réglementaire unifié est la voie que suivent généralement les équipes opérant en Europe ; le CRA ajoute une nouvelle voie à une autoroute existante plutôt que de construire une route entièrement nouvelle.
Ce que cela implique pour les équipes logicielles
Le changement opérationnel est réel, et il mérite d'être formulé avec précision. Avant le 11 septembre, un éditeur de logiciels confronté à une vulnérabilité activement exploitée dans son produit pouvait gérer le calendrier de divulgation à son propre rythme : les processus CVD accordaient généralement des mois ; la divulgation volontaire aux autorités était exactement cela — volontaire. À partir du 11 septembre, l'État dispose d'un premier droit obligatoire sur ce calendrier — 24 heures, à chaque fois, que l'éditeur soit prêt ou non, que le correctif soit prêt ou non, que l'exploit soit public ou non.
Pour les équipes d'ingénierie, cela implique une instrumentation : vous ne pouvez pas signaler une vulnérabilité activement exploitée que vous ne connaissez pas. La surveillance continue des flux de renseignements sur les menaces, des avis éditeurs et de votre propre télémétrie pour détecter des signes d'exploitation n'est plus une bonne pratique pour les équipes matures ; en vertu de l'article 14, c'est un prérequis de conformité. Il en va de même pour disposer d'une définition interne claire de ce que signifie « prendre connaissance » — car l'horloge commence à tourner lorsque votre organisation est informée, non lorsque le RSSI rédige le briefing.
Pour les chefs de produit et les fondateurs de produits SaaS ciblant l'Europe, cela implique une responsabilité de processus : l'obligation de signalement du CRA incombe au fabricant, non au client, non au fournisseur cloud et non au consultant en sécurité. Si votre produit est dans le champ d'application, votre entité juridique est celle à laquelle s'applique l'horloge de 24 heures, et vous avez besoin d'une personne nommément désignée qui sait quoi déposer et où.
La lecture stratégique d'ensemble est que le CRA tire les standards de cybersécurité européens vers le haut, au niveau de ce que les acheteurs entreprises matures dans les secteurs régulés — banque, santé, infrastructures critiques — exigent depuis des années. Les équipes qui gèrent déjà des programmes SOC 2 Type II ou des processus de réponse aux incidents conformes au RGPD trouveront les mécanismes du CRA familiers. Les équipes qui géraient la sécurité de manière informelle découvriront que le CRA est le catalyseur qui transforme la pratique informelle en processus documenté et auditable.
À faire avant le 11 septembre
La liste de contrôle n'est pas longue, mais chaque point doit être réellement accompli, pas seulement planifié.
- Confirmer le périmètre. Recensez tous les produits que votre entreprise commercialise sur le marché européen. S'ils ont une composante numérique — logiciel, micrologiciel, connectivité — ils sont probablement dans le champ d'application. Les produits hérités déjà sur le marché avant l'entrée en vigueur du CRA peuvent également être concernés s'ils reçoivent des mises à jour logicielles.
- Définir en interne « prendre connaissance ». Établissez un seuil clair à partir duquel votre organisation est considérée comme informée d'une vulnérabilité activement exploitée. Ce seuil détermine le départ de l'horloge de 24 heures. L'ambiguïté ici crée un risque de conformité.
- Mettre en place une surveillance continue. Vous ne pouvez pas signaler ce que vous ne pouvez pas détecter. Établissez ou contractualisez une surveillance des renseignements sur les menaces et de la télémétrie pour détecter les signes d'exploitation active dans l'ensemble de votre portefeuille de produits.
- Désigner un responsable de la notification. Nommez la personne (et un suppléant) chargée de soumettre les rapports CRA. Elle doit avoir l'autorité de notifier les autorités sans une longue chaîne d'approbation interne qui empiéterait sur la fenêtre de 24 heures.
- S'inscrire sur la SRP de l'ENISA. La plateforme unique de signalement ouvre le 11 septembre 2026. Pré-inscrivez-vous si l'ENISA ouvre un accès anticipé ; vérifiez au minimum que vos identifiants d'accès sont prêts avant la date limite.
- Préparer des modèles de rapports. La structure de signalement en trois étapes de l'article 14 est prévisible. Préparez dès maintenant des modèles pour l'alerte précoce à 24 heures, le rapport de triage à 72 heures et le rapport final à 14 jours, afin que votre équipe renseigne des faits sous pression plutôt que de rédiger un format.
- Cartographier les chevauchements de régimes. Si vous avez également des obligations NIS2, DORA ou RGPD, vérifiez qu'un incident déclencheur du CRA s'intègre correctement dans tous les flux de notification applicables.
Questions fréquentes
Que requiert le CRA à partir du 11 septembre 2026 ?
À partir du 11 septembre 2026, les fabricants de produits comportant des éléments numériques commercialisés sur le marché européen doivent transmettre une alerte précoce à l'ENISA et à leur CSIRT national dans les 24 heures suivant la prise de connaissance d'une vulnérabilité activement exploitée ou d'un incident de sécurité grave. Un rapport de triage avec une voie de résolution suit dans les 72 heures, et un rapport final est dû dans les 14 jours suivant la disponibilité d'un correctif (30 jours pour les incidents).
À qui s'applique l'obligation de signalement du CRA ?
À tout fabricant commercialisant des produits comportant des éléments numériques sur le marché européen — y compris les logiciels, SaaS, applications mobiles, appareils IoT et systèmes embarqués. Les importateurs et distributeurs ont des obligations plus légères. Surtout, la règle s'applique en fonction du lieu de vente du produit, non du lieu d'établissement du fabricant — les entreprises américaines, britanniques et autres entités non européennes distribuant des logiciels ou des appareils en Europe sont pleinement concernées.
Qu'est-ce qu'une vulnérabilité activement exploitée au sens du CRA ?
Une faille de sécurité dans le produit d'un fabricant que des acteurs malveillants exploitent activement — dans tout environnement de déploiement, pas uniquement contre les propres clients du fabricant. Le règlement couvre également les incidents de sécurité graves, notamment les événements susceptibles d'affecter la protection des données, d'introduire du code malveillant dans une chaîne d'approvisionnement ou de compromettre des environnements de développement ou de production.
Comment le signalement CRA interagit-il avec le RGPD, NIS2 et DORA ?
Les quatre cadres partagent une structure d'alerte précoce à 24 heures, mais s'adressent à des autorités différentes et ont des délais de suivi distincts. Un seul incident peut déclencher simultanément des obligations sous plusieurs régimes. Construisez un processus de triage d'incident unifié qui identifie les régimes applicables et produit la bonne notification à chaque régulateur dans le bon délai, plutôt que de gérer des processus de conformité distincts pour chaque cadre.
Que doivent faire les équipes logicielles avant le 11 septembre 2026 ?
Confirmer quels produits sont dans le périmètre ; définir en interne le départ de l'horloge de 24 heures ; mettre en place ou contractualiser une surveillance continue des vulnérabilités ; nommer un responsable de la notification avec autorité directe pour déposer ; s'inscrire sur la plateforme unique de signalement de l'ENISA ; préparer des modèles de rapports à 24 h, 72 h et 14 jours ; et cartographier les obligations croisées avec le RGPD, NIS2 et DORA pour éviter les notifications manquées ou contradictoires.
Sources
Commission européenne — Obligations de signalement du CRA (source réglementaire primaire)
DLA Piper — La règle des 24 heures du CRA : se préparer aux obligations de signalement de septembre 2026 (août 2026)
Crowell & Moring — CRA de l'UE : date limite de signalement du 11 septembre 2026