DORA : réussir la conformité opérationnelle en banque et assurance
Depuis le 17 janvier 2025, DORA n’est plus un sujet de veille pour les acteurs financiers européens. Le règlement sur la résilience opérationnelle numérique impose une approche plus structurée des risques ICT, des incidents, des tests de résilience et de la dépendance aux prestataires technologiques.
Pour une banque, un assureur, une mutuelle, une institution de prévoyance, une fintech ou un acteur du courtage, le sujet n’est pas seulement de “respecter DORA”. Le vrai enjeu est de transformer une obligation réglementaire en dispositif pilotable : savoir quels services sont critiques, quelles preuves doivent exister, quels prestataires concentrent le risque, quelles équipes doivent être mobilisées et quelles actions produisent un effet concret sur la résilience.
La difficulté vient souvent du décalage entre l’ambition du texte et la réalité des organisations. Les cartographies ne sont pas toujours à jour, les contrats ICT n’ont pas tous le même niveau de détail, les processus incidents sont dispersés, les tests ne couvrent pas toujours les fonctions critiques, et les preuves sont parfois difficiles à reconstituer au moment du contrôle.
La bonne trajectoire n’est donc pas de lancer un programme DORA abstrait et coûteux. Elle consiste à prioriser ce qui protège vraiment l’activité, ce qui répond aux attentes de supervision, et ce qui peut être documenté sans paralyser les équipes.
Pourquoi DORA change la donne pour les acteurs financiers
DORA, pour Digital Operational Resilience Act, vise à renforcer la capacité du secteur financier européen à résister aux perturbations numériques sévères. Les autorités européennes rappellent que le secteur dépend de plus en plus des systèmes ICT et de prestataires technologiques externes. Quand ces dépendances sont mal maîtrisées, un incident technique peut rapidement devenir un incident opérationnel, commercial, réglementaire et réputationnel.
Avant DORA, les exigences de résilience numérique existaient déjà sous plusieurs formes : cybersécurité, continuité d’activité, gestion des risques, externalisation, contrôle interne, conformité, exigences sectorielles. DORA rassemble et harmonise ces attentes pour les entités financières concernées.
Concrètement, une organisation doit être capable de montrer :
- comment elle identifie et pilote ses risques ICT ;
- comment elle détecte, classe et remonte les incidents majeurs ;
- comment elle teste sa résilience opérationnelle numérique ;
- comment elle encadre les prestataires ICT qui soutiennent des fonctions critiques ou importantes ;
- comment elle documente les décisions, les contrôles, les remédiations et les responsabilités.
Le changement est important pour les directions métiers, car DORA ne peut pas rester un sujet DSI ou cyber. Les fonctions critiques se trouvent dans les parcours clients, les opérations, la gestion de contrats, les paiements, l’indemnisation, la conformité, les reportings, les plateformes de distribution, les outils de scoring, les flux de données et les prestataires qui les soutiennent.
Les cinq chantiers DORA à traiter en priorité
1. Cartographier les services critiques et les dépendances ICT
La première erreur consiste à partir des outils. Il faut partir de l’activité.
Quels services doivent continuer à fonctionner pour protéger les clients, respecter les obligations réglementaires et maintenir l’exploitation ? Quels processus sont critiques ? Quelles applications, données, interfaces, équipes et prestataires soutiennent ces processus ? Quels scénarios d’incident auraient un impact majeur ?
Cette cartographie doit relier trois niveaux :
- les services ou processus métiers critiques ;
- les actifs ICT et flux de données qui les supportent ;
- les tiers, sous-traitants et chaînes de dépendance qui peuvent affecter leur disponibilité, leur intégrité ou leur confidentialité.
Pour une banque de détail, cela peut concerner les paiements, l’espace client, l’octroi de crédit, les contrôles LCB-FT, la gestion des réclamations ou les reportings réglementaires. Pour un assureur, cela peut concerner la souscription, la gestion des sinistres, l’encaissement des primes, les réseaux de distribution, la relation courtier, l’actuariat, la gestion des contrats ou les plateformes de gestion déléguée.
La sortie attendue n’est pas une cartographie parfaite. C’est une cartographie exploitable, maintenue, reliée aux contrôles et utilisable en comité.
2. Structurer la gestion des risques ICT
Le risque ICT doit être traité comme un risque opérationnel majeur, pas comme une liste de vulnérabilités techniques.
Un dispositif utile doit préciser :
- les rôles et responsabilités entre métiers, risques, conformité, DSI, cyber, achats et juridique ;
- la méthode d’identification, d’évaluation et de priorisation des risques ICT ;
- les contrôles attendus sur les actifs critiques ;
- les plans de remédiation et leur suivi ;
- les critères d’escalade vers la gouvernance ;
- les preuves disponibles en cas de contrôle.
La valeur se crée quand les risques deviennent arbitrables. Une direction générale ou un comité des risques ne peut pas piloter DORA si les sujets remontent sous forme de tickets techniques isolés. Il faut transformer les constats en décisions : risque accepté, risque réduit, dépendance à diversifier, contrat à renforcer, test à planifier, remédiation à financer.
3. Industrialiser la gestion des incidents ICT
DORA renforce l’attention portée aux incidents liés aux technologies de l’information et de la communication. La difficulté n’est pas seulement de déclarer un incident majeur. Elle est de disposer, avant l’incident, d’un processus clair de détection, qualification, escalade, décision, communication, remédiation et retour d’expérience.
Un dispositif mature doit répondre à des questions simples :
- qui détecte l’incident ?
- qui qualifie son impact métier et réglementaire ?
- qui décide s’il est majeur ?
- qui consolide les informations nécessaires ?
- qui communique aux parties prenantes internes et externes ?
- qui suit les actions de remédiation ?
- où sont stockées les preuves ?
Les organisations les plus avancées alignent les processus incidents cyber, IT, opérations, conformité, risque opérationnel, relation client et communication. Sans cet alignement, l’incident est traité plusieurs fois, avec des informations incohérentes et un risque de retard.
4. Encadrer les prestataires ICT critiques
Les dépendances aux prestataires ICT sont au cœur de DORA. Le sujet ne concerne pas seulement les grands fournisseurs cloud. Il peut aussi toucher des éditeurs SaaS, infogérants, plateformes de relation client, prestataires data, outils de signature, solutions de paiement, fournisseurs de reporting, outils de gestion de sinistres, solutions de courtage ou prestataires de cybersécurité.
Le travail prioritaire consiste à identifier les prestataires qui soutiennent des fonctions critiques ou importantes, puis à vérifier que les contrats, les contrôles et les processus de suivi couvrent les points essentiels :
- description des services fournis ;
- niveaux de service attendus ;
- sécurité, continuité, audit et accès aux informations ;
- sous-traitance et chaîne de dépendance ;
- localisation, disponibilité et restitution des données ;
- obligations de notification ;
- clauses de sortie et réversibilité.
Pour éviter l’effet tunnel, il faut prioriser les contrats qui portent le plus de risque. Un inventaire exhaustif est utile, mais le premier impact business vient souvent de 10 à 30 prestataires vraiment critiques.
5. Tester la résilience et documenter les preuves
Une organisation peut avoir de bons processus sur le papier et rester fragile en situation réelle. Les tests permettent de vérifier si les dispositifs fonctionnent : reprise d’activité, restauration, bascule, gestion de crise, réaction d’un prestataire, cyberattaque simulée, rupture de flux, indisponibilité applicative, incident data, défaillance d’un fournisseur.
Le niveau de test doit être proportionné à la criticité. L’objectif n’est pas de multiplier les exercices artificiels. Il est de prouver que les services critiques peuvent résister, répondre et se rétablir dans des conditions acceptables.
Chaque test doit produire une trace exploitable :
- scénario testé ;
- périmètre concerné ;
- participants ;
- résultats observés ;
- écarts constatés ;
- décisions prises ;
- actions de remédiation ;
- responsable et échéance ;
- preuve de clôture.
Sans preuve, l’effort existe peut-être, mais il devient difficile à démontrer.
Comment respecter DORA sans exploser le budget
Le piège classique est de transformer DORA en programme transversal sans priorisation. Tout devient important, donc plus rien n’avance assez vite.
Une trajectoire plus efficace repose sur trois principes.
Premier principe : partir des fonctions critiques. Les sujets doivent être classés selon leur impact sur les clients, la continuité d’activité, les obligations réglementaires, la réputation et les pertes potentielles. Une application secondaire et un processus de paiement critique ne doivent pas recevoir le même niveau d’effort.
Deuxième principe : réutiliser l’existant. Beaucoup d’éléments existent déjà dans les organisations : cartographies applicatives, plans de continuité, registres fournisseurs, politiques cyber, contrôles de risque opérationnel, processus incidents, comités, audits internes, documentation achats. DORA exige souvent de relier, renforcer et prouver, plus que de repartir de zéro.
Troisième principe : produire des livrables actionnables. Une politique de 80 pages n’aide pas si les équipes ne savent pas quoi faire. Il vaut mieux disposer d’un registre de dépendances critiques à jour, d’une matrice de responsabilités claire, d’un processus incident testé et d’un tableau de bord de remédiation suivi.
Feuille de route DORA en 90 jours
Jours 1 à 30 : cadrer et objectiver
La première phase doit sortir du flou.
Actions prioritaires :
- confirmer le périmètre des entités, activités et fonctions concernées ;
- identifier les services critiques ou importants ;
- collecter les cartographies existantes ;
- lister les prestataires ICT qui soutiennent ces services ;
- recenser les incidents, audits, contrôles et plans d’action déjà connus ;
- évaluer la maturité actuelle par chantier DORA ;
- construire une première matrice risques / impacts / efforts.
Livrable attendu : une vue de pilotage simple qui distingue les risques critiques, les quick wins, les dépendances majeures et les arbitrages à porter en comité.
Jours 31 à 60 : prioriser et combler les écarts critiques
La deuxième phase doit réduire les risques les plus visibles.
Actions prioritaires :
- formaliser les rôles et responsabilités DORA ;
- renforcer les processus incidents ICT ;
- prioriser les contrats et prestataires ICT critiques ;
- lancer les revues contractuelles à fort enjeu ;
- définir le plan de tests de résilience ;
- aligner les preuves disponibles avec les attentes de contrôle ;
- installer un suivi des remédiations.
Livrable attendu : un plan d’action validé, financé et suivi, avec responsables, échéances, preuves attendues et risques résiduels.
Jours 61 à 90 : industrialiser le pilotage
La troisième phase doit rendre le dispositif durable.
Actions prioritaires :
- mettre en place un tableau de bord DORA ;
- intégrer les contrôles dans les routines risques, cyber, achats et conformité ;
- tester un scénario d’incident ou de défaillance fournisseur ;
- produire un retour d’expérience ;
- clôturer ou replanifier les remédiations ;
- préparer les éléments de preuve pour audit ou supervision ;
- définir le cycle de revue régulier.
Livrable attendu : un dispositif qui ne dépend pas d’un seul projet, mais d’une gouvernance récurrente.
Adapter DORA aux métiers banque, assurance, courtage et fintech
DORA est un cadre commun, mais les priorités changent selon le modèle d’activité.
Dans la banque, les points sensibles portent souvent sur la disponibilité des services digitaux, les paiements, les parcours d’octroi, les contrôles réglementaires, les flux de données, les outils de conformité et les dépendances à des prestataires critiques.
Dans l’assurance, la priorité peut se concentrer sur la souscription, la gestion des contrats, les sinistres, les réseaux de distribution, les plateformes de gestion déléguée, les données sensibles, l’actuariat, la relation client et les interfaces partenaires.
Dans le courtage, la question centrale est souvent la maîtrise d’un écosystème composé de plateformes, assureurs, outils CRM, solutions de signature, prestataires de gestion et flux d’échange.
Dans les fintechs, le défi est de concilier vitesse d’exécution, croissance produit, dépendance cloud ou SaaS, exigences réglementaires et preuves de contrôle.
La méthode doit donc rester commune, mais les exemples, les tests, les contrats prioritaires et les indicateurs doivent être adaptés au métier.
Quand mobiliser un consultant DORA
Un consultant externe peut être utile quand l’organisation manque de bande passante, de méthode ou de recul. Il ne remplace pas les responsables internes, mais il accélère le cadrage, la coordination et la production des livrables.
Les cas d’usage les plus fréquents sont :
- diagnostic de maturité DORA ;
- cartographie des fonctions critiques et dépendances ICT ;
- structuration du plan de remédiation ;
- revue des processus incidents ;
- coordination entre DSI, risques, conformité, achats et métiers ;
- préparation d’un comité de pilotage ;
- revue de prestataires ICT critiques ;
- documentation des preuves ;
- pilotage PMO d’un programme DORA ;
- appui à un audit interne ou contrôle de supervision.
Babylone Consulting accompagne les acteurs banque, assurance et services financiers en mobilisant des consultants indépendants expérimentés sur les sujets risques, conformité, transformation, opérations, IT, data, achats et contrôle interne.
Contacter Babylone Consulting pour cadrer une mission DORA
Consulter les missions ouvertes
FAQ DORA
DORA s’applique-t-il déjà aux acteurs financiers ?
Oui. DORA est entré en application le 17 janvier 2025. Les entités concernées doivent donc traiter le sujet comme un dispositif opérationnel actif, pas comme un projet futur.
DORA concerne-t-il seulement la DSI ?
Non. La DSI et les équipes cyber sont essentielles, mais DORA touche aussi les métiers, les risques, la conformité, le contrôle interne, les achats, le juridique, la gestion des prestataires, la relation client et la direction générale. La résilience opérationnelle numérique dépend de toute la chaîne.
Quelle est la priorité si tout n’est pas prêt ?
La priorité est d’identifier les fonctions critiques, les dépendances ICT majeures, les prestataires à risque, les processus incidents et les preuves manquantes. Il faut ensuite traiter les écarts selon leur impact business et réglementaire, plutôt que lancer des actions uniformes partout.
Faut-il créer une page DORA par métier ?
Pas en première intention. Pour le SEO et pour l’utilisateur, une page maître claire est préférable. Des articles satellites peuvent ensuite traiter des angles plus précis : DORA assurance, DORA banque, prestataires ICT critiques, incidents, tests de résilience, budget, gouvernance ou feuille de route.
DORA impose-t-il de changer tous les contrats ICT ?
Pas mécaniquement. Le bon réflexe consiste à prioriser les contrats qui soutiennent des fonctions critiques ou importantes, puis à vérifier les clauses, les niveaux de service, les obligations de notification, les droits d’audit, la sous-traitance, la réversibilité et les preuves disponibles.
Comment éviter un programme DORA trop lourd ?
En partant des risques réels, en réutilisant les dispositifs existants, en limitant les premiers lots aux services et prestataires critiques, et en produisant des livrables utiles aux équipes : cartographie, matrice de responsabilités, processus incident, registre prestataires, plan de tests, suivi des remédiations.