DORA est entré en application le 17 janvier 2025. En dix-huit mois, les entités financières dans le scope — banques, assureurs, gestionnaires d'actifs, prestataires ICT critiques — ont produit des politiques, des registres et des cartographies. La conformité documentaire avance. Mais là s'arrête souvent le bilan positif. Les premières observations des autorités compétentes (BCE, ACPR, ESMA) et les audits de maturité conduits en 2025 et début 2026 révèlent quatre lacunes structurelles dans la gouvernance ICT réelle. Dans cet article, vous découvrirez pourquoi ces lacunes persistent — et ce qu'une organisation peut raisonnablement corriger avant les prochains cycles de supervision.
Ce que 18 mois d'application ont réellement produit
Le tableau de bord intermédiaire est nuancé. D'après les retours consolidés des superviseurs nationaux européens publiés au premier trimestre 2026, environ 78 % des entités essentielles dans le scope DORA ont établi un registre des prestataires ICT tiers et une politique de gestion du risque ICT documentée. C'est la norme minimale — et elle est globalement respectée.
Mais DORA n'est pas un exercice documentaire. Les articles 24 à 27 imposent un programme de tests de résilience opérationnelle effectif, des délais de notification précis en cas d'incident majeur, et une gouvernance intégrée du risque ICT au niveau du conseil d'administration. Sur ces trois axes, l'écart entre le document et la réalité opérationnelle est significatif.
Une donnée d'arbitrage : selon une enquête Deloitte EU Financial Services publiée en mars 2026, 61 % des entités interrogées reconnaissent que leur programme de tests DORA "n'est pas encore opérationnel à l'échelle requise". Le ratio conformité déclarative / conformité opérationnelle oscille entre 1,4 et 1,8 selon les typologies d'entités. Pour chaque mesure opérationnellement active, il existe entre 0,4 et 0,8 mesure sur le papier uniquement.
Lacune 1 : les tests de résilience restent cosmétiques
DORA distingue deux niveaux de tests. Les tests de base (article 24) — revues de vulnérabilités, scans, tests de pénétration — s'appliquent à toutes les entités dans le scope. Les Threat-Led Penetration Tests (TLPT, article 26) concernent les entités d'importance systémique désignées par les superviseurs et doivent être conduits par des prestataires certifiés sous le cadre TIBER-EU.
Le problème observé : même les tests de base restent fréquemment des exercices annuels ponctuels, déconnectés du cycle de remédiation. Une entité qui réalise un test de pénétration en mars 2025, corrige 60 % des vulnérabilités identifiées et ne reteste pas avant mars 2026 n'a pas un programme de résilience — elle a un audit avec un cycle de publication annuel. DORA attend un programme continu, avec des boucles de remédiation tracées et auditables.
L'erreur courante : confier les tests à l'équipe de sécurité interne sans supervision externe, puis présenter les résultats comme preuve de conformité DORA. Un test conduit par l'équipe qui opère les systèmes testés ne satisfait pas aux exigences d'indépendance de l'article 24(3). Les superviseurs commencent à demander les mandats et les CV des testeurs lors des contrôles sur place.
Lacune 2 : le registre ICT ne couvre pas les niveaux 2 et 3
L'article 28(3) de DORA impose la tenue d'un registre "exhaustif et actualisé" de tous les accords contractuels avec des prestataires ICT tiers. Dans la pratique, la majorité des registres établis en 2025 couvrent les prestataires directs — le niveau 1. La visibilité s'arrête là.
Or, les incidents systémiques les plus coûteux des dernières années impliquent précisément les niveaux 2 et 3. L'incident CrowdStrike de juillet 2024 a paralysé des systèmes dans des entités qui n'avaient aucune relation contractuelle directe avec l'éditeur — il était intégré dans les solutions de leurs prestataires MSP. La panne Cloudflare de janvier 2025 a affecté des centaines d'entités financières qui ne le référençaient pas dans leur registre DORA parce qu'elles ignoraient leur dépendance indirecte.
La règle pratique : pour chaque prestataire ICT critique — défini comme un prestataire dont la défaillance aurait un impact sur des fonctions critiques ou importantes — demander un niveau de cartographie supplémentaire : ses propres sous-traitants hébergeant des traitements en votre nom. Cette information doit contractuellement être communicable en vertu de l'article 30. Si votre prestataire refuse, c'est un signal de concentration masqué à documenter.
Lacune 3 : les délais de notification sont théoriques
DORA impose une notification initiale aux autorités compétentes dans les 4 heures suivant la classification d'un incident majeur, et un rapport intermédiaire dans les 72 heures. Dans les simulations de crise conduites par les équipes ACPR en 2025, le délai médian entre la détection d'un incident et sa classification formelle comme "incident majeur" est de 6 à 14 heures — avant même de démarrer le chrono des 4 heures réglementaires.
Le point de friction est structurel : le processus de classification. Qui décide qu'un incident est "majeur" au sens DORA ? Sur quels critères quantifiés ? Dans quelle fenêtre de temps ? Dans la majorité des entités auditées, ce processus implique une chaîne de validation à 3 ou 4 niveaux hiérarchiques. Le temps d'atteindre la décision, les 4 heures sont souvent dépassées.
La correction est organisationnelle, pas technique : formaliser un tableau de classification DORA avec des seuils pré-approuvés par le conseil d'administration — nombre d'utilisateurs affectés, durée d'interruption, volume de données compromises — et déléguer la décision de classification au RSSI ou au CRO avec un droit d'alerte autonome. Le régulateur peut accepter un délai dépassé sur bonne foi documentée ; il n'accepte pas un processus de décision non formalisé.
Lacune 4 : le risque ICT n'est pas intégré dans le cycle de décision du conseil
DORA (article 5) impose que les membres de l'organe de direction restent "actifs dans la gestion du risque ICT" et définissent des "stratégies de tolérance au risque ICT". Dans les faits, la gouvernance ICT reste dans les directions techniques et arrive au conseil sous forme de rapports agrégés — une fois par an, dans 68 % des entités interrogées (Deloitte, mars 2026).
Ce n'est pas une question de compétence technique des administrateurs. C'est une question de format de reporting. Un tableau de bord ICT conçu pour un RSSI — taux de vulnérabilités corrigées, temps moyen de détection, logs d'incidents — ne permet pas à un conseil de prendre des décisions stratégiques sur la tolérance au risque. Ce qu'un conseil peut décider : quel niveau d'interruption de service est acceptable pour quelle fonction critique ? Quelle part du budget allouer à la continuité d'activité ? Ces décisions nécessitent un langage de risque métier — pas un langage technique.
L'indicateur pratique : votre conseil peut-il répondre, sans consulter la DSI, à la question suivante — "quelle est notre RTO pour le système de paiement en cas d'incident ICT majeur ?" Si la réponse nécessite un aller-retour, votre gouvernance ICT n'est pas intégrée au sens de l'article 5 DORA.
Ce que vous pouvez engager dès maintenant
Trois actions à portée immédiate, sans programme de transformation. Premièrement, réévaluer l'indépendance de vos testeurs : vérifiez que vos tests de pénétration DORA sont conduits par des parties indépendantes des équipes opérantes. C'est votre premier risque de défaut en inspection. Deuxièmement, enrichir votre registre ICT d'un niveau : contactez vos cinq prestataires les plus critiques et demandez leur liste de sous-traitants hébergeant des données ou des fonctions en votre nom. La réponse — ou l'absence de réponse — est déjà un indicateur. Troisièmement, formaliser votre tableau de classification des incidents : un document d'une page, pré-approuvé, avec seuils explicites et délégation de décision au RSSI.
Presidio intègre un module de gestion du risque ICT aligné DORA — registre tiers par niveaux, suivi des incidents avec chronomètre réglementaire intégré, et workflow de notification structuré. Pour évaluer l'écart entre votre gouvernance actuelle et les attentes régulatrices, un entretien de 30 minutes suffit à cartographier les priorités. Voir aussi notre analyse sur les clauses contractuelles DORA Article 28 et notre bilan sur les risques de concentration ICT.
Conclusion
Dix-huit mois après l'entrée en application de DORA, trois certitudes s'imposent. La conformité documentaire avance mais ne préjuge pas de la conformité opérationnelle — et les régulateurs le savent. Les premières inspections approfondies, attendues pour 2026-2027, cibleront précisément l'écart entre les politiques et leur mise en œuvre réelle. Les entités qui investissent dès maintenant dans la remédiation opérationnelle — tests indépendants, registre niveau 2, processus de notification formalisé, gouvernance conseil structurée — auront une longueur d'avance dans un cycle de supervision qui vient juste de commencer. Et dans votre contexte : si vous deviez recevoir une demande d'information superviseur demain matin, quel serait le maillon le plus fragile de votre chaîne de gouvernance ICT ?