DORA : ce que le règlement change vraiment pour vos prestataires TIC
Registre d'information, tests de résilience, stratégies de sortie, sous-traitance en cascade. Ce qu'une organisation régulée doit désormais exiger d'un opérateur informatique — et comment le prouver en audit.
Le règlement UE 2022/2554, dit DORA, est applicable depuis le 17 janvier 2025. Il ne s'adresse pas seulement aux banques, aux assureurs et aux entreprises d'investissement : il redéfinit ce que ces entités doivent exiger de leurs prestataires de services informatiques, et ce que ces prestataires doivent être capables de démontrer. Pour un opérateur qui exploite l'infrastructure d'une organisation régulée, ce n'est pas une contrainte de plus — c'est le cahier des charges.
La question utile n'est donc pas « sommes-nous conformes ? » mais « qu'est-ce que notre prestataire nous permet de prouver le jour de l'audit ? ». Voici ce que DORA place noir sur blanc.
Le registre d'information
DORA impose à l'entité financière de tenir un registre de tous ses accords contractuels portant sur l'usage de services TIC (art. 28), et de le communiquer à l'autorité compétente — au Luxembourg, la CSSF. Ce registre suit un format défini par des normes techniques et distingue notamment les services qui soutiennent des fonctions critiques ou importantes.
Concrètement, votre opérateur doit vous fournir les éléments de ce registre sans que vous ayez à les reconstituer : identité et lieu d'établissement du prestataire, nature du service, localisation des données et de leur traitement, et la liste des sous-traitants. Si obtenir ces informations demande trois relances et un tableur bricolé, le problème n'est pas le registre : c'est le prestataire.
Les tests de résilience
DORA exige un programme de tests de résilience opérationnelle numérique proportionné au risque, et, pour les entités les plus critiques, des tests de pénétration fondés sur la menace (TLPT). Un opérateur sérieux ne se contente pas de dire que ses sauvegardes existent : il les teste, il horodate ces tests, et il vous en remet le résultat. La différence entre « nous sauvegardons » et « voici le journal de la dernière restauration testée, réussie » est exactement celle que cherche un auditeur.
La gestion et la notification des incidents
Le règlement encadre la classification et la notification des incidents majeurs liés aux TIC. Pour que l'entité financière puisse notifier dans les délais, son opérateur doit détecter, qualifier et remonter l'incident vite, et documenter la chronologie. Un incident dont on ne peut pas reconstituer le déroulé n'est pas un incident géré — c'est un incident subi.
La sous-traitance en cascade, et la sortie
DORA regarde toute la chaîne. Un prestataire qui sous-traite à son tour une brique critique doit le déclarer, et l'entité financière doit pouvoir en apprécier le risque. Le règlement encadre aussi les clauses contractuelles (art. 30) et impose des stratégies de sortie pour les services qui soutiennent des fonctions critiques : vous devez pouvoir quitter un prestataire sans interrompre votre activité ni perdre vos données.
C'est là que la conformité rejoint la souveraineté. Une stratégie de sortie n'a de valeur que si elle est réalisable : données restituables dans un format ouvert, configurations documentées, absence de dépendance qui rendrait le départ théorique. Une clause de réversibilité qu'on ne peut pas exécuter n'est pas une garantie, c'est une formule.
Ce que DORA ne fait pas. Le règlement n'exige pas que vos données restent sur le sol européen, ni que votre prestataire soit européen. Il exige que vous maîtrisiez et prouviez votre dispositif. La souveraineté est un choix distinct, que DORA rend simplement plus facile à documenter — voir notre analyse du CLOUD Act.