--- title: "L'obligation de notification du Cyber Resilience Act est en vigueur. Chez la plupart des fabricants, les processus ne sont encore que du théâtre. | Guardian360" description: "L'obligation de notification du Cyber Resilience Act est entrée en vigueur le 11 septembre 2026 : les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents graves dans un délai de 24 heures. Les données d'enquête révèlent une forte prise de conscience mais une faible préparation. Ce que vous devez déclarer, à qui cela s'applique, et à quoi ressemble réellement le fait d'être prêt." url: https://guardian360.net/fr/blog/cra-reporting-duty-is-live/ locale: fr source: guardian360.net --- [← Tous les articles](https://guardian360.net/fr/blog/) Opinion # L'obligation de notification du Cyber Resilience Act est en vigueur. Chez la plupart des fabricants, les processus ne sont encore que du théâtre. Par Jan Martijn Broekhof · 11 septembre 2026 Aujourd’hui, le 11 septembre 2026, l’obligation de notification du Cyber Resilience Act (CRA) entre en vigueur dans toute l’Union européenne. Pas en décembre 2027, lorsque les exigences essentielles applicables aux produits entreront en jeu et que tout le monde s’attend au véritable moment de vérité. Aujourd’hui. Si vous fabriquez un produit comportant des éléments numériques et que vous le vendez sur le marché de l’UE, le compte à rebours de votre première notification commence à courir dès cet instant, que votre organisation ait ou non pris note de la date. J’écrivais en juillet que le Cyber Resilience Act était la réglementation que personne ne suivait d’assez près, celle qui peut retirer un produit du marché plutôt que se contenter de sanctionner l’entreprise qui le commercialise. Cet article se concentrait sur le tableau d’ensemble de la conformité : le périmètre, la catégorisation, la relation avec NIS2. Celui-ci porte sur l’obligation bien plus étroite et bien plus tranchante qui vient d’entrer en vigueur, et sur l’écart inconfortable entre le nombre de fabricants qui affirment la connaître et le nombre de ceux qui sont réellement capables d’agir dans les délais que la loi leur accorde. ## La date que personne ne surveillait La plupart des commentaires sur le CRA gravitent encore autour de décembre 2027, et cela se comprend, puisque c’est à ce moment que les exigences essentielles de cybersécurité et les obligations d’évaluation de la conformité s’appliqueront pleinement. Mais l’article 14 du règlement a réservé une date distincte, plus précoce, spécifiquement pour la notification : à partir du 11 septembre 2026, les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents graves affectant leurs produits, et cette obligation s’applique aux produits déjà présents sur le marché, et pas seulement aux nouveaux lancements. La Commission européenne a publié ses orientations pratiques à ce sujet le 27 juillet 2026, quelques semaines seulement avant l’entrée en vigueur de la date. C’est une fenêtre étroite pour une obligation assortie d’un premier délai de 24 heures. Les exigences essentielles de décembre 2027 laissent aux fabricants environ quinze mois de préparation à partir de maintenant. L’obligation de notification en a laissé bien moins. ## Que devez-vous exactement déclarer ? C’est la question qui fait trébucher, et il vaut la peine d’y répondre avec précision plutôt qu’en termes généraux. Vous déclarez une vulnérabilité activement exploitée, c’est-à-dire lorsqu’il existe des preuves crédibles que quelqu’un l’utilise contre votre produit en ce moment même. Vous déclarez un incident grave, c’est-à-dire un événement qui compromet réellement la sécurité de votre produit, et non une simple faiblesse théorique. Ce que vous ne déclarez pas, c’est chaque CVE attribuée à votre code, chaque constat issu de votre propre test d’intrusion, ou chaque signalement reçu via votre programme de divulgation responsable ou votre bug bounty, sauf s’il existe des preuves d’une exploitation effective. Le webinaire organisé le 27 août par le ministère néerlandais des Affaires économiques et de la Politique climatique et le National Cyber Security Centre (NCSC) a été catégorique sur cette distinction, et pour de bonnes raisons : sans elle, les fabricants noieraient leur CSIRT national sous le bruit ou, pire, présumeraient que chaque signalement de vulnérabilité exige la même urgence de 24 heures et épuiseraient l’équipe censée traiter ceux qui comptent vraiment. Vous pouvez toujours signaler volontairement les cas de moindre gravité, et il y a de bonnes raisons de prendre cette habitude. Mais l’obligation légale porte spécifiquement sur l’exploitation active et les incidents graves, et savoir où passe cette ligne est la première chose que votre processus de réponse aux incidents doit maîtriser. ## Le compte à rebours ne s’arrête pas pour votre réunion de réponse aux incidents Une fois que vous savez, le calendrier est échelonné et implacable. Une alerte précoce doit être émise dans les 24 heures suivant la prise de connaissance. Une notification plus complète suit dans les 72 heures, couvrant ce que vous savez à ce stade sur la nature, l’impact et les mesures d’atténuation. Un rapport final clôt le dossier : quatorze jours après qu’une mesure corrective est devenue disponible pour une vulnérabilité, ou un mois pour un incident grave, selon les orientations de la Commission européenne. L’analyse de Freshfields sur cette nouvelle obligation soulève un point qui mérite réflexion : les délais de notification commencent à courir dès l’instant où vous prenez connaissance des faits, et le compte à rebours ne s’interrompt ni le week-end ni les jours fériés. Il n’existe aucun délai de grâce parce que votre responsable sécurité était en conférence, ou parce que l’incident s’est produit un vendredi soir. Si votre organisation ne dispose pas déjà d’un processus défini précisant qui évalue un signalement, qui décide s’il franchit le seuil et qui le soumet, vous construisez ce processus pour la première fois sous un délai de 24 heures déjà en cours, ce qui est précisément le pire moment pour construire quoi que ce soit. La notification elle-même transite par votre CSIRT national, le NCSC aux Pays-Bas, et par le Single Reporting Platform à l’échelle de l’UE exploité par l’ENISA, de sorte qu’un fabricant en Belgique, en Allemagne ou ailleurs dans l’UE suit le même calendrier échelonné via son propre point de contact national. Les modalités varient légèrement d’un État membre à l’autre ; l’obligation et les délais, eux, ne varient pas. ## Pourquoi les chiffres de préparation sont-ils aussi mauvais ? C’est ici que l’affirmation selon laquelle « chez la plupart des fabricants, les processus ne sont que du théâtre » doit faire ses preuves, et les données d’enquête la confirment plus crûment que je ne l’anticipais. Le SME Cyber Resilience Maturity Assessment Model de l’ENISA, publié le 13 juillet 2026 et fondé sur un travail de terrain mené auprès de 194 organisations dans 31 pays, a révélé une forte prise de conscience du CRA mais une préparation pratique systématiquement faible, la réponse aux incidents et la gestion du cycle de vie des produits ressortant comme les deux domaines les plus faibles dans l’ensemble. Avoir conscience qu’une loi existe n’équivaut pas à disposer d’un processus capable d’agir dans une fenêtre de 24 heures. L’étude de la Linux Foundation et de l’OpenSSF sur la préparation au CRA en 2026, tirée de 843 répondants, raconte une histoire similaire sous un autre angle. Soixante-six pour cent ne savaient toujours pas ce qu’ils devaient concrètement faire pour se mettre en conformité, un chiffre qui n’avait guère bougé par rapport aux 62 pour cent de l’année précédente. Seuls 41 pour cent des fabricants s’attendaient à atteindre la pleine conformité avant l’échéance de décembre 2027, et seuls 34 pour cent identifiaient correctement cette date au départ. Parmi les répondants qui connaissaient le CRA, 54 pour cent restaient incapables de distinguer clairement les obligations d’un fabricant de celles d’un dépositaire (steward). Rien de tout cela n’est un reproche adressé à une quelconque équipe de conformité. Cela traduit une réglementation passée de l’abstrait à l’opérationnel plus vite que la plupart des processus organisationnels ne pouvaient suivre. Mais cela signifie qu’une part significative des fabricants qui lisent ces lignes ont franchi la ligne du 11 septembre sans aucun processus éprouvé derrière eux, ce qui est exactement le scénario que l’obligation de notification a été conçue pour révéler. ## Qui doit réellement déclarer ? Dans le cadre du CRA, l’obligation de notification incombe au fabricant, l’entité qui met sur le marché de l’UE un produit comportant des éléments numériques sous son propre nom ou sa propre marque, et la taille de l’organisation ne vous en exonère pas. Un importateur ou un distributeur ne porte généralement pas d’obligation de notification autonome, sauf s’il vend sous sa propre marque ou modifie substantiellement le produit, auquel cas il devient de fait le fabricant de ce produit. Les dépositaires de logiciels open source sont soumis à une version allégée de cette même obligation, qui reflète la relation différente qu’ils entretiennent avec les produits qu’ils maintiennent. Les petites et micro-entreprises entrent elles aussi pleinement dans le périmètre ; la seule concession que le NCSC néerlandais a confirmée est l’absence de sanction en cas de non-respect du délai strict de 24 heures dans cette catégorie, ce qui constitue une atténuation, pas une exemption. Un détail mérite d’être signalé car il crée une réelle confusion : le CRA lui-même n’exige aucun enregistrement préalable avant de pouvoir déclarer. Vous n’avez besoin ni d’un compte ni d’un identifiant pour soumettre une notification. Il s’agit d’un choix de conception délibéré, distinct de l’obligation d’enregistrement qui existe au titre de la Cyberbeveiligingswet (la transposition néerlandaise de NIS2) pour les organisations qui relèvent également de cette loi. Les deux obligations coexistent en parallèle, et non comme un processus unique combiné, et les confondre est une erreur facile à commettre. ## À quoi ressemble réellement le fait d’être « prêt » ? Se préparer à l’obligation de notification du CRA n’est pas compliqué en principe. C’est exigeant en pratique, ce qui est un problème différent. Commencez par un inventaire honnête de ce que contiennent réellement vos produits, idéalement au moyen d’un Software Bill of Materials (SBOM), car vous ne pouvez pas évaluer si une vulnérabilité signalée vous concerne si vous ignorez quels composants vous distribuez. Fixez à l’avance vos propres seuils internes définissant ce qui constitue une exploitation active ou un incident grave, afin que ce jugement ne soit pas rendu pour la première fois sous pression. Construisez une chaîne d’escalade avec des rôles nommés : qui donne l’alerte, qui décide, qui soumet. Rédigez dès maintenant des modèles pour l’alerte précoce, la notification à 72 heures et le rapport final, pendant que personne n’est sous la contrainte d’un délai. Et alignez tout cela avec les autres régimes au titre desquels vous déclarez déjà, car un nombre non négligeable de fabricants qui lisent ces lignes relèvent aussi de la Cyberbeveiligingswet ou de l’AVG, et faire tourner trois processus de notification non coordonnés constitue un risque en soi. C’est, et ce n’est pas un hasard, la même discipline que je défendais en juillet lorsque j’écrivais sur les exigences de conformité plus larges du CRA : sachez ce que vous détenez, catégorisez-le honnêtement, et constituez la documentation avant que le régulateur ne la réclame. L’obligation de notification a simplement fait passer cet argument de « à terme » à « maintenant ». Si un client vous annonçait ce matin que quelqu’un exploite activement une vulnérabilité dans votre produit, votre organisation saurait-elle, dans les 24 heures, qui prend exactement ce signalement en charge ? Si la réponse honnête est « on trouverait bien une solution », alors l’obligation de notification n’est pas entrée en vigueur aujourd’hui pour rien. ## Sources - European Commission, Cyber Resilience Act, Reporting obligations, Shaping Europe’s Digital Future: [digital-strategy.ec.europa.eu/en/policies/cra-reporting](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) - ENISA, SME Cyber Resilience Maturity Assessment Model, published 13 July 2026. - Linux Foundation Research, Linux Foundation Europe, and OpenSSF, “The CRA Readiness Reality: What Changed (and What Didn’t) Between 2025 and 2026?”, June 2026: [linuxfoundation.org](https://www.linuxfoundation.org/blog/the-cra-readiness-reality-what-changed-and-what-didnt-between-2025-and-2026) - Freshfields, “Cyber Resilience Act reporting obligations take effect on 11 September 2026”: [freshfields.com](https://www.freshfields.com/en/our-thinking/blogs/technology-quotient/cyber-resilience-act-reporting-obligations-take-effect-on-11-september-2026-102nzmk) - Ministry of Economic Affairs and Climate Policy and National Cyber Security Centre (NCSC), Cyber Resilience Act, Themasessie Meldplicht (webinar), 27 August 2026.