Le registre d'informations DORA est la base de données que chaque entité financière doit tenir sur l'ensemble de ses accords contractuels avec des prestataires tiers de services TIC, en distinguant ceux qui soutiennent des fonctions critiques ou importantes. Imposé par l'article 28, paragraphe 3, de DORA et structuré par les 15 modèles du règlement d'exécution (UE) 2024/2956, il est collecté chaque année par les autorités compétentes.
Ce n'est pas une annexe de plus au dossier fournisseurs : c'est à partir de ces registres que les autorités européennes de surveillance (AES) ont désigné, le 18 novembre 2025, les 19 premiers prestataires tiers critiques de services TIC. Et la qualité des données reste le point faible : lors de l'exercice à blanc de 2024, seuls 6,5 % des registres analysés passaient tous les contrôles. Ce guide explique ce que contient le registre, pourquoi des remises sont rejetées et comment le tenir à jour.
L'essentiel en 30 secondes
- Base légale : article 28, paragraphe 3, de DORA ; format fixé par le règlement d'exécution (UE) 2024/2956 (15 modèles, de B_01.01 à B_99.01).
- Périmètre : tous les accords de services TIC, intragroupe compris, au niveau de l'entité et, pour les groupes, aux niveaux sous-consolidé et consolidé.
- Remise : annuelle, avec une date d'arrêté au 31 décembre de l'année précédente.
- Rejets : surtout des champs obligatoires vides, des LEI ou EUID invalides et des références orphelines entre modèles.
- Méthode : le registre se maintient au rythme des contrats, pas une fois par an.
Qui doit tenir le registre d'informations DORA, et à quel niveau ?
L'article 28, paragraphe 3, de DORA, applicable depuis le 17 janvier 2025, impose aux entités financières de :
- tenir et mettre à jour le registre, au niveau de l'entité et aux niveaux sous-consolidé et consolidé ;
- distinguer les accords qui soutiennent des fonctions critiques ou importantes ;
- déclarer au moins une fois par an le nombre de nouveaux accords, les catégories de prestataires, le type d'accords et les services et fonctions fournis ;
- fournir sur demande le registre complet ou certaines sections ;
- informer en temps utile l'autorité de tout projet d'accord portant sur une fonction critique ou importante, et lorsqu'une fonction le devient.
Toutes les entités financières dans le champ de DORA sont visées : banques, assureurs, entreprises d'investissement, établissements de paiement et de monnaie électronique, prestataires de services sur crypto-actifs, sociétés de gestion. Un point souvent mal lu : le paragraphe 2 du même article dispense les microentreprises et les entités au cadre simplifié de la stratégie formelle de risque lié aux tiers, mais le paragraphe 3 ne prévoit aucune exemption pour le registre.
Dans un groupe, l'entreprise mère détermine le périmètre, et le registre consolidé couvre toutes les entités financières et tous les prestataires intragroupe de services TIC (article 6 du règlement 2024/2956). Le registre couvre tous les prestataires directs, plus les sous-traitants qui sous-tendent effectivement un service soutenant une fonction critique ou importante. Et la notion de service TIC est large : SaaS, cloud, données de marché, infogérance, licences avec maintenance, services rendus par une filiale. En France, l'ACPR collecte les registres ; les établissements de crédit importants relèvent du canal de la Banque centrale européenne.
Que contient le registre ? Les 15 modèles de l'ITS 2024/2956
Le règlement d'exécution (UE) 2024/2956 du 29 novembre 2024, publié au Journal officiel le 2 décembre 2024, fixe les « modèles types » du registre. Son annexe I en décrit 15, conçus comme des tables relationnelles : colonnes fixes, lignes illimitées, une seule valeur par cellule.
| Modèle | Contenu | Point d'attention |
|---|---|---|
| B_01.01 | Entité qui tient le registre | Identifiée par son LEI |
| B_01.02 | Entités du périmètre de consolidation | LEI obligatoire pour chaque entité financière |
| B_01.03 | Succursales hors du pays d'origine | Souvent oubliées |
| B_02.01 | Accords contractuels : informations générales | Numéro de référence unique, coût annuel |
| B_02.02 | Accords contractuels : informations spécifiques | Fonction soutenue, dates, préavis, droit applicable, localisation des données |
| B_02.03 | Accords intragroupe | Relie le contrat intragroupe au contrat externe |
| B_03.01 à B_03.03 | Signataires des accords | Qui signe pour recevoir, qui signe pour fournir |
| B_04.01 | Entités qui utilisent les services | Pas forcément le signataire |
| B_05.01 | Prestataires tiers de services TIC | LEI ou EUID, pays du siège, dépense annuelle, maison mère ultime |
| B_05.02 | Chaîne d'approvisionnement | Rang 1 pour le prestataire direct, au-delà pour les sous-traitants |
| B_06.01 | Identification des fonctions | Criticité motivée et datée, RTO et RPO en heures |
| B_07.01 | Évaluation des services critiques | Substituabilité, dernier audit, plan de sortie, alternatives |
| B_99.01 | Définitions | Sens interne des options fermées |
Les quatre clés qui relient les modèles
Quatre clés relient les modèles : le numéro de référence de l'accord, l'identifiant des entités et des prestataires, l'identifiant de fonction et le type de service TIC (code S01 à S19 de l'annexe III). Chaque clé doit exister à l'identique dans le modèle de référence : un contrat cité dans B_07.01 mais absent de B_02.01, et la remise échoue.
Les données les plus difficiles à réunir
- Les identifiants. Chaque prestataire personne morale est identifié par un LEI valide et actif ou par un EUID, et par les deux s'ils existent ; les entités financières, uniquement par leur LEI. Le LEI compte 20 caractères (norme ISO 17442), dont deux chiffres de contrôle calculés selon ISO/IEC 7064 (MOD 97-10).
- Les fonctions. Une criticité motivée et datée, un RTO et un RPO en heures. La valeur « 0 » signifie « non défini » : un registre rempli de zéros trahit surtout l'absence de BIA.
- L'évaluation des services critiques : substituabilité sur quatre niveaux, plan de sortie, possibilité de réintégration, alternatives identifiées.
À quoi sert le registre côté superviseurs ?
Au niveau national, l'ACPR indique (webinaire DORA du 23 janvier 2026) s'en servir pour évaluer la gestion du risque lié aux tiers, cartographier les interdépendances, mesurer la concentration et gérer un incident survenu chez un tiers.
Au niveau européen, les autorités nationales transmettent chaque année les registres aux AES. Les critères de désignation des prestataires critiques (article 31, paragraphe 2) se lisent directement dans les modèles : impact systémique, importance des entités qui en dépendent, recours pour des fonctions critiques, y compris via la sous-traitance, substituabilité.
Le 18 novembre 2025, les AES ont publié la première liste de prestataires tiers critiques : 19 noms, dont Amazon Web Services, Microsoft, Google Cloud, Oracle, SAP, IBM, Accenture, Capgemini, Orange et Deutsche Telekom. La liste est mise à jour chaque année (article 31, paragraphe 9). Un prestataire mal identifié dans votre registre est un prestataire mal agrégé dans l'analyse européenne.
Quand et comment remettre le registre ?
La décision des AES sur la collecte (ESA 2024 22) fixe le principe : une remise annuelle, une date d'arrêté au 31 décembre de l'année précédente, une transmission des autorités nationales aux AES au plus tard le 31 mars. La première année faisait exception.
| Cycle | Date d'arrêté | Remise à l'autorité nationale | Transmission aux AES |
|---|---|---|---|
| 2025 (première remise) | 31 mars 2025 | Fenêtres nationales, avant le 30 avril | 30 avril 2025 |
| 2026 | 31 décembre 2025 | ACPR : du 1er janvier au 31 mars 2026 | 31 mars 2026 |
| 2027 | 31 décembre 2026 | À confirmer par chaque autorité | 31 mars 2027, selon la décision des AES |
Le format. Le paquet de remise est une archive .zip contenant un fichier CSV par modèle et des métadonnées JSON, au format xBRL-CSV (« plain CSV » pour l'EBA), qui publie le modèle de points de données (DPM), la taxonomie et les règles de validation. L'outil de conversion fourni pendant l'exercice à blanc n'est plus mis à jour : chaque entité choisit sa solution. En France, la remise passe par le portail OneGate de la Banque de France, et l'ACPR recommande une remise test sur l'environnement d'homologation.
Quelles erreurs font rejeter un registre ?
Trois sources publiques dessinent le même tableau. Lors de l'exercice à blanc de 2024 (rapport des AES du 17 décembre 2024), les champs obligatoires manquants représentaient environ 86 % des contrôles en échec. Pour les premières remises officielles, le relevé de l'EBA (avril 2025, mis à jour en mai) pointe des clés étrangères violées, des clés primaires manquantes, des LEI introuvables dans la base GLEIF et des EUID massivement mal formés : 58 170 au format invalide, contre 2 717 retrouvés dans le système d'interconnexion des registres du commerce. Pour la campagne 2026, l'ACPR cite des dates d'arrêté erronées, des archives mal structurées et des fichiers qui ne sont pas en UTF-8.
| Erreur | Exemple typique | Parade |
|---|---|---|
| Champ obligatoire vide | Code du prestataire absent de B_02.02 | Contrôle de complétude par modèle |
| Référence orpheline | Contrat cité dans B_07.01, absent de B_02.01 | Un numéro de contrat unique, réutilisé partout |
| LEI invalide | Code national (SIREN, par exemple) à la place du LEI | Contrôle du format et des chiffres de contrôle, puis vérification GLEIF |
| EUID mal formé | LEI déclaré comme EUID | Règle de format à la saisie |
| Valeur hors liste | Option absente du DPM | Listes de valeurs publiées par l'EBA |
| Erreur technique | Encodage, arborescence, date d'arrêté | Remise test en homologation |
Attention : un registre accepté une année peut être rejeté l'année suivante. Pour 2026, la CSSF luxembourgeoise a ainsi annoncé appliquer les mêmes règles à davantage de champs.
Construire et maintenir le registre en 7 étapes
Étape 1 — Nommer un propriétaire
Le registre croise des données que personne ne détient seul : contrats (achats), services (DSI), criticité et objectifs de reprise (continuité), concentration (risques), clauses (juridique). Nommez un propriétaire et un responsable par bloc de données.
Étape 2 — Inventorier tous les accords TIC
Rapprochez la base contrats, la comptabilité fournisseurs et la cartographie applicative. Les écarts révèlent les abonnements SaaS payés par carte, les contrats-cadres oubliés et les services rendus par une filiale sans contrat écrit.
Étape 3 — Collecter et vérifier les identifiants
Pour chaque prestataire : LEI vérifié dans la base publique de la GLEIF, EUID s'il est immatriculé dans l'Union, pays du siège, maison mère ultime. Exigez contractuellement ces données, y compris pour les sous-traitants critiques : les AES avaient prévenu dès 2024 que les identifiants des prestataires ne seraient pas toujours disponibles immédiatement.
Étape 4 — Relier chaque service aux fonctions qu'il soutient
Une fonction est critique ou importante lorsque sa perturbation nuirait sérieusement à la performance financière, à la solidité ou à la continuité des services de l'entité, ou à sa conformité (article 3, point 22, de DORA). Reprenez la liste de votre BIA, avec ses RTO et RPO : c'est le point de jonction avec le plan de continuité d'activité, qui doit porter les mêmes fonctions et les mêmes objectifs de reprise.
Étape 5 — Cartographier la chaîne de sous-traitance
Pour chaque service critique, obtenez du prestataire direct la liste des sous-traitants dont la défaillance affecterait la sécurité ou la continuité du service, et attribuez-leur un rang. Le règlement délégué (UE) 2025/532 précise ce que l'entité doit évaluer avant d'accepter cette sous-traitance.
Étape 6 — Évaluer substituabilité, sortie et alternatives
Le prestataire est-il remplaçable ? Le service peut-il être réintégré ? Une alternative est-elle identifiée ? Répondre « oui » à la question du plan de sortie engage : ce plan doit exister, être documenté et testé.
Étape 7 — Contrôler, remettre, puis maintenir au fil de l'eau
Avant chaque remise : complétude, format, unicité des clés, références croisées, puis remise test. Ensuite, branchez la mise à jour sur le cycle de vie des contrats : nouvel accord, avenant, résiliation, changement de localisation des données, nouveau sous-traitant, fonction reclassée critique (à signaler aussi à l'autorité). Un rapprochement trimestriel avec la comptabilité fournisseurs rattrape les oublis.
Registre, article 30, concentration et sortie : un seul dossier
Les clauses de l'article 30. Tout contrat de services TIC doit notamment décrire les services, les conditions de sous-traitance, les lieux de fourniture et de traitement des données, les niveaux de service et les droits de résiliation avec leurs préavis. Pour les fonctions critiques s'ajoutent des niveaux de service chiffrés, des plans de continuité testés chez le prestataire, des droits d'audit et des stratégies de sortie. Or plusieurs colonnes du registre se remplissent à partir de ces clauses : préavis, droit applicable, pays de fourniture, localisation des données. Un champ impossible à remplir signale souvent une clause absente. Pour les fournisseurs de produits numériques s'ajoutent les clauses liées au Cyber Resilience Act.
Le risque de concentration (article 29). Avant de conclure un accord critique, l'entité vérifie s'il la rendrait dépendante d'un prestataire difficilement substituable, ou s'il multiplierait les accords critiques avec des prestataires identiques ou étroitement liés. Regroupez les accords par identifiant et par maison mère ultime, et les concentrations apparaissent ; avec des noms saisis à la main (« AWS », « Amazon Web Services EMEA »), elles restent invisibles.
Les stratégies de sortie (article 28, paragraphe 8). Pour les services qui soutiennent des fonctions critiques, l'entité doit disposer de plans de sortie documentés, testés et revus, pour quitter un prestataire sans perturber ses activités. C'est de la continuité d'activité : la défaillance d'un tiers fait partie des indisponibilités qu'un PCA doit couvrir.
Tableur ou outil dédié ?
Un classeur suffit à une entité qui gère quelques dizaines de contrats, sans groupe à consolider. Au-delà, quinze onglets à garder cohérents à la main deviennent ingérables, et le registre n'est plus qu'une copie des données des achats, de la DSI et de la continuité, qui diverge dès le lendemain de la remise. La vraie question n'est pas l'outil, c'est l'endroit où vit la donnée. Voir aussi : tableur ou ResiPlan ?
Ce que fait ResiPlan, concrètement
- Registre assemblé depuis l'existant, sans ressaisie : fournisseurs, contrats, fonctions critiques ou importantes et leurs liens avec les prestataires alimentent les modèles.
- Contrôles avant remise : champs obligatoires, valeurs autorisées, format et chiffres de contrôle du LEI (ISO 17442), codes pays, références orphelines entre modèles.
- Reprise de l'existant : import d'un fichier de registre déjà constitué.
- Vue groupe : registre consolidé et vue des concentrations par prestataire.
- Contrats : checklist des clauses de l'article 30 pour chaque contrat.
- Exports du registre en Excel et en CSV.
Les données métier sont hébergées dans l'Union européenne. Une précision honnête : un logiciel ne rend personne « conforme » et ne certifie personne, et ResiPlan ne remet rien aux autorités à votre place. Découvrir le module registre d'informations ou démarrer un essai gratuit de 7 jours, sans carte bancaire.
Checklist : votre registre est-il prêt pour la prochaine remise ?
- Un propriétaire du registre et un responsable par bloc de données sont nommés.
- L'inventaire a été rapproché de la comptabilité fournisseurs et de la cartographie applicative.
- Chaque entité financière a un LEI valide ; chaque prestataire personne morale, un LEI ou un EUID vérifié, ainsi que sa maison mère ultime.
- Chaque service est rattaché à ses fonctions, avec une criticité motivée et datée.
- Les RTO et RPO viennent de la BIA, et aucun « 0 » ne masque une valeur inconnue.
- Les sous-traitants des services critiques sont listés avec leur rang.
- Chaque « oui » à la question du plan de sortie correspond à un plan documenté et testé.
- Les contrôles de complétude, de format et de références croisées passent sans erreur.
- Une remise test a été faite sur l'environnement d'homologation.
Pour un diagnostic plus large : checklist de préparation DORA et évaluation rapide d'un fournisseur.
FAQ
Faut-il un LEI pour chaque prestataire TIC ?
Pour les prestataires personnes morales, il faut un LEI valide et actif ou un EUID, et les deux lorsqu'ils existent. Les entités financières ne peuvent être identifiées que par leur LEI. Seules les personnes physiques agissant à titre professionnel peuvent l'être par un autre code, précédé du code pays.
Les fournisseurs non critiques doivent-ils figurer dans le registre ?
Oui. Le registre couvre tous les accords portant sur des services TIC. La distinction sert à graduer le détail : l'évaluation de B_07.01 et l'inscription des sous-traitants ne concernent que les services qui soutiennent des fonctions critiques ou importantes.
Les contrats intragroupe sont-ils concernés ?
Oui. Les prestataires intragroupe sont des prestataires à part entière. Lorsqu'une filiale informatique achète des services à un tiers pour le compte du groupe, le modèle B_02.03 relie le contrat intragroupe au contrat externe pour faire apparaître toute la chaîne.
Quelle est la prochaine échéance ?
Selon la décision des AES, la prochaine remise portera sur une date d'arrêté au 31 décembre 2026, avec une transmission aux AES au plus tard le 31 mars 2027. Chaque autorité fixe sa fenêtre de collecte : en 2026, celle de l'ACPR courait du 1er janvier au 31 mars. Surveillez les communications de votre superviseur dès la fin de l'année.
Combien de temps faut-il pour constituer le registre ?
Tout dépend du nombre d'accords, de la disponibilité des identifiants et de l'existence d'une BIA à jour. En pratique, une entité dotée d'une base contrats propre et d'une BIA récente produit un premier registre en quelques semaines ; un groupe qui part de tableurs dispersés doit compter plusieurs mois.
Pour aller plus loin
- Guide DORA 2026 : obligations pour les entités financières
- DORA 2026 : premier cycle d'audit, ce qui vous attend
- DORA vs NIS2 : quelle réglementation s'applique à vous ?
- Plan de continuité d'activité : guide 2026 en 8 étapes
- BIA en 7 étapes, avec modèle gratuit
Un registre d'informations n'est pas un livrable annuel : c'est la photographie, à une date donnée, d'une relation fournisseurs que vous pilotez toute l'année.