DORA en France : guide ACPR/AMF 2026 pour les entités financières

En une phrase. Le règlement DORA (règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier) s’applique directement en France depuis le 17 janvier 2025 : les banques, assureurs, sociétés de gestion, prestataires de paiement et une quinzaine d’autres catégories d’entités financières doivent gérer leurs risques TIC, notifier leurs incidents majeurs à l’ACPR ou à l’AMF, tenir un registre d’informations sur leurs prestataires TIC et, pour les plus grandes, conduire des tests de pénétration fondés sur la menace (TLPT).

DORA n’est pas une directive : c’est un règlement, directement applicable sans transposition. La France a néanmoins dû adapter le code monétaire et financier via la directive d’accompagnement (directive (UE) 2022/2556), intégrée au même véhicule législatif que la transposition de NIS2. Résultat : le secteur financier français relève de DORA et de ses superviseurs sectoriels (ACPR, AMF), et non de l’ANSSI — DORA est lex specialis par rapport à NIS2.

Ce guide couvre le périmètre, les cinq piliers, la répartition ACPR/AMF, les RTS applicables et un plan d’action 2026.

Points clés

• Applicable depuis le 17 janvier 2025 à une vingtaine de catégories d’entités financières, plus leurs prestataires TIC critiques.
• ACPR : banques, assurances, prestataires de paiement. AMF : sociétés de gestion, entreprises d’investissement, prestataires crypto (MiCA).
• Registre d’informations sur tous les contrats TIC, à remettre annuellement au superviseur — première collecte réalisée en avril 2025 au format ESA.
• Notification des incidents TIC majeurs : rapport initial sous 4 heures après classification (et au plus tard 24 h après détection), intermédiaire sous 72 h, final sous un mois.
• Tests TLPT tous les 3 ans pour les entités désignées, sur le modèle TIBER-EU.

1. Qui est concerné en France

L’article 2 de DORA vise notamment : établissements de crédit, établissements de paiement et de monnaie électronique, entreprises d’investissement, sociétés de gestion, entreprises d’assurance et de réassurance, intermédiaires d’assurance (au-delà des seuils de micro-entreprise), institutions de retraite professionnelle, prestataires de services sur crypto-actifs, plateformes de financement participatif, ainsi que les prestataires tiers de services TIC désignés comme critiques (CTPP), supervisés directement au niveau européen par les autorités européennes de surveillance (AES).

Le principe de proportionnalité (article 4) module les exigences : un intermédiaire d’assurance de 30 salariés n’est pas soumis au même niveau qu’un établissement systémique, et certaines entités bénéficient du cadre simplifié de gestion du risque TIC (article 16).

2. Les cinq piliers de DORA

Pilier 1 — Gouvernance et gestion du risque TIC (articles 5 à 16)

L’organe de direction porte la responsabilité finale de la gestion du risque TIC : cartographie des actifs et des fonctions critiques ou importantes, politique de sécurité, détection, continuité d’activité et plans de réponse et de rétablissement, communication de crise. La logique prolonge l’arrêté du 3 novembre 2014 sur le contrôle interne (bien connu des établissements ACPR), mais avec un niveau de détail nettement supérieur, précisé par le RTS sur le cadre de gestion du risque TIC.

Pilier 2 — Notification des incidents TIC (articles 17 à 23)

Les incidents sont classifiés selon les critères du RTS dédié (clients affectés, durée, étendue géographique, pertes de données, criticité des services, impact économique). Pour un incident majeur : notification initiale dans les 4 heures suivant la classification et au plus tard 24 heures après détection, rapport intermédiaire sous 72 heures, rapport final sous un mois. Les entités doivent aussi pouvoir signaler volontairement les cybermenaces importantes. Sur le chevauchement avec les autres régimes de notification, voir notre analyse comparée DORA / NIS2 / RGPD et la notification de violation RGPD — un même incident peut déclencher les trois.

Pilier 3 — Tests de résilience (articles 24 à 27)

Toutes les entités testent régulièrement leurs systèmes (analyses de vulnérabilités, tests de scénarios, revues de code). Les entités désignées par leur superviseur conduisent en plus des tests de pénétration fondés sur la menace (TLPT) tous les 3 ans, selon le cadre TIBER-EU décliné en France sous pilotage Banque de France/ACPR. Les testeurs doivent répondre à des exigences strictes — le recours à des prestataires qualifiés type PASSI est une pratique de place.

Pilier 4 — Risque lié aux tiers TIC (articles 28 à 44)

C’est le pilier le plus lourd opérationnellement : recensement exhaustif des contrats TIC dans un registre d’informations au format normalisé (ITS du 29 novembre 2024), clauses contractuelles obligatoires (article 30 : audit, résiliation, localisation des données, sous-traitance en cascade, stratégie de sortie), analyse de risque avant contractualisation, stratégie multi-fournisseurs. Les premières remises de registres aux superviseurs ont eu lieu en avril 2025 via le portail de l’ACPR et de l’AMF, pour agrégation européenne par les AES et désignation des prestataires critiques. Le parallèle avec l’encadrement des sous-traitants sous l’article 28 RGPD et la sous-traitance cloud est direct : mêmes fournisseurs, clauses différentes, registres distincts.

Pilier 5 — Partage d’informations (article 45)

Cadre volontaire d’échange de renseignements sur les cybermenaces entre entités financières.

3. Répartition ACPR / AMF et sanctions

• ACPR : établissements de crédit, sociétés de financement, établissements de paiement et de monnaie électronique, organismes d’assurance et intermédiaires.
• AMF : sociétés de gestion, entreprises d’investissement, conseillers en investissement, prestataires crypto, plateformes de financement participatif.

Les pouvoirs de sanction s’exercent via les commissions des sanctions existantes de chaque autorité, selon le régime adapté du code monétaire et financier. DORA ne fixe pas de plafond harmonisé pour les entités financières (contrairement au RGPD ou à NIS2) — mais les astreintes contre les prestataires TIC critiques supervisés par les AES peuvent atteindre 1 % du chiffre d’affaires quotidien moyen mondial, par jour, pendant six mois.

4. Plan d’action 2026

1. Registre d’informations : industrialiser la collecte (la remise est annuelle, les rejets pour erreurs de format ont été massifs lors de la première campagne).
2. Cartographie des fonctions critiques ou importantes et des actifs TIC qui les portent — même socle que la cartographie du SI.
3. Revue contractuelle article 30 : avenants sur les contrats TIC supportant des fonctions critiques, stratégie de sortie documentée et testée.
4. Procédure incidents : chronomètre 4 h/24 h/72 h testé en exercice, articulation avec la CNIL côté données personnelles.
5. Programme de tests : plan pluriannuel, préparation TLPT pour les entités désignées.

La volumétrie documentaire de DORA (registre, contrats, politiques, incidents) se prête mal à une gestion sous tableur. Legiscope automatise la partie commune aux référentiels — cartographie des fournisseurs et des traitements, suivi des clauses contractuelles, registres — ce qui évite de reconstruire trois fois la même base pour DORA, NIS2 et le RGPD.

FAQ

DORA s’applique-t-il aux fintechs et aux prestataires crypto ?

Oui. Les établissements de paiement, de monnaie électronique et les prestataires de services sur crypto-actifs agréés MiCA sont dans le périmètre de l’article 2. Le principe de proportionnalité et le cadre simplifié de l’article 16 allègent les exigences pour les petites structures, sans les en dispenser. Voir aussi notre analyse du coût de la non-conformité DORA pour les fintechs.

Quelle différence entre DORA et NIS2 pour une banque française ?

DORA est lex specialis : une entité financière couverte par DORA applique DORA pour l’essentiel de la gestion du risque TIC et de la notification d’incidents, sous supervision ACPR/AMF, et non les obligations NIS2 équivalentes sous supervision ANSSI. Détail complet dans notre comparatif DORA vs NIS2.

Le registre d’informations est-il vraiment obligatoire pour toutes les entités ?

Oui, c’est une obligation de l’article 28(3) pour toutes les entités financières, quelle que soit leur taille, couvrant tous les accords contractuels TIC — pas seulement ceux qui portent des fonctions critiques. Le format est fixé par l’ITS européen et la remise s’effectue annuellement auprès de l’ACPR ou de l’AMF.

Qu’est-ce qu’un incident TIC « majeur » ?

Un incident qui atteint les seuils du RTS de classification : proportion de clients ou de contreparties affectés, durée d’indisponibilité, étendue géographique, pertes de données (disponibilité, intégrité, confidentialité), impact sur des services critiques et coût. La classification doit être outillée et rapide, puisque le délai de 4 heures court à partir d’elle.

Conclusion

DORA a fait passer le secteur financier français d’une logique de principes (arrêté de 2014, orientations EBA) à un régime prescriptif et outillé : registre normalisé, délais de notification en heures, tests offensifs obligatoires, clauses contractuelles types. En 2026, les superviseurs sont passés de la pédagogie au contrôle — les entités qui n’ont pas industrialisé leur registre d’informations et leur filière incidents s’exposent en premier. Le bon réflexe : traiter DORA, NIS2 et RGPD comme un socle unique de gestion des risques, pas comme trois silos.