Le Règlement UE 2022/2554, dit DORA (Digital Operational Resilience Act), est applicable depuis le 17 janvier 2025. Pas de délai de grâce, pas de transposition nationale : contrairement à NIS2 qui est une directive, DORA est un règlement européen directement applicable dans les 27 États membres dès sa date d’entrée en vigueur.
Pour un DSI d’établissement financier, cette distinction est fondamentale. Votre ERP, s’il supporte des fonctions critiques, entre dans le périmètre de supervision. Et votre contrat avec votre éditeur doit contenir des clauses que la majorité des contrats signés avant 2024 ne prévoient tout simplement pas.
Ce guide fait le point sur l’état des obligations en 2026, dix-huit mois après l’entrée en application du règlement.
DORA en bref : qui est concerné et depuis quand ?
Périmètre réglementaire : 21 catégories d’entités financières
DORA couvre 21 catégories d’entités définies à l’article 2 du règlement. Le périmètre est large : établissements de crédit, sociétés de bourse, entreprises d’assurance et de réassurance, sociétés de gestion d’actifs, prestataires de services de paiement, établissements de monnaie électronique, prestataires de services sur crypto-actifs agréés, infrastructures de marchés (contreparties centrales, dépositaires centraux), et fintechs réglementées (source : dora-finance.fr).
Les petites entités bénéficient d’un cadre simplifié prévu à l’article 16, mais les exigences essentielles (cartographie des risques TIC, registre des prestataires, clauses contractuelles) restent obligatoires pour toutes.
Date d’application : 17 janvier 2025, sans période de tolérance
L’ACPR et l’AMF ont confirmé l’entrée en vigueur au 17 janvier 2025 sans période de grâce formelle (AMF France, DORA). L’année 2025 a constitué la phase d’audit et d’exigences documentaires. En 2026, les autorités de supervision sont passées aux contrôles approfondis.
Si votre établissement n’a pas encore finalisé son registre ICT (Register of Information) ni mis à jour ses contrats avec les fournisseurs TIC critiques, vous êtes techniquement en situation de non-conformité depuis plus d’un an.
Ce que DORA n’est pas : une directive généraliste comme NIS2
NIS2 est une directive : chaque État membre l’a transposée (ou non, dans les délais) dans son droit national. DORA est un règlement : il s’applique directement, uniformément, dans toute l’Union européenne. Aucune variante nationale, aucun délai de transposition, aucun « attendons les décrets ».
De plus, DORA est sectoriel et prescriptif. Il ne se contente pas de fixer des objectifs de résilience ; il définit des mécanismes concrets : délais de notification au quart d’heure près, fréquence minimale des tests, liste des clauses contractuelles obligatoires.
Votre ERP est-il un « prestataire TIC critique » au sens de DORA ?
Quand un ERP devient un service TIC critique
DORA distingue deux niveaux dans les contrats TIC :
- Contrats standards : tout fournisseur TIC, quelle que soit l’importance du service fourni.
- Fonctions critiques ou importantes : les services TIC qui, en cas d’interruption, compromettent directement les exigences réglementaires de l’entité ou l’exécution de ses activités essentielles.
Un ERP financier qui gère la comptabilité générale, le reporting réglementaire (COREP, FINREP pour les banques), ou la chaîne de liquidation répond généralement au critère de « fonction critique ou importante ». Dans ce cas, les exigences contractuelles de l’article 30 du règlement s’appliquent dans leur version renforcée.
Les grands éditeurs face aux critères DORA de concentration
DORA introduit un concept nouveau à l’échelle européenne : la supervision directe des « prestataires tiers TIC critiques » (CTPP, Critical Third-Party Providers) désignés au niveau européen par les ESAs (EBA, ESMA, EIOPA). Ces prestataires font l’objet d’une surveillance exercée par un « lead overseer ».
En pratique, les premiers hyperscalers cloud (AWS, Microsoft Azure, Google Cloud) ont été désignés dans cette catégorie en 2025-2026. Or, SAP S/4HANA Cloud, Oracle NetSuite, Microsoft Dynamics 365 Finance et d’autres ERP SaaS s’appuient massivement sur ces infrastructures. Votre « éditeur ERP » n’est donc pas uniquement votre interlocuteur direct : la chaîne de sous-traitance remonte jusqu’aux hyperscalers.
L’enjeu de la sous-traitance en cascade
L’article 28(2) de DORA exige que les entités financières identifient et documentent la chaîne complète de sous-traitance de leurs fournisseurs TIC critiques. Si votre ERP SaaS tourne sur AWS et qu’AWS sous-traite une partie de son infrastructure à un sous-traitant de niveau N+2, cette information doit figurer dans votre registre ICT.
Demandez à votre éditeur ERP la liste de ses sous-traitants critiques. Si cette liste n’existe pas ou n’est pas mise à jour, c’est une non-conformité DORA de votre côté, pas uniquement de sa responsabilité.
Les 5 piliers DORA qui impactent directement votre ERP
DORA s’organise autour de cinq piliers. Voici comment chacun d’eux se traduit concrètement dans la gestion de votre ERP.
1. Gestion du risque TIC (articles 5 à 16)
Le conseil d’administration de l’entité financière est personnellement responsable de l’approbation et du suivi du cadre de gestion du risque TIC (article 5). Ce n’est pas un sujet délégable au seul RSSI. Pour l’ERP, cela signifie :
- Identifier les processus métiers critiques qui dépendent de l’ERP (clôture comptable, reporting réglementaire, traitement des paiements).
- Cartographier les actifs TIC associés à ces processus.
- Définir des objectifs de RTO (Recovery Time Objective) et RPO (Recovery Point Objective) formellement documentés.
- Tester la continuité au minimum annuellement.
2. Gestion des incidents TIC (articles 17 à 23)
DORA impose un régime de notification harmonisé pour les incidents TIC majeurs. Les délais sont stricts : notification initiale à l’autorité compétente dans les 4 heures suivant la classification de l’incident (et au plus tard 24 heures après la détection), rapport intermédiaire à 72 heures, rapport final dans le mois suivant.
Un incident sur votre ERP comptable ou votre module de paiement peut déclencher cette obligation. Avez-vous un processus de classification des incidents TIC qui distingue les événements mineurs des incidents majeurs au sens de DORA ? La plupart des établissements réalisent en 2026 qu’ils n’ont pas de critères formalisés.
Les seuils de classification incluent notamment une interruption de service supérieure à 2 heures, un impact sur plus de 10 % des clients, ou une perte économique supérieure à 100 000 euros.
3. Tests de résilience opérationnelle (articles 24 à 27)
Toutes les entités doivent conduire des tests de résilience au minimum une fois par an. Pour les entités significatives (établissements systémiques identifiés par l’EBA ou l’ESMA), des tests d’intrusion pilotés par la menace (TLPT, Threat-Led Penetration Testing) sont obligatoires tous les trois ans.
Un TLPT est un exercice de red team simulant une attaque réaliste sur des systèmes en production. Si votre ERP fait partie du périmètre systémique, il peut être inclus dans ce test. Anticipez ce point avec votre éditeur : a-t-il déjà participé à un TLPT pour un client financier ? Dispose-t-il d’une documentation sécurité accessible à un prestataire de test mandaté ?
4. Gestion du risque lié aux tiers TIC (articles 28 à 44)
C’est le pilier le plus opérationnel pour un DSI. Il impose :
- Un registre ICT (Register of Information) documentant tous les contrats avec des prestataires TIC, avec une granularité sur les sous-traitants. Ce registre est transmis annuellement aux autorités de supervision.
- Des clauses contractuelles obligatoires (article 30) pour tous les prestataires TIC, renforcées pour les fonctions critiques.
5. Partage d’informations sur les menaces (article 45)
Le partage est volontaire, mais DORA encourage les entités financières à rejoindre des groupes sectoriels d’échange sur les menaces (ISAC). En France, le secteur financier dispose de structures dédiées. C’est un signal de maturité de plus en plus scruté lors des audits.
Ce que vous devez exiger de votre éditeur ERP dans le contrat (clauses article 30)
L’article 30 de DORA liste les clauses obligatoires dans tout contrat avec un prestataire TIC supportant des fonctions critiques ou importantes. Si votre contrat actuel ne les contient pas, vous devez négocier un avenant.
Droit d’audit complet. Votre établissement doit disposer d’un droit d’audit direct sur les locaux, systèmes et processus de votre éditeur ERP, ou via un tiers indépendant mandaté par vous. Un simple rapport SOC 2 fourni par l’éditeur ne suffit pas : le droit à l’audit actif est requis.
SLA de disponibilité avec RTO/RPO contractuels. Les niveaux de service doivent inclure des objectifs de reprise formellement définis. Un contrat qui promet « 99,9 % de disponibilité » sans définir de RTO ni de RPO en cas d’incident majeur n’est pas conforme.
Notification d’incident dans les 4 heures. Si votre éditeur ERP subit un incident qui impacte votre service, il doit vous notifier dans un délai compatible avec votre propre obligation de notification au régulateur (4 heures). Cette clause doit figurer explicitement dans le contrat, avec les canaux de notification désignés.
Plan de sortie (exit plan) documenté. En cas de résiliation ou de défaillance de l’éditeur, vous devez pouvoir migrer vos données dans un délai raisonnable. Le contrat doit préciser la durée pendant laquelle les données restent accessibles, le format d’export, et le délai de migration garanti.
Transparence sur la sous-traitance. Votre éditeur doit vous communiquer la liste de ses sous-traitants critiques et vous notifier de toute modification matérielle. Un changement d’hébergeur (passage d’AWS à Azure, par exemple) doit vous être signalé avant la mise en production.
ERP cloud et DORA : les risques spécifiques à surveiller
Concentration sur 3 hyperscalers : un risque systémique reconnu
La quasi-totalité des ERP SaaS du marché (SAP, Oracle, Microsoft, Sage, Workday) s’appuient sur AWS, Azure ou GCP. DORA reconnaît explicitement ce risque de concentration systémique. Les régulateurs s’inquiètent d’un scénario où une panne majeure d’un hyperscaler affecterait simultanément des dizaines d’établissements financiers.
Pour votre établissement, cela signifie documenter cette dépendance dans votre registre ICT et réfléchir à des plans de mitigation (redondance multi-cloud, plans de continuité d’activité testés).
Multi-tenancy : votre disponibilité dépend d’autres clients
Un ERP SaaS multi-tenant signifie que vous partagez des ressources avec d’autres clients de l’éditeur. Un incident sur le tenant d’un autre client (attaque DDoS massive, bug applicatif, configuration erronée) peut impacter votre disponibilité. Demandez à votre éditeur comment les tenants sont isolés et quelle est sa politique d’isolation des incidents.
Localisation des données : la question de la souveraineté
L’article 30(2)(j) de DORA exige que les contrats spécifient les pays où les données seront traitées et stockées. Pour un établissement financier français soumis à la supervision de l’ACPR, les données de reporting prudentiel hébergées hors UE posent des questions de souveraineté et de droit d’accès des autorités.
Vérifiez dans votre contrat ERP que la localisation des données est explicitement définie et que le traitement en dehors de l’UE (pour des opérations de support ou de maintenance) est encadré par des garanties contractuelles appropriées.
Plan d’action en 6 étapes pour la mise en conformité DORA de votre ERP
Étape 1 : Cartographier les services TIC critiques. Identifiez si votre ERP supporte des fonctions critiques ou importantes au sens de DORA. Documentez les processus métiers dépendants, les actifs TIC associés, et les niveaux de service cibles (RTO/RPO).
Étape 2 : Évaluer votre registre ICT et vos contrats existants. Construisez ou mettez à jour votre Register of Information. Auditez vos contrats ERP pour identifier les clauses manquantes au regard de l’article 30.
Étape 3 : Négocier les avenants contractuels avec votre éditeur. Présentez à votre éditeur la liste des clauses manquantes. Les grands éditeurs (SAP, Oracle, Microsoft, Sage) ont adapté leurs contrats standard en 2024-2025, mais les versions antérieures nécessitent souvent des avenants spécifiques.
Étape 4 : Mettre en place les tests de résilience sur le périmètre ERP. Planifiez des tests de continuité annuels incluant l’ERP. Si vous êtes une entité significative, évaluez l’inclusion de l’ERP dans votre programme TLPT.
Étape 5 : Documenter les processus de gestion d’incidents TIC. Formalisez vos critères de classification des incidents TIC, vos chaînes de notification (interne et vers l’ACPR/AMF), et vos procédures de reporting.
Étape 6 : Préparer votre rapport DORA pour l’autorité de supervision. L’ACPR et l’AMF demandent des éléments d’avancement sur la conformité DORA. Préparez un dossier qui documente votre registre ICT, vos résultats de tests, et votre plan de mise à niveau contractuelle.
Tableau de bord DORA ERP : les indicateurs à suivre en 2026
Quelques indicateurs à instrumenter dans votre tableau de bord DSI :
- Taux de couverture du registre ICT : pourcentage de contrats TIC actifs documentés dans le Register of Information, avec granularité sur les sous-traitants.
- Couverture contractuelle article 30 : pourcentage des contrats TIC critiques mis à jour avec les clauses obligatoires.
- RTO/RPO définis et testés : pour chaque fonction critique supportée par l’ERP.
- Délai moyen de notification interne : temps entre la détection d’un incident TIC et sa classification, pour vérifier que vous pouvez respecter le délai de 4 heures vers le régulateur.
- Date du dernier test de résilience ERP et résultats.
DORA n’est pas une réglementation supplémentaire à cocher sur une liste de conformité. C’est un signal clair des régulateurs européens : la résilience opérationnelle numérique du secteur financier ne peut plus reposer sur des engagements verbaux d’éditeurs. Elle doit être contractualisée, testée et documentée.
Pour approfondir la dimension réglementaire de votre SI financier, consultez également notre guide sur la directive NIS2 et les obligations ERP pour les ETI, notre article sur le PRA/PCA et la continuité du SI critique, et notre analyse sur l’archivage et la rétention des données ERP face aux obligations légales.
