Applicable depuis le 17 janvier 2025, le règlement DORA a fait passer la résilience numérique du secteur du registre des bonnes pratiques financières, à celui de l'obligation. Après une première année consacrée à la mise en conformité documentaire, 2026-2027 est celle de la preuve : registres exploitables, tests réels, stratégies de sortie crédibles. C'est un chantier d'architecture autant que de conformité.

DORA en 4 mots

Le Digital Operational Resilience Act — règlement (UE) 2022/2554 — impose aux entités financières de pouvoir résister à un incident informatique majeur, y répondre et y remédier, y compris lorsque cet incident survient chez un prestataire. Il s'accompagne de la directive (UE) 2022/2556, qui ajuste les textes sectoriels existants, et d'une série de normes techniques (RTS et ITS) élaborées par les autorités européennes de surveillance (ABE, AEAPP, AEMF).

Parce qu'il s'agit d'un règlement, DORA s'applique directement dans tous les États membres, sans transposition : les mêmes règles valent à Paris, Francfort ou Milan.

Qui est concerné ?

Une vingtaine de catégories d'entités financières entrent dans le périmètre, notamment :

• les établissements de crédit, les établissements de paiement et de monnaie électronique ;
• les entreprises d'investissement, les sociétés de gestion, les dépositaires centraux et les plateformes de négociation ;
• les entreprises d'assurance et de réassurance, ainsi que les intermédiaires d'assurance au-delà d'une certaine taille ;
• les institutions de retraite professionnelle ;
• les prestataires de services sur crypto-actifs agréés au titre de MiCA ;
• les agences de notation, les administrateurs d'indices critiques, les plateformes de financement participatif.

Et, indirectement, tous leurs prestataires de services informatiques : éditeurs, hébergeurs, infogéreurs, fournisseurs cloud, ESN. Ils ne sont pas assujettis en propre (sauf si désignés comme prestataire critique, voir plus bas), mais les obligations de leurs clients financiers se traduisent en clauses contractuelles, en audits et en exigences de tests.

Le texte applique un principe de proportionnalité : taille, profil de risque, nature et complexité des activités modulent les exigences. Certaines petites entités bénéficient d'un cadre de gestion du risque simplifié.

Les cinq piliers

Le calendrier

• 16 janvier 2023 : entrée en vigueur du règlement.
• 2023-2024 : adoption des normes techniques (classification des incidents, cadre de gestion du risque, registre d'information, politique de recours aux prestataires, TLPT…).
• 17 janvier 2025 : application de l'ensemble des obligations.
• 2025 : première remise des registres d'information aux autorités, puis aux autorités européennes de surveillance pour préparer la désignation des prestataires critiques.
• Fin 2025 : publication de la première liste de prestataires tiers critiques désignés par les autorités européennes (à vérifier : périmètre et date exacte sur les sites de l'ABE, de l'AEAPP et de l'AEMF).
• 2026-2027 : premiers cycles de supervision des prestataires critiques et premières campagnes de TLPT selon les programmes fixés par les autorités.

En France, l'ACPR et l'AMF sont les autorités compétentes selon la nature des entités. Le projet de loi relatif à la résilience des infrastructures critiques, qui porte la transposition de NIS2 et les ajustements liés à DORA, était encore en cours d'adoption à mi-2026 (statut à confirmer).

La notification des incidents majeurs

Un incident est qualifié de majeur selon des critères harmonisés : clients et contreparties touchés, durée et interruption de service, étendue géographique, perte de données, criticité des services affectés, impact économique. Une fois l'incident classé majeur, les normes techniques fixent un rythme serré :

Ces délais sont intenables sans une cartographie à jour reliant chaque service métier à ses applications, à ses infrastructures et à ses prestataires : c'est elle qui permet de qualifier l'impact en quelques heures plutôt qu'en quelques jours. Vérifier les délais applicables dans la version en vigueur des normes techniques.

Le cœur du sujet : les prestataires tiers

Le registre d'information

Chaque entité doit tenir un registre de tous ses accords contractuels portant sur des services TIC, au niveau de l'entité et du groupe, en distinguant ceux qui soutiennent des fonctions critiques ou importantes. Le registre suit un format normalisé : identification des prestataires, services fournis, fonctions soutenues, localisation des données et des traitements, chaîne de sous-traitance, substituabilité.

Beaucoup d'organisations l'ont constitué en 2025 dans l'urgence, à partir d'extractions des achats et de la comptabilité fournisseurs. Résultat fréquent : un registre juridiquement complet mais déconnecté de la cartographie du SI, donc inutilisable pour qualifier un incident ou évaluer une concentration. Le relier au référentiel d'architecture est le chantier de 2026.

Les clauses contractuelles obligatoires

L'article 30 fixe un socle minimal pour tout contrat TIC :

• description complète des services et des niveaux de service ;
• localisation des régions ou pays de fourniture et de traitement des données ;
• disponibilité, authenticité, intégrité et confidentialité des données ;
• accès, récupération et restitution des données en cas d'insolvabilité, de résolution ou de fin de contrat ;
• assistance en cas d'incident, coopération avec les autorités, droits de résiliation.

Pour les contrats qui soutiennent des fonctions critiques ou importantes, s'y ajoutent :

• des niveaux de service quantifiés et des délais de préavis ;
• des plans de continuité du prestataire, testés ;
• la participation du prestataire aux tests de l'entité, y compris aux TLPT ;
• des droits d'accès, d'inspection et d'audit sans restriction ;
• des stratégies de sortie assorties d'une période de transition adéquate.

Les stratégies de sortie et le risque de concentration

DORA exige, pour chaque fonction critique ou importante externalisée, une stratégie de sortie documentée et testée : comment quitter le prestataire sans perturber l'activité, sans dégrader la qualité du service et sans enfreindre la réglementation. L'entité doit aussi évaluer le risque de concentration : dépendance à un prestataire difficilement substituable, ou recours à plusieurs prestataires eux-mêmes liés.

C'est ici que DORA rejoint la souveraineté numérique : une banque dont les fonctions critiques reposent sur un seul hyperscaler soumis à un droit étranger cumule risque de concentration, risque extraterritorial et risque de coupure. Le Data Act, qui supprime les frais de sortie cloud à partir du 12 janvier 2027, rend enfin ces stratégies de sortie économiquement réalistes.

La supervision des prestataires critiques

Innovation majeure du texte : les prestataires TIC jugés critiques pour le secteur financier européen sont désignés par les autorités européennes de surveillance et placés sous la supervision directe d'un « superviseur principal ». Celui-ci peut mener des inspections, émettre des recommandations et infliger des astreintes pouvant atteindre 1 % du chiffre d'affaires quotidien moyen mondial du prestataire. Les grands fournisseurs de cloud figurent parmi les premiers concernés.

Pour l'entité financière, cette supervision ne transfère pas la responsabilité : elle reste pleinement responsable du respect de ses obligations, quel que soit son prestataire.

Pourquoi DORA est un chantier d'architecture

Lu en architecte, DORA demande de pouvoir répondre en permanence à une question simple : « si ce composant tombe, quelles fonctions critiques s'arrêtent, pour combien de clients, et comment les rétablir ? ». Cela suppose une chaîne de traçabilité complète, que TOGAF et ArchiMate outillent naturellement :

Un modèle unique — capacité métier → application → composant technique → prestataire → contrat — sert à la fois le registre DORA, la qualification des incidents, l'évaluation de concentration et les plans de sortie. Il sert aussi NIS2 et le Cyber Resilience Act, qui demandent la même visibilité sur la chaîne d'approvisionnement : un seul référentiel pour trois textes.

Les pièges observés

• Le registre « tableur » : exhaustif pour l'autorité, inexploitable pour l'opérationnel parce qu'il ne dit pas quelles fonctions s'arrêtent quand un prestataire tombe.
• La stratégie de sortie de papier : rédigée pour l'audit, jamais testée, sans estimation de délai ni de coût, sans solution de repli identifiée.
• La sous-traitance en cascade ignorée : l'éditeur SaaS est connu, l'hyperscaler qui l'héberge ne l'est pas — et c'est souvent lui le point de concentration.
• Les fonctions critiques trop nombreuses : tout qualifier de critique dilue l'effort ; une qualification argumentée, validée par les métiers, concentre les moyens là où l'impact est réel.
• DORA traité par la seule conformité : sans l'architecture, la DSI et les achats, le dispositif reste déclaratif.

Feuille de route en quatre étapes

1. Qualifier les fonctions critiques ou importantes avec les métiers, sur la base de la carte des capacités, et documenter la justification de chaque qualification.
2. Relier le registre d'information à la cartographie : pour chaque fonction critique, les applications, les composants et les prestataires de rang 1 et 2 qui la soutiennent.
3. Évaluer concentration et substituabilité, puis rédiger et tester les stratégies de sortie des services les plus exposés, en exploitant les droits du Data Act.
4. Réviser les contrats au fil des renouvellements (clauses de l'article 30) et intégrer la résilience aux revues d'architecture des nouveaux projets.

Indicateurs de pilotage

• Part des fonctions critiques ou importantes dont la chaîne de dépendances est cartographiée de bout en bout.
• Part des contrats soutenant une fonction critique conformes à l'article 30.
• Part des fonctions critiques externalisées disposant d'une stratégie de sortie testée, et délai de sortie estimé.
• Nombre de prestataires non substituables à moins de six mois.
• Délai moyen de qualification d'un incident (de la détection à la classification).

DORA ne demande pas d'éliminer les dépendances — c'est impossible — mais de les connaître, de les contractualiser et de savoir en sortir. C'est exactement la définition de l'autonomie stratégique.

Notre offre « NIS2 / DORA — volet architecture » combine analyse d'exposition, architecture de conformité, registre des dépendances et exercices de coupure en 3 à 4 mois. Services associés : C-02, B-04, G-01, E-02.