Le règlement DORA est applicable depuis le 17 janvier 2025. Assez de temps s’est écoulé pour que les premières remises réglementaires aient eu lieu, que les autorités européennes aient désigné les prestataires TIC critiques, et que l’ACPR ait commencé à formuler des constats. Le tableau qui se dessine est moins celui d’un défaut de volonté que celui d’un défaut de données.

Le registre d’informations, premier révélateur

DORA impose aux entités financières de tenir un registre d’informations recensant l’ensemble de leurs accords contractuels portant sur des services TIC. Ce registre est remis à l’autorité nationale — l’ACPR pour les banques et assurances françaises — qui le transmet aux Autorités européennes de surveillance (ABE, AEAPP, AEMF). La première campagne a été calée sur une date de référence au 31 mars 2025, pour une transmission aux AES fin avril 2025.

Sur le papier, l’exercice est administratif. En pratique, il a mis au jour un problème de fond : très peu d’établissements disposaient d’un inventaire fiable, structuré et à jour de leurs dépendances informatiques. Le format de remise est contraignant — identifiants légaux normalisés, chaînes de sous-traitance, qualification des fonctions critiques ou importantes — et il ne tolère pas l’approximation. Les remises incomplètes ou mal formées ont été fréquentes, au point que la qualité des registres est devenue un sujet de supervision à part entière plutôt qu’une simple formalité de collecte.

C’est l’enseignement le plus utile de cette première année : DORA a agi comme un révélateur de la maturité réelle de la gestion des tiers. Un registre que l’on ne peut pas produire proprement, c’est un signal que la cartographie sous-jacente n’existe pas.

Les prestataires critiques sont désormais surveillés directement

Le 18 novembre 2025, les trois Autorités européennes de surveillance ont publié la première liste de prestataires tiers de services TIC critiques (CTPP) désignés au titre de l’article 32 de DORA. La désignation s’est appuyée sur les registres d’informations collectés, complétés par une évaluation de criticité portant notamment sur l’importance systémique du prestataire et la substituabilité de ses services, puis par une phase contradictoire permettant aux prestataires concernés de présenter leurs observations.

Les analyses publiées à partir de cette liste font état de dix-neuf prestataires désignés, principalement des fournisseurs de cloud et de plateformes de grande taille. La liste officielle est annexée au communiqué des AES ; nous renvoyons vers celle-ci plutôt que de reproduire des noms de seconde main.

Concrètement, ces prestataires basculent sous supervision directe européenne, exercée par des équipes conjointes d’examen (Joint Examination Teams) associant personnels des AES et des autorités nationales. Cela ouvre la voie à des analyses de risque annuelles, des demandes d’information, des inspections et, le cas échéant, des recommandations dont le non-suivi peut se répercuter sur les entités financières clientes.

Pour un établissement, l’effet est indirect mais réel : une partie du risque fournisseur est désormais regardée à l’échelle européenne, ce qui ne dispense en rien de sa propre diligence contractuelle et de ses propres stratégies de sortie.

Ce que l’ACPR relève côté français

L’ACPR a présenté en janvier 2026 un état des lieux de l’application de DORA auprès des banques et assureurs français. Les constats qu’elle met en avant sont convergents avec ceux observés au niveau européen :

Domaine Constat récurrent
Registre d’informations Qualité de données insuffisante, rejets techniques à la remise, chaînes de sous-traitance incomplètes
Incidents majeurs Classification hétérogène, processus de qualification et de notification insuffisamment outillés
Tests de résilience Programmes de tests encore embryonnaires ou à l’état de projet dans une partie des établissements
Gouvernance Responsabilités mal réparties entre fonctions IT et risques, implication limitée de l’organe de direction
Risque tiers Évaluation des prestataires et stratégies de sortie documentées de façon inégale

Des pourcentages précis circulent dans la presse spécialisée sur la proportion d’établissements ayant déclaré un incident majeur ou ne disposant pas encore de programme de tests. Ces chiffres proviennent de reprises d’enquêtes de place et nous n’avons pas pu les recouper avec une publication officielle de l’ACPR ; nous préférons ne pas les avancer ici. Ce qui est documenté, en revanche, c’est la nature des écarts, et elle est constante.

Les tests d’intrusion fondés sur la menace (TLPT), attendus au moins tous les trois ans pour les entités désignées, constituent l’autre point de vigilance. Ce sont des exercices lourds, qui supposent une chaîne de commandement claire et une cartographie des fonctions critiques préalablement stabilisée — ce qui nous ramène au registre.

Trois leçons transposables hors du secteur financier

DORA ne concerne que les entités financières et leurs prestataires. Mais l’expérience de sa première année vaut pour toute organisation qui verra arriver NIS2.

1. L’inventaire précède tout. On ne peut ni notifier un incident correctement, ni tester ce qui compte, ni évaluer un fournisseur, si l’on ne sait pas quelles fonctions métier dépendent de quels actifs et de quels tiers. Les organisations qui ont souffert sur le registre DORA sont celles qui ont découvert cette dépendance au moment de la remise.

2. La qualification d’incident est un processus, pas un réflexe. Décider en quelques heures si un événement franchit un seuil de notification réglementaire suppose des critères écrits, des rôles nommés et un entraînement. Improvisé le jour J, cet arbitrage produit soit du sur-signalement, soit du silence.

3. Le risque tiers est le point de friction commun. DORA, NIS2 et ISO 27001:2022 convergent sur ce terrain. Les clauses contractuelles, les droits d’audit, les plans de réversibilité et la surveillance continue des fournisseurs constituent le chantier le plus souvent repoussé, et le plus long à rattraper.

Pour un RSSI ou un dirigeant qui doit tenir ces trois fronts sans équipe dédiée, l’enjeu est la tenue dans la durée : un registre vit, une cartographie se périme, une procédure non répétée se dégrade. GALEA aide sur ce point précis en maintenant la cartographie du système d’information et les contrôles de conformité multi-référentiels dans un même espace, de sorte qu’une mise à jour serve à la fois à DORA, à NIS2 et à ISO 27001 plutôt que d’être ressaisie trois fois.

Sources

Sources consultées le 23 septembre 2026.

Questions fréquentes

Une PME prestataire d’une banque est-elle soumise à DORA ?

Elle n’est pas une entité financière au sens du règlement et n’est donc pas directement assujettie, sauf désignation comme prestataire TIC critique, ce qui vise de très grands acteurs. En revanche, elle subit DORA par contrat : ses clients financiers doivent lui imposer des clauses précises sur l’accès, l’audit, la notification d’incident et la réversibilité.

À quelle fréquence le registre d’informations doit-il être mis à jour ?

Le registre doit être tenu à jour en continu et est remis à l’autorité compétente selon le calendrier annuel qu’elle publie. Concrètement, la mise à jour se déclenche à chaque nouveau contrat TIC, chaque changement de sous-traitant et chaque modification du caractère critique d’une fonction.

Les constats de l’ACPR peuvent-ils déboucher sur des sanctions ?

DORA prévoit des mesures correctrices et un régime de sanctions dont les modalités nationales relèvent du texte de transposition en cours d’examen au Parlement français. À ce stade, la supervision française privilégie visiblement l’injonction et la remédiation, mais rien n’indique que cette phase pédagogique soit permanente.