Votre ERP gère la comptabilité, les paiements fournisseurs, le reporting réglementaire et la paie. Si ce système tombe, votre entreprise ne ralentit pas — elle s’arrête. C’est exactement le scénario que le règlement DORA (Digital Operational Resilience Act) vise à prévenir dans le secteur financier européen. Depuis le 17 janvier 2025, cette réglementation impose aux entités financières et à leurs prestataires TIC critiques un cadre de résilience opérationnelle numérique sans précédent.
Le problème : la plupart des DSI et RSSI du secteur financier savent que DORA existe, mais peu ont cartographié précisément ce que le règlement change dans la gestion, le contrat et les tests de leur ERP. Ce guide comble ce manque.
L’essentiel en 30 secondes
- DORA (règlement UE 2022/2554) s’applique depuis le 17 janvier 2025 à 20 types d’entités financières et à leurs prestataires TIC.
- L’ERP est presque toujours classé « système critique » car il porte la comptabilité, les paiements et le reporting réglementaire.
- Sanctions : jusqu’à 2 % du CA annuel mondial pour les entités financières, amendes journalières jusqu’à 1 % du CA quotidien mondial pendant 6 mois (Avenga).
- SAP a été officiellement désigné « prestataire TIC tiers critique » par les autorités européennes de surveillance (SAP).
- DORA complète NIS2, il ne la remplace pas : les deux s’appliquent, avec des périmètres et des autorités de contrôle distincts.
DORA en 3 minutes : ce que dit le règlement européen de résilience numérique
Contexte : pourquoi l’UE impose DORA
Le 19 juillet 2024, une mise à jour de CrowdStrike Falcon a provoqué la plus grande panne informatique de l’histoire récente. Des banques comme Bank of America, Chase, Capital One et Wells Fargo ont vu leurs systèmes de paiement interrompus. Les pertes estimées pour les 500 plus grandes entreprises américaines : plus de 5,4 milliards de dollars (Wikipedia). Les entités financières les plus touchées étaient celles les moins matures sur la gestion des risques tiers — précisément le sujet de DORA.
Ce n’est pas un cas isolé. Les cyberattaques sur le secteur financier se multiplient : ransomwares ciblant les systèmes bancaires, compromission de chaînes d’approvisionnement logicielles, vol de données sensibles. L’UE a tiré les leçons de ces incidents pour imposer un cadre harmonisé à l’ensemble du secteur financier.
Périmètre : qui est concerné ?
DORA s’applique à 20 types d’entités financières :
- Établissements de crédit (banques, sociétés de financement)
- Entreprises d’investissement et sociétés de gestion
- Compagnies d’assurance et de réassurance
- Institutions de paiement et de monnaie électronique
- Prestataires de services crypto-actifs
- Dépositaires centraux de titres et plateformes de négociation
- Fonds de pension professionnels
Et surtout : leurs prestataires TIC tiers critiques — éditeurs d’ERP, hébergeurs cloud, fournisseurs d’infrastructure. Le registre DORA, devenu obligatoire en 2025, couvre près de 22 000 entités financières dans l’UE (SBS Software).
Calendrier : application depuis janvier 2025, contrôles renforcés 2026
- 14 décembre 2022 : adoption du règlement UE 2022/2554
- 17 janvier 2025 : entrée en application
- 17 janvier 2026 : la Commission européenne procède à une revue du dispositif et soumet un rapport au Parlement et au Conseil (EUR-Lex)
- 2026-2027 : montée en puissance des contrôles par les autorités européennes de surveillance (ABE, AEAPP, AEMF)
Le premier cycle de tests TLPT (Threat-Led Penetration Testing) est en cours. Les entités financières significatives doivent réaliser un TLPT au moins tous les 3 ans (EBA).
Les 5 piliers de DORA et leur impact sur l’ERP
DORA s’articule autour de 5 piliers qui structurent l’ensemble des obligations. Chacun a des implications directes sur votre ERP.
Pilier 1 — Gestion des risques TIC : cartographier les dépendances ERP
L’article 8 de DORA exige l’identification et la documentation de toutes les « fonctions critiques ou importantes ». L’ERP entre presque toujours dans cette catégorie : il porte la comptabilité générale et analytique, le cycle fournisseur (commandes, réceptions, factures, paiements), le reporting réglementaire et souvent la paie.
Ce que cela change concrètement :
- Dresser la carte complète des dépendances de l’ERP : serveurs, bases de données, middleware, connecteurs bancaires, interfaces avec les systèmes de trading ou de gestion d’actifs
- Documenter les scénarios de panne : que se passe-t-il si le serveur ERP tombe ? Si la base de données est corrompue ? Si le lien avec la passerelle de paiement est coupé ?
- Maintenir un registre TIC actualisé, transmissible aux autorités de contrôle
Pilier 2 — Classification et signalement des incidents : intégrer l’ERP dans le processus de notification
DORA impose un processus de détection, classification et signalement des incidents TIC majeurs aux autorités compétentes. Si votre ERP subit un incident qui affecte la continuité d’un service financier — par exemple, l’impossibilité de générer les états réglementaires ou de traiter les paiements — cet incident doit être classifié et, selon sa gravité, notifié aux autorités.
Implications ERP :
- Intégrer la supervision ERP dans le SIEM (Security Information and Event Management) de l’entreprise
- Définir des seuils d’alerte spécifiques à l’ERP : temps d’arrêt, nombre de transactions bloquées, perte de données
- Documenter la procédure de notification : qui signale, dans quel délai, à quelle autorité
Pilier 3 — Tests de résilience opérationnelle : tester le basculement ERP (PRA/PCA)
C’est le pilier qui change le plus la donne pour les équipes ERP. DORA impose des tests de résilience réguliers, à deux niveaux :
- Tests de base : tests de vulnérabilité, tests de performance, tests de basculement vers l’environnement de secours (PRA/PCA), tests de restauration des sauvegardes
- Tests avancés (TLPT) : pour les entités significatives, des tests de pénétration pilotés par la menace, menés par des équipes spécialisées simulant des attaques réelles sur les systèmes critiques — y compris l’ERP
Le TLPT sous DORA se distingue du pentest classique : il couvre l’ensemble de l’organisation, pas un périmètre isolé. Il peut durer 3 à 4 mois et inclut un exercice de « purple teaming » obligatoire où l’équipe d’attaque collabore ensuite avec l’équipe de défense (Blaze InfoSec).
Pour l’ERP, cela signifie :
- Simuler une panne complète du système ERP et mesurer le temps de basculement vers le PRA
- Tester la restauration d’une sauvegarde ERP en conditions réelles (pas sur papier)
- Vérifier que les interfaces critiques (banque, reporting, paie) se reconnectent correctement après un basculement
Pilier 4 — Gestion des risques liés aux tiers TIC : votre éditeur ERP est-il un prestataire critique ?
C’est le pilier le plus transformant pour la relation entre l’entreprise et son éditeur ERP. DORA exige une évaluation formelle de chaque prestataire TIC avant la signature du contrat, un suivi continu des risques, et des clauses contractuelles spécifiques (audit, portabilité, plan de sortie).
Les autorités européennes de surveillance (ESA) ont le pouvoir de désigner directement les prestataires TIC « critiques » et de les soumettre à une supervision directe. SAP a déjà reçu cette désignation officielle (SAP). D’autres éditeurs majeurs d’ERP suivront probablement.
Ce que cela implique :
- Vérifier si votre éditeur ERP figure sur la liste des prestataires critiques désignés par les ESA
- Auditer les clauses de votre contrat ERP : SLA, droit d’audit, portabilité des données, plan de sortie (exit strategy)
- S’assurer que l’éditeur peut vous fournir les preuves de conformité DORA demandées par les régulateurs
Pilier 5 — Partage d’informations : les données ERP dans les échanges sectoriels
DORA encourage (sans l’imposer strictement) le partage d’informations sur les cybermenaces entre entités financières. Si votre ERP détecte une tentative d’intrusion via une vulnérabilité connue d’un connecteur tiers, cette information peut être partagée avec d’autres acteurs du secteur pour prévenir des attaques similaires.
En pratique, cela nécessite de cloisonner les informations partagées pour ne pas exposer de données métier sensibles — un travail d’architecture qui touche directement la couche ERP.
Checklist DORA pour votre ERP
10 questions à poser à votre éditeur ou hébergeur ERP
- Disposez-vous d’un plan de continuité d’activité (PCA) documenté et testé pour votre plateforme ERP ?
- Quel est votre RTO (Recovery Time Objective) et RPO (Recovery Point Objective) contractuel ?
- Vos datacenters sont-ils situés dans l’UE ? Si non, quelles garanties de souveraineté offrez-vous ?
- Avez-vous été désigné « prestataire TIC tiers critique » par les ESA ? Si oui, sous quelle supervision ?
- Accordez-vous un droit d’audit DORA à vos clients financiers ? Sous quelles conditions ?
- Comment assurez-vous la portabilité des données en cas de résiliation ou de défaillance ?
- Quel est votre processus de notification d’incidents TIC majeurs ?
- Vos sous-traitants (hébergeur cloud, fournisseur de base de données) sont-ils identifiés et documentés dans votre registre TIC ?
- Quelles certifications de sécurité détenez-vous (ISO 27001, SOC 2, C5) ?
- Pouvez-vous fournir les preuves de conformité demandées par les régulateurs financiers dans un délai compatible avec les obligations de reporting DORA ?
Clauses contractuelles à renégocier
DORA impose des exigences contractuelles précises pour les accords avec les prestataires TIC. Pour votre contrat ERP, vérifiez :
- SLA de disponibilité : un SLA de 99,5 % laisse 43 heures d’indisponibilité par an. Pour un ERP financier critique, visez 99,9 % minimum
- Droit d’audit : le contrat doit prévoir un accès raisonnable aux locaux et systèmes du prestataire pour audit — y compris par les régulateurs
- Portabilité et exit plan : clause de réversibilité détaillée, formats de données standards, délai de restitution, accompagnement à la migration
- Notification d’incidents : délai de notification contractuel (DORA impose un signalement initial « sans retard indu »), contenu minimal du rapport
- Sous-traitance en chaîne : droit de veto ou d’information sur les sous-traitants critiques de votre éditeur
Plan de test de résilience ERP
Un plan de test conforme à DORA pour l’ERP doit couvrir au minimum :
Tests annuels :
- Basculement vers l’environnement de secours (PRA) avec chronométrage du RTO réel
- Restauration d’une sauvegarde complète de la base de données ERP
- Test de reconnexion des interfaces critiques (banque, reporting réglementaire, paie)
- Test de charge en conditions dégradées (un noeud serveur en moins)
Tests tous les 3 ans (TLPT pour entités significatives) :
- Simulation d’attaque ciblée sur le système ERP par une équipe red team externe
- Purple teaming obligatoire : restitution conjointe avec l’équipe de défense
- Documentation complète des vulnérabilités découvertes et plan de remédiation
ERP cloud vs on-premise face à DORA : avantages et risques
Cloud public : concentration du risque tiers mais meilleure résilience infra
Déployer un ERP sur un cloud hyperscaler (AWS, Azure, Google Cloud, OCI) offre des avantages structurels pour la résilience : redondance multi-zones, basculement automatique, SLA élevés, certifications de sécurité (ISO 27001, SOC 2, C5 pour l’Allemagne). Oracle publie des guides de conformité DORA spécifiques pour OCI (Oracle).
Mais le cloud concentre le risque tiers : si votre ERP tourne sur Azure et que Microsoft subit un incident majeur (scénario CrowdStrike), votre PCA dépend de la résilience de Microsoft, pas de la vôtre. DORA l’a compris : le règlement impose que l’entité financière reste « pleinement responsable » de sa résilience, même quand elle externalise.
En pratique : un ERP cloud simplifie la conformité DORA sur l’infrastructure, mais complexifie la gestion du risque de concentration tiers. Les régulateurs attendront une analyse de ce risque de concentration et un plan de sortie crédible.
On-premise : maîtrise totale mais responsabilité PCA/PRA plus lourde
Un ERP on-premise donne une maîtrise totale sur l’infrastructure. Pas de dépendance à un hyperscaler, pas de risque de concentration tiers au niveau de l’hébergement. En revanche, la responsabilité du PCA/PRA repose entièrement sur l’entreprise : datacenter de secours, réplication des données, tests de basculement, mise à jour des patchs de sécurité.
Pour une banque régionale ou un assureur de taille intermédiaire, cette responsabilité a un coût significatif en compétences internes et en infrastructure.
Modèle hybride : le compromis le plus fréquent
La majorité des entités financières retiennent un modèle hybride : ERP principal en cloud privé ou public, avec un site de secours distinct (autre datacenter, autre cloud provider). Ce modèle permet de bénéficier de la résilience du cloud tout en limitant le risque de concentration.
DORA n’impose pas de modèle de déploiement. Le règlement exige des résultats (continuité de service, temps de reprise, tests prouvés) — pas des choix techniques. Le DSI reste libre de son architecture, mais il doit prouver qu’elle tient.
Comment les principaux ERP se positionnent face à DORA
SAP : prestataire TIC critique désigné
SAP est le premier grand éditeur d’ERP à avoir été officiellement désigné « prestataire TIC tiers critique » (CTPP) par les autorités européennes de surveillance (SAP). Cette désignation signifie que SAP est soumis à une supervision directe des ESA et doit répondre aux standards les plus élevés de sécurité, de continuité et de conformité.
Pour les clients SAP du secteur financier, cette désignation est une garantie : SAP ne peut pas se soustraire aux exigences DORA. En contrepartie, les audits de conformité seront plus fréquents et les exigences contractuelles plus strictes.
SAP propose des outils de support à la conformité DORA, notamment via SAP LeanIX pour la cartographie des applications et des dépendances TIC (SAP LeanIX).
Oracle : guides de conformité OCI et clauses DORA
Oracle a publié des guides de conformité DORA pour Oracle Cloud Infrastructure (OCI), détaillant comment les fonctionnalités d’Exadata et Recovery Appliance s’alignent sur les articles 7 à 12 de DORA. Oracle met en avant la résilience intégrée de ses appliances (basculement automatique, chiffrement, isolation) et des provisions contractuelles spécifiques pour la portabilité et les exit strategies (Oracle).
Oracle propose également une checklist contractuelle DORA spécifique pour NetSuite, son ERP cloud PME, qui couvre les exigences de l’article 30 sur les arrangements contractuels.
Sage, Cegid, Odoo : où en sont les éditeurs européens ?
Les éditeurs européens de taille intermédiaire n’ont pas encore fait l’objet d’une désignation CTPP par les ESA. Leur exposition à DORA dépend du nombre de clients financiers qu’ils servent et de leur classification par les régulateurs nationaux.
Pour ces éditeurs, la question DORA se pose à deux niveaux :
- Comme prestataire TIC : si un client du secteur financier utilise Sage ou Cegid pour sa comptabilité, l’éditeur doit être en mesure de répondre aux exigences contractuelles DORA (SLA, audit, portabilité, notification d’incidents)
- Comme entreprise : si l’éditeur traite lui-même des données financières ou fournit des services de paiement, il peut être directement soumis à DORA
Le niveau de maturité varie. Les grands éditeurs européens (Sage, Cegid) disposent généralement de certifications ISO 27001 et de PCA documentés. Les éditeurs plus petits (Odoo Community, Dolibarr) doivent être évalués au cas par cas — la certification et la documentation de conformité dépendent du partenaire d’hébergement et d’intégration, pas de l’éditeur open source.
DORA vs NIS2 : deux règlements, deux logiques
DORA et NIS2 s’appliquent en parallèle, mais avec des périmètres et des logiques différents :
| Critère | DORA | NIS2 |
|---|---|---|
| Règlement/Directive | Règlement (application directe) | Directive (transposition nationale) |
| Secteur | Financier exclusivement | 18 secteurs (énergie, santé, transport, numérique…) |
| Entités visées | Entités financières + prestataires TIC | Entités essentielles et importantes |
| Autorité de contrôle | ESA (ABE, AEAPP, AEMF) | ANSSI (France), BSI (Allemagne)… |
| Tests de pénétration | TLPT obligatoire (entités significatives) | Tests de sécurité mais pas de TLPT |
| Supervision des tiers | Supervision directe des CTPP | Responsabilité de l’entité |
Si votre entreprise est une banque ou un assureur, DORA prévaut sur NIS2 pour les aspects de résilience numérique (principe de lex specialis). Mais vous restez soumis à NIS2 pour les obligations qui ne sont pas couvertes par DORA.
Pour approfondir les obligations NIS2, consultez notre guide NIS2 et ERP pour les ETI.
Ce qu’il faut surveiller en 2026-2027
Le premier cycle de conformité DORA ne fait que commencer. Voici les échéances et les sujets à suivre :
- Revue de la Commission européenne (janvier 2026) : premier bilan d’application, possibles ajustements des normes techniques
- Désignation de nouveaux CTPP : après SAP, d’autres éditeurs d’ERP pourraient être désignés prestataires critiques par les ESA
- Montée en puissance des contrôles : les autorités de surveillance commencent à auditer les registres TIC et les plans de test de résilience
- Convergence DORA/NIS2 : les entreprises du secteur financier soumises aux deux textes devront rationaliser leurs dispositifs de conformité
- Tests TLPT : le premier cycle de tests avancés est en cours pour les entités significatives — les retours d’expérience alimenteront les bonnes pratiques du marché
Pour approfondir la sécurité de votre ERP, consultez notre guide cybersécurité ERP et notre analyse de la directive NIS2. Si vous évaluez un modèle cloud pour votre ERP financier, notre comparatif cloud vs on-premise détaille les arbitrages techniques et économiques.
