DORA – Règlement sur la résilience opérationnelle numérique du secteur financier

    1. Home  - 
    2. DORA – Règlement sur la résilience opérationnelle numérique du secteur financier

    Mise à jour (mai 2026) : DORA est en application directe depuis le 17 janvier 2025. Une partie du marché a véhiculé fin 2025 l’idée d’un « recul » de DORA sous l’effet du Digital Omnibus Package. Cette lecture est largement erronée. Les exigences de fond (gouvernance ICT, gestion des incidents, tests, supervision des prestataires critiques) ne sont pas remises en cause. Le mouvement réel porte sur la rationalisation administrative et l’harmonisation des notifications, pas sur l’allègement du niveau d’exigence. Novembre 2025 a même marqué une intensification avec la désignation officielle des premiers prestataires tiers critiques (CTPP), faisant entrer les hyperscalers dans la supervision financière européenne directe.

    Le règlement DORA (UE 2022/2554) impose un cadre uniforme de résilience opérationnelle numérique à l’ensemble du secteur financier européen. Il fait basculer la cybersécurité d’une discipline technique vers une exigence de stabilité systémique : un incident TIC majeur dans une banque, une compagnie d’assurance ou une infrastructure de marché peut désormais déclencher un risque pour l’ensemble du système financier.

    Son principe central : la résilience numérique d’une entité financière dépend autant de ses systèmes propres que de ses dépendances externes. Cloud, SaaS, prestataires KYC, hébergeurs, éditeurs core banking, fournisseurs de services managés. DORA traite la chaîne d’approvisionnement TIC comme une extension du risque interne.

    Image de juriste étudiant NIS2, DORA, le cadre cyber européen

    DORA : ce qu’une entreprise doit comprendre immédiatement :

    • DORA est le texte cyber le plus structurant du secteur financier européen. Il fusionne cybersécurité, continuité d’activité, gestion des risques opérationnels et supervision réglementaire dans un cadre unique.
    • La cybersécurité devient une exigence de stabilité financière, pas une question technique annexe. Le management body doit comprendre, piloter, valider et arbitrer le risque ICT.
    • Les prestataires deviennent une composante explicite du risque interne. Cloud, SaaS, KYC, paiement, hébergement, support externalisé : tous entrent dans le périmètre de gouvernance.
    • La logique passe de la politique documentaire à la preuve permanente. Le régulateur ne demande plus « avez-vous une politique ? » mais « pouvez-vous démontrer son application, l’avoir testée, et l’exécuter en crise ? ».
    • DORA pousse fortement vers l’observabilité. SIEM, SOC, journalisation, classification d’événements, supervision continue deviennent des prérequis, pas des options.
    • L’objectif n’est plus l’absence d’incident, c’est la continuité maîtrisée malgré l’incident.
    • Le texte est profondément géopolitique. Il répond à la dépendance européenne aux hyperscalers, à la concentration technologique, et aux tensions hybrides. Les premiers CTPP ont été désignés en novembre 2025.
    • Pour les PME et ETI prestataires du secteur financier, la conformité DORA descend contractuellement la chaîne de sous-traitance. Vous n’êtes peut-être pas régulé DORA, mais votre client bancaire vous imposera ses exigences.

    Qui est concerné ?

    Situation

    Concerné par DORA ?

    Niveau d’attention

    Banque, établissement de crédit
    Établissement de paiement, monnaie électronique
    Compagnie d’assurance ou de réassurance
    Infrastructure de marché (CCP, CSD, plateforme de négociation)

    Oui

    Très élevé

    Société de gestion d’actifs, gestionnaire de FIA
    Fintech, paytech, néobanque
    Prestataire de financement participatif (crowdfunding)
    Prestataire de services sur crypto-actifs (sous MiCA)

    Oui

    Élevé

    Institution de retraite professionnelle (≥ 15 affiliés)

    Oui

    Modéré à élevé

    Agence de notation de crédit

    Oui

    Élevé

    Prestataire TIC du secteur financier (cloud, SaaS, MSSP, éditeur)

    Indirectement, ou directement si désigné CTPP

    Élevé

    PME ou ETI fournisseur d’une entité financière

    Indirect, par effet contractuel

    Modéré à élevé

    Très petite entreprise d’assurance, gestionnaire FIA exempté

    Hors champ (exemptions Solvabilité II, MiFID II)

    Faible

    Pour la liste exhaustive des entités assujetties et le détail des exemptions (article 2 du règlement), voir Conformité DORA.

    Nature juridique du texte

    Consulter directement le règlement (UE) 2022/2554.

    Règlement européen d’application directe, sans loi de transposition. C’est une différence fondamentale avec NIS2, qui est une directive et dépend du contenu de la loi de transposition de chaque État membre. DORA s’impose uniformément dans les 27 États membres depuis le 17 janvier 2025.

    Publié au Journal officiel le 27 décembre 2022, entré en vigueur le 16 janvier 2023, il est devenu pleinement applicable le 17 janvier 2025 après une période de préparation de 24 mois. Cette date marque une rupture : à partir de ce jour, le texte est opposable, les superviseurs peuvent contrôler, et les sanctions peuvent être prononcées.

    DORA n’est pas un texte isolé. Il fonctionne avec un écosystème de normes techniques de réglementation (RTS), de normes techniques d’exécution (ITS), de guidelines et de Q&A publiés par les autorités européennes de surveillance (EBA pour les banques, EIOPA pour les assurances, ESMA pour les marchés). Ces textes secondaires précisent les obligations concrètes. Plusieurs RTS sont entrés en vigueur en 2024-2025 et l’écosystème continue de s’enrichir.

    En France, les autorités nationales compétentes sont l’ACPR (Autorité de contrôle prudentiel et de résolution) pour les banques, les assurances et les établissements de paiement, et l’AMF (Autorité des marchés financiers) pour les sociétés de gestion, les infrastructures de marché et les prestataires d’investissement.

    Pour les prestataires tiers critiques (CTPP), DORA introduit une innovation majeure : un Lead Overseer désigné parmi les trois autorités européennes de surveillance (ESAs) exerce une supervision directe sur le prestataire au niveau européen, court-circuitant les autorités nationales. C’est la première fois que des entreprises non financières (hyperscalers cloud, éditeurs de logiciels critiques) entrent dans le périmètre de supervision financière européenne directe.

    Présentation générale

    DORA repose sur une idée que dix ans de cyberattaques contre le secteur financier ont rendue incontournable : dans une économie financiarisée et numérisée, un incident TIC majeur peut devenir un risque systémique.

    Historiquement, trois disciplines coexistaient sans vraiment se parler. La cybersécurité protégeait les systèmes. La continuité d’activité protégeait l’exploitation. La conformité protégeait juridiquement. DORA fusionne ces trois dimensions dans un cadre unique qui considère qu’une panne cloud peut devenir systémique, qu’un rançongiciel peut devenir un risque financier, qu’une dépendance SaaS peut devenir critique, et qu’un incident ICT peut affecter la stabilité du marché.

    Le règlement s’organise autour de cinq piliers structurants.

    Les 5 piliers DORA.

    Pilier 1 : gestion du risque TIC

    Le plus large. Il impose une gouvernance, des politiques, une cartographie des actifs critiques, des mécanismes de protection et de détection, des plans de reprise, et une amélioration continue. L’organe de direction (management body) doit comprendre, valider et arbitrer le risque ICT en première personne.

    Pilier 2 : gestion et signalement des incidents TIC

    Classification harmonisée des incidents selon des critères européens uniformes, notification réglementaire à l’autorité compétente selon un calendrier précis, reporting structuré. L’incident cyber devient un événement réglementaire formel.

    Pilier 3 : tests de résilience opérationnelle

    Tests réguliers de vulnérabilité, exercices, et pour les entités les plus importantes, tests de pénétration avancés fondés sur le renseignement sur les menaces (TLPT, Threat-Led Penetration Testing). Tous les trois ans pour les entités significatives.

    Pilier 4 : gestion des prestataires TIC

    Probablement la partie la plus innovante du règlement. Registre obligatoire des fournisseurs, classification par criticité, clauses contractuelles minimales obligatoires, droit d’audit, exigences de réversibilité. Pour les prestataires désignés critiques par les ESAs, supervision directe au niveau européen.

    Pilier 5 : partage d’informations

    Mécanisme volontaire encourageant le partage d’indicateurs de compromission, de CTI et de leçons apprises entre acteurs du secteur. Moins prescriptif que les autres piliers, mais structurant à terme.

    Le texte construit une doctrine européenne complète de résilience numérique financière. Il devient le modèle implicite pour les évolutions futures d’autres cadres sectoriels (santé, énergie).

    Contexte et champ d’application

    Plusieurs évolutions ont convergé vers la nécessité d’un cadre comme DORA.

    L’explosion des dépendances numériques d’abord. Le secteur financier s’est massivement transformé en quinze ans. Banques en ligne, paiements instantanés, mobile banking, trading algorithmique, KYC dématérialisé, gestion d’actifs assistée par IA, tout repose sur des chaînes techniques complexes mêlant développements internes, SaaS, cloud, APIs, prestataires KYC, et services managés. La résilience d’une banque ne se mesure plus à ses propres centres de données, mais à la solidité de l’écosystème complet sur lequel elle s’appuie.

    L’industrialisation de la cybercriminalité ensuite. Ransomware-as-a-Service, phishing à grande échelle, contournement MFA, attaques de supply chain logicielle (SolarWinds, MOVEit, Kaseya), automatisation par IA. Le secteur financier reste la cible privilégiée parce qu’il combine valeur immédiate (vol direct), valeur indirecte (données clients monétisables) et impact systémique (effet réputationnel massif).

    Les risques géopolitiques aussi. Le régulateur européen considère désormais la cybersécurité comme un enjeu de souveraineté et les dépendances technologiques comme des risques stratégiques. La domination des hyperscalers américains (AWS, Azure, Google Cloud) sur le cloud financier européen est devenue un sujet politique de premier plan.

    La concentration technologique enfin. Quelques acteurs supportent une part démesurée du système financier européen. Une panne majeure de l’un d’eux pourrait avoir un effet en cascade sur des centaines d’établissements simultanément. DORA introduit pour la première fois un mécanisme de supervision directe de ces acteurs par les autorités financières européennes.

    Le champ d’application est volontairement très large. Plus de 20 catégories d’entités financières sont visées (article 2), couvrant l’ensemble des métiers du secteur. Les exemptions ciblent uniquement les très petites structures sans impact systémique (petits gestionnaires FIA, petites entreprises d’assurance Solvabilité II, institutions de retraite de moins de 15 affiliés, microentreprises d’intermédiation).

    Une dimension particulièrement structurante concerne les prestataires tiers TIC. Le règlement les traite comme une extension du risque interne. Tous les contrats critiques doivent inclure des clauses minimales obligatoires. Les prestataires désignés critiques par les ESAs (CTPP) entrent dans une supervision directe au niveau européen, indépendamment de leur taille ou de leur localisation. La première vague de désignations CTPP en novembre 2025 a touché plusieurs hyperscalers cloud, marquant un changement d’ère.

    Pour les PME et ETI prestataires du secteur financier, la conformité DORA descend par voie contractuelle. Vous n’êtes peut-être pas régulé directement, mais votre client bancaire vous imposera les clauses DORA dans tous les nouveaux contrats et les renouvellements. C’est l’un des effets de diffusion les plus structurants du texte.

    Pilier 1 : gestion du risque TIC

    (voir chapitre II). Cadre complet et documenté, validé par l’organe de direction, mis à jour au moins une fois par an. Comprend une stratégie de résilience numérique, des politiques de sécurité formalisées, un inventaire des actifs TIC critiques, des mécanismes de détection des menaces, des plans de continuité d’activité testés régulièrement, des procédures de gestion des changements, et une gouvernance de la sécurité de l’information.

    L’organe de direction porte la responsabilité finale du cadre. Il doit suivre une formation régulière, valider explicitement les politiques, et être informé en temps réel des incidents majeurs. Cette responsabilité personnelle, similaire à celle introduite par NIS2, est l’une des ruptures culturelles du texte.

    Une banque doit cartographier l’intégralité de ses systèmes critiques (core banking, paiements, trading, KYC, reporting réglementaire), identifier les dépendances vis-à-vis de ses prestataires cloud, et prévoir des plans de bascule testés en cas de défaillance. Le niveau de détail attendu dépasse largement les exercices ITIL classiques.

    Pilier 2 : gestion et signalement des incidents TIC

    (voir chapitre III). Classification harmonisée selon des critères européens : nombre de clients affectés, durée de l’incident, impact financier, étendue géographique, impact sur les services critiques, impact réputationnel. Les RTS publiés en 2024 précisent les seuils.

    Pour les incidents majeurs, calendrier de notification en trois temps : notification initiale dans les 24 heures, notification intermédiaire dans les 72 heures, rapport final dans le délai fixé par les RTS (généralement un mois). En France, banques et établissements de paiement notifient à l’ACPR, sociétés de gestion à l’AMF.

    Une banque qui subit une panne de son système de paiement affectant des dizaines de milliers de clients pendant plusieurs heures doit notifier à l’ACPR dans les délais réglementaires, même si l’incident est maîtrisé. La logique n’est plus celle du contrôle a posteriori, mais celle de la vision en temps réel des risques systémiques.

    Pilier 3 : tests de résilience opérationnelle

    (voir chapitre IV). Programme de tests régulier couvrant l’ensemble des systèmes critiques. Tests de vulnérabilité, tests de pénétration classiques, tests de continuité et de reprise, simulations de scénarios.

    Pour les entités significatives (banques d’importance systémique, principales compagnies d’assurance, infrastructures de marché majeures), tests de pénétration avancés TLPT tous les trois ans. Ces tests sont conduits par des équipes red team simulant des attaquants réels selon les tactiques observées sur les groupes cybercriminels ciblant le secteur financier. Coordonnés au niveau européen via le framework TIBER-EU. Coût significatif, plusieurs centaines de milliers d’euros par test.

    Pilier 4 : gestion des prestataires TIC

    (voir chapitre V). Registre obligatoire de l’ensemble des accords contractuels avec des prestataires TIC, à tenir à jour. Classification par criticité fonctionnelle. Pour les prestations critiques, clauses contractuelles minimales obligatoires : description précise des services, niveaux de service, droit d’audit, accès aux données, obligations de sécurité, plans de continuité, exigences de réversibilité et de portabilité, sous-traitance encadrée, droit de résiliation, juridiction et droit applicable.

    L’autorité compétente peut imposer des modifications contractuelles, voire interdire le recours à un prestataire jugé trop risqué. C’est une innovation par rapport au cadre classique de la sous-traitance financière. Une compagnie d’assurance qui utilise AWS pour héberger son système de gestion des sinistres doit pouvoir, contractuellement, permettre à l’ACPR d’auditer AWS et garantir que les données peuvent être rapatriées si la relation est interrompue.

    Pour les prestataires critiques (CTPP) désignés par les ESAs sur la base de critères de criticité systémique, supervision directe au niveau européen par un Lead Overseer. Le Lead Overseer peut diligenter des inspections, demander des informations, formuler des recommandations contraignantes, et imposer des astreintes financières (jusqu’à 1% du chiffre d’affaires mondial quotidien moyen). La première vague de désignations CTPP a eu lieu en novembre 2025.

    Pilier 5 : partage d’informations

    (voir chapitre VI). Mécanisme volontaire de partage d’indicateurs de compromission, de tactiques d’attaque observées et de leçons apprises entre entités financières. Coopération avec les CERT sectoriels (CERT-FR, CERT financier). Vise à industrialiser une CTI sectorielle, encore embryonnaire en 2026 mais qui devrait monter en puissance.

    DORA ne prescrit pas une architecture de référence unique. Il pose des thèmes techniques que les RTS et ITS précisent, et que les autorités sectorielles (ACPR, AMF) interprètent dans leurs guidelines.

    Gouvernance et reporting. Comité de risque ICT au niveau direction, reporting structuré, sponsor exécutif, arbitrages tracés, gouvernance documentaire mature. Le management body doit être en mesure de qualifier un incident majeur en moins d’une heure et d’arbitrer en crise.

    Observabilité. Pierre angulaire implicite du texte. Logs centralisés, SIEM, SOC interne ou externalisé, corrélation d’événements, détection comportementale, classification automatique des incidents selon les critères DORA. Pour une banque d’importance moyenne, ce sont plusieurs millions d’euros annuels.

    Gestion des identités et des accès. MFA généralisée, IAM mature, PAM pour les comptes à privilèges, revues d’habilitations régulières, gestion du cycle de vie des accès. Le secteur financier doit dépasser l’état de l’art moyen pour atteindre un niveau qualifié.

    Résilience opérationnelle. Sauvegardes isolées (offline ou immuables) pour résister aux rançongiciels, PRA et PCA testés en conditions réalistes, exercices de crise impliquant la direction, scénarios de défaillance de prestataire critique. Les tests doivent être documentés et leurs résultats analysés.

    Sécurité supply chain. Due diligence à l’entrée en relation, clauses contractuelles DORA-compatibles, suivi continu des dépendances, gestion de la concentration (le règlement encourage explicitement à éviter une concentration excessive sur un seul prestataire), stratégies de sortie réalistes.

    Gestion des vulnérabilités. Patch management discipliné, scans réguliers, priorisation selon l’exposition, suivi des CVE critiques. Les délais de remédiation des vulnérabilités critiques exploitées sont un point d’attention récurrent des superviseurs.

    Documentation et preuve. Point critique. DORA exige la capacité à démontrer en temps réel l’existence, la mise à jour et l’application des mesures. Politiques, procédures, registres, preuves d’exécution, rapports de tests, comptes rendus de comités, traces des décisions. Un dossier DORA mature représente plusieurs centaines de pages de documentation vivante.

    Cybersecurity mesh, Zero Trust. Pas prescrits explicitement, mais fortement implicites. Le texte pousse vers la segmentation forte, la vérification continue, la résistance à la propagation latérale. Les architectures réseau historiques des banques (modèle château-douve) sont progressivement remises en cause.

    DateÉtape
    2020Proposition initiale de la Commission européenne
    14 décembre 2022Adoption du règlement par le Parlement et le Conseil
    27 décembre 2022Publication au Journal officiel de l’Union européenne
    16 janvier 2023Entrée en vigueur
    2023-2024Publication progressive des RTS et ITS par les ESAs
    17 janvier 2025Application pleine et entière du règlement
    2025Publication des dernières RTS, montée en puissance des contrôles ACPR/AMF
    Novembre 2025Désignation officielle des premiers prestataires tiers critiques (CTPP)
    2025-2026Premiers cycles de tests TLPT
    2026-2027Adoption attendue du Digital Omnibus, harmonisation des notifications
    2026-2028Montée en puissance des contrôles, premières sanctions significatives

    Point de réalisme : la date du 17 janvier 2025 a été un signal fort, mais elle n’a pas marqué une bascule binaire. Beaucoup d’entités, notamment les plus petites, ont activé une démarche de mise en conformité étalée sur 2025-2027. Les superviseurs ACPR et AMF ont jusqu’ici privilégié la pédagogie sur la sanction, en attendant la maturation de l’écosystème RTS. La période 2027-2028 verra probablement les premières sanctions significatives, notamment sur les manquements aux exigences de tests et de gestion des prestataires.

    DORA est la lex specialis du cadre cyber européen pour le secteur financier. C’est une articulation centrale, qui détermine quel texte s’applique à quelle entité.

    NIS2. Articulation par exclusion. Les entités financières couvertes par DORA sont exemptées de NIS2 sur le champ couvert par DORA (résilience opérationnelle, gestion des risques TIC, notification d’incidents, tests, gestion des prestataires). DORA est plus prescriptif et plus précis que NIS2 sur ces sujets. Pour une banque, c’est DORA qui s’applique. Pour son fournisseur cloud, c’est potentiellement DORA s’il est désigné CTPP, NIS2 sinon. La frontière est claire en théorie, plus floue en pratique pour les acteurs hybrides (fintech non régulées, prestataires mixtes).

    RGPD. Articulation fonctionnelle. Un incident DORA qui implique des données personnelles déclenche les deux régimes simultanément : notification à l’ACPR ou à l’AMF au titre de DORA (24 heures, 72 heures, rapport final), notification à la CNIL au titre du RGPD (72 heures). Le Digital Omnibus prévoit l’unification via le guichet unique SEP.

    AI Act. Articulation croissante. L’IA devient simultanément un outil métier (gestion d’actifs algorithmique, scoring crédit, lutte anti-blanchiment), un outil de fraude (deepfakes, fraude au président), un outil de cybersécurité (détection comportementale) et un risque opérationnel propre. Pour les systèmes d’IA à haut risque dans le secteur financier (scoring crédit notamment), les autorités nationales de supervision financière conservent leur compétence propre. Les entités DORA articulent donc leurs obligations AI Act avec leur cadre DORA existant, sans doublon de supervision.

    CRA (Cyber Resilience Act). Articulation indirecte mais structurante. Le CRA impose des exigences de sécurité aux produits numériques. Les banques et assurances utilisent massivement de tels produits (équipements réseau, terminaux de paiement, objets connectés assurance). Le CRA améliore donc en amont la qualité des briques que les entités DORA intègrent dans leurs SI.

    Cybersecurity Act. Articulation forte sur les certifications. Une entité financière peut utiliser les schémas européens (EUCC pour les produits, EUCS lorsqu’il sera adopté pour le cloud, EUMSS pour les services managés) pour qualifier la confiance dans ses fournisseurs critiques TIC. La certification ne remplace pas la gouvernance DORA mais l’alimente. La proposition de CSA2 du 20 janvier 2026 introduit même la possibilité d’exclure des fournisseurs à haut risque, ce qui croisera directement la gestion des CTPP.

    eIDAS 2. Articulation à venir sur l’identité et l’authentification. Le déploiement du portefeuille européen d’identité numérique impactera les processus KYC bancaires (entrée en relation client) et les mécanismes d’authentification forte. Les wallets opérés par des prestataires financiers ou utilisés massivement pour le KYC entreront dans la zone DORA.

    MiCA. Articulation directe et formelle. Les prestataires de services sur crypto-actifs (CASP) agréés au titre de MiCA sont expressément inclus dans le champ DORA (article 2). La résilience opérationnelle des plateformes crypto régulées s’aligne ainsi sur celle des banques traditionnelles.

    CER (Critical Entities Resilience). Articulation pour les entités du secteur financier également classées entités critiques au sens de CER (résilience physique). Le secteur financier figure parmi les onze secteurs couverts par CER.

    DSA, DMA, Data Act, DGA, ePrivacy. Pas d’articulation directe structurante avec DORA, hors cohérence générale du cadre numérique européen.

    Pour la vue d’ensemble du cadre cyber européen et de ses articulations, voir Le cadre réglementaire cyber.

    Le paquet Digital Omnibus publié par la Commission le 19 novembre 2025 ne remet pas en cause les piliers de DORA. C’est un point important à clarifier, parce qu’une partie du marché a véhiculé fin 2025 une lecture erronée d’un prétendu « recul » de DORA.

    L’architecture du texte reste intacte. Les exigences de gouvernance ICT, de gestion des incidents, de tests de résilience, de supervision des prestataires critiques, de gestion contractuelle des tiers ne sont pas modifiées. Le mouvement de l’omnibus porte sur la rationalisation administrative, pas sur l’allègement du niveau d’exigence.

    Guichet unique de notification d’incidents (SEP). Création d’un Single Entry Point géré par l’ENISA, permettant à une entité soumise à plusieurs régimes de notification de notifier un même incident une seule fois. Pour une banque qui subit un incident touchant des données personnelles, c’est aujourd’hui un cumul : notification à l’ACPR au titre de DORA, notification à la CNIL au titre du RGPD, parfois notification au CSIRT national si l’incident a une dimension cyber significative. Demain, une notification unique au SEP avec routage automatique vers les autorités compétentes. Mise en service prévue 18 à 24 mois après l’adoption du règlement omnibus, donc 2027 ou plus probablement 2028 en pratique.

    Harmonisation à 96 heures du délai de notification. L’omnibus harmonise à 96 heures les délais entre RGPD, NIS2, DORA et CER. DORA conserve son calendrier propre (24 h initiale, 72 h intermédiaire, rapport final selon RTS) mais l’alignement RGPD à 96 heures supprime certaines asymétries actuelles.

    Digital Omnibus on AI. Applicable au 2 août 2026, il précise la compétence des autorités de supervision dans le secteur financier pour les systèmes d’IA à haut risque. Les autorités nationales de supervision financière (ACPR, AMF en France) conservent leur compétence propre, évitant le doublon de supervision avec les autorités AI Act sectorielles.

    Le signal politique reste extrêmement clair. L’Europe ne réduit pas son ambition cyber. Plusieurs éléments indiquent même un durcissement progressif : désignation des premiers CTPP en novembre 2025, montée en puissance des RTS et ITS, convergence croissante avec NIS2, importance grandissante donnée à la supply chain TIC, surveillance renforcée des dépendances cloud. Simplification ne veut pas dire dérégulation. Harmonisation ne veut pas dire baisse des exigences.

    La question DORA pour une PME ou une ETI se pose rarement frontalement. Vous n’êtes presque jamais une banque, une compagnie d’assurance ou une infrastructure de marché. Vous êtes leur prestataire. Et c’est précisément là que se joue l’essentiel de la pression DORA pour les structures de votre taille.

    Trois situations très différentes existent, et il faut commencer par identifier laquelle est la vôtre.

    Première situation : vous êtes une entité financière de taille moyenne directement assujettie. Société de gestion d’actifs de moins de 50 salariés, établissement de paiement émergent, fintech, prestataire de financement participatif, compagnie d’assurance régionale, intermédiaire d’assurance significatif. Vous êtes pleinement dans le champ DORA, mais sans les moyens des grands acteurs. C’est la situation la plus inconfortable parce qu’elle exige un dispositif complet sur les cinq piliers, calibré à votre taille.

    Deuxième situation : vous êtes prestataire TIC d’une ou plusieurs entités financières. Éditeur SaaS utilisé par des banques, hébergeur, MSSP, prestataire KYC, intégrateur, consultant cyber, fournisseur de services managés. Vous n’êtes pas directement régulé DORA, mais vos clients bancaires vous imposent contractuellement leurs exigences. La pression descend par la chaîne d’approvisionnement, et elle est réelle.

    Troisième situation : vous êtes prestataire désigné critique (CTPP). Très rare pour une PME. Mais une ETI fournissant un service réellement systémique à plusieurs grandes banques européennes peut être désignée par les ESAs. Dans ce cas, vous basculez sous supervision directe européenne, indépendamment de votre statut financier propre. C’est une catégorie à part qui nécessite un accompagnement spécifique.

    Pour chacune, la trajectoire est différente.

    1/ Pour une entité financière moyenne directement assujettie.

    L’approche par paliers reste valable, mais le niveau plancher est sensiblement plus élevé que pour NIS2. Le secteur financier ne tolère pas une conformité documentaire vide. Les superviseurs ACPR et AMF disposent d’une culture du contrôle approfondi, et leurs équipes inspectent en profondeur.

    Cadre de gouvernance ICT validé par l’organe de direction. Cartographie complète des actifs TIC critiques, des dépendances, des flux. PSSI alignée sur DORA et les RTS publiés. Procédure de gestion des incidents avec les seuils de classification DORA bien intégrés. Registre des contrats prestataires TIC à jour. Plan de tests pluriannuel, incluant tests de vulnérabilité, tests de continuité, et préparation à une éventuelle inclusion dans le périmètre TLPT.

    L’effort initial est conséquent : pour une société de gestion ou un établissement de paiement de taille moyenne, comptez 12 à 18 mois de structuration intensive, avec un budget projet souvent compris entre 200 000 et 800 000 euros selon le point de départ. Le coût annuel récurrent (maintien, audits, tests) se stabilise ensuite autour de 100 000 à 300 000 euros selon la taille.

    L’écueil le plus fréquent reste la sous-estimation du pilier prestataires. Beaucoup d’entités financières moyennes ont sous-traité leur informatique à un petit nombre de prestataires sans clauses DORA-compatibles. Renégocier ces contrats avec des fournisseurs qui ont parfois le pouvoir de marché (éditeur core banking unique, hébergeur cloud central) est un exercice politiquement délicat et techniquement lourd.

    2/ Pour un prestataire TIC d’entités financières.

    C’est probablement la situation la plus répandue parmi les PME et ETI tech françaises. Vous éditez un logiciel utilisé par des banques. Vous hébergez des données de compagnies d’assurance. Vous fournissez du KYC à des établissements de paiement. Vous opérez un SaaS de gestion d’actifs. Vos clients sont assujettis DORA, donc vous le devenez par effet de cascade.

    La pression arrive par trois canaux. Le contrat d’abord : vos clients vous imposent des clauses minimales DORA dans tous les nouveaux contrats et les renouvellements (droit d’audit, niveaux de service, plans de continuité, réversibilité, sous-traitance encadrée). Les questionnaires sécurité ensuite : vos clients vous adressent des questionnaires fournisseurs DORA-compatibles, parfois de plusieurs centaines de lignes, qui font la part belle aux preuves opérationnelles. Les audits enfin : pour les services critiques, vos clients peuvent exercer leur droit d’audit, ou demander un audit indépendant à votre charge.

    Ce qu’il faut structurer concrètement :

    • ISO 27001 ou équivalent comme socle minimum, voire SecNumCloud pour les prestataires cloud visant le secteur financier français ;
    • documentation complète des processus de sécurité, des sauvegardes, de la continuité, de la gestion d’incidents ;
    • capacité à produire rapidement les preuves demandées par les questionnaires fournisseurs (politiques signées, comptes rendus de comités, rapports d’audit, résultats de tests, registres) ;
    • contractualisation soignée avec les sous-traitants (vos propres fournisseurs cloud, vos sous-traitants techniques), pour démontrer la maîtrise de la chaîne en cascade ;
    • plan de réversibilité réel (pas seulement documenté), avec exercices de restauration vers une plateforme alternative ;
    • assurance cyber dimensionnée à la criticité des données traitées.

    Pour une PME prestataire d’une dizaine d’établissements financiers, la mise à niveau DORA-compatible représente typiquement 6 à 12 mois de chantier et un investissement de 50 000 à 250 000 euros, principalement sur la documentation, la mise à niveau technique et la certification ISO 27001 si elle n’existait pas.

    L’écueil principal reste la dispersion. Chaque client envoie son propre questionnaire, parfois redondant, parfois contradictoire. Sans une démarche unifiée et un référentiel propre, la PME passe son temps à répondre à des audits clients au lieu de progresser. La bonne stratégie : se doter d’un socle de preuves opérationnelles unifié, puis le projeter dans les questionnaires clients plutôt que de les traiter au cas par cas.

    3/ Pour un prestataire désigné critique (CTPP).

    Situation rare mais existante. Si votre ETI a été désignée CTPP en novembre 2025 ou lors d’une vague ultérieure, vous basculez sous supervision directe du Lead Overseer européen. Ce n’est plus une mise en conformité par effet de cascade, c’est une supervision pleine. Inspections sur site, demandes d’informations contraignantes, recommandations à appliquer, astreintes possibles à 1 % du chiffre d’affaires mondial quotidien moyen en cas de manquement.

    Le dispositif requis se rapproche de celui des grandes entités financières assujetties, avec quelques spécificités : gouvernance dédiée au statut CTPP, point de contact avec le Lead Overseer, capacité à répondre rapidement à des demandes européennes, transparence sur la sous-traitance et la concentration. À ce stade, un accompagnement spécialisé est presque toujours nécessaire.

    Mais trois principes communs aux trois situations.

    Premier principe : la preuve opérationnelle prime sur la documentation. DORA est un texte qui sanctionne moins l’absence de PSSI que l’incapacité à démontrer que ce qui est écrit est effectivement appliqué. Une politique de sauvegarde isolée et testée tous les six mois, avec un compte rendu signé et une preuve de restauration, vaut mieux qu’une PSSI de 200 pages jamais lue.

    Deuxième principe : la concentration des prestataires est un sujet de fond. DORA encourage explicitement la diversification des dépendances critiques. Pour une PME qui dépend à 100 % d’AWS, ou d’un éditeur core banking unique, ou d’un MSP exclusif, la trajectoire de mise en conformité passe nécessairement par une réflexion sur la réversibilité réelle. Documenter ne suffit pas, il faut être capable de basculer.

    Troisième principe : la gouvernance compte autant que la technique. Le management body doit pouvoir parler DORA, comprendre les enjeux, arbitrer en crise. Pour une PME où le dirigeant est aussi le DSI, c’est une bonne nouvelle. Pour une ETI où la direction délègue tout à la DSI, c’est un chantier culturel à mener avant tout le reste.

    L’écueil le plus dommageable reste de considérer DORA comme un sujet purement technique délégué aux équipes IT et sécurité. Le secteur financier européen vient de basculer dans un cadre où la cybersécurité est un sujet de stabilité systémique, opposable au plus haut niveau. Une PME ou une ETI qui ne fait pas ce basculement culturel restera mal préparée, même avec un dispositif technique impeccable.

    Pour structurer votre trajectoire selon votre situation, voir Conformité DORA.

    DORA ne fixe pas de plafonds harmonisés d’amendes administratives uniques. Le texte renvoie aux régimes nationaux de supervision financière et aux cadres sectoriels existants (CRD pour les banques, Solvabilité II pour les assurances, MiFID pour les prestataires d’investissement). Chaque autorité nationale applique son arsenal habituel : injonctions, astreintes, amendes administratives, suspensions, retraits d’agrément.

    Pour les entités financières assujetties. Les sanctions peuvent atteindre des montants très significatifs, calibrés sur le chiffre d’affaires et la gravité du manquement, selon les cadres sectoriels. L’ACPR et l’AMF disposent de leur grille classique de sanctions financières, qui peut atteindre plusieurs millions d’euros pour une banque importante. Au-delà du montant, la sanction publique (publication de la décision, mention au bilan, signal aux marchés) peut avoir un effet réputationnel supérieur au montant lui-même.

    Pour les prestataires tiers critiques (CTPP). Innovation majeure du texte. Les ESAs disposent d’un pouvoir d’astreinte directe pouvant atteindre 1% du chiffre d’affaires mondial quotidien moyen du prestataire pour chaque jour de manquement aux recommandations contraignantes du Lead Overseer. Sur la durée, le montant peut devenir colossal. Pour un hyperscaler générant plusieurs centaines de milliards de dollars de revenus annuels, l’astreinte quotidienne se compte en millions.

    Responsabilité des dirigeants. DORA augmente fortement la responsabilité managériale. Le management body porte la responsabilité finale du cadre ICT et peut être personnellement mis en cause en cas de manquement grave, indépendamment de la sanction de la personne morale.

    Effet réputationnel. Particulièrement structurant dans le secteur financier. Un signalement DORA important rendu public peut affecter la confiance des clients, la cotation, la prime de risque. C’est souvent l’aspect le plus craint par les directions générales, plus encore que le montant de l’amende elle-même.

    Effet opérationnel. Un superviseur peut imposer des mesures correctrices contraignantes : suspension d’activités, interdiction de recourir à un prestataire jugé trop risqué, obligation de migration sous délai, plan de remédiation sous astreinte. Pour une banque, ces mesures peuvent avoir un impact opérationnel direct supérieur à toute amende.

    À ce stade (mai 2026), peu de sanctions DORA significatives ont été prononcées. Les superviseurs sont entrés dans une phase de contrôle progressif depuis janvier 2025. Les premières sanctions structurantes sont attendues sur 2027-2028, probablement sur les manquements aux exigences de tests TLPT, à la gestion contractuelle des prestataires critiques, ou à la qualité de la notification d’incidents.

    DORA change profondément le paradigme cyber pour les entreprises du secteur financier.

    Avant DORA, la cybersécurité bancaire reposait sur trois piliers traditionnels : protection des systèmes (sécurité périmétrique, antivirus, pare-feu), prévention (sensibilisation, durcissement, conformité), et reprise (sauvegardes, PRA). C’était utile, mais souvent insuffisant face à des attaques modernes qui contournent le périmètre, exploitent les fournisseurs, et durent plusieurs mois en silence avant de se déclencher.

    Après DORA, la cybersécurité bascule vers un autre registre. Résilience plutôt que prévention pure. Continuité plutôt que reconstruction. Observabilité plutôt que confiance dans le périmètre. Maîtrise des dépendances plutôt que sécurité interne seule. Gouvernance au niveau direction plutôt que technicité confinée à la DSI. Rapidité décisionnelle plutôt que processus longs.

    Le texte pousse implicitement plusieurs disciplines qui étaient parfois traitées en pointillé :

    • supervision continue (SIEM, SOC, détection comportementale, CTI sectorielle) ;
    • gestion des identités à un niveau qualifié (IAM mature, PAM, MFA résistante au phishing) ;
    • architecture Zero Trust (segmentation forte, vérification continue, microsegmentation) ;
    • résilience opérationnelle testée (PRA, PCA, exercices de crise impliquant la direction) ;
    • gouvernance des tiers (cartographie des dépendances critiques, gestion de la concentration, plans de réversibilité) ;
    • pilotage COMEX (capacité à qualifier et arbitrer un incident en moins d’une heure).

    Le texte transforme la cybersécurité d’une discipline purement technique en une capacité de survie opérationnelle. L’objectif final n’est plus l’absence d’attaque (jugée inatteignable) ni même la confidentialité parfaite (jugée insuffisante), mais la continuité maîtrisée des fonctions critiques malgré l’incident. C’est une rupture culturelle.

    Pour les PME et ETI prestataires du secteur financier, l’effet est indirect mais réel. Vos clients bancaires vous imposeront progressivement les clauses DORA dans tous les contrats. Vous devrez démontrer une maturité opérationnelle équivalente, sans nécessairement disposer des moyens d’une banque. C’est le moment de structurer votre démarche, parce que ce que les banques exigent aujourd’hui devient demain l’attendu standard pour tous les marchés sensibles.

    Où en êtes-vous sur DORA ?

    DORA n’est pas un projet à date de fin. C’est un état permanent, démontrable, opposable, qui doit tenir face à un contrôle, à un incident réel, ou à une crise de marché. Les entreprises qui ont fait la mise en conformité initiale en 2024-2025 entrent maintenant dans la phase la plus difficile : maintenir le dispositif vivant, le faire évoluer avec les RTS qui continuent de sortir, et démontrer sa robustesse en conditions réelles.

    Quelques questions concrètes pour situer votre maturité :

    • Savez-vous exactement quelles dépendances numériques pourraient arrêter votre activité, et combien de temps il vous faudrait pour basculer ?
    • Votre direction serait-elle capable de qualifier un incident DORA majeur en moins d’une heure et de prendre les bonnes décisions de notification ?
    • Vos prestataires critiques sont-ils réellement gouvernés (clauses, audits, exercices de réversibilité), ou simplement référencés ?
    • Votre cybersécurité protège-t-elle vos systèmes, ou votre capacité à continuer l’activité ? Ce n’est pas tout à fait la même chose.
    • Votre conformité DORA est-elle démontrable par des preuves opérationnelles, ou seulement documentaire ?
    • Si votre principal fournisseur cloud devenait indisponible demain matin, sauriez-vous continuer à fonctionner ?

    Radical-SSI accompagne les entreprises du secteur financier et leurs prestataires sur l’ensemble de la trajectoire DORA : diagnostic de maturité, structuration de la gouvernance ICT, mise en place des cinq piliers, revue des contrats prestataires, préparation aux tests TLPT, exercices de crise impliquant la direction, maintien en condition opérationnelle dans la durée.

    Prenons rendez-vous pour une consultation sans engagement.

    Pour aller plus loin sur la mise en œuvre opérationnelle, voir Conformité DORA.

    Pour les entités hors secteur financier, voir Conformité NIS2.

    Pour la vue d’ensemble du cadre européen, voir Le cadre réglementaire cyber.

    Partagez cette page via :