↓ Version .md brute (pour NotebookLM)

Vingt-quatre heures pour parler : le Cyber Resilience Act et l'obligation de signalement du 11 septembre 2026

Le contexte

Le 11 septembre 2026, une règle discrète mais structurante entre en application dans l'ensemble de l'Union européenne. Elle tient dans un seul article — l'article 14 du règlement (UE) 2024/2847, plus connu sous le nom de *Cyber Resilience Act*, ou CRA — et elle impose au fabricant d'un produit numérique de signaler aux autorités, dans les vingt-quatre heures suivant sa prise de connaissance, toute vulnérabilité de son produit qui est activement exploitée, ainsi que tout incident grave affectant la sécurité de ce produit.

Le CRA a été adopté le 23 octobre 2024. Il poursuit un objectif que le droit européen n'avait jamais formulé aussi frontalement : faire porter la sécurité des produits numériques par ceux qui les conçoivent, et non par ceux qui les achètent. Le règlement impose des exigences essentielles de cybersécurité dès la conception et pendant tout le cycle de vie, organise des procédures d'évaluation de la conformité, et fait du marquage CE le signe visible de cette conformité. Il s'applique aux fabricants, mais aussi aux importateurs et aux distributeurs.

Son application est échelonnée. L'Agence nationale de la sécurité des systèmes d'information, l'ANSSI, résume ce calendrier en trois jalons. De juin à décembre 2026, les organismes d'évaluation de la conformité sont accrédités puis notifiés. En septembre 2026, les obligations de signalement entrent en vigueur. En décembre 2027, l'ensemble du règlement s'applique et les autorités de surveillance du marché commencent leurs contrôles. Autrement dit : la première obligation réellement contraignante que rencontreront les industriels n'est pas une obligation de sécuriser, c'est une obligation de dire.

Ce que l'obligation exige précisément

Le mécanisme repose sur une séquence à trois temps, identique dans sa structure pour les vulnérabilités et pour les incidents graves, mais avec un horizon final différent. Premier temps : l'alerte précoce, dans les vingt-quatre heures de la prise de connaissance — non pas un rapport complet, mais un signal. Deuxième temps : la notification proprement dite, dans les soixante-douze heures, qui apporte des informations générales sur le produit, une première évaluation de la nature de l'exploitation ou de l'incident, et les mesures correctives ou d'atténuation déjà prises ou disponibles pour les utilisateurs. Troisième temps : le rapport final, dû au plus tard quatorze jours après la mise à disposition d'une mesure corrective pour une vulnérabilité, ou dans le mois suivant la notification à soixante-douze heures pour un incident grave.

Le destinataire n'est pas unique, mais le geste l'est. Le fabricant dépose sa notification sur la plateforme unique de signalement, la *Single Reporting Platform*, gérée par l'ENISA, l'agence de l'Union européenne pour la cybersécurité, et opérationnelle à compter du 11 septembre 2026. Cette plateforme transmet simultanément l'information au CSIRT désigné comme coordinateur dans l'État membre où le fabricant est établi, puis, sans délai, aux CSIRT des autres États membres où le produit est disponible, ainsi qu'à l'ENISA. Pour la France, le CSIRT coordinateur est le CERT-FR, au sein de l'ANSSI. Les CSIRT nationaux partagent ensuite certaines informations avec leurs autorités de surveillance du marché respectives, afin que celles-ci puissent exercer leurs pouvoirs de contrôle.

Une soupape existe : dans des circonstances exceptionnelles, notamment à la demande du fabricant, la diffusion de la notification peut être retardée pour des motifs justifiés tenant à la cybersécurité, pour une durée limitée au strict nécessaire — c'est l'article 16, paragraphe 2, précisé par un règlement délégué de la Commission. La logique se comprend d'elle-même : diffuser trop tôt l'existence d'une faille exploitée non corrigée revient à en élargir la surface d'exploitation.

La plateforme est enfin ouverte aux signalements volontaires : toute personne physique ou morale peut l'utiliser pour déclarer une vulnérabilité ou un incident. Le point mérite d'être souligné pour la communauté de la recherche en sécurité, car il crée un canal européen unifié là où n'existaient que des points de contact dispersés.

La définition qui change tout

Le cœur technique du dispositif n'est pas dans les délais, il est dans une définition. L'article 3, point 42, du règlement définit la vulnérabilité activement exploitée comme celle « pour laquelle il existe une preuve fiable » qu'un acteur malveillant l'a exploitée dans un système sans l'autorisation du propriétaire de ce système.

Cette formulation contient deux verrous. Le premier est celui de la preuve fiable : le régime ne se déclenche pas sur une hypothèse, une inquiétude ou un score de gravité. Il faut des éléments — journaux, télémétrie, indicateurs de compromission, rapport d'incident client — établissant que l'exploitation a eu lieu. Le second verrou est celui de l'absence d'autorisation, qui exclut par construction la recherche de bonne foi : un test d'intrusion mené sous contrat, un audit de laboratoire, une preuve de concept publiée, ou une vulnérabilité de type *zero-day* découverte sans trace d'exploitation malveillante préalable ne sont pas des vulnérabilités activement exploitées et ne déclenchent pas l'obligation à vingt-quatre heures.

L'implication vaut d'être méditée : la même faille, techniquement identique, change de régime selon ce qu'on peut prouver de son usage par des tiers. La qualification dépend donc de la capacité du fabricant à observer son propre parc. Un éditeur qui ne collecte aucune télémétrie et ne reçoit aucun signalement client ne « prend jamais connaissance » d'une exploitation — et ne déclenche jamais son chronomètre. Ce n'est pas une stratégie de conformité recommandable, mais c'est une tension réelle du dispositif, que les premiers mois d'application permettront d'observer.

Le périmètre, ou pourquoi cela concerne à peu près tout le monde

Le CRA s'applique aux « produits comportant des éléments numériques », définis comme les produits logiciels ou matériels et leurs solutions de traitement de données à distance, y compris les composants logiciels ou matériels mis sur le marché séparément. L'ANSSI décrit quatre catégories.

La catégorie « par défaut » couvre tous les produits qui ne sont ni importants ni critiques : l'agence cite explicitement les brosses à dents électriques, les smartphones et les ordinateurs. Les produits importants de classe I regroupent dix-neuf types de produits — infrastructures de gestion de clés, SIEM, gestionnaires de mots de passe, systèmes d'exploitation, routeurs, navigateurs, domotique, jouets connectés. La classe II en compte quatre : hyperviseurs, pare-feu et systèmes de détection ou de prévention d'intrusion, microprocesseurs et microcontrôleurs résistants à l'altération. Les produits critiques comprennent les modules matériels de sécurité de type HSM, les cartes à puce et assimilés, et les passerelles de compteurs intelligents.

Restent hors champ, parce qu'elles relèvent de régimes sectoriels distincts : dispositifs médicaux et de diagnostic in vitro, systèmes et composants automobiles, produits certifiés de l'aviation civile, équipements marins, et produits développés exclusivement à des fins de sécurité nationale, de défense ou de traitement d'informations classifiées.

L'architecture française et les sanctions

Trois rôles, trois institutions. L'ANSSI, dirigée depuis janvier 2023 par Vincent Strubel, est autorité notifiante : elle évalue, contrôle et notifie les organismes d'évaluation de la conformité, sur la base d'une accréditation délivrée par le COFRAC. Elle est aussi, via le CERT-FR, le CSIRT coordinateur qui centralise les signalements et coordonne les remédiations avec les fabricants. La surveillance du marché, en revanche, revient à l'Agence nationale des fréquences, l'ANFR, avec l'ANSSI en soutien technique. L'ANFR pourra imposer le retrait du marché d'un produit ou des amendes pouvant atteindre quinze millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial du fabricant.

Un point de méthode enfin, rappelé par l'ANSSI : la conformité ne se suspend pas à la publication des normes harmonisées. Ces normes facilitent la démonstration de conformité et emportent une présomption, mais leur usage demeure volontaire ; les exigences essentielles du règlement s'appliquent sans attendre.

Les enjeux pratiques

Ce que le CRA transforme réellement, ce n'est pas le niveau de sécurité exigé — les exigences essentielles ressemblent à ce que toute organisation mature pratique déjà — mais la vitesse de la chaîne de décision. Vingt-quatre heures, ce n'est pas un délai administratif : c'est un délai d'astreinte. Cela suppose un titulaire et un suppléant identifiés, un modèle de notification pré-rempli, un critère écrit de ce qui constitue une « preuve fiable » d'exploitation, et un exercice à blanc mené au moins une fois avant l'échéance.

Cela suppose aussi un SBOM tenu à jour. L'annexe I, partie II, impose, pendant la période de support, un inventaire lisible par machine des composants logiciels — au format SPDX ou CycloneDX — ainsi qu'une politique de divulgation coordonnée assortie d'un point de contact accessible, dont la mise en œuvre technique la plus courante est le fichier security.txt. Sans SBOM exploitable, la question « quelles versions de nos produits embarquent cette dépendance ? » ne trouve pas de réponse en vingt-quatre heures ; avec un SBOM interrogeable, elle en trouve une en quelques minutes.

Comparé aux régimes voisins, le CRA occupe une place singulière. L'article 33 du RGPD fait notifier celui qui subit la violation de données ; NIS 2, l'entité essentielle ou importante qui subit l'incident. Le CRA, lui, fait notifier celui qui a écrit le code, même lorsque ses clients n'ont rien remarqué — un déplacement du centre de gravité de la responsabilité vers l'amont de la chaîne d'approvisionnement logicielle.

Angles de lecture pour NotebookLM (à coller dans « Personnaliser » de l'Audio Overview)

Cinq entrées possibles dans ce sujet, selon ce que l'on cherche à en tirer. Choisissez-en une et collez-la telle quelle dans le champ de personnalisation de l'Audio Overview.

Angle 1 — Audit offensif et points de contrôle techniques. Traite ce document du point de vue d'un auditeur qui doit vérifier, avant le 11 septembre 2026, si un éditeur est réellement capable de tenir le délai de vingt-quatre heures. Détaille les artefacts à demander en priorité — SBOM interrogeable, security.txt publié et joignable, procédure de notification écrite avec titulaire et suppléant, critère documenté de la « preuve fiable » d'exploitation, journaux de télémétrie permettant d'établir cette preuve — et explique comment un test d'intrusion autorisé se distingue juridiquement d'une exploitation active au sens de l'article 3, point 42.

Angle 2 — Architecture et API du signalement. Concentre-toi sur la mécanique de la plateforme unique de signalement de l'ENISA : flux de soumission en trois étapes, routage automatique vers le CSIRT coordinateur puis vers les CSIRT des autres États membres et l'ENISA, partage avec les autorités de surveillance du marché, et report exceptionnel de diffusion prévu à l'article 16, paragraphe 2. Discute de la façon dont une organisation pourrait instrumenter cette chaîne — pré-remplissage automatique depuis un système de gestion d'incidents, corrélation avec le SBOM, horodatage de la prise de connaissance — et des risques de sécurité propres à une plateforme qui concentre l'information sur des failles exploitées non corrigées.

Angle 3 — Comparaison avec les autres régimes de notification déjà traités dans le dépôt. Mets ce dispositif en regard des régimes voisins déjà couverts par Droit Vivant : l'article 33 et l'article 34 du RGPD, mobilisés à propos de la violation de données du ministère de l'Éducation nationale, et l'obligation de sécurité de l'article 32 discutée à propos de la DGFiP. Explique en quoi le CRA renverse le point d'imputation — l'éditeur du produit plutôt que l'entité victime —, compare les délais (24 h contre 72 h), les destinataires (CSIRT et ENISA contre autorité de protection des données et personnes concernées) et les plafonds de sanction (15 M€ ou 2,5 % contre 20 M€ ou 4 %).

Angle 4 — Veille réglementaire automatisée sur le CRA. Propose une méthode concrète pour construire une veille continue sur la mise en œuvre du Cyber Resilience Act : sources à surveiller (actualités de l'ANSSI, portail de l'ANFR, publications de l'ENISA sur la plateforme unique, actes d'exécution et actes délégués publiés au Journal officiel de l'Union européenne, portail de mise en œuvre de la Commission), fréquence utile, mots-clés de filtrage, et déclencheurs d'alerte pertinents — publication de normes harmonisées, désignation des premiers organismes notifiés en France, nouveaux actes délégués précisant le report de diffusion.

Angle 5 — Prospective contentieuse et réglementaire. Explore les zones de friction que les premiers mois d'application vont révéler. Qui apprécie le caractère « fiable » de la preuve d'exploitation, et selon quels standards ? Que devient l'obligation pour un fabricant qui n'observe pas son parc et prétend n'avoir jamais pris connaissance de l'exploitation ? Comment s'articulent le CRA et l'obligation de notification RGPD lorsqu'une même faille produit une violation de données ? Et quelle pression le régime fait-il peser sur les chaînes de dépendances open source, dont les mainteneurs ne sont ni fabricants ni distributeurs mais dont le code se retrouve dans des produits soumis au règlement ?