Le RRA est un problème de 2026, pas de 2027

Demandez à une équipe produit quand le Règlement sur la Résilience Cybernétique (RRA) entrera en vigueur pour elle, et la plupart répondront décembre 2027. Cette date correspond à l'application des exigences essentielles, de l'évaluation de conformité et du marquage CE, et c'est celle à laquelle chaque présentation de feuille de route se réfère. Pourtant, c'est une mauvaise date pour planifier.

Le RRA est entré en vigueur le 10 décembre 2024, et l'article 71 établit une échéance progressive, et non une date unique. Les dispositions relatives à la notification des organismes d'évaluation de la conformité (chapitre IV, articles 35 à 51) s'appliquent à partir du 11 juin 2026. Les obligations de reporting de l'article 14 entrent en vigueur le 11 septembre 2026. Seule la partie principale du règlement, les exigences essentielles de l'annexe I et la procédure de conformité menant au marquage CE, attendront le 11 décembre 2027 (Règlement (UE) 2024/2847, article 71; Commission européenne, « Le Règlement sur la Résilience Cybernétique : Résumé du texte législatif »). Ainsi, la première obligation contraignante pour un fabricant déjà concerné intervient environ quinze mois avant la date sur laquelle tout le monde planifie.

Il ne s'agit pas d'un plaidoyer pour commencer tôt. C'est une question d'ordre. L'équipe qui organise son travail sur le RRA en partant de la date de décembre 2027 pour le marquage CE place l'obligation de reporting en dernier, alors que le calendrier et les dépendances opérationnelles la placent en premier.

Ce qui entre en vigueur en 2026

L'article 14 n'est pas une simple obligation administrative que l'on peut ajouter à la fin. À partir du 11 septembre 2026, un fabricant d'un produit contenant des éléments numériques doit notifier toute vulnérabilité activement exploitée dans ce produit, ainsi que tout incident grave affectant sa sécurité, au CSIRT désigné comme coordinateur pour l'État membre concerné et à l'ENISA, via une plateforme de reporting unique. Le délai est impitoyable : un avertissement précoce dans les 24 heures suivant la prise de connaissance, une notification plus complète dans les 72 heures, et un rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective pour une vulnérabilité, ou dans le mois pour un incident grave (Règlement (UE) 2024/2847, article 14).

Lisez attentivement le déclencheur. Une « vulnérabilité activement exploitée » est définie comme une vulnérabilité pour laquelle il existe des preuves fiables qu'un code malveillant a été exécuté par un acteur sur un système sans l'autorisation du propriétaire du système (Règlement (UE) 2024/2847, article 3). Il ne s'agit pas d'un scénario hypothétique que l'on peut traiter à loisir. C'est un événement réel et daté qui déclenche un compte à rebours de 24 heures dès que vous en prenez connaissance, et cette obligation est en vigueur plus d'un an avant les exigences essentielles qui vous auraient permis de la détecter.

L'obligation de connaissance précède l'obligation de gestion

Voici l'inversion que les plans ancrés sur 2027 ignorent. Une obligation de reporting dans les 24 heures suivant la prise de connaissance revient, en pratique, à une obligation de savoir prendre connaissance. Vous ne pouvez pas déposer un avertissement précoce concernant une vulnérabilité activement exploitée dans votre produit si vous n'avez pas :

• Aucun canal par lequel les informations sur l'exploitation vous parviennent,
• Aucun inventaire qui vous indique quelles versions livrées contiennent le composant affecté,
• Aucune règle de triage pour déterminer si un incident est « grave » avant la fermeture de la fenêtre de 72 heures.

Chacune de ces capacités est décrite dans l'annexe I, partie II du même règlement : maintenir une liste des matériaux logiciels (SBOM) couvrant au moins les dépendances de premier niveau dans un format lisible par machine, mettre en œuvre une politique de divulgation coordonnée des vulnérabilités avec un point de contact pour les signalements, et corriger les vulnérabilités sans délai via des mises à jour de sécurité (Règlement (UE) 2024/2847, annexe I, partie II). Ces exigences sont légalement applicables à partir du 11 décembre 2027. Mais l'obligation de reporting qui vous lie dès le 11 septembre 2026 est difficile à satisfaire de manière fiable sans elles. La loi vous permet de reporter le processus de gestion à 2027 ; elle ne vous permet pas de reporter les conséquences une fois la prise de connaissance effective.

Ainsi, l'effet pratique de l'article 14, pour quiconque est réellement concerné, est d'avancer de quinze mois la nécessité de mettre en place une partie du modèle opérationnel décrit dans l'annexe I, partie II. Non pas parce que les exigences essentielles s'appliquent plus tôt, mais parce que l'obligation de reporting est difficile à satisfaire de manière fiable sans l'épine dorsale opérationnelle que ces exigences décrivent.

L'objection, et pourquoi elle ne tient pas

Un praticien attentif pourrait objecter, et cette objection mérite d'être prise au sérieux. L'article 14 est restrictif. Il ne s'applique qu'aux vulnérabilités activement exploitées et aux incidents graves, et non à la routine des vulnérabilités de faible gravité. Un produit bien géré peut passer longtemps sans événement signalable. Alors pourquoi ne pas mettre en place un processus de reporting minimal à partir de septembre 2026, maintenir le développement de la gestion des vulnérabilités sur la voie de 2027, et accepter le faible risque d'un déclenchement précoce ?

Trois raisons pour lesquelles cette approche minimaliste est un piège.

Premièrement, le cadre des « événements rares » inverse le risque. L'obligation n'est pas contraignante parce qu'elle se déclenche souvent. Elle est dangereuse parce qu'elle se déclenche de manière imprévisible et lance un compte à rebours de 24 heures que vous ne pouvez pas interrompre pour construire des capacités. La semaine où vous avez une vulnérabilité activement exploitée est précisément celle où vous ne pouvez pas vous permettre de constituer une SBOM pour déterminer quels clients sont affectés.

Deuxièmement, la forme de responsabilité est différente d'un écart de conformité, et pire. Une posture incomplète au regard de l'annexe I se révèle lors d'une évaluation, dans une salle, avec une chance de remédier. Une notification manquée dans les 24 heures est un échec discret, daté et prouvable extérieurement. Elle crée un dossier qui peut ensuite être utilisé dans des discussions de supervision ou d'application de la loi, et la trace de reporting que vous constituez à partir de septembre 2026 fait partie de ce dossier. Un processus minimal n'est pas une version réduite de la conformité ; c'est une trace documentée des moments où vous n'étiez pas prêt.

Troisièmement, un processus de reporting sans processus de gestion derrière lui n'est qu'une mascarade. Pouvoir soumettre un formulaire à l'ENISA dans les 24 heures est sans valeur si vous ne pouvez pas répondre aux questions réelles du formulaire : quelles versions sont affectées, quelle est la mesure corrective, quand sera-t-elle livrée. L'obligation de reporting et les exigences de gestion forment un seul système observé à deux moments différents. Vous ne pouvez pas acheter la partie observable et sauter la partie machine.

Planifiez à rebours à partir de septembre 2026

La correction pratique n'est pas « faites tout maintenant ». Il s'agit d'identifier le sous-ensemble minimal des exigences essentielles de 2027 que l'article 14 rend indispensables en 2026, et d'organiser ce sous-ensemble en fonction de la date de septembre 2026 plutôt que de décembre 2027.

Ce minimum pour la préparation au reporting est plus petit que l'ensemble du programme de l'annexe I et suffisamment précis pour être planifié :

• Une liste des matériaux logiciels (SBOM) à jour pour chaque produit livré, couvrant au moins les dépendances de premier niveau, afin de pouvoir évaluer l'impact d'une vulnérabilité exploitée en quelques heures, et non en semaines.
• Un canal de réception surveillé et une politique de divulgation coordonnée des vulnérabilités, afin que les signalements d'exploitation et les rapports tiers vous parviennent réellement et déclenchent le compte à rebours dont vous êtes responsable.
• Une règle écrite de triage des incidents et de gravité permettant de classer un événement comme signalable dans la fenêtre de 72 heures, sans avoir à convoquer un comité.
• Un responsable désigné et un chemin de soumission éprouvé vers le CSIRT coordinateur et l'ENISA, testé sur la plateforme de reporting avant d'en avoir besoin en situation réelle.

Aucune de ces mesures ne nécessite les normes harmonisées ou la procédure de conformité qui sont encore en cours de finalisation pour 2027. Tout cela peut être construit dès maintenant, et tout cela constitue un acompte sur les obligations de 2027 plutôt que du travail jetable. Les fabricants de produits importants de l'annexe III, classe II ont une seconde raison de ne pas attendre : leur procédure de conformité nécessite généralement un organisme notifié, et ces organismes ne peuvent être désignés qu'à partir de l'entrée en vigueur du chapitre IV, le 11 juin 2026. La capacité d'évaluation est limitée, et les files d'attente se forment aux dates butoirs, et non avant.

La règle à retenir

Lorsqu'un règlement s'applique par étapes, la date médiatique est généralement la dernière, et la dernière date est la moins utile pour la planification. Lisez plutôt l'échéancier progressif et demandez-vous quelle obligation les autres dépendent. Pour le RRA, l'obligation de reporting de l'article 14 arrive en premier dans le calendrier et dans le graphe des dépendances : vous ne pouvez pas signaler ce que vous ne pouvez pas détecter, et vous ne pouvez pas détecter sans l'épine dorsale de gestion que les exigences de 2027 décrivent. Planifiez le travail à rebours à partir du 11 septembre 2026, et non en avant vers le 11 décembre 2027, et l'ordre s'imposera de lui-même.

Si votre tâche immédiate consiste à déterminer quels de vos produits sont concernés par le RRA et ce que l'obligation de reporting de septembre 2026 exige concrètement pour chacun, cette analyse de portée et de recoupement est le type de travail que ISMS Copilot est conçu pour accélérer. Pour de nombreuses équipes, le travail autour du marquage CE est une étape de 2027 ; la préparation à l'article 14 est une étape de 2026. Planifiez en priorité la première.

Il s'agit d'une analyse pratique de conformité, et non de conseils juridiques. Confirmez la portée et les obligations de votre produit en vous référant au règlement lui-même et, le cas échéant, à votre autorité compétente ou à un conseiller juridique.