Réglementation DORA : qui est concerné et quelles obligations ?
Loïc Le Saout — 15 septembre, 2026
La réglementation DORA s’applique depuis le 17 janvier 2025 aux entités financières qui entrent dans son champ d’application. La conformité DORA repose sur leur résilience opérationnelle numérique : prévenir les perturbations, maintenir les services essentiels et les rétablir lorsqu’un incident survient. Elle encadre aussi leurs relations avec les fournisseurs informatiques, sans imposer indistinctement à chaque entreprise les mêmes obligations.
Pour savoir ce que votre organisation doit préparer, trois questions sont prioritaires : quel est son statut réglementaire, quelles opérations dépendent du numérique et quelles preuves permettent de démontrer sa capacité à faire face à une défaillance ? Ce guide distingue les entreprises directement assujetties, les conséquences pour leurs partenaires et les principaux chantiers à organiser.
Qu’est-ce que la réglementation DORA ?
DORA signifie Digital Operational Resilience Act. Il s’agit du règlement (UE) 2022/2554 relatif à la résilience opérationnelle numérique du secteur financier dans l’Union européenne. Son objectif est d’harmoniser les exigences en matière de maîtrise du risque numérique et de renforcer la protection des services face aux cybermenaces, aux pannes et aux défaillances de partenaires. Les TIC désignent les technologies de l’information et de la communication sur lesquelles reposent ces services.
L’expression « loi DORA » est courante dans les recherches, mais le texte principal est bien un règlement européen, directement applicable. Une directive distincte, la directive (UE) 2022/2556, adapte plusieurs textes sectoriels. Parler seulement de « directive DORA » peut donc brouiller la compréhension du cadre réglementaire : les obligations centrales sont portées par le règlement, complété par des normes techniques et des règlements délégués ou d’exécution. L’ACPR présente le cadre DORA et les textes qui le complètent.
Une entrée en vigueur différente de la date d’application
Adopté le 14 décembre 2022 et publié le 27 décembre 2022, le règlement DORA est entré en vigueur le 16 janvier 2023. Sa date d’application est le 17 janvier 2025, après une période de préparation. Il ne s’agit donc plus d’un projet à anticiper pour une échéance future : une entité assujettie doit désormais faire vivre son dispositif et corriger ses écarts. L’ESMA précise ce calendrier et rassemble les textes techniques associés.
La résilience dépasse la seule cybersécurité
Un antivirus ou un pare-feu contribue à la sécurité numérique, mais ne répond pas à toutes les questions de continuité. Une organisation sait-elle restaurer une application ? Retrouver les bonnes données ? Mobiliser les décideurs si un fournisseur cloud devient indisponible ? Informer les personnes concernées ? La résilience relie les systèmes d’information aux services à maintenir, aux responsabilités et à la capacité de reprise. Ces questions permettent de traduire les enjeux réglementaires en situations concrètes.
Quelles entreprises sont directement concernées par DORA ?
Le champ d’application dépend d’abord de la catégorie juridique et du statut de l’entité, et non de son seul usage de l’informatique. L’article 2 du règlement énumère les catégories visées et prévoit des exclusions. Une société ne devient pas une entité financière assujettie simplement parce qu’elle travaille pour une banque. À l’inverse, l’appellation « fintech » ne permet pas, à elle seule, de déterminer son régime.
| Famille d’acteurs | Exemples de catégories visées |
| Banque et paiements | Établissements de crédit, établissements de paiement, prestataires de services d’information sur les comptes, établissements de monnaie électronique. |
| Investissement et gestion | Entreprises d’investissement, sociétés de gestion d’OPCVM, gestionnaires de fonds d’investissement alternatifs relevant du champ applicable. |
| Infrastructures de marché | Dépositaires centraux de titres, contreparties centrales, plateformes de négociation et référentiels centraux. |
| Assurance et retraite | Entreprises d’assurance et de réassurance, certaines catégories d’intermédiaires, institutions de retraite professionnelle. |
| Autres catégories encadrées | Certains prestataires sur cryptoactifs, prestataires de financement participatif, agences de notation de crédit et administrateurs d’indices de référence d’importance critique. |
Ce tableau est un repère, pas une liste exhaustive ni un avis d’assujettissement. Il faut vérifier les exclusions et les dispositions propres à chaque catégorie. Par exemple, les intermédiaires d’assurance, de réassurance ou d’assurance à titre accessoire qui sont des microentreprises ou des petites ou moyennes entreprises sont exclus dans les conditions prévues par le texte. La FAQ DORA de l’ACPR détaille notamment ce cas.
Le principe de proportionnalité ne signifie pas que toute petite structure est dispensée. La mise en œuvre tient compte de la taille, du profil de risque, de la nature et de la complexité des activités. Certaines entités bénéficient d’un cadre simplifié ou de dispositions particulières. Pour votre analyse, rassemblez les agréments, les métiers effectivement exercés et l’organisation du groupe ; faites valider le périmètre par vos équipes conformité et vos conseils.
Que change DORA pour les prestataires informatiques ?
L’impact sur un prestataire tiers de services TIC dépend de sa relation avec l’entité financière et de son éventuelle désignation au titre de la supervision européenne. Hébergement, services cloud, maintenance ou exploitation externalisée peuvent créer des dépendances à examiner. Le client doit comprendre ce qu’il confie, où le service est fourni, quelles données sont traitées et comment une interruption pourrait affecter son activité.
Pour un fournisseur, cela se traduit notamment par des demandes d’information, des clauses contractuelles et des éléments de preuve : engagements de disponibilité, assistance en cas d’incident, sécurité, accès et coopération avec les contrôles, continuité ou réversibilité selon la prestation et sa criticité. L’entité financière reste responsable du respect des dispositions applicables. Acheter un service ou déléguer une tâche ne transfère pas automatiquement cette responsabilité au partenaire.
Deux sens différents du mot « critique »
Une fonction critique ou importante est qualifiée au niveau de l’entité financière. Un prestataire tiers critique, lui, relève d’une désignation européenne et d’un cadre spécifique de supervision. Un fournisseur qui soutient une fonction importante chez un client n’est pas, pour cette seule raison, soumis à cette supervision à l’échelle européenne. Les autorités européennes de surveillance ont annoncé leurs premières désignations le 18 novembre 2025.
En pratique, demandez à votre fournisseur des réponses rattachées aux services réellement utilisés. Une présentation générale de son infrastructure ne suffit pas à comprendre votre dépendance. Précisez les interlocuteurs, les engagements vérifiables et les informations attendues lors d’un changement ou d’une interruption. Cette méthode évite de confondre une promesse commerciale de conformité avec une relation documentée et contrôlable.
Quelles sont les principales obligations DORA ?
Le dispositif s’organise autour de quatre chantiers opérationnels : gestion des risques TIC, incidents, tests de résilience et risques liés aux tiers. Le partage volontaire d’informations sur les cybermenaces est souvent présenté comme un cinquième pilier. Il ne faut pas le transformer en obligation générale de participation.
Piloter les risques et organiser la gouvernance
Les articles 5 à 16 encadrent la gouvernance et la gestion des risques TIC. L’organe de direction doit définir, approuver et superviser le cadre de gestion, avec des responsabilités et des moyens adaptés. Le travail consiste à relier les actifs et les dépendances aux processus métiers, à évaluer les risques, puis à mettre en place des mesures de protection, de détection et de rétablissement. La politique de sécurité des TIC doit rester utilisable par les équipes, pas seulement archivée.
Prenons une application de paiement : connaître son serveur ne suffit pas si personne n’a identifié les réseaux et les autres ressources TIC dont elle dépend, son mécanisme d’authentification, ses sauvegardes et son partenaire d’hébergement. Une cartographie des systèmes d’information rend ces liens visibles et aide à prioriser les traitements. La page consacrée à la gestion des risques TIC DORA approfondit ce passage de l’inventaire au suivi des mesures.
Gérer les incidents et notifier les incidents majeurs
Les articles 17 à 23 portent sur les incidents liés aux TIC, leur classification et leur déclaration. Une entité doit pouvoir détecter les événements, enregistrer les faits, coordonner la réponse et déterminer si les critères réglementaires d’un incident majeur sont remplis. Tous les tickets de support n’appellent pas une notification à l’autorité compétente. Cette procédure définit les responsabilités, les informations attendues et les délais, ainsi que la communication entre équipes et décideurs.
Le règlement délégué (UE) 2024/1772 précise la classification ; les règlements (UE) 2025/301 et 2025/302 encadrent le contenu, les délais et les modèles de reporting. Pour le fonctionnement détaillé, consultez la gestion des incidents TIC DORA. Une chronologie fiable et une chaîne d’escalade préparée rendent les échanges avec l’autorité plus faciles à organiser.
Tester la résilience et suivre les corrections
Les articles 24 à 27 prévoient des tests de résilience opérationnelle numérique adaptés aux risques. Hors dispositions particulières concernant les microentreprises, les systèmes et applications soutenant des fonctions critiques ou importantes doivent être testés au moins annuellement. Les exercices peuvent porter sur les vulnérabilités des réseaux, la sécurité des composants TIC ou les capacités de fonctionnement. Les tests avancés fondés sur la menace, appelés TLPT, sont réservés aux entités identifiées par les autorités, et non à toutes les entreprises assujetties.
Pour une organisation, l’intérêt est de vérifier une capacité réelle : restaurer, reprendre ou réagir avec les bonnes personnes. Un résultat doit déboucher sur des écarts priorisés, un responsable et une vérification après correction. Le programme de tests de résilience DORA détaille ces exercices sans réduire la démarche à un test d’intrusion isolé.
Maîtriser les relations avec les tiers
Les articles 28 à 30 encadrent la gestion du risque lié aux prestataires tiers. L’entité doit évaluer ses accords, ses dépendances et le risque de concentration. L’article 30 distingue les dispositions contractuelles minimales et les exigences supplémentaires pour les services soutenant des fonctions critiques ou importantes. Le registre d’informations prévu par l’article 28 couvre les accords d’utilisation de services TIC : il ne se limite pas aux seuls fournisseurs jugés les plus sensibles.
Pour le rendre utile, reliez chaque prestation à son contrat, aux processus soutenus et aux dépendances identifiées. Une stratégie de sortie doit également pouvoir être examinée concrètement : récupération des données, délais et solution de remplacement. La gestion des prestataires TIC DORA développe les contrats, le suivi et la réversibilité.
DORA et NIS2 : quelles différences pour votre organisation ?
Ces deux textes poursuivent un objectif de résilience, mais leur champ et leur fonctionnement diffèrent. Pour une entreprise, la bonne question n’est pas de choisir la réglementation la plus commode : il faut déterminer celle qui correspond à son statut et à ses métiers, puis comprendre leur articulation.
| Point de comparaison | DORA | NIS2 |
| Nature du texte | Règlement européen directement applicable. | Directive nécessitant une transposition nationale. |
| Champ principal | Catégories d’entités financières et cadre des relations avec les tiers informatiques. | Entités de nombreux secteurs, selon les critères du texte et les règles nationales. |
| Articulation | Régime sectoriel spécifique pour les exigences équivalentes couvertes. | Les dispositions correspondantes peuvent être écartées lorsque les conditions de son article 4 sont réunies. |
DORA joue le rôle de texte sectoriel spécial pour les dispositions équivalentes visées par NIS2 ; cela ne signifie pas que toutes les autres réglementations disparaissent. Un fournisseur peut avoir ses propres obligations NIS2 et devoir répondre aux demandes contractuelles d’un client financier. L’ANSSI explique cette articulation. La page conformité NIS2 présente la démarche de préparation correspondante.
Comment préparer une mise en conformité exploitable ?
Une démarche utile commence par les services à maintenir et les preuves disponibles. Elle ne nécessite pas de réécrire immédiatement toute la documentation. L’objectif est de repérer les écarts qui fragilisent réellement la continuité, puis de construire un plan d’action cohérent avec votre stratégie de résilience numérique, vos ressources et vos échéances. Voici une séquence pratique à adapter à votre périmètre.
- Confirmer le statut et le périmètre. Vérifiez les agréments, les catégories visées et les exclusions. En France, identifiez l’autorité compétente ainsi que les activités et entités du groupe à intégrer. Cette validation évite de bâtir un programme sur une interprétation approximative.
- Désigner les responsables. Répartissez les rôles entre direction, SI, risques, conformité, achats et partenaires. Qui valide une priorité ? Qui arbitre un budget ? Qui intervient pendant une crise ? Une responsabilité nommée doit correspondre à un pouvoir de décision réel.
- Relier les services à leurs dépendances TIC. Cartographiez les applications, les actifs, les données et les partenaires nécessaires. Repérez les points uniques de défaillance. Vous obtenez ainsi une base commune pour l’évaluation des risques, les exercices et l’examen des accords.
- Prioriser les écarts et les mesures. Séparez ce qui existe, ce qui doit être amélioré et ce qui reste à construire. Associez chaque action à un responsable et à un résultat attendu. Une priorité doit se justifier par son impact, pas seulement par la facilité d’achat d’un outil.
- Vérifier les capacités annoncées. Choisissez un scénario adapté : interruption d’une application, restauration d’une sauvegarde ou indisponibilité d’un partenaire. Observez les délais, les décisions et les obstacles. Les exercices permettent de confronter les procédures aux conditions de fonctionnement réelles.
- Organiser les preuves et la révision. Conservez les validations, rapports, corrections et versions utiles. Prévoyez leur actualisation après un changement significatif ou un incident. La conformité doit rester démontrable quand une personne quitte l’équipe ou qu’un contrat évolue.
Quels pièges éviter dans votre démarche DORA ?
Le premier piège est de confondre protection et résilience. Une sauvegarde annoncée ne prouve pas qu’elle peut être restaurée dans les conditions attendues. Le deuxième est de croire qu’une externalisation décharge le client de sa responsabilité. Sans visibilité sur la prestation et sans procédure commune, la dépendance reste difficile à maîtriser.
Autre erreur : constituer un dossier pour un contrôle sans organiser son entretien. Un inventaire périmé ou un rapport sans correction suivie perd rapidement sa valeur. Enfin, une certification ou une norme de sécurité peut apporter des éléments utiles, mais ne suffit pas à démontrer le respect de toutes les exigences DORA. Il faut vérifier leur couverture et les compléter selon le périmètre applicable.
Passer du cadre réglementaire à une préparation concrète
La réglementation DORA relie la sécurité, la gouvernance et la continuité du secteur financier. Pour avancer, confirmez votre assujettissement, identifiez vos dépendances et vérifiez vos capacités plutôt que de commencer par une liste de produits. Votre entité et ses conseils restent responsables de l’analyse juridique et des décisions réglementaires. Le point de départ est votre environnement réel : ce qu’il faut protéger, ce qui peut interrompre vos opérations et les preuves à construire pour suivre les progrès. Pour transformer ces constats en priorités techniques et organisationnelles, échangez avec ACI Technology.