Registre d’informations DORA : ce qu’il contient

Depuis le 17 janvier 2025, chaque entité financière soumise à DORA, le règlement (UE) 2022/2554 sur la résilience opérationnelle numérique, tient un registre d’informations : la liste de tous ses contrats de services informatiques, qu’ils soutiennent ou non une fonction critique ou importante (article 28). Son format est fixé par le règlement d’exécution (UE) 2024/2956 : quinze tableaux liés entre eux, transmis chaque année à l’Autorité de contrôle prudentiel et de résolution (ACPR) ou à l’Autorité des marchés financiers (AMF). La campagne 2026 s’est close le 31 mars, sur les contrats en vigueur au 31 décembre 2025. La suivante, sur les contrats en vigueur au 31 décembre 2026, est attendue au premier trimestre 2027.

Le fichier se produit avec le bon outil. Ce qui prend du temps, ce sont les données : des prestataires identifiés sans ambiguïté, des fonctions évaluées, une chaîne de sous-traitance connue, et un registre qui suit vos contrats d’une année sur l’autre.

À quoi il sert

Le registre a trois lecteurs. Vous d’abord : il fait partie de votre cadre de gestion du risque lié aux technologies de l’information et de la communication (TIC), et vous y suivez vos dépendances, vos risques de concentration et vos stratégies de sortie.

Votre superviseur ensuite. Dans son webinaire DORA du 23 janvier 2026, l’ACPR dit s’en servir pour évaluer votre gestion des risques liés aux prestataires, cartographier les interdépendances, mesurer le risque de concentration et gérer un incident survenu chez un prestataire. Elle a fait de 2026 une « année de supervision », avec la conformité des contrats TIC parmi ses trois priorités : nous y revenons dans notre article sur le temps que DORA prend au CTO.

Les autorités européennes de surveillance (AES), enfin, s’en servent pour désigner les prestataires TIC critiques, qu’elles supervisent ensuite directement. Leur première liste, publiée le 18 novembre 2025 à partir des registres remis cette année-là, compte 19 prestataires. Pour constater que des centaines d’entités dépendent du même fournisseur, elles doivent le reconnaître d’un registre à l’autre. D’où la rigueur des contrôles : un prestataire mal identifié rend vos lignes inexploitables.

Qui doit le tenir

Toutes les entités financières soumises à DORA : établissements de crédit, établissements de paiement et de monnaie électronique, prestataires de services d’information sur les comptes, entreprises d’investissement, prestataires de services de financement participatif, prestataires de services sur crypto-actifs agréés au titre de MiCA, sociétés de gestion, assureurs… Les microentreprises ne sont pas dispensées : l’article 28 les exonère de la stratégie en matière de risques liés aux prestataires (paragraphe 2), pas du registre (paragraphe 3).

Le registre se tient au niveau de l’entité et, dans un groupe, aux niveaux sous-consolidé et consolidé ; un registre unique peut couvrir les trois (considérant 2 du règlement d’exécution). La foire aux questions de l’ACPR précise qui remet un registre individuel et qui remet un registre consolidé : une entité qui n’appartient à aucun groupe, ou dont la maison mère est établie hors de l’Espace économique européen, remet le sien.

L’ACPR reçoit les registres des établissements de crédit, sauf les plus importants, qui remettent le leur à la Banque centrale européenne, ainsi que ceux des établissements de paiement et de monnaie électronique, des entreprises d’investissement et des assureurs. L’AMF reçoit ceux des sociétés de gestion, des prestataires de services de financement participatif, des prestataires de services sur crypto-actifs et des entreprises de marché.

Si vous éditez un logiciel ou fournissez un service informatique à des entités financières, vous ne tenez pas de registre, mais vous figurez dans celui de vos clients : la partie Si vous êtes le prestataire vous concerne.

Ce qu’il contient

Les contrats concernés

Le registre recense « tous les accords contractuels portant sur l’utilisation de services TIC » fournis par des prestataires, sans seuil de montant ni d’importance. Les services TIC sont, selon l’article 3 de DORA, les « services numériques et de données fournis de manière permanente par l’intermédiaire des systèmes de TIC » : hébergement, cloud, logiciel en ligne (SaaS), fourniture de données, développement, infogérance, assistance, conseil informatique, matériel loué en tant que service. Votre messagerie y figure au même titre que le cœur de votre plateforme ; seul le niveau de détail change. Les prestataires de votre propre groupe y figurent aussi.

Trois cas sortent du registre :

• Un achat ponctuel. Un logiciel acheté une fois, sans maintenance, assistance ni mise à jour, n’est pas fourni de manière permanente (question 94 de la FAQ des AES sur la remise des registres).
• Un service financier réglementé. Quand une entité financière vous rend un service qui relève de son activité réglementée, comme votre banque partenaire, c’est avant tout un service financier, pas un service TIC, selon la réponse de la Commission européenne à la question 2999 des AES. Un service sans lien avec cette activité, rendu par la même entité, reste un service TIC.
• Un contrat terminé. Le registre ne contient que les contrats en cours ; vos règles de conservation habituelles s’appliquent aux autres (questions 52 et 53 de la FAQ des AES).

Tout dépend ensuite de la fonction que le service soutient. Une fonction est critique ou importante si sa perturbation est susceptible de nuire sérieusement à votre performance financière, à la continuité de vos services, ou au respect des conditions de votre agrément (article 3, point 22). Pour les services qui en soutiennent une, le registre en demande beaucoup plus : localisation et sensibilité des données, sous-traitants, évaluation du service.

Un service numérique ou de données fourni de manière permanente est un service TIC. S’il s’agit d’un service financier réglementé rendu par une entité financière, il sort du registre, comme un achat ponctuel sans maintenance. Sinon, le contrat est inscrit au registre ; si le service soutient une fonction critique ou importante, le registre décrit aussi ses données, ses sous-traitants et son évaluation.

Quinze tableaux reliés par quatre clés

Le règlement d’exécution organise le registre comme une petite base de données : quinze tableaux à colonnes fixes et lignes illimitées, reliés par quatre clés (considérant 8) :

• le numéro de référence que vous attribuez à chaque contrat ;
• l’identifiant de chaque entité et de chaque prestataire ;
• l’identifiant de chaque fonction ;
• le type de service TIC, choisi parmi dix-neuf catégories, de S01 (gestion de projets TIC) à S19 (logiciel en tant que service), en passant par S17 et S18 pour l’infrastructure et la plateforme à la demande (annexe III).

Chaque colonne prend une seule valeur (article 4) : un contrat qui couvre trois types de services occupe trois lignes, un service qui soutient deux fonctions en occupe deux. Les clés doivent se répondre d’un tableau à l’autre : une clé vide fait rejeter tout le fichier (question 40 de la FAQ des AES).

Les choix qui font un registre fiable

Le règlement d’exécution dit quelles colonnes remplir. Les décisions qui comptent restent les vôtres, et ce sont elles que le superviseur lira.

Vos fonctions et leur criticité

Il n’existe pas de liste officielle des fonctions : DORA ne définit pas le terme, et les AES renvoient à votre organisation interne (questions 56 et 112 de leur FAQ). Pour un établissement de paiement, ce peut être l’exécution des opérations de paiement, la connaissance client, la lutte contre le blanchiment, le service client ou la comptabilité. Chaque fonction reçoit un identifiant par activité agréée : la même fonction exercée pour deux activités en reçoit deux.

Pour chacune, vous indiquez si elle est critique ou importante, pourquoi, à quelle date vous l’avez évaluée, l’impact d’une interruption, et deux objectifs exprimés en heures : le délai de rétablissement (RTO) et la perte de données admissible (RPO). Ces objectifs viennent de votre analyse d’impact sur l’activité. Le règlement prévoit des valeurs pour les cas où rien n’a été fait : « évaluation non réalisée », une date d’évaluation au 31 décembre 9999, un objectif à zéro. Elles sont permises, mais elles disent au superviseur ce qui manque.

Le découpage des contrats

Vous attribuez vous-même le numéro de référence de chaque contrat. Il doit rester unique et stable, d’une année sur l’autre et, dans un groupe, d’une entité à l’autre (question 43).

Un contrat cadre et ses bons de commande se déclarent comme un accord général et des accords subséquents. Les AES vous laissent choisir le niveau de détail : le contrat cadre quand toutes vos entités utilisent les mêmes services, le bon de commande quand une entité ou un service a ses propres conditions (question 106). La dépense annuelle se répartit entre les niveaux sans être comptée deux fois. Un contrat à durée indéterminée se déclare avec une date de fin au 31 décembre 9999.

L’identifiant de chaque prestataire

C’est la donnée qui manquait le plus souvent lors de l’exercice à blanc de 2024. Les règles sont strictes (article 3 du règlement d’exécution) :

• un prestataire établi dans l’Union s’identifie par son identifiant d’entité juridique (LEI) ou par son identifiant unique européen (EUID), celui des registres du commerce ;
• un prestataire établi hors de l’Union, par son LEI uniquement ;
• seul un prestataire personne physique peut être identifié autrement, par exemple par son numéro d’immatriculation ou de TVA.

Vérifiez d’abord quelle entité a signé : un éditeur américain contracte souvent avec ses clients européens par une filiale européenne, qui s’identifie alors comme un prestataire de l’Union. Renseignez ensuite sa maison mère ultime : c’est elle qui permet aux AES de regrouper les filiales d’un même groupe (question 42).

Un EUID se cherche à la main, entreprise par entreprise, sur le portail e-Justice de la Commission : il n’existe pas d’interface de programmation (question 41). Saisissez-le en entier, point compris. Le LEI se vérifie automatiquement dans la base de la GLEIF, la fondation qui gère ces codes, et c’est contre elle que les AES contrôlent chacun d’eux. Il doit être valide et actif : la tolérance annoncée pour 2025 sur les LEI expirés (question 44) n’a rien d’une règle.

Si un prestataire établi hors de l’Union n’a pas de LEI, renseignez un autre identifiant : le fichier ne sera pas rejeté, mais la ligne sera signalée comme un défaut de qualité, et les AES ne pourront peut-être pas l’exploiter (question 40). Demandez-lui d’en obtenir un.

La chaîne de sous-traitance

Pour les seuls services qui soutiennent une fonction critique ou importante, le registre remonte la chaîne. Il inclut les sous-traitants qui « sous-tendent de fait » le service, c’est-à-dire ceux dont la défaillance compromettrait sa sécurité ou sa continuité (considérant 6 du règlement d’exécution). Le prestataire avec lequel vous avez signé occupe le rang 1, son sous-traitant le rang 2, et ainsi de suite (article 2).

Prenons un exemple : vous confiez la surveillance de vos transactions à un éditeur SaaS (rang 1), qui l’héberge chez un fournisseur de cloud public (rang 2). Si ce fournisseur tombe, votre surveillance s’arrête : il figure dans votre registre, avec son identifiant. Le règlement vous charge d’obtenir ces identifiants par l’intermédiaire de votre prestataire direct (article 3, paragraphe 6). Prévoyez-le dans le contrat : sans clause, la réponse dépend de sa bonne volonté.

Dans un groupe, le tableau B_02.03 relie le contrat signé avec votre prestataire intra-groupe au contrat que celui-ci a conclu à l’extérieur.

L’évaluation des services critiques

Pour chaque service qui soutient une fonction critique ou importante, le tableau B_07.01 demande votre évaluation :

• la substituabilité du prestataire, sur quatre niveaux allant de « non substituable » à « facilement substituable », et sa raison quand elle est difficile ;
• la date du dernier audit du service ;
• l’existence d’un plan de sortie : DORA impose des stratégies de sortie pour ces services (article 28, paragraphe 8) ;
• la possibilité de réintégrer le service chez vous, l’impact de son arrêt, et l’existence d’autres prestataires capables de le rendre.

La date d’audit est souvent mal comprise. Elle ne vise que les audits menés par vous (audit interne ou personnel qualifié), avec d’autres clients du même prestataire (audit groupé), ou par un tiers que vous avez désigné. Le rapport SOC 2 ou le certificat ISO 27001 de votre prestataire n’en tient pas lieu. Sans audit, le règlement demande d’indiquer le 31 décembre 9999.

La remise annuelle

Le calendrier

À l’ACPR, la campagne 2026 a ouvert le 1er janvier et s’est close le 31 mars, sur les contrats en vigueur au 31 décembre 2025, la « date d’arrêté ». Le calendrier 2027 n’est pas encore publié.

L’AMF a annoncé en juillet 2026 qu’elle collecterait en 2027 les registres de toutes les entités qu’elle supervise au titre de DORA : sociétés de gestion entrant dans son champ, prestataires de services de financement participatif, prestataires de services sur crypto-actifs et entreprises de marché. La collecte devrait commencer au premier trimestre 2027, et le format comme les règles de validation devraient rester inchangés (communication de l’AMF, relayée par l’Association française de la gestion financière).

Le format

Le registre se remet en xBRL-CSV, que l’Autorité bancaire européenne (EBA) appelle « plain CSV » : une archive zip qui contient un fichier CSV par tableau, de b_01.01.csv à b_99.01.csv, et quelques fichiers de description (report.json, parameters.csv, FilingIndicators.csv, et reportPackage.json dans un dossier META-INF). Sur OneGate, le portail de remise de l’ACPR, cette archive est encodée en base 64 et placée dans une enveloppe XML. L’accréditation au portail se fait avec le LEI de l’entité, seul identifiant admis pour une entité financière : sans LEI, pas de remise. Le registre peut être rempli en français ou en anglais, mais dans une seule langue (FAQ de l’ACPR).

Les AES ne fournissent plus l’outil de conversion d’Excel vers CSV proposé lors de l’exercice à blanc de 2024. Il faut un outil qui produise le fichier, ou quelqu’un qui sache le faire : l’ACPR qualifie elle-même cette étape de « technique » et invite à identifier à l’avance les personnes capables de la réaliser.

Ce qui fait rejeter un fichier

Les contrôles s’appliquent en deux temps. D’abord des contrôles techniques : format, nommage, structure de l’archive. Un fichier qui échoue est rejeté. Ensuite des contrôles de validation : règles du modèle de données, cohérence entre tableaux, LEI vérifiés auprès de la GLEIF et EUID auprès des registres européens. Une erreur déclenche un retour sur la qualité des données, et il faut remettre le fichier corrigé dans un délai court.

Lors de l’exercice à blanc de 2024, mené sur la base du volontariat, 1 039 registres ont été reçus et 947 analysés : 6,5 % seulement passaient les 116 contrôles de qualité. Les valeurs obligatoires manquantes représentaient 86 % des erreurs, au premier rang desquelles les identifiants des prestataires et de leurs maisons mères. Le tableau B_02.02, celui des services et des fonctions, concentrait 60 % des données manquantes.

À l’ACPR, les trois premières causes de rejet technique, présentées dans le webinaire de janvier 2026, étaient plus prosaïques :

1. la date limite de remise saisie à la place de la date d’arrêté : il fallait 2025-12-31, pas 2026-03-31 ;
2. un niveau manquant dans l’arborescence de l’archive ;
3. des fichiers encodés en ANSI au lieu d’UTF-8.

L’ACPR reconnaît aussi que les règles de validation de 2025 avaient changé en cours de campagne, et dit les avoir stabilisées pour 2026. Déposez votre fichier sur l’espace d’homologation de OneGate avant la date limite, puis lisez le compte rendu de traitement : il liste chaque anomalie et sa gravité.

Le tenir à jour entre deux remises

Le règlement d’exécution demande d’examiner régulièrement le registre et de corriger rapidement toute erreur (article 3). Un registre reconstruit chaque hiver pour la remise est faux le reste de l’année. Ce qui fonctionne :

1. Partir des faits, pas des souvenirs. Le grand livre fournisseurs, la liste des applications de votre fournisseur d’identité (SSO), les factures cloud et la liste de vos sous-traitants au sens du RGPD couvrent l’essentiel de vos services TIC.
2. Brancher le registre sur les achats. Avant de signer, DORA vous demande de déterminer si le service soutiendra une fonction critique ou importante (article 28, paragraphe 4). Faites de la ligne du registre une étape de la signature.
3. Demander les données au moment de signer. LEI ou EUID, maison mère, pays de stockage et de traitement des données, sous-traitants : c’est le moment où le prestataire a le plus de raisons de répondre.
4. Revoir les évaluations à date fixe. Criticité des fonctions, dates d’audit, plans de sortie : au moins une fois par an, avant la date d’arrêté.
5. Produire le fichier depuis une source unique. Un registre recopié d’un tableur à l’autre accumule les écarts. Tenez une seule source, générez le fichier à partir d’elle, et vérifiez-le avec les règles de validation publiées par l’EBA avant de le déposer.

Deux autres obligations de l’article 28 courent toute l’année :

• Le registre sur demande. L’autorité peut demander à tout moment le registre complet ou certaines de ses parties.
• L’information préalable. Vous informez l’autorité en temps utile de tout projet de contrat portant sur un service qui soutient une fonction critique ou importante, et lorsqu’une fonction le devient. L’ACPR demande pour l’instant le formulaire annexé à son instruction 2019-I-06, modifiée par l’instruction 2020-I-09, au plus tard 6 semaines avant l’entrée en vigueur de la sous-traitance (question B11 de sa FAQ).

Si vous êtes le prestataire

Si vous éditez un logiciel ou fournissez un service informatique à des entités financières, vous ne tenez pas de registre, mais vous figurez dans celui de chacun de vos clients. Leurs questionnaires reprennent les colonnes du registre :

• la raison sociale de l’entité qui signe, son LEI ou son EUID, le pays de son siège et sa maison mère ultime ;
• le type de service, presque toujours S19 (logiciel en tant que service) pour un éditeur SaaS ;
• les pays où les données sont stockées et ceux où elles sont traitées ;
• les sous-traitants qui sous-tendent votre service, avec leurs identifiants, si ce service soutient une fonction critique chez votre client ;
• les préavis de résiliation et le droit applicable.

Une société immatriculée dans l’Union a déjà un EUID, attribué par son registre du commerce. Vos clients peuvent tout de même vous demander un LEI, plus simple à vérifier en masse ; en France, l’Insee en délivre, et il se renouvelle chaque année. Si vous signez depuis une entité établie hors de l’Union, le LEI est obligatoire.

Préparez une fiche d’une page qui répond à ces colonnes, et tenez-la à jour : vous la renverrez à chaque nouveau client financier. Pour les services qui soutiennent une fonction critique, vos clients négocieront aussi les clauses de l’article 30 : niveaux de service, droits d’audit, stratégie de sortie ; notre page conformité DORA les résume. Enfin, votre rapport SOC 2 ou votre certification ISO 27001 nourrit l’évaluation de vos clients, mais ne remplit pas leur colonne « dernier audit » : seul y figure un audit mené par votre client, avec d’autres clients, ou par un tiers qu’il désigne.

Ce que nous prenons en charge

Si personne ne porte la sécurité chez vous, nous tenons le rôle de responsable de la sécurité des systèmes d’information (RSSI) : c’est notre offre RSSI externalisé. Pour le registre, nous recensons vos contrats, qualifions avec vous vos fonctions et leur criticité, obtenons de vos prestataires les identifiants et les sous-traitants qui manquent, puis tenons le registre à jour. Au moment de la remise, nous produisons le fichier xBRL-CSV, le vérifions avec les règles de validation de l’EBA et préparons le dépôt avec vous. Un workshop hebdomadaire d’une heure fait le point, avec un suivi en asynchrone entre deux workshops.

Si vous avez déjà un RSSI ou un responsable des risques, il garde le pilotage avec notre offre Accompagnement à la conformité : nous apportons notre lecture du règlement d’exécution, construisons le registre avec lui et préparons le fichier de remise. Si vous ne savez pas où en est votre registre, une analyse d’écarts le situe, avec le reste de votre conformité DORA, et liste ce qui manque avant la prochaine remise.

Questions fréquentes

Faut-il inscrire nos outils du quotidien, comme la messagerie ou le CRM ?

Oui, dès lors qu’ils sont fournis de manière permanente dans le cadre d’un contrat : DORA ne prévoit aucun seuil. Tant qu’ils ne soutiennent pas de fonction critique ou importante, les colonnes à remplir sont moins nombreuses.

Notre banque partenaire doit-elle figurer au registre ?

Pas pour ses services financiers réglementés, comme la tenue de comptes ou l’exécution de paiements : selon la Commission européenne, ce sont avant tout des services financiers. Un service sans lien avec son activité réglementée, comme un logiciel qu’elle vous fournirait à part, y figure.

Un prestataire établi hors de l’Union n’a pas de LEI : que faire ?

Vérifiez d’abord l’entité qui a signé : si c’est une filiale établie dans l’Union, son EUID suffit. Sinon, demandez au prestataire d’obtenir un LEI et, en attendant, renseignez un autre identifiant : le fichier passera, mais la ligne sera signalée comme un défaut de qualité.

Par où commencer

D’ici la prochaine date d’arrêté, trois chantiers comptent :

1. extraire la liste de vos fournisseurs de la comptabilité et de votre fournisseur d’identité ;
2. lister vos fonctions et décider lesquelles sont critiques ou importantes ;
3. demander dès maintenant leur LEI ou leur EUID, et leurs sous-traitants, aux prestataires qui soutiennent ces fonctions.

Le reste se règle tableau par tableau. Pour faire le point avant la remise de 2027, parlons de votre registre : si nos offres ne sont pas encore pertinentes pour vous, nous vous le dirons.