Le règlement DORA — Digital Operational Resilience Act, ou Regulation (EU) 2022/2554 pour les puristes — est applicable depuis le 17 janvier 2025. Si vous travaillez dans la conformité, la DSI ou la direction des risques d'un établissement financier européen, ce texte redéfinit les règles du jeu. Pas dans six mois. Maintenant.
Soyons francs : la plupart des guides sur DORA se contentent de paraphraser le Journal Officiel. Ici, on va décortiquer ce que ça change vraiment au quotidien, avec des retours terrain et sans langue de bois.
Pourquoi DORA existe — et pourquoi maintenant
Le secteur financier européen repose sur des systèmes numériques interconnectés à un niveau que peu de régulateurs avaient pleinement mesuré. La panne CrowdStrike de juillet 2024 a servi de piqûre de rappel : des milliers d'institutions financières paralysées en quelques heures à cause d'une mise à jour défaillante chez un seul éditeur. Une banque espagnole n'a pas pu traiter de virements pendant 14 heures.
Avant DORA, chaque pays de l'UE avait sa propre approche. Une banque opérant en France, Allemagne et Italie devait jongler avec trois cadres réglementaires différents pour la gestion du risque cyber. Le résultat ? Des zones grises, des doublons administratifs, et surtout des angles morts que les attaquants exploitaient volontiers.
DORA harmonise tout ça. Un seul cadre. Vingt-et-un types d'entités concernés. Application directe, sans transposition nationale — c'est un règlement, pas une directive.
Les 5 piliers de DORA : vue d'ensemble
Le règlement s'articule autour de cinq axes. On les survole ici avant de plonger dans chacun :
| Pilier | Articles | Objet | Fréquence |
|---|---|---|---|
| Gestion des risques ICT | 5-16 | Cadre global de maîtrise du risque numérique | Continu |
| Reporting incidents ICT | 17-23 | Notification harmonisée des incidents majeurs | Par événement |
| Tests de résilience | 24-27 | Tests annuels + TLPT tous les 3 ans | Annuel / triennal |
| Risques tiers ICT | 28-44 | Registre prestataires, clauses contractuelles, supervision | Continu |
| Partage d'informations | 45 | Échange volontaire de renseignements cyber | Volontaire |
Pilier 1 — La gestion des risques ICT en profondeur
C'est le socle. Sans lui, le reste ne tient pas. Les articles 5 à 16 imposent un cadre de gestion des risques ICT qui va bien au-delà d'une politique de sécurité classique.
La responsabilité remonte au comité de direction
Premier changement majeur : le comité de direction porte la responsabilité ultime de la gestion du risque ICT. Fini le temps où la cybersécurité restait cantonnée à la DSI avec un budget négocié au lance-pierres. L'article 5 est explicite — les membres du board doivent définir, approuver et superviser la mise en œuvre du cadre de gestion des risques ICT.
Un RSSI d'une banque régionale m'a confié que DORA avait eu un effet inattendu dans son établissement. Pour la première fois en douze ans, le conseil d'administration lui a demandé un reporting mensuel détaillé. Plus de tableau de bord avec des feux verts pour tout le monde — des indicateurs précis, des scénarios de risque chiffrés, des plans de remédiation datés.
Cartographie et identification des fonctions critiques
Chaque entité doit identifier ses fonctions critiques ou importantes, cartographier les systèmes qui les supportent, et évaluer les risques associés. Ça paraît évident, mais combien d'établissements savent réellement quels systèmes supportent leur processus de compensation interbancaire ? Ou quel prestataire héberge les données de leurs clients les plus sensibles ?
Les articles 8 et 9 détaillent les exigences en matière de protection : politiques de sécurité réseau, chiffrement des données au repos et en transit, gestion des identités et des accès, détection des anomalies. Pas de surprise technique ici — mais l'obligation de formalisation et de documentation change la donne pour beaucoup.
Le cadre simplifié pour les petites entités
L'article 16 prévoit un cadre simplifié pour les micro-entreprises et certaines petites entités. Elles restent soumises aux obligations fondamentales mais bénéficient d'allègements sur la documentation et les processus. Attention toutefois — "simplifié" ne signifie pas "optionnel". Une petite société de gestion doit quand même disposer d'un cadre de gestion des risques ICT proportionné à sa taille et à la complexité de ses activités.
Pilier 2 — Le reporting des incidents ICT majeurs
Les articles 17 à 23 instaurent un processus de notification harmonisé à l'échelle européenne. Avant DORA, une banque présente dans cinq pays devait se conformer à cinq procédures différentes de déclaration d'incidents. Un cauchemar administratif en pleine gestion de crise.
Le calendrier de notification
| Étape | Délai | Contenu |
|---|---|---|
| Notification initiale | 4h après classification (max 24h après détection) | Nature de l'incident, systèmes affectés, impact estimé |
| Rapport intermédiaire | 72 heures | Évolution, mesures prises, impact révisé |
| Rapport final | 1 mois | Analyse racine, mesures correctives, leçons apprises |
Quatre heures. Ça laisse peu de marge pour tergiverser sur la qualification d'un incident. Les critères de classification sont définis dans les normes techniques (RTS) publiées par les Autorités Européennes de Surveillance — EBA, EIOPA et ESMA. Un incident est considéré majeur en fonction du nombre de clients affectés, de la durée d'indisponibilité, de l'étendue géographique, de la perte de données et de l'impact sur les transactions.
Votre équipe SOC est-elle dimensionnée pour classifier un incident en moins de 4 heures un vendredi soir ? La question mérite d'être posée avant que la situation ne se présente. Pour comprendre les détails de cette procédure, consultez notre article sur le reporting des incidents ICT DORA.
Pilier 3 — Les tests de résilience opérationnelle numérique
Deux niveaux de tests coexistent sous DORA. Les tests de résilience de base concernent toutes les entités ; les tests TLPT sont réservés aux entités significatives.
Tests de base — annuels, obligatoires pour tous
Chaque année minimum, les entités financières doivent conduire des évaluations de vulnérabilité, des analyses de la sécurité réseau, des analyses en source ouverte, des examens de sécurité physique et des tests de pénétration. Le périmètre doit couvrir l'ensemble des systèmes et applications ICT supportant des fonctions critiques.
TLPT — Threat-Led Penetration Testing pour les entités significatives
Inspirés du framework TIBER-EU, les tests TLPT doivent être conduits au moins tous les trois ans par des testeurs externes qualifiés. Ils simulent des attaques réalistes basées sur des renseignements actuels sur les menaces. Le périmètre inclut les fonctions critiques externalisées — ce qui signifie que vos prestataires cloud peuvent être inclus dans le test.
Un point souvent sous-estimé : le coût d'un TLPT. Comptez entre 200 000 et 500 000 euros pour un établissement de taille intermédiaire. Le marché des prestataires qualifiés est encore étroit, ce qui tire les prix vers le haut.
Pilier 4 — La gestion des risques liés aux tiers ICT
C'est probablement l'aspect le plus novateur — et le plus contraignant — de DORA. Les articles 28 à 44 imposent un cadre strict pour gérer la relation avec les prestataires de services ICT. Si vous voulez approfondir ce sujet, notre analyse détaillée sur DORA et la gestion des risques ICT tiers couvre l'ensemble des obligations.
Le registre d'informations — pas un simple tableur
Chaque entité financière doit constituer et maintenir un registre exhaustif de tous ses contrats avec des prestataires ICT tiers. Ce registre doit contenir la nature des services, les fonctions supportées, la classification critique ou non, les sous-traitants, les juridictions de traitement des données, et les mécanismes de sortie. Il doit être transmis à l'autorité compétente sur demande. Plus de détails dans notre article dédié au registre d'informations DORA.
Clauses contractuelles minimales (article 30)
Tout contrat avec un prestataire ICT doit intégrer des dispositions précises sur les niveaux de service, les droits d'audit, les obligations de notification, les plans de sortie et les garanties de continuité. Pour les fonctions critiques, les exigences sont encore renforcées : localisation des données, encadrement de la sous-traitance, participation aux tests de sécurité.
Concrètement, ça implique de revoir potentiellement des centaines de contrats. Une compagnie d'assurance de taille moyenne travaille typiquement avec 50 à 150 prestataires ICT. Combien de ces contrats intègrent aujourd'hui une clause de sortie conforme à l'article 30 ? Très peu, en général.
Supervision directe des prestataires ICT critiques
Innovation majeure : les prestataires ICT désignés comme critiques seront directement supervisés par un superviseur principal parmi les trois AES. Ce superviseur peut réaliser des inspections sur site, demander des informations, émettre des recommandations et imposer des astreintes en cas de non-conformité. Les critères de désignation tiennent compte de l'importance systémique du prestataire, du degré de dépendance des entités financières et de la substituabilité du service.
Pilier 5 — Le partage d'informations cyber
L'article 45 encourage — sans imposer — les entités financières à échanger des renseignements sur les menaces cyber. Tactiques, techniques et procédures des attaquants, indicateurs de compromission, alertes de sécurité. DORA pose le cadre juridique de ce partage, notamment en matière de protection des données et de responsabilité.
En pratique, les ISAC (Information Sharing and Analysis Centers) sectoriels existants comme le FS-ISAC devraient voir leur rôle renforcé. Mais on est loin d'un partage systématique — la culture du secret reste profondément ancrée dans la finance.
Qui est concerné par DORA ? Les 21 catégories d'entités
Le périmètre est vaste. Voici les principales catégories :
| Catégorie | Exemples |
|---|---|
| Établissements de crédit | Banques commerciales, banques mutualistes |
| Entreprises d'investissement | Sociétés de bourse, courtiers |
| Établissements de paiement | Prestataires de services de paiement |
| Établissements de monnaie électronique | Émetteurs de monnaie électronique |
| Entreprises d'assurance et de réassurance | Assureurs vie, non-vie, réassureurs |
| Intermédiaires d'assurance | Courtiers d'assurance (au-dessus des seuils) |
| Institutions de retraite professionnelle | Fonds de pension |
| Sociétés de gestion | OPCVM, FIA, sociétés de gestion de portefeuille |
| Prestataires de services sur crypto-actifs | Exchanges, custodians crypto (sous MiCA) |
| Dépositaires centraux de titres | Euroclear, Clearstream |
| Contreparties centrales | LCH, Eurex Clearing |
| Plateformes de négociation | Euronext, marchés régulés, MTF |
| Agences de notation | S&P, Moody's, Fitch (établissements UE) |
| Prestataires de services de financement participatif | Plateformes de crowdfunding |
| Administrateurs d'indices de référence | Euribor, indices critiques |
Et les prestataires ICT tiers critiques, même s'ils ne sont pas des entités financières, tombent sous la supervision directe des AES.
DORA vs NIS2 : quelle articulation ?
Question récurrente. DORA est un règlement sectoriel (lex specialis) ; NIS2 est une directive transversale. Pour les entités financières, DORA prévaut en cas de chevauchement. Mais si vous êtes un opérateur de services essentiels au sens de NIS2 ET une entité financière, vous devez vous conformer aux deux. Notre comparatif détaillé DORA vs NIS2 décortique les recoupements et les différences.
Les étapes de mise en conformité — par où commencer
Le règlement est applicable depuis janvier 2025. Si vous n'avez pas encore commencé, il est urgent d'accélérer. Voici une feuille de route pragmatique :
| Étape | Action | Délai recommandé |
|---|---|---|
| 1 | Gap analysis DORA vs pratiques actuelles | 1-2 mois |
| 2 | Identification et documentation des fonctions critiques | 2-3 mois |
| 3 | Cartographie des prestataires ICT + constitution du registre | 3-4 mois |
| 4 | Revue et renégociation des contrats (article 30) | 6-12 mois |
| 5 | Mise en place du cadre de gestion des incidents | 2-3 mois |
| 6 | Programme de tests de résilience | Annuel |
| 7 | Adaptation de la gouvernance — implication du board | Immédiat |
Sanctions : ce que risquent les entités non conformes
DORA laisse aux États membres le soin de définir les sanctions. En France, l'ACPR (banques, assurances) et l'AMF (marchés) sont les autorités compétentes. Les mesures possibles incluent des injonctions, des astreintes, des sanctions pécuniaires et — dans les cas extrêmes — le retrait d'agrément. Pour un panorama complet, consultez notre article sur les sanctions DORA.
Pour les prestataires ICT critiques, les AES peuvent imposer des astreintes allant jusqu'à 1% du chiffre d'affaires mondial journalier moyen. Ça peut monter vite pour un hyperscaler.
Les normes techniques — RTS et ITS
Les AES ont publié les normes techniques en deux lots :
| Lot | Date | Contenu |
|---|---|---|
| Lot 1 | Janvier 2024 | Cadre gestion risques ICT, classification incidents, reporting, registre d'informations, politique tiers ICT |
| Lot 2 | Juillet 2024 | TLPT, critères désignation prestataires critiques, cadre supervision directe, sous-traitance |
FAQ — Questions fréquentes sur le règlement DORA
DORA s'applique-t-il aux succursales d'entités de pays tiers ?
Oui, dans la mesure où elles sont établies dans l'UE et relèvent de la supervision d'une autorité compétente européenne.
Les prestataires ICT qui ne sont pas désignés comme critiques sont-ils hors périmètre ?
Non. Les obligations contractuelles de l'article 30 s'appliquent à tous les prestataires ICT tiers — la désignation critique ajoute la supervision directe par les AES, mais les exigences de base s'appliquent à tous.
Quel budget prévoir pour la mise en conformité ?
Difficile de généraliser. Pour un établissement bancaire de taille intermédiaire (1 000 à 5 000 employés), les estimations du marché oscillent entre 2 et 8 millions d'euros sur deux ans, incluant les audits, la mise à niveau technique, la renégociation des contrats et les tests TLPT.
DORA remplace-t-il les guidelines existantes de l'EBA sur l'externalisation ?
DORA absorbe et renforce les guidelines EBA/2019/02 sur l'externalisation. Les entités qui étaient déjà conformes à ces guidelines ont une base solide mais doivent combler les écarts, notamment sur le registre d'informations et les tests de résilience.
DORA transforme la manière dont le secteur financier européen aborde la résilience numérique. Ce n'est plus un sujet technique — c'est un enjeu de gouvernance au plus haut niveau. Les entités qui ont anticipé s'en sortent mieux. Les autres rattrapent, tant bien que mal. Où en êtes-vous ?