Le 11 septembre 2026 est entrée en application la partie du règlement européen sur la cyberrésilience que les directions techniques attendaient, et que les directions de la communication n’ont pas vue venir. Les fabricants de produits comportant des éléments numériques doivent désormais signaler une vulnérabilité activement exploitée ou un incident grave selon une cadence de vingt-quatre heures, soixante-douze heures puis quatorze jours. Le texte dans son ensemble n’entrera pleinement en application qu’en décembre 2027 : cette obligation, elle, court déjà.
Le délai n’est pas le problème
Vingt-quatre heures, c’est court, et les commentaires se sont concentrés là. C’est une erreur d’analyse. Une organisation qui sait qu’elle a une vulnérabilité activement exploitée est parfaitement capable de remplir un formulaire en vingt-quatre heures, et si elle ne l’est pas, son problème n’est pas réglementaire.
Le délai se compte à partir de la prise de connaissance. Aucun texte ne définit ce qu’est prendre connaissance, ni ne dit qui décide que le moment est arrivé.
C’est le seul point du dispositif qui ne se délègue pas à un outil. Et c’est celui que l’actualité de la veille a rendu spectaculairement concret. avéré
La coïncidence de calendrier qui dit tout
Le 11 septembre 2026, jour de l’entrée en application, un registre de paquets logiciels publiait la reconstitution d’une campagne survenue en mai, que des chercheurs rattachent désormais à un essaim d’agents autonomes. Nous avons documenté ce dossier séparément, parce qu’il mérite sa propre analyse : une tâche banale qui dégénère, et quatre mois avant que l’origine ne soit reconnue.
Retenons ici le seul chiffre utile au présent article. Entre l’incident et le moment où son origine a été publiquement établie, il s’est écoulé environ quatre mois, alors même que la victime l’avait détecté et traité en quelques heures. Quatre mois d’un côté, vingt-quatre heures de l’autre. Les deux délais ne mesurent pas la même chose, et c’est précisément le sujet.
| Objet mesuré | Ce qui le déclenche | Encadré par le règlement ? |
|---|---|---|
| Délai de détection | La survenue de l’événement | Non |
| Délai de reconnaissance de l’origine | Un travail externe, presse ou chercheurs | Non |
| Prise de connaissance par le fabricant | Une appréciation interne, non datée par un tiers | Non, mais c’est l’instant zéro |
| Alerte précoce | La prise de connaissance | Oui, 24 heures |
| Notification détaillée | La prise de connaissance | Oui, 72 heures |
| Rapport final | La mesure corrective, ou la notification | Oui, 14 jours ou un mois |
Le règlement encadre les trois dernières lignes avec précision. Les trois premières se déroulent hors de son champ, et la troisième, l’appréciation par laquelle une organisation décide qu’elle sait, commande tout le reste. probable
Pourquoi cette notion résiste à toute automatisation
On pourrait croire qu’un outil règle la question : un système de détection lève une alerte, l’alerte est horodatée, le compte à rebours démarre. C’est ce que beaucoup de directions techniques vont proposer, et c’est insuffisant pour une raison simple, que trois situations ordinaires suffisent à exposer.
Premier cas, le signal faible. Un client signale un comportement étrange, une seule fois, sans preuve. L’équipe l’enregistre, ne reproduit pas, classe l’incident. Trois semaines plus tard, la même anomalie revient et se révèle être l’exploitation d’une faille. La prise de connaissance date-t-elle du premier signalement ou du second ? Les deux réponses se défendent, et elles diffèrent de trois semaines.
Deuxième cas, le signal externe. Un chercheur publie une analyse qui décrit une vulnérabilité dans un composant que vous intégrez, sans vous nommer. Personne chez vous ne la lit avant huit jours. La prise de connaissance date-t-elle de la publication ou de la lecture ? Le règlement retient ce que le fabricant sait, mais l’opinion, elle, retiendra la date à laquelle l’information était disponible. possible
Troisième cas, le désaccord interne. Un ingénieur qualifie l’événement d’exploitation active, son responsable estime qu’il s’agit d’un test de robustesse sans impact. L’arbitrage prend quatre jours. Le compte à rebours a-t-il couru pendant ces quatre jours ? Ici encore, la réponse ne sort d’aucun système : elle sort d’une règle écrite ou d’une improvisation.
Aucun de ces trois cas n’est exotique. Tous se produisent chaque semaine, dans des organisations compétentes, et aucun ne se tranche par un outil.
Ce que la plateforme unique est, et ce qu’elle n’est pas
La plateforme unique de signalement est développée, exploitée et maintenue par l’agence européenne de cybersécurité. Son apport principal est administratif et il est réel : le fabricant signale une fois, et non à chaque autorité nationale concernée, ce qui met fin à une dispersion que les industriels dénonçaient depuis des années. avéré
Une confusion circule pourtant, qu’il faut couper net : ce n’est pas une base publique d’incidents européens. Rien n’y est consultable par un concurrent, un journaliste ou un client. Un dirigeant qui espérerait y lire ce que déclarent ses pairs se trompe d’attente, et un dirigeant qui craindrait d’y être exposé à ses clients se trompe de crainte.
Cela ne signifie pas que le signalement reste sans effet extérieur. Un signalement crée une trace datée, chez un tiers, qui pourra un jour être confrontée à la date de vos communications publiques. C’est là que la question quitte le terrain technique.
Le décalage que les directions n’ont pas anticipé
Considérons la séquence telle qu’elle va se dérouler en pratique. Une vulnérabilité activement exploitée est identifiée un mardi soir. Le signalement part dans les vingt-quatre heures, parce que l’équipe technique est compétente et que le délai est tenu. La notification détaillée suit trois jours plus tard. Pendant ce temps, l’organisation ne dit rien publiquement, ce qui est parfaitement légitime : le règlement organise un signalement aux autorités, pas une publication, et divulguer trop tôt une faille exploitée serait irresponsable.
Trois semaines passent. L’affaire sort, par un chercheur, par un client, par un correctif trop visible. La première question posée ne sera pas technique. Elle sera : depuis quand saviez-vous ? Et pour la première fois, la réponse existe, horodatée, chez un tiers. probable
Avant ce règlement, la date à laquelle une entreprise avait su relevait de sa parole. Elle relève désormais d’un enregistrement.
Le déséquilibre est là. L’obligation réglementaire produit un horodatage précis de ce que l’organisation savait, tandis que sa communication publique, elle, reste discrétionnaire et non datée. L’écart entre les deux devient un objet observable, alors qu’il était auparavant une zone grise. Ce n’est pas un risque juridique nouveau, c’est un risque de récit nouveau, et il ne se traite pas dans le même service.
La continuité réputationnelle, appliquée au signalement
La continuité réputationnelle est le concept ELMARQ qui décrit l’enjeu : une organisation ne se juge pas sur ce qu’elle dit à un instant donné, mais sur la cohérence de ce qu’elle a dit, fait et su dans la durée. Une déclaration exacte le jour J mais contredite par une date antérieure vaut moins que rien, parce qu’elle transforme un incident technique en question de sincérité.
Appliqué au nouveau régime de signalement, le concept produit trois exigences concrètes, aucune d’elles ne relevant de la direction technique seule.
La première est de dater la prise de connaissance de manière défendable. Cela suppose une règle interne écrite à l’avance, qui dit quel signal, reçu par qui, vaut prise de connaissance, et qui consigne ce moment. Une organisation qui improvise cette appréciation pendant l’incident choisira sa date sous pression, et devra ensuite la défendre dans les pires conditions. possible
La deuxième est de préparer le récit en même temps que le signalement, et non trois semaines plus tard. Non pour publier, mais pour que la version publique, quand elle viendra, soit compatible avec l’horodatage déjà déposé. La chronologie destinée à l’extérieur s’écrit au moment où les faits sont frais, pas au moment où la question est posée.
La troisième est de vérifier que les deux circuits se parlent. Dans la plupart des organisations, le signalement réglementaire remonte par la direction technique et la conformité, et la communication est informée après coup, parfois bien après. Cette configuration garantit mécaniquement le décalage décrit plus haut. Nous l’avions observé sur un autre terrain en documentant le cadre de divulgation des incidents d’intelligence artificielle : la déclaration et le récit obéissent à deux horloges, et personne n’est chargé de les synchroniser.
Trois gestes à poser avant le prochain incident
Ces exigences se traduisent en gestes datables, et aucun ne demande d’investissement.
Écrire la règle de déclenchement, sur une page, validée par la direction technique et la direction générale : quels types de signaux, reçus par quels rôles, valent prise de connaissance, et où ce moment est consigné. Une page suffit, et son existence avant l’incident vaut plus que sa sophistication.
Désigner la personne qui tient la chronologie. Pas celle qui signale, pas celle qui corrige : celle qui écrit, au fil de l’eau, ce que l’organisation a su et quand. Dans la plupart des crises que nous observons, cette chronologie est reconstituée après coup, à partir de messageries, ce qui produit exactement les trous que la question publique viendra sonder. probable
Tester la séquence une fois, à froid, sur un cas fictif, en chronométrant. L’exercice ne mesure pas la capacité technique à corriger, il mesure le temps qui sépare l’arrivée du signal de la décision que le compte à rebours a démarré. C’est le seul chiffre que le règlement rend désormais coûteux.
Nous plaidions en juillet, dans notre cadre de gouvernance informationnelle pour les PME et les ETI, pour que l’arbitrage soit attribué à un rôle nommé plutôt qu’à un comité. Le nouveau régime de signalement en donne la démonstration réglementaire : un comité ne peut pas décider en vingt-quatre heures, un rôle nommé le peut.
Qui est concerné, et sur quel calendrier
L’obligation vise les fabricants de produits comportant des éléments numériques mis sur le marché européen, ce qui recouvre beaucoup plus large que l’industrie du logiciel : un équipement industriel connecté, un objet grand public communicant, un composant embarqué entrent dans le champ. Nombre d’ETI industrielles françaises sont concernées sans s’être encore identifiées comme fabricants au sens du texte. possible
La difficulté d’identification est réelle et mérite d’être dite sans détour. Un fabricant de machines-outils dont les équipements embarquent un automate connecté, un fabricant de matériel médical dont les appareils remontent des données, un équipementier dont les composants intègrent un micrologiciel entrent dans le champ, alors que leurs équipes se perçoivent comme des industriels et non comme des acteurs du numérique. La question à poser en interne n’est pas « sommes-nous une entreprise technologique », elle est « un de nos produits comporte-t-il un élément numérique mis sur le marché européen ». La seconde formulation change la réponse dans beaucoup de cas. possible
Le reste du règlement, exigences de conception, documentation technique, marquage de conformité, ne s’appliquera qu’à partir de décembre 2027. La tentation est donc grande de traiter le sujet comme lointain. Elle est mauvaise : c’est justement l’obligation qui s’applique aujourd’hui qui produit une trace, et une trace ne se rattrape pas rétroactivement.
Une organisation qui découvrirait en 2027 qu’elle aurait dû signaler en 2026 n’aura pas seulement un manquement à traiter. Elle aura à expliquer publiquement un silence dont la durée sera, cette fois, calculable par tout le monde.
Savez-vous, aujourd’hui, quel signal reçu par quelle personne déclenche chez vous le compte à rebours de vingt-quatre heures ? Si la réponse demande une réunion, elle demandera trop de temps le jour venu : réserver un diagnostic de 30 minutes.
