Registre d'information DORA : guide complet

Le registre d'information (Register of Information, souvent abrégé RoI) est le registre obligatoire que toute entité financière soumise à DORA doit tenir et mettre à jour. Il recense l'ensemble des accords contractuels conclus avec des prestataires tiers de services TIC.

Base légale concrète pour la structure et le format : le règlement d'exécution (UE) 2024/2956 de la Commission (29 novembre 2024), pris en application de l'article 28, paragraphes 3 et 9, du règlement (UE) 2022/2554. Ce registre est communiqué à l'autorité compétente sur demande ou selon les modalités qu'elle définit. Il alimente aussi le processus annuel de désignation des prestataires tiers critiques de services TIC par les autorités européennes (EBA, EIOPA, ESMA).

Ce guide pilier pose la cartographie : à quoi sert le registre, de quoi il est composé, comment les données s'articulent, et comment l'aborder opérationnellement. Les articles satellites détaillent les champs obligatoires, le format xBRL-CSV, les erreurs fréquentes et un modèle de travail.

Qui est concerné

Sont soumis à l'obligation les établissements de crédit, établissements de paiement, entreprises d'investissement, prestataires de services sur crypto-actifs, entreprises d'assurance, sociétés de gestion, et l'ensemble des autres types d'entités financières listés à l'article 2 du règlement DORA — plus de vingt catégories codifiées dans le registre (par ex. eba_CT:x639 pour les asset management companies, eba_CT:x300 pour les payment institutions).

Trois niveaux de reporting

Le registre peut être tenu à trois niveaux :

1. Entité individuelle — chaque entité financière tient son propre registre
2. Sous-consolidé — l'entreprise mère d'un sous-groupe tient le registre du sous-groupe
3. Consolidé — l'entreprise mère ultime tient le registre pour l'ensemble du groupe

Pour la plupart des acteurs français de taille intermédiaire (SGP, EP, EMI), le niveau entité individuelle est le point de départ réaliste. Le multi-entités (succursales, intra-groupe, consolidation) ajoute des templates complets (B_01.02, B_01.03, B_02.03, B_03.03) qu'il ne faut pas improviser la veille de la remise.

Les 13 templates : la vraie structure du registre

Le registre n'est pas « un Excel de prestataires ». C'est un modèle de données en 13 templates normalisés (B_01.01 à B_99.01), définis à l'annexe I du règlement d'exécution 2024/2956. Ils sont inter-reliés.

Code	Objet
B_01.01	Entité tenant le registre (identité déclarante)
B_01.02	Entités dans le périmètre de consolidation
B_01.03	Succursales hors pays d'origine
B_02.01	Accords contractuels — informations générales
B_02.02	Accords contractuels — informations spécifiques (template central)
B_02.03	Accords intra-groupe liés à des accords externes
B_03.01	Entités signataires côté client
B_03.02	Prestataires signataires côté fournisseur
B_03.03	Entités du groupe fournissant des services TIC en intra-groupe
B_04.01	Entités (ou succursales) bénéficiaires des services
B_05.01	Fiches prestataires TIC (directs, sous-traitants, mères ultimes)
B_05.02	Chaînes d'approvisionnement (rangs de sous-traitance)
B_06.01	Identification des fonctions internes soutenues
B_07.01	Évaluations des services TIC (substituabilité, audit, plan de sortie)
B_99.01	Terminologie interne des listes fermées

B_02.02 est le cœur opérationnel : une ligne par combinaison accord × entité bénéficiaire × prestataire × fonction × type de service TIC. Un seul contrat qui couvre trois fonctions et deux types de services peut donc générer jusqu'à six lignes.

Quatre clés qui ne doivent jamais bouger

Quatre identifiants relient les templates. Ils doivent être uniques, stables dans le temps, et cohérents partout :

1. Numéro de référence de l'accord contractuel — identifiant interne attribué par l'entité (B_02.01, B_02.02, B_03.*, B_04.01, B_05.02, B_07.01…)
2. LEI de l'entité financière — 20 caractères, format ^[A-Z0-9]{18}[0-9]{2}$ (ISO 17442)
3. Code d'identification du prestataire TIC — LEI ou EUID en priorité (règles strictes selon UE / hors UE / personne physique)
4. Identifiant de fonction — F1, F2… unique par combinaison (LEI entité + activité autorisée + nom de fonction)

Tant que ces clés changent à chaque campagne, le registre est reconstruit plutôt que maintenu. C'est la première cause structurelle d'échec.

Ce que le registre force à savoir (et que beaucoup n'ont pas)

Au-delà de la liste des fournisseurs, le modèle exige notamment :

• Typologie des accords : standalone, accord général (cadre), ou accord ultérieur/associé — avec lien obligatoire vers l'accord général le cas échéant
• 19 types de services TIC (S01 à S19), du project management au SaaS cloud
• Fonctions avec criticité, RTO/RPO en heures, incidence d'interruption
• Localisation des données au repos et du traitement, sensibilité, droit applicable — surtout si la fonction est critique ou importante
• Chaîne de sous-traitance avec rang (1 = direct, 2+ = sous-traitant) et destinataire au rang précédent
• Évaluations : substituabilité, raison de non-substituabilité, date du dernier audit mené ou mandaté par l'entité, existence d'un plan de sortie, possibilité de réintégration

Les champs « localisation / préavis / sensibilité / dépendance » de B_02.02 ne deviennent obligatoires que si le service soutient une fonction critique ou importante (évaluée dans B_06.01). Autrement dit : mal classer la criticité fausse tout le reste du registre.

Calendrier et finalité supervisory

• 22 décembre 2024 : entrée en vigueur du règlement d'exécution 2024/2956
• 2025 : premier exercice de reporting (dry run) organisé par les autorités nationales
• Date de soumission : fixée par chaque autorité compétente (en France : ACPR / AMF selon le type d'entité)

La finalité n'est pas seulement « déposer un fichier ». Le registre permet aux autorités européennes d'identifier les concentrations de dépendance ICT à l'échelle de l'Union. Un registre lacunaire ou techniquement invalide expose à un rejet de remise et à une lecture fausse du risque de concentration.

Méthode en quatre temps

1. Gouvernance et propriétaire du registre

Désignez un propriétaire (souvent conformité / risques) et des contributeurs : juridique (contrats), achats (prestataires), IT (services et criticité technique), métiers (fonctions). Sans collecte transverse, B_02.02 et B_06.01 restent incomplets.

2. Stabiliser les référentiels avant le « remplissage »

Dans cet ordre :

1. Identité déclarante (LEI, type d'entité, autorité) — B_01.01
2. Référentiel des fonctions — B_06.01
3. Référentiel des prestataires (LEI/EUID, mère ultime) — B_05.01
4. Accords généraux puis spécifiques — B_02.01 / B_02.02
5. Chaînes et évaluations — B_05.02 / B_07.01

3. Valider le fond et la technique

L'EBA publie des règles de validation (existence, conditionnelles, format LEI, signe…). Elles sont souvent en sévérité warning — elles ne bloquent pas toujours la soumission, mais un superviseur qui lit des warnings massifs n'est pas rassuré. En parallèle, le package xBRL-CSV a ses propres pièges (voir l'article format).

4. Maintenir en continu

Chaque nouveau prestataire, avenant, changement de criticité ou de localisation doit mettre à jour les templates concernés. La remise annuelle devient alors une extraction datée, pas un chantier.

Articles du cluster

• Champs obligatoires du registre DORA — ce qui est toujours requis vs conditionnel
• Format XBRL-CSV du registre DORA — structure du ZIP, CSV, FilingIndicators
• Erreurs qui ont fait échouer les remises 2025
• Modèle / template opérationnel — comment organiser la collecte

Le rôle d'Axenia. Axenia structure le registre à partir de vos contrats, tiers et fonctions, maintient les clés stables (accords, LEI, fonctions), et prépare les exports dans les formats attendus — pour que la remise annuelle soit une extraction, pas une reconstruction.

---

Synthèse pédagogique à partir du règlement d'exécution (UE) 2024/2956 et du règlement DORA. Ne constitue pas un avis juridique. Vérifiez toujours les instructions de votre autorité compétente et les fichiers de taxonomie / validation EBA en vigueur.