Réglementation DORA : obligations, conformité et calendrier

DORA en bref : un règlement, pas une directive

DORA, pour Digital Operational Resilience Act, désigne le règlement (UE) 2022/2554 du 14 décembre 2022. Son objectif tient en une idée : un incident informatique chez une banque, un assureur ou l'un de leurs prestataires ne doit pas paralyser la fourniture de services financiers.

On entend souvent parler de « directive DORA ». L'expression est trompeuse, et la nuance n'est pas qu'une affaire de vocabulaire. Une directive fixe un objectif que chaque État transpose dans sa loi nationale. Un règlement, lui, s'applique tel quel : l'article 64 le rend obligatoire dans tous ses éléments et directement applicable dans chaque État membre.

La confusion vient du fait que DORA est accompagné d'une vraie directive, la directive (UE) 2022/2556, qui adapte plusieurs directives sectorielles existantes. Le règlement dit « quoi », et une série de normes techniques adoptées par la Commission européenne précisent le « comment » : modèles, seuils et délais.

En pratique, rares sont les entreprises qui découvrent DORA en lisant ses 64 articles. Elles le découvrent plutôt par une demande de l'ACPR sur leur registre de prestataires, par un fournisseur cloud qui refuse un avenant, ou par un incident qu'il faut qualifier en quelques heures. Autant prendre de l'avance.

Qui est concerné par la réglementation DORA ?

L'article 2 du règlement dresse une liste de vingt et une catégories. Les vingt premières, points a) à t), forment les « entités financières ». La vingt et unième, point u), est d'une autre nature : elle vise les prestataires tiers de services TIC.

Les vingt catégories d'entités financières

Regroupées par grandes familles, les entités financières soumises à DORA sont les suivantes :

• Banque et paiement : établissements de crédit, établissements de paiement, prestataires de services d'information sur les comptes, établissements de monnaie électronique.
• Investissement et crypto-actifs : entreprises d'investissement, prestataires de services sur crypto-actifs et émetteurs de jetons se référant à des actifs.
• Infrastructures de marché : dépositaires centraux de titres, contreparties centrales, plates-formes de négociation, référentiels centraux, prestataires de services de communication de données, référentiels des titrisations.
• Gestion d'actifs : gestionnaires de fonds d'investissement alternatifs et sociétés de gestion.
• Assurance et retraite : entreprises d'assurance et de réassurance, intermédiaires d'assurance et de réassurance, institutions de retraite professionnelle.
• Autres acteurs : agences de notation de crédit, administrateurs d'indices de référence d'importance critique, prestataires de services de financement participatif.

Les prestataires TIC : concernés par contrat ou directement

Un éditeur de logiciel, un hébergeur ou une entreprise de services numériques qui travaille pour une banque est touché de deux façons. Dans la grande majorité des cas, DORA l'atteint par le contrat : son client doit y faire figurer les clauses de l'article 30, sur la localisation des données, l'accès, l'audit ou la sortie.

Les prestataires les plus systémiques sont en plus placés sous la surveillance directe des autorités européennes, à partir de l'article 31. Le 18 novembre 2025, l'ESMA, l'ABE et l'AEAPP ont publié une première liste de 19 prestataires TIC critiques, parmi lesquels Amazon Web Services, Google Cloud, Microsoft, Orange, Capgemini et SAP.

Proportionnalité, cadre simplifié et exclusions

DORA ne demande pas à une société de gestion de dix personnes le même dispositif qu'à une grande banque. Trois mécanismes adaptent les obligations à la taille des acteurs, et il ne faut pas les confondre :

• La proportionnalité (article 4) : les règles s'appliquent en tenant compte de la taille, du profil de risque et de la complexité des activités.
• Le cadre simplifié (article 16) : les articles 5 à 15 ne s'appliquent pas, notamment, aux petites entreprises d'investissement non interconnectées, à certains établissements de paiement et de monnaie électronique exemptés, et aux petites institutions de retraite professionnelle, soumis à un régime allégé.
• Les exclusions (article 2, paragraphe 3) : par exemple les intermédiaires d'assurance qui sont des microentreprises ou des PME, ou les petits assureurs visés à l'article 4 de la directive Solvabilité II.

Les microentreprises, elles, restent dans le champ. Au sens de DORA, il s'agit d'une entité de moins de dix personnes dont le chiffre d'affaires ou le total du bilan ne dépasse pas 2 millions d'euros. Elles bénéficient d'allègements ciblés, par exemple pour les tests de résilience.

Les obligations de DORA en cinq piliers

Les obligations des entités financières sont réparties en cinq chapitres, souvent présentés comme les cinq piliers de DORA :

1. la gestion du risque lié aux TIC (articles 5 à 16) ;
2. la gestion, la classification et la déclaration des incidents (articles 17 à 23) ;
3. les tests de résilience opérationnelle numérique (articles 24 à 27) ;
4. la gestion du risque lié aux prestataires tiers de services TIC (articles 28 à 44) ;
5. le partage d'informations sur les cybermenaces (article 45).

1. La gestion des risques informatiques

Tout commence par la gouvernance. L'article 5 confie à l'organe de direction la définition, l'approbation et la supervision du cadre de gestion du risque lié aux TIC, et lui en attribue la responsabilité ultime. Le risque informatique n'est donc plus un sujet que la direction peut laisser au seul service informatique.

Les dirigeants doivent aussi entretenir des connaissances suffisantes pour comprendre ce risque, notamment en suivant régulièrement une formation spécifique. Quant au cadre lui-même, il est documenté et réexaminé au moins une fois par an, ainsi qu'après un incident majeur ou à la demande du superviseur.

Le reste du chapitre décrit ce que ce cadre doit couvrir : recenser les actifs et les dépendances, protéger et prévenir, détecter les anomalies, assurer la continuité des activités avec des plans de réponse et de rétablissement, sauvegarder les données, puis tirer les leçons de chaque incident.

2. Les incidents majeurs et leur déclaration

Chaque entité doit disposer d'un processus pour détecter, enregistrer et classer ses incidents liés aux TIC. Les critères de classification figurent dans le règlement délégué (UE) 2024/1772. Lorsqu'un incident est jugé majeur, il doit être déclaré à l'autorité compétente selon un calendrier très court.

Source : article 5 du règlement délégué (UE) 2025/301. Lorsqu'un délai expire un week-end ou un jour férié, certaines entités peuvent déclarer jusqu'au lendemain ouvré à midi.

Quatre heures, c'est à peine le temps de réunir la cellule de crise et de retrouver le bon contrat d'hébergement. D'où l'intérêt de préparer en amont la chaîne d'escalade, les modèles de déclaration et l'accès au portail de l'autorité, plutôt que de les découvrir le jour de l'incident.

Les clients ne sont pas oubliés : lorsqu'un incident majeur affecte leurs intérêts financiers, l'entité doit les informer sans retard injustifié, ainsi que des mesures prises pour en limiter les effets (article 19, paragraphe 3).

3. Les tests de résilience opérationnelle numérique

Toute entité hors cadre simplifié doit établir un programme de tests proportionné : analyses de vulnérabilités, tests fondés sur des scénarios, tests de performance ou revues de code source, selon les cas. Hors microentreprises, les systèmes qui soutiennent des fonctions critiques ou importantes sont testés au moins une fois par an (article 24).

Les entités désignées par leur autorité vont plus loin : au moins tous les trois ans, elles réalisent un test de pénétration fondé sur la menace, dit TLPT, mené sur les systèmes en production (article 26). L'autorité peut réduire ou augmenter cette fréquence selon le profil de risque de l'entité.

4. Le risque lié aux prestataires TIC

C'est souvent le pilier qui mobilise le plus les directions juridiques et achats. L'article 28 impose de tenir un registre d'informations sur tous les contrats de services TIC, en distinguant ceux qui soutiennent des fonctions critiques ou importantes. Son format est fixé par le règlement d'exécution (UE) 2024/2956.

Pour ces services critiques ou importants, l'entité doit aussi prévoir une stratégie de sortie : comment changer de prestataire en cas de défaillance, de dégradation du service ou de résiliation, sans interrompre son activité ni perdre ses données.

Enfin, l'article 30 liste les clauses que tout contrat de services TIC doit contenir au minimum :

• une description claire des services, et des conditions de sous-traitance lorsqu'elle porte sur une fonction critique ;
• les lieux de fourniture des services et de traitement des données, avec une information préalable en cas de changement ;
• la protection des données, et leur restitution dans un format accessible en cas de défaillance du prestataire ou de fin du contrat ;
• les niveaux de service, et l'assistance en cas d'incident, sans frais supplémentaires ou à un coût fixé à l'avance ;
• la coopération avec les autorités, les droits de résiliation et les préavis, et la participation aux formations de l'entité.

Les contrats qui soutiennent des fonctions critiques ou importantes ajoutent des exigences : niveaux de service chiffrés, obligations de notification, plans d'urgence testés, participation aux tests TLPT, droits d'audit et stratégie de sortie avec période de transition.

5. Le partage d'informations sur les cybermenaces

Dernier pilier, et le seul facultatif : l'article 45 permet aux entités financières d'échanger entre elles des informations sur les cybermenaces, comme des indicateurs de compromission ou des alertes, au sein de communautés de confiance. Celles qui y participent doivent en informer leur autorité compétente.

Qui contrôle DORA en France ?

L'article 46 confie le contrôle aux autorités déjà compétentes pour chaque secteur. En France, le paysage est le suivant :

• L'ACPR : établissements de crédit, assureurs, établissements de paiement et de monnaie électronique, et une partie des entreprises d'investissement. Elle reçoit les déclarations d'incidents majeurs et les registres d'informations.
• L'AMF : sociétés de gestion, gestionnaires de fonds alternatifs et acteurs de marché placés sous sa surveillance.
• La BCE : pour les établissements de crédit importants, dont les déclarations d'incidents lui sont transmises par l'autorité nationale.
• Les autorités européennes de surveillance : l'ABE, l'AEAPP et l'ESMA rédigent les normes techniques et surveillent directement les prestataires TIC critiques.

L'ACPR publie sur sa page dédiée à DORA ses instructions, notamment sur la déclaration des incidents et la remise du registre, ainsi qu'une FAQ régulièrement mise à jour. Selon cette FAQ, les sociétés de financement ne sont tenues d'appliquer DORA qu'après l'adoption de la loi française de transposition de la directive 2022/2556.

Quelles sanctions prévoit DORA ?

Le chiffre de « 10 % du chiffre d'affaires » circule beaucoup. Il ne figure nulle part dans le règlement. Ce que prévoit réellement le texte est à la fois plus simple et moins spectaculaire :

• Pour les entités financières (article 50) : aucun montant n'est fixé. Les autorités disposent de pouvoirs d'enquête, d'inspection et de sanction, et les États membres prévoient des sanctions administratives et des mesures correctives. Le montant dépend donc du droit national.
• Les sanctions pénales (article 52) : les États peuvent choisir de sanctionner certaines violations pénalement plutôt qu'administrativement.
• Pour les prestataires TIC critiques (article 35) : c'est le seul montant chiffré. Le superviseur principal peut imposer une astreinte journalière allant jusqu'à 1 % du chiffre d'affaires quotidien moyen mondial de l'exercice précédent, pendant six mois au maximum.

Au-delà de l'amende, le risque le plus concret reste souvent ailleurs : une injonction de l'autorité, une remise en cause d'un contrat stratégique ou un incident mal géré qui finit dans la presse. Une mise en conformité sérieuse protège d'abord contre cela.

DORA, NIS 2 et RGPD : qui s'applique quand ?

DORA et NIS 2. Pour les entités financières, DORA est le texte spécial. Son article 1er, paragraphe 2, précise qu'il constitue un acte juridique sectoriel au sens de l'article 4 de la directive NIS 2. Les dispositions équivalentes de NIS 2 s'effacent donc au profit de celles de DORA.

DORA et RGPD. Le RGPD continue de s'appliquer en parallèle. Un même incident peut être à la fois un incident majeur au sens de DORA et une violation de données personnelles au sens de l'article 33 du RGPD. Cela signifie deux déclarations et deux destinataires : l'ACPR ou l'AMF d'un côté, la CNIL dans les 72 heures de l'autre.

Si votre organisation suit aussi l'arrivée de l'IA Act, la logique est la même : chaque texte a son périmètre, et les obligations se cumulent. Nous détaillons ce calendrier dans notre guide sur le règlement européen sur l'intelligence artificielle.

Les étapes clés pour assurer votre conformité

DORA s'applique déjà : il ne s'agit plus de se préparer, mais de pouvoir démontrer que le dispositif fonctionne. Voici une feuille de route en sept étapes, à adapter à la taille et au profil de risque de votre organisation.

1. Qualifier votre régime. Vérifiez votre catégorie à l'article 2, les éventuelles exclusions, et si vous relevez du cadre simplifié ou de la qualité de microentreprise. Conservez une note qui justifie cette analyse.
2. Impliquer la direction. Faites approuver le cadre de gestion du risque TIC par l'organe de direction, désignez les responsables et organisez la formation des dirigeants.
3. Cartographier vos fonctions critiques. Partez des activités, pas de la liste des logiciels : pour chaque fonction importante, identifiez les systèmes, les données et les prestataires qui la font tourner.
4. Tenir le registre d'informations. Recensez tous vos contrats de services TIC, signalez ceux qui soutiennent des fonctions critiques, et préparez la remise annuelle à votre autorité.
5. Mettre vos contrats à niveau. Comparez chaque contrat TIC aux exigences de l'article 30, négociez les avenants manquants et formalisez vos stratégies de sortie.
6. Préparer la gestion des incidents. Rédigez la procédure de classification, la chaîne d'escalade et les modèles de déclaration, puis testez-les lors d'un exercice.
7. Tester et réexaminer. Lancez votre programme de tests, suivez la correction des vulnérabilités et réexaminez le cadre au moins une fois par an.

Les étapes 4 et 5 sont souvent les plus longues, car elles dépendent de la réponse des prestataires. Un fournisseur cloud ne signe pas un avenant en une semaine, et certains contrats anciens ne disent tout simplement rien de la localisation des données ou de la sortie.

Mettre vos contrats TIC en conformité plus vite

Vérifier qu'un portefeuille de contrats contient bien les clauses de l'article 30 est un travail de relecture long et répétitif : localisation des données, sous-traitance, droits d'audit, assistance en cas d'incident, préavis de résiliation, réversibilité. C'est précisément le type de tâche où un outil d'analyse de contrat fait gagner du temps.

Avec Tallos, vous intégrez ces exigences à votre playbook juridique, puis l'outil analyse chaque contrat dans Word, signale les clauses absentes ou insuffisantes et propose une rédaction en suivi des modifications. Ses analyses s'appuient uniquement sur le droit en vigueur.

Le fonctionnement est détaillé dans notre guide sur l'analyse de contrat par IA, et nos méthodes pour obtenir les avenants nécessaires dans notre article sur la négociation de contrat avec l'IA.