DORA : ce que la première année d’incidents majeurs révèle sur votre architecture

Un an après l’entrée en application de DORA, les premiers retours européens permettent de dépasser la théorie réglementaire. Les incidents réellement déclarés montrent surtout une chose : la résilience ne dépend pas uniquement de la capacité à détecter et traiter une panne ou une cyberattaque. Elle dépend aussi de la capacité à comprendre rapidement quelles fonctions, applications, infrastructures et dépendances sont réellement touchées.

Le premier rapport annuel publié par les autorités européennes de supervision le 3 juin 2026 recense 3 383 incidents TIC majeurs en 2025. Environ un tiers ont eu un impact transfrontière. Les ESAs soulignent le caractère de plus en plus interconnecté des risques TIC, notamment via les infrastructures et services partagés.1

L’EBA apporte un autre ordre de grandeur : depuis le début du reporting DORA en janvier 2025 et jusqu’en mars 2026, elle indique avoir reçu plus de 18 000 rapports. Les défaillances de systèmes constituent la catégorie dominante des événements déclarés. Parmi les incidents cyber, DDoS, usurpation d’identité et exfiltration ou manipulation de données figurent parmi les techniques les plus fréquemment signalées.2

Ces chiffres ne permettent pas de définir une architecture type des organisations touchées. Ils permettent en revanche de poser une question beaucoup plus opérationnelle : lorsqu’un incident survient, savons-nous réellement reconstruire son impact dans le SI ?

Un incident technique n’est jamais seulement technique

Prenons une interruption d’un service d’authentification.

Vue depuis l’infrastructure, l’incident peut sembler simple : un composant ne répond plus. Vue depuis le système d’information, les conséquences peuvent être très différentes.

Le service peut être utilisé par plusieurs applications. Ces applications peuvent soutenir plusieurs processus métier, dont certains critiques. Des utilisateurs externes, des collaborateurs ou des partenaires peuvent également dépendre de ces applications.

La chaîne à reconstruire devient alors :

incident → composant → application → fonction critique → utilisateurs → transactions.

C’est ce changement d’échelle qui transforme un événement technique en incident opérationnel.

DORA impose d’ailleurs de prendre en compte plusieurs dimensions pour déterminer la gravité d’un incident : clients et contreparties affectés, transactions, durée, étendue géographique, pertes de données, criticité des services ou impact économique.3

Pour évaluer ces critères rapidement, connaître uniquement le serveur ou l’application touchée ne suffit pas. Il faut connaître ce qui en dépend.

Les dépendances partagées constituent un angle mort

Imaginons trois applications : une plateforme de paiement, un portail client et une application interne de gestion des comptes.

Elles sont développées par trois équipes différentes et hébergées dans des environnements distincts. Sur un schéma d’architecture de haut niveau, elles apparaissent indépendantes.

Pourtant, toutes utilisent le même service d’identité.

Une défaillance de ce service peut donc affecter simultanément trois fonctions qui semblaient séparées.

Le même raisonnement s’applique au DNS, au réseau, à l’IAM, aux API Gateway, aux bases de données, aux services cloud, aux solutions de sauvegarde, aux composants de sécurité ou aux fournisseurs TIC.

Une architecture peut donc sembler distribuée tout en reposant sur quelques dépendances communes extrêmement concentrées.

Le premier retour d’expérience DORA renforce l’intérêt d’identifier ces dépendances avant l’incident plutôt que pendant celui-ci.1

Plusieurs petits incidents peuvent révéler une seule faiblesse

DORA introduit également la notion d’incidents récurrents.

Le règlement délégué (UE) 2024/1772 prévoit que des incidents qui ne sont pas individuellement majeurs puissent être considérés collectivement lorsqu’ils se produisent au moins deux fois en six mois, présentent la même cause originelle apparente et atteignent ensemble les critères prévus.3

Cette règle change la manière de regarder l’historique.

Considérons trois événements : en mars, indisponibilité de l’application A pendant 20 minutes ; en mai, dégradation de l’application B pendant 35 minutes ; en juillet, interruption de l’application C pendant 25 minutes.

Pris séparément, ils peuvent être traités comme trois incidents techniques. Mais une analyse des dépendances montre que les trois applications utilisent le même composant réseau.

Le véritable historique n’est donc plus incident A + incident B + incident C, mais composant commun → trois manifestations différentes → plusieurs fonctions métier affectées.

La recherche de la cause racine devient alors indissociable de la connaissance de l’architecture.

Cartographier l’impact avant d’en avoir besoin

Une organisation n’a pas nécessairement besoin de documenter chaque détail technique avec le même niveau de précision.

Pour l’analyse des incidents, une représentation minimale peut déjà relier :

fonction critique → processus métier → application → infrastructure → service TIC → fournisseur.

À cette chaîne peuvent être ajoutés quelques attributs directement utiles : criticité, utilisateurs concernés, localisation, dépendances techniques, fournisseur, solution de secours, RTO/RPO, responsable et procédures de continuité.

L’objectif n’est pas de créer davantage de documentation. Il est de pouvoir répondre rapidement à quelques questions : qu’est-ce qui est touché ? qu’est-ce qui pourrait l’être ensuite ? quelles fonctions dépendent du composant ? existe-t-il une dépendance commune ? quelle solution permet de continuer à fonctionner ?

Cas construit : trois applications, une seule dépendance

Prenons une banque fictive disposant de trois services numériques.

Le portail client utilise un fournisseur d’identité externe. L’application mobile utilise le même fournisseur. L’outil du centre de relation client s’appuie également sur cette identité pour authentifier les collaborateurs.

Le fournisseur subit une panne importante.

Techniquement, une seule dépendance est indisponible. Opérationnellement, trois services deviennent partiellement ou totalement inutilisables.

Sans connaissance des relations entre les objets du SI, l’organisation découvre progressivement l’étendue du problème.

Avec une représentation des dépendances, le raisonnement peut être inversé :

fournisseur d’identité indisponible → trois applications dépendantes → deux services clients + un service interne → fonctions métier concernées → équipes à mobiliser → solutions de continuité à activer.

La valeur de cette connaissance apparaît précisément lorsque le temps manque.

Ce que le premier bilan DORA permet — et ne permet pas — de conclure

Les ESAs indiquent qu’environ un tiers des 3 383 incidents majeurs ont eu un impact transfrontière, tandis que les défaillances de systèmes et événements externes figuraient parmi les principaux moteurs. Elles précisent aussi que l’impact direct sur les clients et les transactions a généralement été limité.1

Ces données agrégées ne prouvent pas que toutes les organisations financières souffrent des mêmes faiblesses architecturales. Elles ne permettent pas non plus de transformer le nombre d’incidents en classement de résilience entre établissements.

Elles montrent en revanche que les incidents TIC doivent être analysés dans un environnement fortement interconnecté, où leurs conséquences peuvent dépasser rapidement les frontières d’une application, d’une entité ou d’un pays.

Le sujet n’est donc plus seulement de disposer d’un processus de gestion d’incident conforme à DORA. Il faut également être capable de relier un événement technique aux services, fonctions, utilisateurs et dépendances qu’il peut réellement affecter.

Une organisation qui construit cette connaissance pendant l’incident la construit trop tard.