Depuis son entrée en application le 17 janvier 2025, DORA a déplacé le centre de gravité des discussions. La question n’est plus seulement de “comprendre le texte”, mais de l’exécuter de manière cohérente, dans des organisations où les incidents ICT traversent les frontières entre IT, cybersécurité, risques, conformité, juridique et métiers. Les pages de référence de l’EIOPA, de l’ESMA et de l’EBA rappellent que DORA couvre à la fois la gestion du risque ICT, le reporting d’incidents majeurs, les tests de résilience et la gestion du risque tiers, dans une logique de résilience opérationnelle du secteur financier.
Passer d’une logique d’incident IT à une logique d’incident DORA
Dans beaucoup d’établissements, la gestion d’incident existait déjà avant DORA. Mais les critères, les circuits d’escalade et les objectifs n’étaient pas nécessairement alignés avec un cadre harmonisé européen. DORA impose désormais une lecture plus structurée : il faut identifier plus vite, qualifier plus finement, conserver des éléments probants exploitables, et être capable de documenter le raisonnement ayant conduit à la classification ou à l’absence de notification. L’enjeu n’est pas uniquement réglementaire ; il touche aussi à la capacité de l’organisation à produire une réponse stable, reproductible et défendable.
La classification : un exercice de jugement, pas un simple seuil automatique
L’une des difficultés pratiques réside dans la classification de l’incident. Les RTS et ITS relatifs au reporting des incidents majeurs ont apporté des précisions attendues par le marché, notamment sur les délais et les gabarits de remontée. L’EBA a indiqué, dans ses travaux sur le reporting des incidents majeurs, des jalons temporels structurants : notification initiale dans les 4 heures après classification et dans les 24 heures après détection, rapport intermédiaire dans les 72 heures, puis rapport final dans un délai d’un mois. Cela pousse les établissements à distinguer clairement trois moments : la détection, la qualification et la classification.
Dans la pratique, cela suppose d’éviter deux écueils. Le premier consiste à traiter la classification comme un automatisme purement technique, alors qu’elle dépend aussi du contexte métier, de la criticité de la fonction touchée et de l’effet potentiel sur les clients, les opérations ou le marché. Le second consiste à repousser la décision faute d’information complète. DORA n’attend pas une certitude parfaite au début d’un incident ; il attend une organisation capable de prendre une décision raisonnable avec une information incomplète, puis de la faire évoluer à mesure que l’investigation progresse.
Les preuves : un angle encore sous-estimé
La conservation des preuves reste un angle faible dans beaucoup d’organisations. Or, dans un cadre DORA, l’établissement doit pouvoir reconstituer ce qui s’est passé, quand, sur quelle base la décision a été prise, et quelles actions ont été menées. Cela suppose de préserver au minimum : les journaux techniques pertinents, les horodatages de détection et d’escalade, les tickets ou comptes rendus d’investigation, les échanges de décision, ainsi que les versions des rapports transmis. La logique probatoire rejoint ici les bonnes pratiques classiques de gestion d’incident, mais avec une exigence de traçabilité plus forte, car ces éléments peuvent être relus par l’audit interne, les fonctions de contrôle ou les superviseurs.
Sur le terrain, cela implique souvent de revoir des points très concrets : durée de rétention des logs, intégrité des journaux, synchronisation des horloges, qualité des notes de qualification, et articulation entre outillage SOC, ticketing, GRC et documentation de crise. Un incident mal documenté n’est pas seulement un problème d’archivage ; c’est un incident plus difficile à défendre, plus difficile à analyser rétrospectivement, et plus difficile à intégrer dans une boucle d’amélioration.
Reporting : éviter la confusion entre rapidité et précipitation
Le reporting DORA impose de la vitesse, mais pas de la précipitation. La bonne pratique n’est pas de produire un rapport parfait dès les premières heures, mais de structurer un mécanisme de remontée progressive. Les travaux publiés au niveau européen sur la centralisation future du reporting des incidents majeurs montrent bien que l’objectif est double : faciliter la circulation de l’information et améliorer la qualité des analyses thématiques à l’échelle de l’Union. Cela suppose que les données remontées soient comparables, lisibles et suffisamment robustes pour être consolidées.
Concrètement, cela conduit à formaliser un runbook de reporting qui distingue :
les informations disponibles immédiatement ;
les hypothèses de travail ;
les éléments restant à confirmer ;
les points qui nécessitent une coordination avec des tiers ou des fonctions métiers.
Dans les établissements les plus avancés, ce runbook est relié à un circuit de validation clair, avec des responsabilités identifiées sur le contenu technique, la cohérence réglementaire et la validation exécutive lorsque nécessaire. L’objectif est simple : réduire le temps de qualification sans sacrifier la cohérence du message transmis.
La coordination inter-fonctions : le vrai sujet d’exécution
Le principal défi DORA n’est pas uniquement technique. Il réside dans la coordination inter-fonctions. Dans un incident significatif, les équipes cyber ne détiennent pas seules toute l’information utile. Les équipes IT comprennent la disponibilité et les dépendances techniques ; les métiers évaluent l’impact opérationnel ; les risques et la conformité apprécient les conséquences de contrôle ; le juridique et la communication interviennent selon la nature et la visibilité de l’événement. Sans mécanisme de coordination, la qualification dérive, les décisions sont retardées, et la traçabilité se fragilise.
Dans ce contexte, le RACI n’est pas un exercice documentaire secondaire. Il devient un outil de réduction du temps de décision. Il doit préciser qui détecte, qui qualifie techniquement, qui classe, qui décide la notification, qui consolide les preuves, qui valide le rapport, et qui pilote les mises à jour. Dans les organisations matures, ce schéma est testé à froid, puis rejoué dans des exercices, afin d’éviter qu’un incident réel ne serve de première répétition.
Le lien avec les prestataires ICT critiques
L’exécution de DORA ne s’arrête pas au périmètre interne. Les établissements doivent aussi gérer les incidents impliquant des prestataires ICT, en particulier lorsque ces prestataires sont devenus critiques pour le fonctionnement d’activités financières. L’oversight européen mis en place sous DORA vise précisément à réduire les risques systémiques et de concentration liés à cette dépendance. Les ESAs ont commencé à formaliser ce cadre de supervision et, en novembre 2025, elles ont désigné des prestataires critiques au niveau européen. Mais ce cadre de supervision ne remplace pas la responsabilité des entités financières dans leur propre gestion du risque tiers.
Sur le plan opérationnel, cela signifie qu’un dispositif DORA crédible doit inclure :
des points de contact identifiés chez les prestataires ;
des exigences contractuelles sur les délais d’escalade et d’information ;
des modalités de collecte de preuves en cas d’incident chez un tiers ;
et une intégration des incidents tiers dans les scénarios de classification et de reporting.
L’un des enseignements de 2025 est clair : la difficulté ne vient pas seulement de la panne ou de l’incident lui-même, mais du temps nécessaire pour qualifier l’impact lorsqu’une partie de l’information reste chez un fournisseur.
Boucles d’amélioration : documenter pour apprendre, pas seulement pour notifier
La mise en œuvre de DORA n’a de valeur que si elle produit un effet durable sur la résilience. Cela suppose de transformer chaque incident significatif, ou chaque quasi-incident, en matière d’amélioration. Les établissements les plus structurés intègrent donc, après la phase de reporting, une revue systématique portant sur la qualité de la détection, la rapidité de la classification, la pertinence du runbook, la disponibilité des preuves et la fluidité de la coordination inter-fonctions. Cette logique permet de passer d’un reporting vécu comme une contrainte à un reporting utilisé comme mécanisme d’apprentissage organisationnel.
Une lecture opérationnelle pour la place financière
Pour le Forum des Compétences, l’intérêt du sujet tient précisément à ce glissement : on quitte le commentaire réglementaire général pour entrer dans la mécanique concrète d’exécution. La bonne question n’est pas “sommes-nous couverts par DORA ?”, mais “sommes-nous capables, en quelques heures, de qualifier un incident, de réunir les bonnes fonctions, de produire une décision traçable et de notifier avec cohérence ?”
La mise en place d’un dispositif opérationnel — runbooks, critères, RACI, conservation des éléments probants, boucles d’amélioration — n’est pas un supplément de conformité. C’est un accélérateur de cohérence entre Risk, Conformité, IT et Cyber, et un levier direct de réduction du temps de qualification et d’amélioration de la réponse documentée. Dans un environnement où la résilience numérique devient un sujet de stabilité financière, cet alignement n’est plus accessoire. Il devient structurant.