DORA vous a exemptés de NIS2. Il ne vous exemptera pas du CRA.

TL;DR. Le 11 septembre, le CRA déclenche un délai de 24 heures. Il vise les produits : l'exemption DORA qui écarte NIS2 ne l'atteint jamais.

Points clés

Ce qui démarre réellement le 11 septembre. Le CRA est entré en vigueur le 10 décembre 2024 avec un calendrier d'application échelonné, et c'est l'échelonnement qui se perd en route.
Pourquoi l'exemption DORA ne l'atteint pas. C'est le point qui mérite la précision, car le raisonnement qui produit la mauvaise réponse est un raisonnement authentiquement solide, poussé un règlement trop loin.
Êtes-vous fabricant ? Personne n'a tranché pour vous. Ici, la position honnête est que la question est ouverte plutôt que réglée, et qu'une banque qui attend qu'elle soit réglée attendra au-delà de la date.
La collision des horloges. Supposons un instant que l'analyse conclue à l'inclusion d'au moins un artefact.

Dans trente-neuf jours, le règlement sur la cyberrésilience déclenche un délai de notification de vingt-quatre heures, et l'exemption que toute banque invoque ne l'arrête pas. Demandez à un établissement financier si NIS2 s'applique et la réponse arrive sans hésitation : DORA est lex specialis, l'article 4 de NIS2 s'efface dès qu'un acte sectoriel couvre le même terrain, et la banque déclare ses incidents informatiques à son autorité compétente plutôt qu'à un CSIRT. Cette réponse est exacte. Elle est aussi sur le point d'être donnée, à tort, à une question portant sur un autre règlement. Le CRA ne régit pas des entités. Il régit des produits, et il impose ses obligations à celui qui les fabrique. Son article de champ d'application ne contient aucune exclusion pour les services financiers, parce qu'une exclusion rédigée pour du droit des entités n'a rien à quoi s'accrocher dans du droit des produits. À compter du 11 septembre 2026, une banque qui met un logiciel à disposition sur le marché doit à l'ENISA une alerte précoce sous vingt-quatre heures — et elle la doit en plus de DORA, non à sa place.

Synthèse pour dirigeants

Une date active, pas un horizon. L'article 14 s'applique à compter du 11 septembre 2026. Le reste du CRA attend le 11 décembre 2027, et l'erreur de planification se loge dans l'écart entre ces deux faits.

Le périmètre dépend de ce que vous livrez, pas de ce que vous êtes. Les exclusions du CRA visent d'autres régimes produits — dispositifs médicaux, véhicules, aviation, équipements marins. La banque n'y figure pas et n'allait jamais y figurer.

Le déclencheur est l'exploitation, pas la gravité. Une vulnérabilité activement exploitée lance le compte à rebours même si aucun client n'est touché et même si rien ne constituerait un incident majeur au sens de DORA.

Personne n'en est propriétaire aujourd'hui. La notification DORA relève de la résilience opérationnelle. La notification CRA relève de celui qui est réputé fabricant — un rôle que la plupart des banques n'ont jamais attribué.

Ce qui démarre réellement le 11 septembre

Le CRA est entré en vigueur le 10 décembre 2024 avec un calendrier d'application échelonné, et c'est l'échelonnement qui se perd en route.

L'application pleine et entière — exigences essentielles de cybersécurité de l'annexe I, évaluation de la conformité, marquage CE, documentation technique — tombe le 11 décembre 2027. La notification des organismes d'évaluation de la conformité est ouverte depuis le 11 juin 2026. Entre les deux se glisse la date qui compte ce trimestre : le 11 septembre 2026, début des obligations de notification de l'article 14.

La structure de notification comporte trois étapes, et elle est plus serrée qu'il n'y paraît.

Alerte précoce sous 24 heures après que le fabricant a eu connaissance d'une vulnérabilité activement exploitée, ou d'un incident grave ayant une incidence sur la sécurité du produit.
Notification complète sous 72 heures, portant le détail technique et les mesures correctives ou d'atténuation prises.
Rapport final sous 14 jours après qu'une mesure corrective est disponible pour une vulnérabilité activement exploitée, ou sous un mois à compter de la notification pour un incident grave.

Les rapports transitent par la plateforme de notification unique du CRA exploitée par l'ENISA. Le fabricant dépose une seule fois, auprès du CSIRT désigné comme coordinateur dans l'État membre de son établissement principal ; la plateforme met simultanément la notification à disposition de l'ENISA, et le CSIRT destinataire la relaie aux autres CSIRT des territoires où le produit est distribué. Ce dépôt unique supprime un prétexte administratif, mais n'assouplit en rien le délai.

Observez le déclencheur. Ni la gravité, ni l'impact client — l'exploitation. Une vulnérabilité activement exploitée dans la nature ouvre une obligation de 24 heures, que quelqu'un ait été lésé ou non, et que les mêmes faits soient qualifiés d'incident majeur ailleurs ou non.

Pourquoi l'exemption DORA ne l'atteint pas

C'est le point qui mérite la précision, car le raisonnement qui produit la mauvaise réponse est un raisonnement authentiquement solide, poussé un règlement trop loin.

L'article 4 de NIS2 contient un mécanisme de renvoi : lorsqu'un acte sectoriel de l'Union impose à des entités d'adopter des mesures de gestion des risques de cybersécurité ou de notifier des incidents importants, et que ces exigences sont au moins équivalentes dans leurs effets, les dispositions correspondantes de NIS2 ne s'appliquent pas. DORA est précisément un tel acte. Un établissement de crédit gère donc son risque informatique et notifie ses incidents majeurs au titre de DORA, et les obligations parallèles de NIS2 s'effacent. Toute direction des affaires réglementaires sait le réciter.

Trois éléments brisent l'analogie dès qu'on la transpose au CRA.

Le mécanisme vit à l'intérieur de NIS2. L'article 4 est une disposition de la directive (UE) 2022/2555 qui écarte des dispositions de la directive (UE) 2022/2555. Ce n'est pas un principe général selon lequel le régime sectoriel d'une entité financière supplanterait tout le reste. Il ne peut rien désactiver dans le règlement (UE) 2024/2847, car rien dans le CRA ne lui est soumis.

Le CRA régit des produits, pas des entités. DORA et NIS2 demandent tous deux quel type d'organisation êtes-vous. Le CRA demande qu'avez-vous mis sur le marché. Ce sont des questions différentes, et les arguments d'équivalence entre elles ne tiennent pas : le régime de notification de DORA n'est en aucun sens « équivalent dans ses effets » à l'obligation, pour un fabricant, d'avertir un CSIRT qu'un artefact livré est exploité, car ils protègent des populations distinctes. DORA protège le système financier par l'intermédiaire du superviseur. L'article 14 protège tous ceux qui exploitent le produit, par l'intermédiaire du réseau des CSIRT.

Les exclusions n'ont pas la bonne forme. L'article de champ d'application du CRA écarte les produits couverts par d'autres législations produits sectorielles — dispositifs médicaux au titre des règlements (UE) 2017/745 et 2017/746, véhicules au titre du règlement (UE) 2019/2144, aviation civile au titre du règlement (UE) 2018/1139, équipements marins au titre de la directive 2014/90/UE — ainsi que les pièces de rechange fabriquées selon des spécifications identiques et les produits développés exclusivement à des fins de sécurité nationale ou de défense. Il n'existe aucune exclusion pour les services financiers, ni pour les produits fabriqués par des entités régies par DORA. Ce n'est pas un oubli que des lignes directrices viendront corriger. C'est ce qui arrive quand un législateur écrit du droit des produits : il n'exclut pas des industries, il exclut d'autres régimes produits.

Tableau 1 : trois régimes, et lequel s'efface

	DORA	NIS2	CRA
Régit	Les entités financières	Les entités essentielles et importantes	Les produits comportant des éléments numériques
Obligation portée par	L'établissement	L'établissement	Le fabricant
Déclencheur de notification	Incident classé majeur	Incident important	Vulnérabilité activement exploitée ou incident grave
Destinataire	Autorité compétente	CSIRT ou autorité compétente	CSIRT de l'établissement principal, et ENISA
Écarté pour les banques ?	Non — c'est la lex specialis	Oui, via l'article 4 de NIS2	Non — rien ne l'écarte

Êtes-vous fabricant ? Personne n'a tranché pour vous

Ici, la position honnête est que la question est ouverte plutôt que réglée, et qu'une banque qui attend qu'elle soit réglée attendra au-delà de la date.

Le CRA vise les produits comportant des éléments numériques mis à disposition sur le marché — fournis en vue de leur distribution ou de leur utilisation dans le cadre d'une activité commerciale. Deux conséquences découlent immédiatement de cette formulation.

Le prix n'est pas le critère. Un logiciel fourni gratuitement entre dans le champ s'il est fourni dans le cadre d'une activité commerciale. La position de la Commission sur l'open source repose sur l'activité commerciale et non sur le paiement, et une banque qui distribue une application pour acquérir et servir des clients payants n'agit pas hors du cadre d'une activité commerciale. L'intuition selon laquelle « nous donnons l'application, donc nous ne vendons pas un produit » est la raison la plus fréquente pour laquelle ce dossier n'a pas été ouvert, et c'est le plus faible des arguments disponibles.

Le logiciel strictement interne en sort réellement. Les produits non mis à disposition sur le marché — le système bancaire central, l'outillage interne, tout ce qui n'est jamais fourni au-delà de l'établissement — ne sont pas visés. C'est une exclusion réelle et substantielle, et c'est pourquoi l'exposition est plus étroite que ne le laisse croire la version alarmiste de cette analyse.

La question n'est donc pas de savoir si une banque entre dans le champ en tant qu'entité. Elle porte sur les artefacts précis qu'elle fournit. Quatre catégories méritent un inventaire avant toute conclusion :

L'application bancaire mobile, distribuée au grand public via les magasins d'applications. Savoir si une application destinée aux clients est un produit fourni pour usage, ou simplement l'interface d'un service rendu par la banque, est la question réellement controversée — et elle est controversée, non tranchée en faveur de la banque.
Les artefacts destinés aux développeurs : SDK, bibliothèques client, outillage d'API et implémentations de référence publiés pour les clients entreprises ou les partenaires. Ceux-là ressemblent beaucoup plus à des produits fournis et beaucoup moins à une interface de service.
Les projets open source que l'établissement publie et maintient dans le cadre de son activité commerciale, où les dispositions relatives au dépositaire peuvent également jouer.
Les logiciels en marque blanche ou embarqués que la banque relivre à des partenaires sous son propre nom, qui est le chemin le plus rapide du statut de déployeur à celui de fabricant dans tout régime produit européen.

La posture de planification honnête ne consiste pas à affirmer une conclusion. Elle consiste à inventorier les artefacts, à consigner une position motivée sur chacun, et à pouvoir exposer ce raisonnement si un CSIRT demande pourquoi aucune notification n'est arrivée.

La collision des horloges

Supposons un instant que l'analyse conclue à l'inclusion d'au moins un artefact. Ce qui change opérationnellement n'est pas l'existence d'un processus d'incident — les banques en ont — mais le fait que deux processus tournent désormais sur le même événement avec des paramètres différents.

Une vulnérabilité affectant un SDK publié par une banque passe sous exploitation active. DORA demande s'il s'agit d'un incident majeur lié aux TIC affectant l'établissement, et si oui, la notification initiale part vers l'autorité compétente dans les quatre heures suivant cette classification et en tout état de cause dans les 24 heures suivant la prise de connaissance, avec un rapport intermédiaire et un rapport final derrière. L'article 14 pose une tout autre question — un produit fabriqué par cet établissement est-il exploité — et lance sa propre alerte précoce de 24 heures vers un CSIRT et l'ENISA.

Les deux peuvent diverger dans les deux sens, ce qui rend dangereux tout processus fusionné.

Une vulnérabilité exploitée dans un SDK livré, sans aucune perturbation des services propres de la banque, peut ne constituer aucun incident majeur au sens de DORA tout en tombant pleinement sous l'article 14. Et une panne grave d'une plateforme construite en interne est une notification DORA sans aucune dimension CRA, puisque rien n'a été mis sur le marché. Bâtir un flux unique qui présume que les deux se déclenchent toujours ensemble produit à la fois des faux négatifs et du bruit réglementaire inutile.

Tableau 2 : ce qu'il faut établir avant le 11 septembre

Question	Ce qu'elle détermine dans votre exposition
Quels artefacts fournissons-nous hors de l'établissement ?	Le périmètre est par produit ; il n'existe pas de réponse au niveau de l'entité
Pour chacun, avons-nous consigné une position sur le statut de fabricant ?	Une hypothèse non consignée n'est pas un moyen de défense
Où se situe notre établissement principal au sens du CSIRT ?	Détermine quel CSIRT national reçoit le dépôt
Sommes-nous enregistrés sur la plateforme de notification unique de l'ENISA ?	24 heures ne suffisent pas à découvrir une étape d'enrôlement
« Activement exploitée » a-t-il un responsable au tri ?	Le déclencheur diffère de toutes les échelles de gravité déjà en place
Qui dépose à 3 h du matin un dimanche ?	Les deux horloges tournent en temps réel, pas en heures ouvrées

Le chiffre qui fixe la priorité

Le non-respect des exigences essentielles de l'annexe I et des obligations des articles 13 et 14 expose à des amendes administratives pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu. Les autres obligations des fabricants, importateurs et distributeurs se situent un cran en dessous, à 10 millions d'euros ou 2 %, et la communication d'informations inexactes ou trompeuses aux autorités à 5 millions d'euros ou 1 %.

Lisez le palier supérieur à l'aune du travail qui s'y rattache. Déterminer si quatre catégories d'artefacts entrent dans le champ, s'enregistrer sur une plateforme de notification et ajouter une branche à un manuel de tri existant représente un chantier modeste, avec un responsable désigné et cinq semaines devant soi. Cela n'a rien de comparable au programme d'évaluation de la conformité et de documentation technique qui attend en décembre 2027. L'asymétrie entre l'exposition et le coût de remédiation constitue tout l'argument, et c'est le rare argument de conformité qui survit au contact d'une réunion d'arbitrage.

Le manuel opérationnel

Cinq mouvements, et le premier n'est pas un avis juridique.

Inventoriez ce qui sort du bâtiment. Pas des systèmes — des artefacts. Tout ce que l'établissement fournit à quelqu'un d'extérieur, y compris les applications gratuites, les bibliothèques publiées et les dépôts open source. La plupart des banques n'ont pas cette liste, car aucune réglementation antérieure ne l'a demandée.
Prenez une position par artefact, par écrit. Fabricant, ou non, et pourquoi. La valeur ne tient pas à l'exactitude de chaque ligne ; elle tient à disposer d'un raisonnement antérieur à l'incident plutôt que reconstruit après coup.
Enrôlez-vous dès maintenant sur la plateforme de notification unique. Enregistrement, identifiants et déposant désigné sont exactement le genre de prérequis invisible jusqu'au moment où un compte à rebours de 24 heures tourne déjà.
Dédoublez le déclencheur au tri. Ajoutez une question explicite — un produit que nous fabriquons est-il activement exploité — évaluée indépendamment de la classification d'incident majeur au sens de DORA. L'indépendance est le point : un contrôle imbriqué hérite du mauvais seuil.
Lancez le chantier SBOM sur l'échéance de décembre 2027. L'annexe I exige une nomenclature logicielle dans un format courant lisible par machine, couvrant au minimum les dépendances de premier niveau. Cette obligation est à seize mois, et c'est le même problème d'énumération que les établissements échouent déjà à résoudre du côté cryptographique.

Le schéma n'est pas nouveau. Un régime est rédigé en pensant à une industrie donnée, les établissements financiers lisent le nom de l'industrie et concluent que le dossier appartient à quelqu'un d'autre. Le CRA a été écrit pour les fabricants d'équipements et les éditeurs de logiciels. Il atteint la banque malgré tout, dans l'espace étroit où celle-ci se trouve en être un — et l'exemption que tout le monde invoquera en premier a été inscrite dans une autre loi, pour un autre objet, et ne s'applique pas.

Foire aux questions

Nous déclarons au titre de DORA. Cela ne suffit-il pas ?
Non. DORA écarte les obligations parallèles de NIS2 par le mécanisme de renvoi de l'article 4 de NIS2 lui-même. Ce mécanisme est interne à NIS2 et n'a aucun effet sur le règlement (UE) 2024/2847. Le CRA impose des obligations aux fabricants de produits, non aux entités financières : il n'y a donc rien qu'un argument de lex specialis puisse écarter.

Notre application bancaire mobile entre-t-elle dans le champ ?
C'est la question réellement ouverte, et elle doit être tranchée délibérément plutôt que présumée. L'application est un logiciel doté d'une connexion de données, fourni au public dans le cadre d'une activité commerciale, ce qui correspond à la formulation du texte. L'argument contraire est qu'elle constitue l'interface d'un service réglementé plutôt qu'un produit fourni pour usage. Consignez une position ; ne vous appuyez pas sur sa gratuité, car le prix n'est pas le critère.

Qu'est-ce qui déclenche exactement le délai de 24 heures ?
La connaissance d'une vulnérabilité de votre produit activement exploitée, ou d'un incident grave ayant une incidence sur la sécurité du produit. Le déclencheur est l'exploitation, non la gravité ni l'impact client — raison pour laquelle il ne se superpose pas à la classification d'incident majeur de DORA.

Auprès de qui déposons-nous concrètement ?
Via la plateforme de notification unique du CRA de l'ENISA, à l'attention du CSIRT désigné comme coordinateur dans l'État membre de votre établissement principal. L'ENISA la reçoit simultanément, et le CSIRT destinataire la partage avec les CSIRT des autres territoires où le produit est distribué. Un seul dépôt, pas plusieurs.

Autre chose démarre-t-il en septembre ?
Non. Uniquement les obligations de notification de l'article 14. Les exigences essentielles de cybersécurité, l'obligation de SBOM, l'évaluation de la conformité, la documentation technique et le marquage CE s'appliquent tous à compter du 11 décembre 2027. Traiter septembre comme le dossier entier est l'image inversée de l'ignorer.

Que risquons-nous si le périmètre est mal apprécié ?
Les manquements aux articles 13 et 14 et aux exigences essentielles de l'annexe I exposent à des amendes pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu. Le coût le plus immédiat est procédural : une alerte précoce manquée ne se rattrape pas rétroactivement, et le moment où un établissement découvre qu'il était fabricant ne devrait pas être celui où un CSIRT demande pourquoi aucune notification n'est arrivée.

Références

Parlement européen et Conseil de l'Union européenne, 2024. Règlement (UE) 2024/2847 concernant des exigences horizontales de cybersécurité pour les produits comportant des éléments numériques (règlement sur la cyberrésilience). Bruxelles : Journal officiel de l'Union européenne. Disponible à l'adresse : Parlement européen et Conseil de l'Union européenne, 2024..
Commission européenne, 2026. Règlement sur la cyberrésilience — Obligations de notification. Bruxelles : Direction générale des réseaux de communication, du contenu et des technologies. Disponible à l'adresse : Commission européenne, 2026..
Commission européenne, 2026. Le règlement sur la cyberrésilience — Synthèse du texte législatif. Bruxelles : Direction générale des réseaux de communication, du contenu et des technologies. Disponible à l'adresse : Commission européenne, 2026..
Parlement européen et Conseil de l'Union européenne, 2022. Directive (UE) 2022/2555 concernant des mesures destinées à assurer un niveau élevé commun de cybersécurité dans l'ensemble de l'Union (directive NIS 2). Bruxelles : Journal officiel de l'Union européenne. Disponible à l'adresse : Parlement européen et Conseil de l'Union européenne, 2022..
Parlement européen et Conseil de l'Union européenne, 2022. Règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier (DORA). Bruxelles : Journal officiel de l'Union européenne. Disponible à l'adresse : Parlement européen et Conseil de l'Union européenne, 2022..

Dernière révision 2026-08-16.

Republier cet article

DORA vous a exemptés de NIS2. Il ne vous exemptera pas du CRA. — Sebastien Rousseau

Le 11 septembre, le CRA déclenche un délai de 24 heures. Il vise les produits : l'exemption DORA qui écarte NIS2 ne l'atteint jamais.

Cet article est sous licence Creative Commons Attribution 4.0 International. La republication nécessite l'attribution à l'URL canonique.

DORA vous a exemptés de NIS2. Il ne vous exemptera pas du CRA. — Sebastien Rousseau

Le 11 septembre, le CRA déclenche un délai de 24 heures. Il vise les produits : l'exemption DORA qui écarte NIS2 ne l'atteint jamais.

Originally published at https://sebastienrousseau.com/fr/2026-08-03-cyber-resilience-act-article-14-reporting-banques-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FONDATEUR · INGÉNIEUR