Ressources › Guide
Le registre d'information DORA, modèle par modèle
Le registre d'information est l'obligation la plus concrète du règlement DORA — Digital Operational Resilience Act, règlement (UE) 2022/2554. Ce n'est ni une politique interne ni une déclaration d'intention : c'est un inventaire structuré, machine-lisible, de tous vos accords contractuels portant sur des services TIC, de leurs prestataires, de leurs sous-traitants, et des fonctions que ces services soutiennent.
Sa forme n'est pas laissée à votre appréciation. Elle est fixée par les normes techniques d'exécution des autorités européennes de surveillance — règlement d'exécution (UE) 2024/2956 — sous la forme de quinze modèles reliés entre eux. Cet article les parcourt un par un, explique ce qui les relie, et signale à chaque étape ce qui fait échouer un dépôt.
À retenir d'emblée : le registre n'est pas un tableur que l'on transmet. C'est une archive .zip contenant un fichier CSV par modèle, plus trois fichiers techniques, nommée selon une convention stricte. Un tableur envoyé par courriel n'est pas un dépôt.
Qui doit en tenir un
La quasi-totalité des entités financières supervisées dans l'Union : établissements de crédit, entreprises d'investissement, sociétés de gestion, établissements de paiement et de monnaie électronique, prestataires de services sur crypto-actifs, plateformes de financement participatif, entreprises d'assurance et de réassurance, institutions de retraite professionnelle, agences de notation, et d'autres encore.
La taille n'exonère pas. Le principe de proportionnalité de DORA allège certaines exigences pour les petites entités, mais le registre d'information n'en fait pas partie : une société de gestion de dix personnes doit produire le même paquet xBRL-CSV qu'une banque systémique. C'est précisément là que la charge est la plus disproportionnée, et c'est ce qui explique que le marché du conseil facture ces dépôts à cinq chiffres.
Les quinze modèles
Chaque modèle porte un code de la forme B_XX.YY et un nombre fixe de colonnes. Voici l'ensemble, tel qu'il figure dans la taxonomie EBA en vigueur.
| Code | Colonnes | Ce que le modèle recense |
|---|---|---|
| B_01.01 | 6 | L'entité qui tient le registre. Un seul enregistrement. |
| B_01.02 | 11 | Les entités entrant dans le périmètre du registre, avec leur type, leur pays et leur total de bilan. |
| B_01.03 | 4 | Les succursales. |
| B_02.01 | 5 | Les accords contractuels — informations générales. C'est ici que naît le CAR, l'identifiant qui relie presque tout le reste. |
| B_02.02 | 18 | Les accords contractuels — informations spécifiques : droit applicable, préavis, pays de stockage des données, niveau de dépendance. |
| B_02.03 | 3 | Les accords intragroupe. |
| B_03.01 | 3 | Les entités signataires côté client. |
| B_03.02 | 3 | Les prestataires TIC signataires. |
| B_03.03 | 3 | Les entités du périmètre de consolidation fournissant le service. |
| B_04.01 | 4 | Les entités utilisatrices des services TIC. |
| B_05.01 | 12 | Les prestataires tiers de services TIC : identifiant, pays, nature, entreprise mère. |
| B_05.02 | 7 | Les chaînes de sous-traitance, rang par rang. |
| B_06.01 | 10 | L'identification des fonctions, et leur caractère critique ou important. |
| B_07.01 | 12 | L'évaluation des services TIC : substituabilité, impact d'une défaillance, stratégie de sortie. |
| B_99.01 | 19 | Les définitions issues des entités utilisatrices. |
Cent vingt-quatre colonnes au total. Le nombre impressionne moins que la structure : ces modèles ne sont pas quinze listes indépendantes que l'on remplirait chacune de son côté.
Ce qui les relie, et pourquoi c'est là que tout casse
Le registre est un graphe, pas une pile de tableaux. Trois chaînes de dépendance le traversent, et une erreur en amont se propage en aval sous forme de plusieurs erreurs de validation apparemment sans rapport.
1. Le CAR, colonne vertébrale du registre
La référence d'accord contractuel (CAR) est créée dans B_02.01. Elle réapparaît dans B_02.02 pour les clauses détaillées, dans B_03.01 à B_03.03 pour les signataires, dans B_04.01 pour les utilisateurs, et dans B_07.01 pour l'évaluation. Un CAR mal orthographié dans un seul de ces modèles produit une ligne orpheline, et l'orpheline est rejetée.
2. La criticité, qui se propage sans prévenir
Une fonction déclarée critique ou importante dans B_06.01 change les obligations de tous les contrats qui la soutiennent. Des colonnes facultatives de B_02.02 deviennent obligatoires : droit applicable, préavis de résiliation de part et d'autre, pays de conservation des données, niveau de dépendance. Une évaluation devient exigible dans B_07.01.
C'est l'erreur la plus coûteuse du registre, parce qu'elle est invisible dans un tableur. Vous cochez « critique » sur une fonction, et six colonnes deviennent obligatoires trois onglets plus loin, sans qu'aucun message ne vous le dise. Le contrôle ne le découvre qu'au dépôt.
3. La chaîne de sous-traitance
B_05.02 recense les sous-traitants rang par rang. DORA ne s'intéresse pas seulement à votre prestataire direct : si votre hébergeur s'appuie lui-même sur un fournisseur de stockage, et que la fonction soutenue est critique, ce fournisseur de rang 2 doit apparaître. Beaucoup d'entités découvrent à cette étape qu'elles ne savent pas répondre — et c'est là un des apports réels de l'exercice, indépendamment du dépôt.
Les identifiants : LEI et EUID
Deux identifiants normalisés tiennent l'ensemble.
Le LEI (Legal Entity Identifier, ISO 17442) est un code de vingt caractères attribué par le système GLEIF. Il identifie votre entité, celles de votre périmètre, et vos prestataires lorsqu'ils en possèdent un. Sa structure comporte deux chiffres de contrôle calculés selon la norme ISO 7064 : un LEI mal recopié est détectable hors ligne, sans interroger aucun service.
L'EUID identifie les entités enregistrées dans un registre du commerce européen, via le système BRIS. Il prend le relais pour les prestataires sans LEI.
Deux ordres de vérification coexistent, et les confondre coûte cher :
- La validité formelle — vingt caractères, alphabet autorisé, clé de contrôle correcte. Elle se vérifie instantanément, hors ligne, et devrait l'être avant toute autre chose.
- L'existence réelle — le code correspond-il à une entité enregistrée, toujours active ? Elle exige une interrogation de GLEIF ou de BRIS. Les contrôles correspondants (
VR_2,VR_12,VR_23,VR_71pour le LEI ;VR_72etVR_78pour l'EUID) sont d'ailleurs marqués « do not run rule » par les autorités, faute d'accès garanti à ces bases au moment du contrôle.
La conséquence pratique est contre-intuitive : un LEI parfaitement bien formé et pourtant faux — celui d'une autre société, ou d'une entité radiée — franchit les contrôles automatiques. Il ne sera relevé que par un examinateur humain, plus tard, et dans un contexte nettement moins confortable.
Le format de dépôt
Le registre se transmet en xBRL-CSV. Concrètement, une archive .zip qui contient :
reports/report.json— les métadonnées du dépôt et la taxonomie visée ;reports/FilingIndicators.csv— la déclaration, modèle par modèle, de ce que vous transmettez ;reports/parameters.csv— dont le paramètreentityID, qui doit correspondre exactement au nom du fichier ;- un fichier CSV par modèle rempli, nommé d'après le code du modèle.
Le nom de l'archive obéit lui-même à une structure imposée :
SujetDuRapport_Pays_CodeCadreVersionModule_Module_DateDeRéférence_HorodatageDeCréation.zip
Les contraintes sont littérales : extension .zip obligatoire, caractères limités aux alphanumériques plus le tiret, le tiret bas et le point, date de référence au format aaaa-mm-jj et jamais dans le futur, nom de fichier unique — un doublon est refusé même si le contenu diffère.
Ces contrôles s'exécutent à la réception, avant même que le contenu ne soit lu. Un registre parfait dans une archive mal nommée est rejeté sans qu'une seule de ses cent vingt-quatre colonnes ait été examinée.
Quand, et à qui
Le registre est transmis annuellement à votre autorité nationale compétente — en France l'ACPR ou l'AMF selon votre statut — qui le transmet aux autorités européennes de surveillance. Il doit en outre être tenu à disposition en permanence : un superviseur peut le demander en dehors de toute campagne annuelle.
La fenêtre de dépôt est fixée nationalement et varie selon l'État membre et le type d'entité. Ne vous fiez pas à une date lue sur un site généraliste : vérifiez celle que votre autorité vous a communiquée, et notez-la. C'est la raison pour laquelle Obligia vous fait saisir votre échéance plutôt que de la calculer à votre place.
Pourquoi c'est plus difficile qu'il n'y paraît
Un registre incomplet n'est pas un registre partiellement conforme : c'est un registre non conforme. Et les trois causes récurrentes d'échec ne sont pas des questions de fond, mais de forme :
- Des identifiants absents ou mal formés, notamment sur les prestataires que personne n'a pensé à recenser — la plateforme de signature électronique, l'outil de paie, le fournisseur de données de marché.
- Des données de criticité incomplètes, parce que la propagation décrite plus haut n'a pas été anticipée.
- Des valeurs hors des listes fermées de la taxonomie : un pays écrit « France » au lieu de
FR, un type de service en clair au lieu de son code.
Aucune de ces trois erreurs n'est visible dans un tableur. Toutes les trois sont fatales au dépôt. La seule approche fiable consiste à rejouer les contrôles des autorités avant de déposer, plutôt que de découvrir le verdict après.
Ce qu'Obligia fait de tout cela
Obligia construit le registre complet sur les quinze modèles, propage automatiquement la criticité vers les contrats concernés, rejoue l'intégralité du catalogue de validation des ESA — 104 règles applicables sur les 120 publiées, les 16 restantes étant hors périmètre pour des raisons documentées — puis produit le paquet xBRL-CSV officiel, nommé selon la convention.
Autrement dit : vous corrigez les erreurs dans une interface qui vous les explique, au lieu de les découvrir dans un accusé de rejet.
Pour aller plus loin : pourquoi un dépôt DORA est rejeté et le format xBRL-CSV expliqué simplement.
Construire mon registre Réserver une démonstration ›
Ce guide est une information générale et non un conseil réglementaire ; la responsabilité du dépôt incombe à l'entité.