DORA : résilience opérationnelle numérique en finance

Pourquoi ce chapitre est nécessaire

DORA — Digital Operational Resilience Act, ou règlement (UE) 2022/2554 — est entré en application le 17 janvier 2025 dans l'ensemble de l'Union européenne. Contrairement à une directive, un règlement s'applique directement dans chaque État membre, sans transposition en droit national : il n'y a pas de version française « allégée » de DORA, ni de délai supplémentaire négocié localement. Depuis cette date, toute entité financière relevant du texte est censée être en conformité, pas en train de la construire.

Ce chapitre sert de point d'entrée avant d'aborder, dans les chapitres suivants, chacun des cinq piliers en détail. L'objectif ici n'est pas de vous donner une liste d'articles à cocher, mais de vous permettre de répondre à trois questions préalables : est-ce que mon organisation est concernée, en quoi DORA diffère-t-il des textes que je connais déjà (NIS2, PSD2, ISO 27001), et quelles obligations sont réellement nouvelles plutôt que reformulées.

DORA ne remplace pas les référentiels de sécurité existants (ISO 27001, PCI DSS, exigences ACPR ou AMF). Il ajoute une couche réglementaire contraignante et harmonisée à l'échelle de l'UE, avec des sanctions propres. Une certification ISO 27001 ne vaut pas conformité DORA — c'est l'un des malentendus les plus coûteux observés chez les entités qui abordent le sujet tardivement.

Le contexte réglementaire : de NIS2 à DORA

Le secteur financier européen dépendait déjà, avant 2025, de textes sectoriels épars : PSD2 pour les services de paiement, des lignes directrices de l'Autorité bancaire européenne (ABE) sur l'externalisation, des exigences nationales de l'ACPR ou de la BCE. Cette fragmentation posait un problème concret : un groupe bancaire opérant dans six pays devait composer avec six interprétations locales de ce qu'est une gestion « adéquate » du risque informatique.

DORA a été conçu pour unifier ce paysage spécifiquement pour la finance, sur le même calendrier que NIS2 (directive sur la sécurité des réseaux et systèmes d'information, transposée en droit national à partir d'octobre 2024). Les deux textes partagent une même ambition — renforcer la cybersécurité des infrastructures critiques européennes — mais ne se recouvrent pas :

• NIS2 est une directive généraliste, transposée différemment selon les États membres, qui couvre des secteurs très larges (énergie, santé, transport, numérique, administration).
• DORA est un règlement sectoriel, d'application directe et identique dans toute l'UE, qui ne couvre que les entités financières et leurs prestataires TIC critiques.

Quand une entité financière relève à la fois de NIS2 et de DORA, c'est DORA qui prévaut lex specialis derogat legi generali — la loi spéciale prime sur la loi générale. L'article 1er de DORA prévoit explicitement cette articulation pour éviter la double réglementation contradictoire.

Champ d'application : qui est concerné

DORA couvre un périmètre volontairement large, listé à l'article 2 du règlement. Il ne s'agit pas seulement des banques :

Ce dernier point mérite une attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire particulière : DORA ne s'arrête pas aux entités financières elles-mêmes. Les fournisseurs de services informatiques jugés « critiques » par les autorités européennes de surveillance (ABE, AEMF, AEAPP) sont directement soumis à une supervision — c'est une nouveauté majeure par rapport aux textes antérieurs, qui ne régulaient l'externalisation que du point de vue de l'entité financière cliente.

Une caisse régionale d'épargne qui héberge son cœur bancaire chez un fournisseur cloud américain reste responsable, au titre de DORA, de la résilience de ce service — même si l'incident technique se produit chez le prestataire. Si ce fournisseur cloud est désigné « critique » par les autorités européennes, il devient lui-même directement soumis à une supervision européenne, avec des inspections possibles sur site et des astreintes en cas de non-coopération.

DORA prévoit néanmoins un principe de proportionnalité : les exigences s'appliquent en tenant compte de la taille, du profil de risque, de la nature et de la complexité des activités de chaque entité. Une petite entreprise d'investissement n'est pas soumise au même niveau de granularité qu'une banque systémique. Ce principe est souvent mal compris comme une exemption — ce n'est pas le cas : il module l'intensité des obligations, il ne les supprime jamais.

Les cinq piliers de DORA

DORA structure ses obligations autour de cinq axes, tous rattachés à une gouvernance portée par l'organe de direction — DORA insiste explicitement sur le fait que la responsabilité finale de la résilience numérique ne peut pas être déléguée entièrement à la DSI.

1. Gestion des risques liés aux TIC (articles 5 à 16) — un cadre documenté, revu au moins une fois par an, couvrant l'identification des actifs, la protection, la détection, la réponse et la restauration.
2. Gestion, classification et notification des incidents (articles 17 à 23) — une taxonomie commune des incidents majeurs et des délais de notification stricts aux autorités compétentes.
3. Tests de résilience opérationnelle numérique (articles 24 à 27) — des tests réguliers, et pour les entités les plus significatives, des tests de pénétration fondés sur la menace (TLPT, Threat-Led Penetration Testing) menés sur les systèmes en production, en conditions réelles.
4. Gestion des risques liés aux prestataires tiers TIC (articles 28 à 44) — un registre d'information exhaustif, des clauses contractuelles obligatoires, et un régime de supervision directe pour les prestataires désignés critiques.
5. Partage d'informations (article 45) — un mécanisme volontaire d'échange de renseignements sur les cybermenaces entre entités financières.

Le pilier le plus sous-estimé est le quatrième. Beaucoup d'organisations concentrent leurs efforts sur leur propre système d'information et découvrent tardivement qu'elles doivent aussi cartographier, contractualiser et surveiller l'ensemble de leur chaîne de prestataires TIC — y compris les sous-traitants de leurs prestataires. Le registre d'information prévu par DORA doit couvrir les chaînes de sous-traitance, pas seulement le premier niveau contractuel.

Calendrier : entrée en vigueur et échéances

Le règlement a été publié le 27 décembre 2022 et est entré en application le 17 janvier 2025, après une période de transition de deux ans destinée à laisser aux entités le temps de s'organiser. Cette période a aussi permis aux autorités européennes de surveillance de publier les normes techniques réglementaires (RTS) et d'exécution (ITS) qui précisent les modalités pratiques — format du registre de prestataires, taxonomie des incidents, contenu des tests.

Depuis janvier 2025, il n'existe plus de délai de grâce générique. Certaines échéances restent toutefois progressives, notamment la désignation des prestataires critiques par les autorités européennes, qui s'échelonne dans le temps, et la montée en puissance du régime TLPT, qui ne concerne dans un premier temps que les entités les plus significatives selon des critères fixés par les autorités nationales compétentes.

Si votre organisation n'a pas encore réalisé de gap analysis formel, la priorité immédiate n'est pas de produire de la documentation supplémentaire mais de vérifier trois choses : votre registre de prestataires TIC existe-t-il et est-il à jour, votre procédure de classification des incidents correspond-elle à la taxonomie DORA, et vos contrats avec les prestataires critiques contiennent-ils les clauses d'audit et de réversibilité exigées par l'article 30.

DORA face à NIS2 et PSD2 : ne pas confondre

La confusion la plus fréquente consiste à traiter DORA comme une simple extension de PSD2 ou une déclinaison sectorielle de NIS2. Les trois textes coexistent avec des objectifs et des mécanismes distincts :

• PSD2 régule les services de paiement et l'authentification forte du client ; elle est antérieure à DORA et reste en vigueur, mais son volet sécurité opérationnelle est désormais complété, pour les prestataires de paiement, par les exigences DORA.
• NIS2 vise la résilience des infrastructures numériques critiques au sens large, avec une transposition nationale variable et des sanctions administratives définies par chaque État membre.
• DORA est spécifique à la finance, d'application directe et uniforme, avec un régime de sanctions propre pouvant inclure des astreintes journalières pour les prestataires tiers critiques en cas de non-coopération avec les autorités de surveillance.

Une entité financière qui a déjà mis en œuvre NIS2 dispose d'une base utile — gestion des risques, notification d'incidents — mais doit vérifier chaque exigence DORA indépendamment : les délais de notification, la taxonomie des incidents et les obligations contractuelles envers les prestataires ne sont pas identiques d'un texte à l'autre.

Ce que DORA n'est pas

Il est utile de clarifier ce que la conformité DORA ne garantit pas, pour éviter les promesses commerciales excessives que l'on rencontre chez certains prestataires de conseil :

• DORA n'est pas un label ou une certification délivrée par un organisme tiers — il n'existe pas de « certificat DORA » officiel. La conformité s'évalue par les autorités de supervision compétentes (ACPR, AMF en France), pas par un audit privé qui délivrerait un tampon.
• DORA n'élimine pas le risque cyber — il structure la manière dont ce risque est géré, documenté et communiqué. Une entité conforme peut malgré tout subir un incident majeur ; elle devra en revanche démontrer qu'elle disposait des processus requis.
• DORA ne se résume pas à un projet informatique — la gouvernance, les achats, le juridique et la conformité sont impliqués au même titre que la DSI, en particulier pour le pilier consacré aux prestataires tiers.

Checklist de démarrage

Avant d'aborder les chapitres suivants, une entité financière devrait pouvoir répondre à ces questions :

• Avons-nous identifié précisément notre statut d'entité financière au sens de l'article 2 de DORA, et le périmètre d'entités du groupe concernées ?
• Disposons-nous d'un registre d'information sur nos prestataires TIC, incluant les sous-traitants en cascade ?
• Notre cadre de gestion des risques TIC est-il documenté, approuvé et revu par l'organe de direction ?
• Notre procédure de classification des incidents correspond-elle aux critères et délais fixés par les normes techniques DORA ?
• Savons-nous si nous sommes concernés par le régime de tests TLPT, et selon quel calendrier ?

Les chapitres suivants reprennent chacun de ces points en détail, avec les textes de référence, les délais précis et les documents à produire.

Qui pilote la conformité en interne

Une erreur d'organisation fréquente consiste à confier l'intégralité du dossier DORA à la DSI, en la traitant comme un sujet purement technique. Le règlement dit l'inverse à plusieurs reprises : l'organe de direction doit approuver le cadre de gestion des risques TIC, revoir la stratégie de résilience au moins une fois par an, et rendre compte de sa mise en œuvre. En pratique, une gouvernance DORA efficace associe généralement quatre fonctions : la DSI et la sécurité des systèmes d'information pour la dimension technique, les achats et le juridique pour la contractualisation avec les prestataires, la conformité réglementaire pour l'interface avec les autorités de supervision, et l'audit interne pour la vérification indépendante du dispositif. L'absence de l'une de ces fonctions dans le comité de pilotage est un signal d'alerte fréquent lors des premiers contrôles.

Cette répartition explique aussi pourquoi les projets DORA menés comme de simples chantiers informatiques prennent du retard : la rédaction des clauses contractuelles obligatoires avec les prestataires critiques, par exemple, relève du juridique et des achats, pas de la DSI, et négocier un avenant avec un grand fournisseur cloud américain prend en général plusieurs mois.