CRA, NIS2, DORA : trois textes, un seul dispositif de cyber-résilience

L'Europe a construit sa cyber-résilience en trois morceaux. NIS2 vise les entités essentielles et importantes de dix-huit secteurs critiques : une directive, donc une transposition nationale, dont la version française se fait attendre au point que la Commission a renvoyé la France devant la Cour de justice le 9 juillet. DORA vise les entités financières, banques, assureurs, sociétés de gestion : un règlement, applicable tel quel depuis le 17 janvier 2025, supervisé en France par l'ACPR. Le CRA vise les produits : tout matériel ou logiciel comportant des éléments numériques mis sur le marché européen, avec une première échéance contraignante le 11 septembre 2026, la notification des vulnérabilités activement exploitées, et la Commission vient d'en publier la première guidance d'application.

Vus de Bruxelles, trois périmètres distincts. Vus de l'intérieur d'un groupe, les mêmes personnes : le RSSI, l'équipe conformité, la direction des risques, souvent les mêmes prestataires. Une banque qui édite ses propres applications relève de DORA pour son dispositif, du CRA pour ses produits, et son groupe peut compter des filiales sous NIS2. Le texte prévoit d'ailleurs l'articulation : pour les entités financières, DORA prime sur NIS2, en tant que texte sectoriel spécifique. Encore faut-il savoir précisément qui, dans le groupe, relève de quoi.

Débarrassés de leur vocabulaire propre, les trois textes exigent le même socle. Une gouvernance nommée : les organes de direction sont responsables, personnellement dans NIS2 et DORA, de l'approbation et de la surveillance du dispositif. Une gestion des risques TIC documentée : identifier les actifs, évaluer les menaces, traiter les écarts. Un processus d'incidents : détecter, qualifier, notifier, tirer les leçons. Et une maîtrise des tiers : la chaîne d'approvisionnement dans NIS2, le registre des prestataires TIC dans DORA, remis aux superviseurs depuis avril 2025, la chaîne de composants dans le CRA.

Les différences réelles tiennent aux échéances et aux guichets. Un incident majeur se notifie à l'ANSSI sous NIS2 (alerte précoce sous 24 heures, notification sous 72 heures), au superviseur financier sous DORA selon ses propres modèles harmonisés, à l'ENISA sous le CRA pour une vulnérabilité de produit activement exploitée, sous 24 heures. Trois formulaires, trois horloges, un seul incident réel.

Le traitement en silo produit ici ses dégâts les plus concrets. Trois projets de conformité construisent trois inventaires d'actifs qui divergent, trois cartographies de risques aux échelles incompatibles, trois procédures de notification dont personne ne sait laquelle s'applique à 2 heures du matin quand l'incident est réel et que les trois horloges tournent en même temps.

C'est le test qui ne pardonne pas : un incident significatif chez un acteur financier éditeur de logiciels peut déclencher simultanément une notification DORA au superviseur et une notification CRA à l'ENISA, pendant que les filiales du groupe s'interrogent sur leurs obligations NIS2. Les organisations qui ont répété ce scénario sur un dispositif unifié le déroulent ; les autres le découvrent en le subissant.

La réponse méthodologique est celle que nous décrivions pour l'empilement réglementaire en général : séparer le socle, qui se mesure une fois, des vues réglementaires, qui se déclinent par texte. Un diagnostic de maturité cyber-résilience évalue les capacités communes, gouvernance, risques, incidents, tiers, tests, sur une échelle homogène ; chaque critère est rattaché aux textes qu'il sert, et les trois conformités se lisent comme trois projections du même état des lieux.

Ce croisement rend visibles les collisions utiles : un processus d'incidents unifié, avec ses seuils de qualification et son annuaire de guichets, fait progresser les trois textes d'un coup. Un registre de tiers bien construit sert DORA aujourd'hui et la chaîne d'approvisionnement NIS2 demain. Et un langage de risque commun, celui d'ISO 27005 par exemple, évite que chaque texte réinvente sa propre échelle de gravité.

L'échéance CRA du 11 septembre est le bon déclencheur, parce qu'elle est proche, contraignante et opérationnelle. Trois gestes dans l'ordre : clarifier qui, dans le groupe, relève de quel texte, entité par entité et produit par produit. Unifier le processus de notification, une seule procédure interne, trois guichets de sortie, des responsables nommés et joignables. Puis mesurer la maturité du socle et convertir les écarts en plan d'action daté, en priorisant ce qui sert les trois textes à la fois.

Le calendrier ne s'arrêtera pas là : les obligations principales du CRA arrivent en décembre 2027, la loi Résilience française finira par être votée, DORA continue de monter en exigence sur les tests. Les organisations qui pilotent ce trio depuis un diagnostic unique absorberont chaque nouvelle marche. Les autres recommenceront un chantier à chaque échéance.