Ce qu’il faut retenir
- Depuis le 11 septembre 2026, un fabricant concerné doit utiliser la plateforme unique du Cyber Resilience Act pour notifier une vulnérabilité activement exploitée ou un incident grave affectant la sécurité d’un produit comportant des éléments numériques.
- Le premier signalement intervient dans les 24 heures suivant la prise de connaissance, puis la notification complète dans les 72 heures. Le rapport final n’a pas la même échéance selon qu’il s’agit d’une vulnérabilité ou d’un incident.
- Le vrai chantier n’est pas de rédiger trois fois le même récit : il faut qualifier le déclencheur, conserver l’heure de prise de connaissance, attribuer les rôles et préparer un dossier de preuves réutilisable.
- Les intendants de logiciels libres ne suivent pas encore le même calendrier : l’article 24, paragraphe 3, s’applique à eux à partir du 11 décembre 2027.
Le CRA ne transforme pas chaque bug en notification
La première décision consiste à vérifier le périmètre. L’obligation ouverte le 11 septembre 2026 vise les fabricants de produits comportant des éléments numériques et deux événements précis : la vulnérabilité activement exploitée et l’incident grave ayant un impact sur la sécurité du produit. Une erreur fonctionnelle sans conséquence de sécurité, une hypothèse non confirmée ou une vulnérabilité sans exploitation active établie ne doivent pas être mécaniquement traitées comme le même cas.
Cette distinction impose une qualification documentée. L’équipe produit décrit le composant, les versions touchées et la disponibilité du produit dans l’Union. L’équipe sécurité rassemble les indices d’exploitation ou les effets observés. Le juridique valide le rôle de l’entité et le périmètre du texte sans se substituer à l’analyse technique. Le responsable de notification décide et consigne le motif : signaler, approfondir immédiatement ou classer avec une justification révisable.
Un produit qui incorpore une bibliothèque libre n’efface pas la responsabilité du fabricant. À l’inverse, l’intendant open source visé par l’article 24, paragraphe 3, entre dans son propre calendrier au 11 décembre 2027. Cette nuance compte pour les entreprises qui évaluent déjà le coût et la maintenance de composants open source : la chaîne de dépendances doit identifier les acteurs, pas les confondre.
24 heures, 72 heures et rapport final : trois livrables différents
Le point de départ est la prise de connaissance, pas la fin de l’enquête. L’entreprise doit donc enregistrer une heure opposable : premier signal crédible reçu, personne qui l’a qualifié, éléments disponibles et décision d’escalade. Sans cette trace, le débat sur le délai se déplace après coup vers des courriels, tickets ou messages qui n’avaient pas été conçus comme preuve.
L’alerte précoce doit partir dans les 24 heures. Elle expose ce qui est connu à ce stade et permet une première coordination. La notification complète doit suivre dans les 72 heures. Elle enrichit le dossier avec l’évaluation de l’événement, les produits et territoires concernés, les mesures prises et les informations demandées par la plateforme. Le principe n’est pas d’attendre la certitude parfaite, mais de distinguer clairement faits confirmés, estimations et inconnues.
Le rapport final dépend du cas. Pour une vulnérabilité activement exploitée, il doit être remis au plus tard quatorze jours après qu’une mesure corrective ou d’atténuation est disponible. Pour un incident grave, l’échéance est fixée à un mois après la notification complète des 72 heures. Une seule échéance générique dans l’outil de ticketing produirait donc des rappels erronés.
Une procédure en quatre rôles, pas une boîte mail partagée
Quatre fonctions à nommer
Une organisation minimale peut tenir sur une page, à condition que les responsabilités soient explicites.
- Le déclarant interne reçoit le signal, ouvre l’événement et préserve les éléments initiaux. Support, SOC, équipe produit et canal de divulgation doivent converger vers le même mécanisme.
- Le qualificateur sécurité établit la nature de l’événement, son périmètre technique et les indices d’exploitation. Il travaille avec une nomenclature stable et signale ce qui reste incertain.
- Le décideur réglementaire confirme le rôle de fabricant, déclenche la notification et arbitre les informations sensibles. Un suppléant doit être nommé pour les nuits, week-ends et congés.
- Le déposant possède l’accès à la plateforme ENISA, contrôle les pièces, effectue l’envoi et conserve l’accusé ainsi que la version exacte soumise.
Ces rôles peuvent être tenus par moins de quatre personnes dans une petite structure. Ils ne doivent toutefois pas disparaître dans une responsabilité collective. Une matrice simple précise qui décide, qui exécute, qui contribue et qui doit être informé. Elle inclut le responsable produit, car la correction et sa diffusion appartiennent au cycle de vie du produit, pas seulement à la gestion de crise.
La plateforme unique évite de multiplier les dépôts nationaux initiaux, mais elle ne supprime ni la coordination avec le CSIRT compétent ni les autres obligations possibles. Une violation de données personnelles, un engagement contractuel client ou une réglementation sectorielle peut ouvrir un autre circuit. Le dossier CRA doit donc posséder des points de passage vers les autres procédures, sans fusionner leurs critères ni leurs délais.
Préparer le dossier avant d’avoir quelque chose à déclarer
Le délai de 24 heures est trop court pour découvrir l’inventaire du produit. La préparation commence par une fiche par famille de produits : entité fabricante, versions maintenues, composants critiques, territoires de mise à disposition, responsable produit, canal de correction et dépendances externes. Ce socle rejoint le travail d’intégration des outils et des API : les identifiants doivent rester cohérents entre catalogue produit, tickets, journalisation et dépôt de code.
Le dossier d’événement conserve au minimum la chronologie horodatée, la source du signal, les versions affectées, les indicateurs techniques, les décisions de qualification, les mesures de confinement, l’état de la correction, les communications et les accusés de dépôt. Les données collectées doivent être nécessaires et leur accès limité. Une capture d’écran isolée n’est pas une chronologie ; un ticket sans auteur ni historique n’est pas une preuve suffisante.
Automatiser la collecte peut réduire les oublis, mais l’automatisation ne doit pas décider seule qu’un événement est déclarable. Les mêmes principes valent pour la sécurisation des agents et automatisations : droits minimaux, validation humaine aux étapes sensibles et journal exploitable. Le coût du dispositif doit aussi intégrer astreinte, exercices, conservation et maintenance, pas seulement l’abonnement à un outil ; cette lecture en coût complet est développée dans le dossier sur le coût réel des systèmes numériques et de l’IA.
Un exercice trimestriel révèle les défauts avant le premier dépôt
Le test le plus utile part d’un scénario borné : une vulnérabilité confirmée sur une version distribuée dans plusieurs États membres, avec un indice d’exploitation reçu un vendredi soir. L’équipe doit retrouver l’entité fabricante, ouvrir l’horloge, joindre le décideur suppléant, produire une alerte précoce, enrichir la notification et planifier le rapport final. L’exercice s’arrête avant un envoi réel sur la plateforme, sauf environnement de formation officiellement prévu.
Quatre mesures suffisent pour une première revue : délai entre signal et qualification, délai entre qualification et décision, taux de champs préremplis avec une donnée à jour, et part des preuves retrouvées sans relance manuelle. Chaque échec reçoit un propriétaire et une date de correction. Le comité suivant examine la preuve de correction, pas seulement une déclaration d’intention.
Le CRA rend le signalement opérationnel dès 2026, alors que l’essentiel des exigences de cybersécurité du règlement s’appliquera à partir du 11 décembre 2027. Il serait donc dangereux de réduire le chantier à un formulaire. La procédure de notification doit alimenter dès maintenant le suivi des vulnérabilités, la maintenance et la capacité de correction du produit.
Sources officielles
- Commission européenne, « Cyber Resilience Act — Reporting obligations », mise à jour du 11 septembre 2026, consultée le 30 septembre 2026.
- Règlement (UE) 2024/2847 relatif aux exigences horizontales en matière de cybersécurité, texte officiel consulté le 30 septembre 2026.
- ENISA, lancement de la plateforme unique de notification CRA, 11 septembre 2026, consulté le 30 septembre 2026.
La prochaine action raisonnable
Nommer cette semaine le décideur et son suppléant, puis chronométrer un scénario à blanc. Si l’organisation ne peut pas prouver quand l’horloge a commencé ni qui possède l’accès à la plateforme, la procédure n’est pas encore opérationnelle.
