4 août 2026.
Présentation générale
Le Digital Operational Resilience Act, ou DORA, est le règlement européen qui organise la résilience opérationnelle numérique du secteur financier.
Son intitulé complet est le règlement (UE) 2022/2554 du Parlement européen et du Conseil du 14 décembre 2022 sur la résilience opérationnelle numérique du secteur financier. Il est applicable depuis le 17 janvier 2025. (eur-lex.europa.eu)
DORA part d’un constat : la stabilité du secteur financier ne dépend plus seulement de la solidité financière des établissements. Elle dépend aussi de leur capacité à continuer à fonctionner malgré :
- une cyberattaque ;
- une panne informatique ;
- une défaillance du cloud ;
- une erreur logicielle ;
- une perte ou une corruption de données ;
- l’indisponibilité d’un prestataire technologique ;
- une défaillance d’un système d’intelligence artificielle ;
- une rupture de la chaîne de sous-traitance numérique.
Le règlement impose aux entités financières de pouvoir résister, répondre et se rétablir face à un incident lié aux technologies de l’information et de la communication, ou TIC.
DORA ne réglemente pas spécialement l’intelligence artificielle. Un système d’IA utilisé par une banque, un assureur, une société de gestion ou un prestataire financier peut toutefois constituer :
- un actif TIC ;
- un service TIC fourni par un tiers ;
- un composant d’une fonction critique ou importante ;
- une source de risque opérationnel ;
- un outil de détection et de gestion des incidents.
Les projets d’IA déployés dans le secteur financier doivent donc souvent être examinés simultanément au regard :
- de DORA ;
- du règlement européen sur l’intelligence artificielle ;
- du RGPD ;
- des règles prudentielles et sectorielles ;
- des exigences de cybersécurité ;
- des règles relatives à l’externalisation.
DORA met fin à une approche fragmentée dans laquelle les exigences de sécurité numérique variaient fortement entre les différentes branches du secteur financier. Il établit un socle européen commun portant sur cinq ensembles principaux :
- la gestion des risques liés aux TIC ;
- la déclaration des incidents ;
- les tests de résilience opérationnelle numérique ;
- la maîtrise des risques liés aux prestataires tiers ;
- le partage volontaire d’informations sur les cybermenaces.
Le règlement organise également une surveillance européenne directe de certains prestataires tiers critiques de services TIC, notamment de grands fournisseurs de cloud et de technologies. Les autorités européennes de surveillance ont désigné une première liste de dix-neuf prestataires critiques en novembre 2025. (eba.europa.eu)
Points essentiels
- DORA est applicable depuis le 17 janvier 2025.
- Il s’applique directement dans les États membres de l’Union européenne.
- Il vise une grande partie des établissements et infrastructures du secteur financier.
- La direction de l’entité financière demeure responsable de la gestion du risque TIC.
- Les risques numériques doivent être intégrés à la gouvernance générale de l’établissement.
- Les incidents majeurs liés aux TIC doivent être classés et déclarés aux autorités compétentes.
- Les entités doivent organiser des tests réguliers de résilience.
- Certaines entités doivent réaliser des tests avancés fondés sur la menace, ou TLPT.
- Tous les contrats portant sur des services TIC doivent être recensés dans un registre d’informations.
- Les services soutenant une fonction critique ou importante font l’objet d’exigences contractuelles renforcées.
- L’externalisation d’un service ne transfère pas la responsabilité réglementaire au prestataire.
- Les entités doivent préparer des stratégies de sortie et limiter les risques de concentration.
- Certains fournisseurs TIC sont directement surveillés au niveau européen lorsqu’ils sont désignés comme critiques.
- Un fournisseur d’IA ou de modèle génératif peut être un prestataire TIC au sens de DORA.
- DORA et l’AI Act sont complémentaires : le premier protège la continuité opérationnelle, le second encadre les risques propres aux systèmes d’IA.
1. Finalité de DORA
1.1. La résilience opérationnelle numérique
DORA définit la résilience opérationnelle numérique comme la capacité d’une entité financière à construire, assurer et réévaluer son intégrité et sa fiabilité opérationnelles en utilisant les capacités TIC nécessaires pour garantir la sécurité des réseaux et des systèmes d’information.
Cette notion dépasse la cybersécurité au sens strict.
Une organisation peut être techniquement protégée contre certaines attaques tout en étant incapable :
- de maintenir ses services essentiels ;
- de basculer sur une infrastructure de secours ;
- de restaurer ses données ;
- de communiquer pendant une crise ;
- de remplacer un prestataire défaillant ;
- de reprendre son activité dans un délai acceptable.
DORA impose donc une approche reposant sur la continuité complète des activités numériques, et non sur la seule prévention des intrusions.
1.2. Principe d’harmonisation
Avant DORA, les obligations relatives aux risques informatiques étaient dispersées entre :
- plusieurs directives financières ;
- des orientations des autorités européennes ;
- des règles nationales ;
- des recommandations sectorielles ;
- des contrats d’externalisation.
DORA établit des exigences uniformes applicables dans l’ensemble de l’Union. Il constitue une règle spéciale pour les entités financières en matière de gestion des risques TIC. (eur-lex.europa.eu)
2. Entités concernées
DORA s’applique à une liste étendue d’entités financières.
Sont notamment concernés :
- les établissements de crédit ;
- les établissements de paiement ;
- les prestataires de services d’information sur les comptes ;
- les établissements de monnaie électronique ;
- les entreprises d’investissement ;
- les prestataires de services sur cryptoactifs autorisés au titre de MiCA ;
- les dépositaires centraux de titres ;
- les contreparties centrales ;
- les plates-formes de négociation ;
- les référentiels centraux ;
- les gestionnaires de fonds d’investissement alternatifs ;
- les sociétés de gestion d’organismes de placement collectif ;
- les entreprises d’assurance et de réassurance ;
- les intermédiaires d’assurance, de réassurance et d’assurance à titre accessoire, sous réserve des exclusions prévues ;
- les institutions de retraite professionnelle ;
- les agences de notation ;
- les administrateurs d’indices de référence critiques ;
- les prestataires de services de financement participatif ;
- les référentiels des titrisations.
La qualification exacte dépend des définitions et exclusions prévues à l’article 2 du règlement.
Certaines petites entités ou activités bénéficient :
- d’exclusions ;
- d’un cadre simplifié ;
- ou de l’application du principe de proportionnalité.
DORA ne signifie donc pas que toutes les entités financières doivent mettre en œuvre des dispositifs strictement identiques.
3. Principe de proportionnalité
Les exigences doivent être appliquées en tenant compte notamment :
- de la taille de l’entité ;
- de son profil de risque global ;
- de la nature de ses activités ;
- de leur ampleur ;
- de leur complexité ;
- de l’importance de ses services.
Une petite entité n’est pas tenue de reproduire l’organisation technique d’un groupe bancaire international.
Le principe de proportionnalité ne constitue toutefois pas une dispense générale. Une petite structure peut être fortement dépendante d’un service numérique ou traiter des opérations critiques. Elle doit alors mettre en œuvre des mesures adaptées à ce risque réel.
4. Gouvernance et responsabilité de la direction
4.1. Responsabilité de l’organe de direction
L’organe de direction assume la responsabilité ultime de la gestion du risque lié aux TIC.
Il doit notamment :
- définir et approuver le cadre de gestion des risques ;
- déterminer les rôles et responsabilités ;
- approuver la stratégie de résilience ;
- fixer le niveau de tolérance au risque ;
- surveiller la mise en œuvre des mesures ;
- examiner les incidents importants ;
- approuver les politiques relatives aux prestataires tiers ;
- maintenir des connaissances suffisantes sur les risques numériques.
La direction ne peut donc pas considérer DORA comme un sujet réservé à la direction informatique ou au responsable de la sécurité.
4.2. Formation
Les membres de l’organe de direction doivent maintenir des connaissances et compétences suffisantes pour comprendre et évaluer les risques liés aux TIC.
Cette exigence devient particulièrement importante lorsque l’établissement utilise :
- des modèles d’IA complexes ;
- des infrastructures cloud ;
- des services en mode SaaS ;
- des agents autonomes ;
- des chaînes de sous-traitance techniques.
4.3. Fonctions de contrôle
La gouvernance peut associer :
- la direction générale ;
- la DSI ;
- le RSSI ;
- la direction des risques ;
- la conformité ;
- le juridique ;
- le DPO ;
- l’audit interne ;
- les fonctions métiers ;
- la direction des achats.
Le cloisonnement entre ces fonctions est incompatible avec une gestion complète du risque numérique.
5. Cadre de gestion des risques liés aux TIC
5.1. Identification des actifs et dépendances
L’entité doit identifier et documenter :
- ses fonctions ;
- ses actifs informationnels ;
- ses systèmes TIC ;
- les données utilisées ;
- les dépendances entre systèmes ;
- les prestataires ;
- les fonctions critiques ou importantes ;
- les risques associés.
Cette cartographie doit être maintenue à jour.
Dans un projet d’IA, elle peut notamment comprendre :
- le modèle utilisé ;
- son fournisseur ;
- l’infrastructure d’hébergement ;
- les bases documentaires ;
- les interfaces de programmation ;
- les données d’entrée ;
- les journaux ;
- les mécanismes de secours ;
- les sous-traitants.
5.2. Protection et prévention
L’entité doit mettre en œuvre des politiques et outils destinés à protéger :
- la disponibilité ;
- l’authenticité ;
- l’intégrité ;
- la confidentialité des données ;
- les réseaux ;
- les infrastructures ;
- les systèmes physiques et logiques.
Les mesures peuvent porter sur :
- la gestion des identités et des accès ;
- le chiffrement ;
- les correctifs de sécurité ;
- la segmentation ;
- la journalisation ;
- les sauvegardes ;
- la sécurité des développements ;
- la surveillance des vulnérabilités.
5.3. Détection
Les entités doivent disposer de mécanismes permettant de détecter rapidement :
- les activités anormales ;
- les défaillances ;
- les cyberattaques ;
- les incidents de performance ;
- les pertes de données ;
- les compromissions de comptes.
Dans le domaine de l’IA, la détection peut également concerner :
- une dérive du modèle ;
- une hausse anormale des erreurs ;
- une injection malveillante ;
- une fuite de données ;
- une manipulation du corpus ;
- l’indisponibilité d’une API.
5.4. Réponse et rétablissement
L’entité doit organiser :
- la réponse aux incidents ;
- la continuité des activités ;
- la restauration des systèmes ;
- la communication de crise ;
- la reprise des services ;
- l’analyse des causes.
Les plans doivent être testés et suffisamment documentés.
5.5. Sauvegardes
Les politiques de sauvegarde doivent garantir que les données et systèmes peuvent être restaurés :
- de manière sécurisée ;
- dans des délais compatibles avec les fonctions concernées ;
- sans compromettre leur intégrité ;
- dans un environnement distinct lorsque cela est nécessaire.
Pour une IA, la sauvegarde peut devoir couvrir :
- les données ;
- les paramètres ;
- les configurations ;
- les instructions ;
- les versions ;
- les journaux ;
- les composants de recherche documentaire.
6. Incidents liés aux TIC
6.1. Processus de gestion
Les entités financières doivent établir un processus de gestion des incidents permettant :
- leur détection ;
- leur enregistrement ;
- leur classification ;
- leur traitement ;
- leur suivi ;
- leur analyse ;
- leur déclaration éventuelle.
6.2. Classification
La classification tient notamment compte :
- du nombre de clients ou contreparties affectés ;
- de la durée ;
- de l’étendue géographique ;
- de la perte de données ;
- de la criticité des services ;
- des conséquences économiques ;
- du caractère répétitif de l’incident.
Les critères et seuils ont été précisés par le règlement délégué (UE) 2024/1772. (eur-lex.europa.eu)
6.3. Déclaration des incidents majeurs
Les incidents majeurs liés aux TIC doivent être déclarés à l’autorité compétente selon une procédure harmonisée comprenant :
- une notification initiale ;
- un rapport intermédiaire ;
- un rapport final.
Les cybermenaces importantes peuvent également faire l’objet d’une notification volontaire.
En France, l’ACPR a publié plusieurs instructions en 2025 relatives aux déclarations d’incidents et aux notifications de cybermenaces. (acpr.banque-france.fr)
6.4. Incidents impliquant une IA
Peuvent notamment constituer des incidents TIC selon leurs caractéristiques :
- l’indisponibilité d’un modèle utilisé pour traiter les opérations ;
- la corruption d’une base alimentant un système de détection de fraude ;
- une fuite d’informations par un agent conversationnel ;
- une recommandation erronée provoquée par une manipulation technique ;
- l’interruption d’un fournisseur d’IA hébergé dans le cloud ;
- une attaque contre une interface de modèle ;
- une défaillance affectant de nombreux clients.
Une simple erreur fonctionnelle ne constitue pas automatiquement un incident majeur. L’entité doit appliquer les critères réglementaires de classification.
7. Tests de résilience opérationnelle numérique
7.1. Programme général de tests
Les entités doivent établir un programme proportionné de tests portant notamment sur :
- les vulnérabilités ;
- les scénarios ;
- les performances ;
- la sécurité des réseaux ;
- les contrôles physiques ;
- les sauvegardes ;
- la continuité ;
- les applications ;
- les logiciels.
Les résultats doivent donner lieu à des mesures correctrices.
7.2. Tests des systèmes d’IA
Pour un système d’intelligence artificielle, les tests DORA peuvent inclure :
- la disponibilité du service ;
- la capacité de basculement ;
- la résistance aux attaques ;
- la récupération après corruption ;
- le fonctionnement sans le prestataire principal ;
- la protection des données ;
- la continuité en mode dégradé ;
- la réversibilité ;
- la restauration d’une version antérieure.
Ces tests doivent être distingués des tests de performance, de biais ou d’exactitude imposés par d’autres textes ou par les bonnes pratiques en matière d’IA.
7.3. Tests avancés fondés sur la menace
Certaines entités désignées doivent réaliser, au moins tous les trois ans, des tests avancés de pénétration fondés sur la menace, ou Threat-Led Penetration Testing — TLPT.
Ces tests :
- portent sur les fonctions critiques ou importantes ;
- utilisent des scénarios réalistes ;
- peuvent inclure les systèmes de prestataires ;
- doivent être réalisés selon un cadre strict ;
- mobilisent des testeurs répondant à des exigences particulières.
Les autorités compétentes identifient les entités concernées selon les critères réglementaires.
8. Gestion des risques liés aux prestataires tiers
8.1. Responsabilité maintenue de l’entité financière
Le recours à un fournisseur externe ne transfère pas la responsabilité réglementaire.
Une banque utilisant un modèle fourni par un éditeur ou une infrastructure de cloud public demeure responsable de la maîtrise des risques associés à son service financier.
8.2. Évaluation préalable
Avant de conclure un contrat TIC, l’entité doit notamment apprécier :
- le besoin opérationnel ;
- la criticité du service ;
- les risques de sécurité ;
- la localisation des données ;
- les risques de concentration ;
- la chaîne de sous-traitance ;
- la capacité d’audit ;
- les conditions de sortie ;
- l’impact d’une défaillance.
8.3. Fonction critique ou importante
Une fonction est critique ou importante lorsque sa perturbation compromettrait substantiellement :
- les performances financières de l’entité ;
- la continuité de ses services ;
- le respect de ses obligations ;
- la solidité ou la continuité de ses activités.
Un service d’IA peut soutenir une fonction critique lorsqu’il intervient, par exemple, dans :
- l’exécution d’ordres ;
- la détection de fraude ;
- les paiements ;
- la tarification ;
- le contrôle des risques ;
- la lutte contre le blanchiment ;
- la continuité des opérations.
La qualification dépend de l’usage concret, et non de la seule nature « intelligente » de l’outil.
9. Exigences contractuelles
9.1. Contrats portant sur des services TIC
Les contrats doivent préciser notamment :
- les services fournis ;
- les fonctions concernées ;
- les lieux de traitement et de stockage ;
- les règles relatives à la disponibilité et à l’intégrité ;
- l’assistance en cas d’incident ;
- les obligations de coopération ;
- les conditions de résiliation ;
- la restitution ou récupération des données.
9.2. Fonctions critiques ou importantes
Les contrats soutenant une fonction critique ou importante doivent comporter des stipulations renforcées concernant notamment :
- les niveaux de service ;
- les obligations de notification ;
- les plans de continuité ;
- la participation aux tests ;
- les droits d’accès, d’inspection et d’audit ;
- les stratégies de sortie ;
- les périodes de transition ;
- la coopération avec les autorités.
Le règlement délégué (UE) 2024/1773 précise le contenu de la politique contractuelle applicable aux services soutenant de telles fonctions. (eur-lex.europa.eu)
9.3. Clauses relatives aux fournisseurs d’IA
Un contrat portant sur une IA financière peut notamment devoir traiter :
- la version du modèle ;
- les modalités de mise à jour ;
- la disponibilité de l’API ;
- la conservation des requêtes ;
- l’utilisation des données pour l’entraînement ;
- les sous-traitants cloud ;
- la notification des vulnérabilités ;
- les journaux techniques ;
- la continuité en cas de retrait du modèle ;
- l’exportation des données et configurations ;
- la réversibilité.
Des conditions générales standardisées ne suffisent pas toujours à satisfaire les exigences de DORA.
10. Registre d’informations
10.1. Principe
Les entités financières doivent tenir et actualiser un registre contenant les informations relatives à l’ensemble de leurs accords contractuels portant sur l’utilisation de services TIC.
Le registre couvre donc non seulement les fonctions critiques, mais plus largement les contrats TIC entrant dans son champ.
Il doit être disponible :
- au niveau individuel ;
- au niveau sous-consolidé ;
- au niveau consolidé, selon la structure du groupe.
10.2. Finalités
Le registre permet :
- de cartographier les dépendances ;
- d’identifier les concentrations ;
- de préparer les contrôles ;
- d’alimenter la désignation des prestataires critiques ;
- d’évaluer les risques de sous-traitance.
Depuis le 17 janvier 2025, les entités concernées doivent disposer de ce registre. Les autorités européennes utilisent les informations transmises pour identifier les prestataires critiques. (eba.europa.eu)
10.3. Mise en œuvre française
L’ACPR a publié l’instruction n° 2025-I-12 relative à la remise des registres d’informations sur les accords contractuels portant sur des services TIC. (acpr.banque-france.fr)
URL
11. Risque de concentration et dépendance technologique
11.1. Concentration systémique
De nombreuses entités financières dépendent des mêmes fournisseurs :
- cloud ;
- infrastructures ;
- réseaux ;
- logiciels ;
- modèles d’IA ;
- services de cybersécurité.
Une défaillance unique peut donc affecter simultanément une grande partie du secteur.
11.2. Concentration individuelle
Une entité doit également vérifier si elle dépend excessivement :
- d’un fournisseur ;
- d’une région cloud ;
- d’un modèle propriétaire ;
- d’une interface unique ;
- d’un sous-traitant difficilement remplaçable.
11.3. Verrouillage technologique
Le risque est particulièrement fort lorsque :
- les données ne sont pas facilement exportables ;
- le modèle ne peut pas être remplacé ;
- les procédures internes dépendent d’un format propriétaire ;
- le fournisseur contrôle les mises à jour ;
- aucune solution de repli n’existe.
L’entité doit concevoir des stratégies de sortie réalistes, et non uniquement théoriques.
12. Prestataires tiers critiques de services TIC
12.1. Désignation européenne
Les autorités européennes de surveillance — ABE, AEAPP et AEMF — peuvent désigner certains prestataires comme critiques selon des critères tels que :
- leur impact systémique ;
- le nombre et le type d’entités financières clientes ;
- l’importance des fonctions soutenues ;
- leur caractère substituable ;
- leur degré d’interconnexion.
Les critères ont été précisés par le règlement délégué (UE) 2024/1502. (eur-lex.europa.eu)
12.2. Première liste
En novembre 2025, les autorités européennes ont désigné dix-neuf prestataires TIC critiques à l’échelle de l’Union. Cette liste comprend notamment de grands groupes de cloud, d’infrastructures, de données financières et de services technologiques. Elle est publiée et mise à jour par les autorités européennes. (esma.europa.eu)
Liste officielle
12.3. Surveillance directe
Chaque prestataire critique est placé sous la responsabilité d’un superviseur principal européen.
La surveillance peut porter notamment sur :
- la gouvernance ;
- la sécurité ;
- la continuité ;
- les risques physiques ;
- la gestion des incidents ;
- la portabilité ;
- les tests ;
- la sous-traitance ;
- la qualité des services.
Le superviseur peut :
- demander des informations ;
- mener des enquêtes ;
- réaliser des inspections ;
- formuler des recommandations ;
- imposer des astreintes dans les conditions prévues.
Cette surveillance ne remplace pas l’obligation de chaque entité financière de contrôler ses propres prestataires.
13. Sous-traitance en chaîne
Un fournisseur TIC peut lui-même recourir à plusieurs sous-traitants.
Exemple :
- une banque contracte avec un éditeur d’IA ;
- l’éditeur utilise un modèle fourni par une autre entreprise ;
- le modèle est hébergé chez un fournisseur cloud ;
- les journaux sont gérés par un autre prestataire ;
- certaines données sont annotées par un sous-traitant.
DORA impose de maîtriser cette chaîne, en particulier lorsqu’elle soutient une fonction critique ou importante.
L’entité doit notamment pouvoir identifier :
- les sous-traitants essentiels ;
- la localisation des services ;
- les changements significatifs ;
- les risques de concentration ;
- les conséquences d’une défaillance.
14. Partage d’informations sur les cybermenaces
DORA permet aux entités financières de mettre en place des mécanismes d’échange volontaire portant notamment sur :
- les indicateurs de compromission ;
- les tactiques et techniques d’attaque ;
- les alertes ;
- les outils de cybersécurité ;
- les procédures de détection.
Ces échanges doivent :
- renforcer la résilience du secteur ;
- être organisés dans des communautés de confiance ;
- protéger les données personnelles ;
- respecter le secret des affaires ;
- respecter le droit de la concurrence.
L’objectif est d’éviter que chaque établissement traite isolément des menaces communes.
15. Articulation entre DORA et l’intelligence artificielle
15.1. L’IA comme service TIC
Un service d’IA peut relever de la notion de service TIC lorsqu’il est fourni de manière continue par un prestataire externe.
Peuvent notamment être concernés :
- une API de modèle génératif ;
- un logiciel de détection de fraude ;
- un système de notation ;
- un service d’analyse documentaire ;
- une plateforme de surveillance ;
- un modèle hébergé dans le cloud ;
- un outil d’assistance à la conformité.
15.2. L’IA comme source de risque opérationnel
Les principaux risques comprennent :
- indisponibilité du modèle ;
- erreur généralisée ;
- dérive de performance ;
- injection de commandes malveillantes ;
- fuite de données ;
- empoisonnement du corpus ;
- dépendance à une API ;
- retrait brutal d’une version ;
- changement unilatéral du fournisseur ;
- absence de solution de secours.
15.3. L’IA comme outil de résilience
L’IA peut également assister :
- la détection d’anomalies ;
- l’analyse des journaux ;
- la classification des incidents ;
- la surveillance des fournisseurs ;
- l’identification de signaux faibles ;
- la réponse aux cyberattaques ;
- la mise à jour des cartographies.
L’usage d’une IA pour gérer les risques ne dispense pas d’évaluer les risques propres à cet outil.
16. Articulation entre DORA et l’AI Act
DORA et l’AI Act ont des finalités différentes.
DORA
DORA vise :
- la continuité opérationnelle ;
- la cybersécurité ;
- les incidents ;
- les tests ;
- les prestataires TIC ;
- la résilience du secteur financier.
AI Act
L’AI Act vise notamment :
- les pratiques d’IA interdites ;
- les systèmes à haut risque ;
- la transparence ;
- la gouvernance des modèles ;
- la qualité des données ;
- la supervision humaine ;
- la surveillance du marché.
Un système utilisé pour évaluer la solvabilité ou la notation de crédit d’une personne physique peut relever du régime des systèmes à haut risque du RIA, tout en étant intégré au cadre DORA de gestion des actifs et des prestataires TIC.
Une seule documentation peut alimenter plusieurs démarches, mais les analyses ne sont pas interchangeables.
17. Articulation avec le RGPD
Lorsqu’un incident affecte des données personnelles, l’entité peut devoir respecter simultanément :
- les obligations de déclaration DORA ;
- la notification de violation de données à la CNIL au titre du RGPD ;
- l’information des personnes concernées lorsque le risque est élevé ;
- d’autres notifications sectorielles.
Les autorités, délais, critères et contenus de déclaration ne sont pas identiques.
L’existence d’une déclaration DORA ne dispense donc pas automatiquement d’une notification au titre du RGPD.
18. Articulation avec NIS 2
DORA constitue une réglementation sectorielle spéciale pour les entités financières relevant de son champ.
L’articulation avec la directive NIS 2 repose sur le principe selon lequel les exigences de DORA relatives à la gestion des risques TIC et aux incidents ont vocation à prévaloir comme règles sectorielles équivalentes pour les entités financières concernées.
Cela n’exclut pas toute coopération entre :
- autorités financières ;
- autorités de cybersécurité ;
- autorités NIS 2 ;
- autorités chargées de la protection des données.
19. Contrôle en France
19.1. ACPR
L’Autorité de contrôle prudentiel et de résolution assure la mise en œuvre de DORA pour les organismes relevant de sa compétence, notamment dans les secteurs bancaire et assurantiel.
Elle a publié :
- des instructions sur les incidents ;
- une instruction sur les registres d’informations ;
- une foire aux questions ;
- des documents d’accompagnement.
Portail DORA de l’ACPR
19.2. AMF
L’Autorité des marchés financiers est compétente pour les acteurs relevant de son champ, notamment certaines sociétés de gestion, entreprises d’investissement, infrastructures ou prestataires financiers.
Elle a créé un dossier thématique présentant :
- la gestion du risque TIC ;
- les incidents ;
- les tests ;
- les prestataires ;
- les obligations de registre.
Dossier DORA de l’AMF
20. Sanctions
DORA oblige les États membres à prévoir des sanctions et mesures administratives effectives, proportionnées et dissuasives.
Les autorités compétentes peuvent notamment disposer de pouvoirs permettant :
- de demander des informations ;
- d’effectuer des contrôles ;
- d’ordonner la cessation d’un manquement ;
- d’exiger des mesures correctrices ;
- de prononcer des sanctions administratives selon le droit national applicable.
Le régime exact dépend :
- de l’entité concernée ;
- de l’autorité compétente ;
- des textes nationaux d’adaptation ;
- de la gravité du manquement.
Il ne faut donc pas présenter DORA comme prévoyant une amende européenne unique comparable à celle du RGPD.
21. Méthode pratique de conformité
Gouvernance
- Désigner clairement les responsables.
- Informer régulièrement l’organe de direction.
- Former les dirigeants aux risques TIC.
- Associer le juridique, la conformité, les risques, la DSI et le RSSI.
Cartographie
- Recenser les actifs TIC.
- Identifier les fonctions critiques ou importantes.
- Cartographier les flux de données.
- Recenser les dépendances et sous-traitants.
- Intégrer les systèmes et fournisseurs d’IA.
Incidents
- Mettre en place une classification conforme.
- Organiser les circuits d’alerte.
- Préparer les notifications.
- Coordonner DORA, RGPD et les obligations sectorielles.
- Conserver les éléments de preuve.
Tests
- Définir un programme annuel.
- Tester les sauvegardes et la reprise.
- Corriger les vulnérabilités identifiées.
- Préparer les TLPT lorsque l’entité est concernée.
- Inclure les services externalisés.
Prestataires
- Tenir le registre d’informations.
- Classer les fonctions soutenues.
- Renégocier les contrats insuffisants.
- Contrôler les sous-traitants.
- Préparer des stratégies de sortie.
- Surveiller les risques de concentration.
IA
- Recenser les modèles et API utilisés.
- Déterminer les fonctions soutenues.
- Tester la continuité en cas d’indisponibilité.
- Prévoir une solution de repli.
- Encadrer les mises à jour.
- Vérifier la récupération des données et configurations.
Jurisprudence
Au 4 août 2026, la jurisprudence spécifiquement consacrée à l’interprétation de DORA demeure encore limitée, compte tenu de son application depuis le 17 janvier 2025.
Les premiers contentieux devraient notamment porter sur :
- la qualification d’un service TIC ;
- la notion de fonction critique ou importante ;
- le niveau de diligence attendu de l’organe de direction ;
- la conformité des contrats ;
- la qualité des registres ;
- les obligations de déclaration ;
- les stratégies de sortie ;
- la responsabilité en cas de défaillance d’un fournisseur.
Les décisions antérieures relatives à l’externalisation, à la cybersécurité ou à la continuité opérationnelle restent pertinentes, mais ne doivent pas être présentées comme une jurisprudence propre à DORA.
Acteurs
Entités financières
Elles sont responsables de leur résilience et du contrôle de leurs prestataires.
Organes de direction
Ils portent la responsabilité ultime du cadre de gestion des risques TIC.
Prestataires de services TIC
Ils fournissent notamment des services cloud, logiciels, données, infrastructures, cybersécurité ou IA.
Prestataires tiers critiques
Ils sont directement soumis à la surveillance des autorités européennes.
ABE, AEAPP et AEMF
Les trois autorités européennes élaborent les normes techniques et organisent la surveillance des prestataires critiques.
ACPR et AMF
Elles assurent en France le contrôle des entités relevant de leurs compétences respectives.
ANSSI et CNIL
Elles peuvent intervenir selon les aspects liés à la cybersécurité ou aux données personnelles.
Débats actuels
DORA empêche-t-il l’externalisation ?
Non. Il impose de maîtriser les risques et de conserver la responsabilité de l’activité externalisée.
Un fournisseur cloud critique devient-il le régulateur de ses clients ?
Non. Sa désignation entraîne une surveillance européenne directe, mais chaque entité financière demeure responsable de son propre risque.
Tous les fournisseurs d’IA sont-ils soumis directement à DORA ?
Non. Ils peuvent être soumis à des obligations contractuelles en qualité de prestataires TIC. Seuls les prestataires désignés comme critiques sont soumis au cadre européen direct de surveillance prévu par DORA.
Une fonction utilisant l’IA est-elle nécessairement critique ?
Non. La qualification dépend des conséquences de son interruption ou de sa défaillance pour l’activité financière.
DORA interdit-il l’utilisation de modèles étrangers ?
Non. Il impose toutefois d’évaluer les risques, la localisation, la sous-traitance, la continuité et les possibilités de sortie.
La conformité DORA suffit-elle pour respecter l’AI Act ?
Non. Les deux textes poursuivent des objectifs distincts et peuvent s’appliquer cumulativement.
Actualité récente
DORA est pleinement applicable depuis le 17 janvier 2025.
En 2025, les principales étapes de mise en œuvre ont notamment porté sur :
- la remise des registres d’informations ;
- l’organisation des déclarations d’incidents ;
- la préparation de la surveillance des prestataires critiques ;
- l’adaptation des orientations sectorielles ;
- les premiers contrôles de mise en œuvre.
Le 18 novembre 2025, les autorités européennes ont annoncé la première désignation de prestataires tiers critiques. (eba.europa.eu)
En 2026, les autorités européennes ont engagé le fonctionnement opérationnel du dispositif de surveillance. L’ABE indique que dix-neuf prestataires critiques avaient été désignés dans le cadre de DORA. (eba.europa.eu)
Les autorités européennes ont également publié en juin 2026 un premier rapport agrégé sur les incidents majeurs liés aux TIC survenus en 2025. (eba.europa.eu)
Ressources essentielles
Base documentaire Dabo Tibi Ius
Droit bancaire et financier et intelligence artificielle
Cette fiche présente notamment l’articulation entre intelligence artificielle, cybersécurité, données, réglementation financière et DORA.
Blockchain et intelligence artificielle : enjeux et applications
Cette fiche comporte un développement relatif à DORA, à la sécurité des services financiers numériques et à la résilience.
Droit de l’intelligence artificielle
La recherche dans la base n’a pas permis d’identifier une fiche Dabo Tibi Ius autonome antérieure exclusivement intitulée « DORA ». La présente fiche synthétise donc les articles transversaux de la base et les sources institutionnelles européennes et françaises.
Texte principal
Règlement (UE) 2022/2554 — DORA
Version consolidée
Résumé EUR-Lex
Principaux textes complémentaires
Règlement délégué (UE) 2024/1502 — désignation des prestataires critiques
Règlement délégué (UE) 2024/1772 — classification des incidents
Règlement délégué (UE) 2024/1773 — politique contractuelle relative aux fonctions critiques
Autorités européennes
Portail DORA de l’Autorité bancaire européenne
Surveillance des prestataires critiques
Portail DORA de l’ESMA
Liste des prestataires critiques
Préparation et remise des registres
France
Portail DORA de l’ACPR
FAQ de l’ACPR
Registre d’informations — instruction ACPR n° 2025-I-12
Dossier DORA de l’AMF
FAQ
Qu’est-ce que DORA ?
DORA est le règlement européen qui impose aux acteurs financiers de prévenir, gérer et surmonter les incidents numériques susceptibles d’affecter leurs activités.
Depuis quand s’applique-t-il ?
Depuis le 17 janvier 2025.
DORA concerne-t-il seulement les banques ?
Non. Il couvre également de nombreux acteurs des paiements, de l’investissement, de l’assurance, des fonds, des cryptoactifs et des infrastructures de marché.
DORA est-il un texte sur l’intelligence artificielle ?
Non. Il porte sur la résilience opérationnelle numérique. Les systèmes d’IA utilisés par les acteurs financiers peuvent toutefois entrer dans son champ en tant qu’actifs ou services TIC.
Une entreprise financière reste-t-elle responsable après externalisation ?
Oui. L’externalisation ne transfère pas sa responsabilité réglementaire au fournisseur.
Qu’est-ce qu’une fonction critique ou importante ?
Une fonction dont la perturbation compromettrait substantiellement la continuité, la solidité, les performances ou les obligations réglementaires de l’entité.
Tous les contrats TIC doivent-ils être recensés ?
Les entités doivent tenir un registre de leurs accords contractuels portant sur l’utilisation de services TIC, avec des informations plus détaillées pour les fonctions critiques ou importantes.
Qu’est-ce qu’un prestataire TIC critique ?
Un fournisseur désigné par les autorités européennes en raison de son importance systémique pour le secteur financier.
DORA impose-t-il de déclarer tous les incidents ?
Tous les incidents doivent être gérés et classés. Seuls ceux qui répondent aux critères de majoration doivent faire l’objet de la déclaration obligatoire harmonisée.
Qu’est-ce qu’un TLPT ?
Un test avancé de pénétration fondé sur des scénarios réalistes de menace, obligatoire pour certaines entités désignées.
DORA remplace-t-il le RGPD ?
Non. Un incident peut devoir être déclaré à la fois au titre de DORA et du RGPD.
DORA remplace-t-il NIS 2 ?
DORA constitue, pour les entités financières concernées, le cadre sectoriel spécial en matière de gestion des risques TIC et de déclaration des incidents.
Comment DORA s’applique-t-il à un fournisseur d’IA ?
Le fournisseur peut être qualifié de prestataire de services TIC. Le contrat, les dépendances, la continuité, la sous-traitance et la stratégie de sortie doivent alors être maîtrisés.
Méthodologie : Cette fiche a été générée avec l’assistance de l’intelligence artificielle à partir de la base documentaire et de sources juridiques complémentaires lorsque cela était nécessaire. Elle constitue une synthèse documentaire et ne remplace pas un avis juridique.
Résumé pédagogique
Définition
DORA est le règlement européen relatif à la résilience opérationnelle numérique du secteur financier. Applicable depuis le 17 janvier 2025, il oblige les banques, assureurs, sociétés de gestion et de nombreux autres acteurs financiers à prévenir, gérer et surmonter les incidents affectant leurs systèmes informatiques et leurs prestataires technologiques.
Exemple
Une banque utilise un service d’intelligence artificielle hébergé dans le cloud pour détecter les opérations frauduleuses. Elle doit identifier le fournisseur dans son registre TIC, évaluer la criticité du service, encadrer contractuellement la sécurité et les audits, prévoir une solution de repli et tester la continuité en cas d’indisponibilité. Elle reste responsable même si la panne provient du fournisseur.
Problématique juridique
Le secteur financier dépend d’un nombre limité de fournisseurs de cloud, de données, de logiciels et de modèles d’IA. Une défaillance unique peut affecter simultanément de nombreux établissements. DORA cherche à réduire ce risque systémique sans interdire l’externalisation, en imposant une gouvernance, des tests, des contrats renforcés et des stratégies de sortie.
Cadre légal
Le cadre repose sur le règlement (UE) 2022/2554 et ses règlements techniques complémentaires. Il est contrôlé en France principalement par l’ACPR et l’AMF. DORA s’articule avec le RGPD, NIS 2, les règles financières sectorielles et le règlement européen sur l’intelligence artificielle. Il ne réglemente pas directement le fonctionnement des modèles d’IA, mais encadre leur sécurité, leur disponibilité et la dépendance aux fournisseurs lorsqu’ils sont utilisés par une entité financière.
Fiches Dabo Tibi Ius associées :
- Cybersécurité
- Cloud computing
- Systèmes d’IA dans la finance
- RGPD
- NIS 2
- MiCA