Cartographie des risques fournisseurs dans les services financiers : comment construire un registre DORA qui tient à l’audit

Le Registre d’Informations n’est pas un livrable de conformité que l’on produit une fois avant l’échéance et que l’on range ensuite. C’est un document vivant, transmis aux autorités nationales puis consolidé au niveau européen, qui doit refléter à tout moment la réalité de la dépendance d’un établissement financier envers ses prestataires TIC. En France, l’échéance annuelle de remise est fixée au 31 mars, les autorités nationales consolidant ensuite les registres reçus avant de les transmettre aux autorités européennes de surveillance. Beaucoup d’établissements abordent encore cet exercice comme une déclaration ponctuelle plutôt que comme une infrastructure de pilotage à construire une bonne fois pour toutes. Voici comment le construire pour qu’il tienne face à un contrôle.

Qu’exige le Register of Information DORA ? Les 7 champs obligatoires par relation contractuelle

Le format technique du registre, défini par les normes techniques d’exécution (ITS), comporte plusieurs dizaines de points de données répartis dans des tables reliées entre elles. Dans la pratique, ces points de données se regroupent en sept catégories d’informations obligatoires que chaque relation contractuelle avec un prestataire TIC doit documenter.

Premièrement, l’identification du prestataire : dénomination légale, identifiant (LEI lorsqu’il existe), pays d’établissement et type de prestataire. Deuxièmement, la description du service TIC fourni : nature précise de la prestation, pas une catégorie générique. Troisièmement, la ou les fonctions de l’entité financière supportées par ce service, avec l’indication de leur caractère critique ou important. Quatrièmement, les caractéristiques du contrat : référence, date de début, date de fin ou caractère à durée indéterminée, et délai de préavis de résiliation. Cinquièmement, la localisation des données traitées ou hébergées dans le cadre du service. Sixièmement, la chaîne de sous-traitance lorsqu’elle existe : identité des sous-traitants, pays d’établissement, nature des services sous-traités. Septièmement, les éléments liés à la sortie et à la gestion du risque : statut de la stratégie de sortie applicable au contrat, et lien vers l’évaluation de risque associée au prestataire.

Le premier cycle de remise, en 2025, a mis en évidence un problème récurrent : entre un tiers et la moitié des contrats déclarés par les établissements présentaient au moins un champ obligatoire manquant ou invalide. La cause la plus fréquente n’est pas la complexité du format, mais l’absence d’un point de collecte unique — les informations existent, dispersées entre les achats, le juridique et la DSI, mais personne n’en détient une version consolidée et à jour au moment de la remise.

Quelle différence entre le registre DORA et votre cartographie interne ?

Le registre et la cartographie de pilotage interne répondent à deux besoins différents, et confondre les deux conduit soit à un registre trop pauvre pour être utile en interne, soit à une cartographie interne qui n’est jamais réconciliée avec ce qui a été transmis aux autorités.

Le registre est un artefact réglementaire : son format est imposé, son contenu doit correspondre exactement à ce que prévoit l’ITS, et il est conçu pour être lu par un superviseur qui compare des établissements entre eux. La cartographie interne, elle, est un outil de pilotage : elle peut intégrer des informations que le registre ne demande pas — score de risque consolidé par prestataire, historique des incidents, indicateurs de performance, alertes en cours — parce qu’elle sert à la prise de décision quotidienne des équipes Risques, Conformité et Achats, pas à la conformité formelle. La bonne pratique consiste à faire du registre un sous-produit de la cartographie interne plutôt que l’inverse : une seule base de données de référence sur les tiers TIC, dont le registre réglementaire est un export formaté, et non une seconde source de vérité maintenue en parallèle avec le risque de divergence que cela implique.

Comment classifier les prestataires TIC critiques ? Les 4 critères DORA

DORA distingue deux niveaux de classification qu’il faut documenter séparément dans le registre. Le premier est propre à chaque établissement : une fonction est critique ou importante si sa défaillance nuirait sérieusement à la performance financière, à la solidité ou à la continuité de l’activité — c’est à l’établissement de le déterminer pour chacune de ses fonctions.

Le second niveau relève de la désignation, par la Commission européenne, de certains prestataires comme prestataires tiers critiques (CTPP) à l’échelle de l’Union, sur la base de quatre critères : l’importance systémique du prestataire pour la stabilité, la continuité ou la qualité de la fourniture de services financiers dans l’Union ; le nombre et le type d’entités financières qui dépendent de ce prestataire ; le degré de substituabilité du prestataire, c’est-à-dire la difficulté à trouver une alternative en cas de défaillance ; et la nature et la complexité des services fournis, notamment leur caractère critique pour les fonctions opérationnelles des entités dépendantes.
La première liste de prestataires ainsi désignés a été publiée par la Commission en novembre 2025. Pour le registre, cela implique de documenter, pour chaque prestataire, s’il figure sur cette liste — une information distincte de la classification de criticité propre à l’établissement, et qu’il ne faut pas confondre avec elle : un prestataire désigné critique au niveau européen peut ne soutenir qu’une fonction courante chez vous, et inversement.

Le risque de concentration : la dimension cartographique la plus souvent négligée

L’article 29 de DORA impose d’identifier et de gérer le risque de concentration : la dépendance excessive d’un établissement, ou du secteur financier dans son ensemble, à l’égard d’un nombre restreint de prestataires. Ce risque prend trois formes qu’un registre bien construit doit permettre de croiser : la dépendance à un prestataire unique pour plusieurs fonctions critiques, la concentration géographique de plusieurs prestataires dans une même région exposée à un même risque systémique, et le partage d’une infrastructure sous-jacente commune entre plusieurs prestataires en apparence distincts — par exemple plusieurs éditeurs logiciels hébergés chez le même fournisseur cloud.

C’est une dimension que la plupart des registres, construits contrat par contrat, ne rendent pas visible par défaut : rien dans un tableau de contrats individuels ne signale qu’un même prestataire supporte cinq fonctions critiques différentes réparties sur plusieurs directions métier. La Banque centrale européenne a constaté que plus de 30 % du budget total d’externalisation des grandes banques européennes se concentre sur une dizaine de prestataires TIC seulement — un niveau de concentration bien réel et précisément ce que l’article 29 vise à faire remonter. Construire cette vue suppose d’ajouter, au-dessus du registre contrat par contrat, une vue agrégée par prestataire qui recense toutes les fonctions critiques qu’il supporte, tous établissements et toutes filiales confondus.

Comment cartographier le sous-traitant du sous-traitant, au-delà du rang 1 ?

Le registre ne s’arrête pas au prestataire avec lequel l’établissement a signé un contrat. Lorsque ce prestataire recourt lui-même à des sous-traitants pour exécuter tout ou partie du service, en particulier pour les fonctions critiques ou importantes, cette chaîne de sous-traitance doit être documentée au-delà du premier rang. Un audit de supervision mené par la BCE en 2025 a mis en évidence que la chaîne de sous-traitance moyenne pour les services TIC critiques atteint 2,7 niveaux chez les établissements significatifs, certains montages atteignant cinq rangs.

C’est là que la plupart des registres deviennent incomplets, non par mauvaise volonté mais par manque de visibilité contractuelle : un établissement n’a pas de relation directe avec le sous-traitant de rang 2 ou 3, et dépend donc de la transparence contractuelle imposée à son prestataire de rang 1 pour obtenir cette information. La clause à négocier dès la signature du contrat initial — et à faire réviser dans les contrats existants qui ne la prévoient pas — est une obligation de notification et de documentation, par le prestataire, de tout recours à un sous-traitant intervenant dans l’exécution d’une fonction critique ou importante, avec mise à jour du registre à chaque changement dans cette chaîne.

Quand mettre à jour le registre DORA ? Les déclencheurs de mise à jour obligatoire

Un registre qui n’est révisé qu’à l’approche de l’échéance annuelle de remise ne peut pas, par construction, refléter la réalité de la relation avec les prestataires tout au long de l’année — c’est précisément l’écart entre cartographie calendaire et vitesse réelle du risque.

Pour un registre DORA, les événements suivants doivent déclencher une mise à jour immédiate, indépendamment du cycle de remise annuel : la signature d’un nouveau contrat TIC, le renouvellement ou l’avenant d’un contrat existant, la résiliation d’une relation contractuelle, un changement dans la chaîne de sous-traitance déclaré par le prestataire, un incident TIC notifié touchant ce prestataire, une modification de la classification de criticité d’une fonction, ou la découverte d’une situation de concentration non identifiée jusqu’alors. Documenter ces déclencheurs dans une procédure interne, avec un responsable identifié pour chacun, transforme le registre d’un exercice de reconstitution annuelle en une base vivante — exactement ce que les autorités de supervision cherchent à vérifier lorsqu’elles interrogent la fraîcheur des données déclarées.

Tenir ces déclencheurs à jour manuellement, contrat par contrat, devient intenable au-delà de quelques dizaines de prestataires TIC répartis entre plusieurs directions métier — c’est le rôle d’une solution de gestion des risques tiers (TPRM).

Une plateforme TPRM centralise le référentiel des prestataires et de leurs contrats, alimenté une seule fois par les achats, le juridique et la DSI, et le maintient à jour en continu : elle rapproche automatiquement les nouveaux contrats du référentiel existant, signale la fonction critique dès qu’un même prestataire y apparaît pour la seconde fois, et déclenche une alerte de révision dès qu’un des événements listés ci-dessus survient, plutôt que d’attendre la reconstitution annuelle du registre.
C’est exactement le principe que décrit Alain Chenal, Procurement Methods & Performance Director chez Egis, à propos de l’intégration d’Aprovall à son écosystème ERP : « Aprovall, et le lien avec l’ERP d’Oracle, nous permet de qualifier notre référentiel automatiquement et rapidement. Désormais, nous avons un peu plus de 6000 tiers actifs dans notre référentiel sur l’ERP, dont l’onboarding fluidifié pose les bases d’un pilotage plus fin de la conformité et des engagements RSE. »

Le principe est transposable au registre DORA : un référentiel unique, alimenté en continu, qui sert à la fois d’export réglementaire et d’outil de pilotage interne, plutôt que deux bases tenues séparément avec le risque de divergence que cela implique.

Articuler DORA et NIS2 dans la cartographie

Construire un registre DORA et une cartographie des risques fournisseurs NIS2 comme deux exercices séparés revient à collecter deux fois les mêmes informations de base — identité du prestataire, nature du service, criticité de la fonction supportée — avec des formats et des responsables différents. Les deux cadres partagent un socle de données commun, seule la couche réglementaire qui s’applique par-dessus diffère selon que l’entité relève du périmètre financier de DORA ou du périmètre plus large de NIS2. La bonne pratique consiste à construire un référentiel unique des tiers TIC et fournisseurs critiques, alimenté une seule fois, dont chaque cadre réglementaire — DORA, NIS2, ou les deux lorsque l’établissement y est soumis simultanément — extrait sa propre vue formatée, plutôt que de maintenir deux cartographies parallèles qui finissent presque toujours par diverger au bout de quelques mises à jour.