Conformité DORA, 20 mois après: un taux flatteur, une résilience encore à prouver

Depuis le 17 janvier 2025, le règlement DORA (Digital Operational Resilience Act) s’applique aux banques, aux assureurs et à l’ensemble des acteurs financiers européens. Vingt mois plus tard, la plupart des établissements affichent un taux de conformité DORA élevé. Ce chiffre rassure, mais il trompe : il accorde le même poids à chaque exigence. Une politique rédigée pèse autant qu’un plan de sortie testé sur un prestataire critique. Sur le terrain, le corpus documentaire est en place presque partout. Les difficultés se concentrent ailleurs : la cartographie des fonctions critiques, le pilotage des prestataires TIC, les tests de résilience et le maintien du dispositif une fois le programme clos. Cet article tire les leçons de DORA observées dans nos missions, puis s’arrête sur les deux zones où l’écart entre conformité déclarée et résilience réelle reste le plus net.

Pourquoi un taux de conformité DORA élevé ne suffit-il pas ?

Premier constat : les programmes DORA ont livré leur socle documentaire. Politiques, procédures, cadre de gestion du risque TIC, gouvernance : ces livrables existent et répondent à la lettre du texte. Calculé article par article, avec un poids identique pour chaque exigence, le taux de conformité atteint donc un niveau élevé.

Ce calcul masque l’essentiel. Les exigences les plus lourdes à exécuter (gestion du risque lié aux tiers, tests de pénétration fondés sur la menace, tests de résilience à l’échelle de l’établissement) pèsent autant dans la moyenne qu’une politique validée en comité. Or ce sont elles qui concentrent les retards.

Notre lecture : un taux unique ne suffit plus. Chaque exigence mérite deux mesures distinctes. La conformité réglementaire vérifie que le dispositif est formalisé. La conformité opérationnelle vérifie qu’il est exécuté et que l’établissement en conserve la preuve. C’est l’écart entre ces deux mesures qui renseigne une direction générale sur sa résilience réelle.

Pourquoi la cartographie des fonctions critiques résiste-t-elle autant ?

Deuxième constat : l’identification des fonctions critiques ou importantes (FCI) reste le point de départ le plus fragile. Obtenir une cartographie systématique, qui relie chaque FCI à ses processus, ses actifs et ses prestataires, demande un effort que peu d’établissements ont mené jusqu’au bout.

Les incohérences apparaissent à plusieurs niveaux. Au sein d’un même groupe, les entités n’identifient pas toujours leurs FCI selon les mêmes critères. Entre deux acteurs du même secteur, aux métiers comparables, les listes diffèrent parfois nettement. Le registre d’information, qui recense les accords avec les prestataires TIC, hérite de ces fragilités : son exactitude, sa cohérence et sa complétude restent insuffisantes.

La cartographie n’est pas un livrable figé. Les listes établies lors de la première collecte sont déjà à réévaluer, en cohérence avec les analyses d’impact métier (BIA). Et beaucoup vivent encore dans des fichiers Excel, difficilement exploitables au moment où elles comptent le plus : pendant un incident.

Le risque tiers, angle mort le plus visible de DORA

Le pilier consacré aux prestataires TIC concentre les écarts les plus lourds. La première difficulté est organisationnelle : piloter les prestataires qui supportent des FCI suppose de clarifier qui décide et qui contrôle, entre achats groupe, centrales d’achat et entités qui consomment les services. Cette répartition reste souvent floue. La deuxième ligne de maîtrise manque fréquemment d’une vision consolidée des risques liés aux prestataires.

Le cycle de vie du contrat révèle d’autres failles. L’appréciation du risque avant signature reste légère. L’intégration des clauses DORA dans les contrats existants n’est pas achevée partout, et les contrats remédiés présentent encore des écarts. Les indicateurs de performance et de risque associés aux prestations critiques sont incomplets.

Deux sujets résistent particulièrement. Les stratégies et plans de sortie, d’abord : les formaliser pour un service critique exige d’identifier une alternative crédible, ce que peu d’établissements ont documenté. La réaction aux événements chez les prestataires, ensuite : un incident ou un changement significatif chez un fournisseur déclenche rarement l’actualisation de l’analyse de risque associée. Le registre est remis, mais le pilotage opérationnel reste à construire.

Que reste-t-il de DORA une fois le programme terminé ?

Le bilan compte un acquis réel : les entités financières ont nettement monté en compétences sur la résilience opérationnelle. Mais DORA n’a pas d’échéance finale. Le run se compose d’activités récurrentes : réévaluation annuelle des FCI, contrôle de cohérence avec les BIA, actualisation du registre d’information, audits DORA annuels, collecte et analyse des incidents, campagnes de tests. Chacune suppose un propriétaire identifié, un calendrier et des moyens.

Deux chantiers restent ouverts. Les tests de résilience, d’abord : ils portent encore trop peu sur les actifs et les prestations qui supportent les FCI. La gestion du risque tiers, ensuite, qui reste le sujet central. Au-delà de l’intégration des clauses DORA, une question n’est pas tranchée : qui pilote les prestataires sous l’angle du risque ? Entre direction des achats, DSI et équipe cyber, cette responsabilité n’a souvent pas de propriétaire évident.

Comment passer d’une conformité déclarée à une conformité prouvée ?

• Mesurer autrement. Évaluer chaque exigence sur deux axes, réglementaire et opérationnel, et pondérer les écarts selon leur impact plutôt que les compter à parts égales. Un plan de sortie absent sur un service critique ne pèse pas comme une procédure à relire.
• Traiter les FCI comme un processus annuel, et tester leurs supports. La réévaluation part de la liste précédente, passe par des ateliers de cohérence avec les entités et les BIA, puis alimente la consolidation au niveau groupe. Un outil de cartographie partagé, exploitable en situation d’incident, remplace le fichier Excel. Les tests de résilience ciblent en priorité les actifs et prestations qui supportent ces FCI.
• Désigner un pilote du risque tiers. Arbitrer clairement le rôle des achats, de la DSI et de la cyber, commencer par les prestataires qui supportent des FCI, rédiger les plans de sortie les plus exposés et relier chaque événement significatif chez un fournisseur à l’actualisation de son analyse de risque.
• Organiser le run avant la fin du build. Nommer les propriétaires, fixer le calendrier récurrent et prévoir des moyens pérennes, avant que l’équipe projet ne se disperse.

Vingt mois après son entrée en application, DORA a produit ce qu’un programme de conformité produit le plus facilement : des documents et une montée en compétences réelle des équipes. La résilience opérationnelle numérique se mesure ailleurs : dans la capacité à cartographier ses fonctions critiques de façon cohérente, à tester ce qui les supporte, à piloter les prestataires qui les servent et à maintenir le dispositif une fois l’équipe projet partie. Les établissements qui distinguent dès aujourd’hui conformité DORA déclarée et conformité prouvée aborderont les prochains contrôles avec un net avantage.

Un test simple pour commencer : pour chacune de vos FCI, pouvez-vous nommer le prestataire critique qui la supporte, la personne qui pilote son risque et le plan de sortie associé ? Chaque réponse manquante indique où concentrer les efforts.