DORA : automatiser le registre d'information sur les prestataires TIC

Le registre d'information DORA est l'inventaire structuré de tous les accords contractuels d'un établissement avec ses prestataires tiers de services TIC — à tenir à jour en continu et à remettre chaque année à l'autorité compétente selon des modèles imposés. Ce n'est pas un document bureautique : c'est un jeu de tables reliées (entités, contrats, prestataires, fonctions supportées, criticité) qui doit être cohérent, réconcilié et rejouable. Le produire à la main sur Excel ne tient pas à l'échelle d'un groupe.

Qu'est-ce que le registre d'information DORA ?

Le règlement DORA (Digital Operational Resilience Act, Règlement (UE) 2022/2554), applicable depuis le 17 janvier 2025, impose aux entités financières — dont les assureurs, mutuelles et banques — de renforcer leur résilience opérationnelle numérique. L'un de ses piliers est la gestion du risque lié aux tiers TIC : un établissement doit maîtriser sa dépendance à ses prestataires informatiques (cloud, éditeurs, infogérance, sous-traitants).

Le registre d'information (art. 28 de DORA) en est l'instrument concret : chaque entité tient un inventaire de l'ensemble de ses accords contractuels portant sur l'usage de services TIC fournis par des tiers. Ce registre alimente la surveillance : les autorités compétentes (l'ACPR en France pour ses assujettis) collectent ces registres et les transmettent aux ESAs (EBA, EIOPA, ESMA), qui les agrègent pour identifier les prestataires critiques à l'échelle européenne.

Sa structure est normalisée par des standards techniques (le Règlement d'exécution (UE) 2024/2956 définit les modèles) : le registre n'est pas un tableau libre mais un ensemble de modèles reliés (les templates RT.xx) — entités du groupe, accords contractuels, prestataires identifiés par leur LEI, fonctions de l'entreprise supportées, niveau de criticité, chaînes de sous-traitance.

Pourquoi le registre est un problème de données, pas de rédaction

À l'échelle d'un groupe, le registre agrège des centaines de contrats, des dizaines d'entités et des prestataires en cascade. Trois difficultés le rendent ingérable à la main :

1. La cohérence référentielle. Les modèles sont reliés par des identifiants (LEI des prestataires, identifiants de contrats, rattachement aux fonctions). Une incohérence entre tables — un prestataire cité dans un contrat mais absent du référentiel — est une erreur bloquante à la remise. C'est exactement le type de contrôle inter-états qu'une chaîne outillée sait faire et qu'un classeur ne fait pas.

2. La mise à jour continue. Le registre n'est pas une photo annuelle : il doit refléter en permanence les contrats en cours, les entrées/sorties de prestataires, les évolutions de criticité. Le reconstituer une fois par an à la main est une source d'erreurs et de retard.

3. La qualité des identifiants. LEI manquants ou périmés, fonctions mal rattachées, sous-traitants non déclarés : la donnée d'entrée est rarement propre. Sans étape de qualité outillée, le registre remis échoue aux contrôles.

À quoi ressemble une production outillée du registre

L'approche qui tient traite le registre comme un livrable de reporting réglementaire, avec la même chaîne que côté prudentiel. Schéma type, générique et illustratif :

Sources (référentiel achats/contrats, ERP fournisseurs, CMDB / cartographie SI, référentiel LEI) → couche de traitement gouvernée (Databricks : rapprochement contrats ↔ prestataires ↔ fonctions, contrôles de complétude et de cohérence des identifiants) → modèle sémantique (les modèles RT.xx définis une fois, avec leurs liens) → restitution et contrôle (Power BI : suivi de complétude, écarts, prestataires critiques, chaînes de sous-traitance) → génération du registre au format attendu pour la remise à l'autorité.

L'intérêt : le registre devient rejouable et réconcilié — chaque ligne reliée à sa source contractuelle, les contrôles inter-modèles passés avant remise, et une mise à jour rejouée sans repartir de zéro. C'est la logique de la gestion des risques TIC détaillée dans notre article dédié et le guide DORA.

Chiffres-clés — repères de marché (DORA)

• Règlement (UE) 2022/2554 (DORA) applicable depuis le 17 janvier 2025 — le registre d'information est une obligation en vigueur, pas future.

• Modèles normalisés par le Règlement d'exécution (UE) 2024/2956 : une série de templates reliés (entités, accords contractuels, prestataires, fonctions, criticité, sous-traitance).

• Identification par LEI des prestataires tiers de services TIC exigée — la qualité des identifiants est une cause fréquente de rejet.

• Remise annuelle à l'autorité compétente (ACPR en France), agrégation par les ESAs ; un exercice « dry run » a été mené par les ESAs en 2024 avant la première collecte officielle. (Modalités et calendrier à confirmer sur les instructions de l'autorité applicable.)

Le parti pris Finengy : le registre comme livrable de reporting

Finengy Advisory industrialise les chaînes de reporting réglementaire. Le registre d'information DORA relève de la même discipline que les QRT Solvabilité II : une donnée dispersée à collecter, réconcilier, contrôler et remettre au bon format. Nous outillons cette chaîne avec Databricks (rapprochement et qualité des données contrats/prestataires à l'échelle), Power BI (suivi de complétude et de criticité) et l'intégration des référentiels, pour que le registre soit tenu en continu et rejouable, pas reconstitué à la main chaque année.

Un établissement déjà équipé d'une chaîne de reporting prudentiel dispose d'un socle réutilisable — la même discipline de données, appliquée au risque TIC. Si votre registre DORA se prépare encore dans des classeurs, auditons ensemble votre chaîne de reporting.

FAQ

Qui doit tenir un registre d'information DORA ? Toutes les entités financières dans le périmètre de DORA — dont les assureurs, mutuelles, institutions de prévoyance, banques et établissements financiers — doivent tenir le registre de leurs accords contractuels portant sur des services TIC fournis par des tiers, au niveau entité et, le cas échéant, au niveau groupe.

Quelle est la différence entre le registre d'information et la cartographie des risques TIC ? La cartographie des risques TIC identifie et évalue les risques sur les systèmes et fonctions ; le registre d'information est l'inventaire structuré des contrats avec les prestataires tiers, à remettre à l'autorité selon des modèles imposés. Les deux se nourrissent mutuellement mais répondent à des obligations distinctes.

À quelle fréquence remet-on le registre ? Le registre est tenu à jour en continu et remis à l'autorité compétente (l'ACPR en France) selon la cadence qu'elle fixe, généralement annuelle. Les autorités agrègent ensuite l'information au niveau des ESAs pour désigner les prestataires tiers critiques.

Pourquoi ne pas tenir le registre sur Excel ? Parce que les modèles sont reliés par des identifiants (LEI, contrats, fonctions) et exigent des contrôles de cohérence inter-tables que le suivi manuel ne garantit pas. À l'échelle d'un groupe, une chaîne outillée réconcilie les sources, contrôle les identifiants et rejoue la production — ce qu'un classeur ne fait pas de façon fiable.

Sources : Règlement (UE) 2022/2554 (DORA, EUR-Lex), art. 28 (registre d'information, gestion du risque tiers TIC) ; Règlement d'exécution (UE) 2024/2956 (ITS sur les modèles du registre d'information) ; standards techniques réglementaires DORA ; ESAs (EBA/EIOPA/ESMA), exercice « dry run » 2024 ; ACPR. Modalités et calendrier de remise à confirmer sur les instructions de l'autorité applicable. Contenu informatif, ne constitue pas un conseil réglementaire.