Le Registre d’Information DORA : Ce Qu’il Faut Fournir et Avant Quand

Sommaire

Les sections suivantes détaillent ce que le registre exige concrètement, pourquoi sa construction s’est révélée si difficile pour la majorité du secteur, et comment structurer une préparation crédible.

• Un Document que Peu d’Entreprises Prennent au Sérieux à Temps
• Qu’est-ce que le Registre d’Information, Précisément
• La Structure du Registre : les Modèles de Données
• Ce Qu’il Faut Fournir, Champ par Champ
• Le Lien Entre le Registre et les Tests d’Intrusion Ciblés
• La Classification de Criticité, Étape la Plus Sensible
• Les Échéances Pays par Pays
• Pourquoi les Échéances Varient Malgré un Règlement Unique
• La Date de Référence du 31 Décembre 2025
• Le Piège de la Sous-Traitance en Cascade
• Construire la Gouvernance Avant l’Outil
• Le Coût d’une Non-Conformité Découverte Tardivement
• Maintenir le Registre Vivant Après la Première Soumission
• Les Erreurs les Plus Coûteuses
• Étude de Cas : un Assureur Multi-Pays
• Checklist de Préparation
• FAQ
• Regard d’Expert
• Références

Un Document que Peu d’Entreprises Prennent au Sérieux à Temps

Le Registre d’Information est, sur le papier, un simple inventaire structuré des prestataires informatiques d’une institution financière. Dans la pratique, c’est le livrable DORA qui a fait échouer plus de 93% des entreprises lors du test blanc mené par les autorités européennes de supervision en 2024. Cette différence entre la simplicité apparente du concept et la difficulté réelle de son exécution mérite d’être comprise en détail, parce qu’elle explique pourquoi tant d’organisations sous-estiment encore aujourd’hui l’ampleur du chantier qui les attend concrètement, sur le terrain.

Ce document n’est pas une formalité administrative isolée. Il structure la relation de l’entité avec l’ensemble de son écosystème de prestataires technologiques, et sert de base aux autorités de supervision pour évaluer la concentration du risque sectoriel sur certains prestataires critiques — un enjeu systémique qui dépasse largement la seule institution qui soumet son registre.

Cet enjeu systémique explique pourquoi les autorités européennes accordent une importance particulière à la qualité de ce registre au-delà du seul intérêt de l’entité qui le soumet : lorsque plusieurs institutions financières dépendent du même prestataire cloud ou du même fournisseur de services de paiement critique, une défaillance chez ce prestataire unique peut se propager simultanément à travers l’ensemble du secteur. Le Registre d’Information, agrégé à l’échelle européenne, permet précisément aux autorités d’identifier ces concentrations de risque avant qu’elles ne se matérialisent en crise sectorielle, un objectif de stabilité financière qui dépasse largement la seule conformité individuelle de chaque entité soumettant son propre registre.

Une insuffisance de ce référentiel signifie concrètement, pour la Directions des Systèmes d’Information comme pour la Direction des Risques, qu’une partie du patrimoine contractuel de l’entreprise reste invisible au moment même où elle est examinée par un régulateur, ce qui expose l’entité à un risque de non-conformité qu’aucune bonne foi ne suffit à corriger après coup.

Qu’est-ce que le Registre d’Information, Précisément

Le Registre d’Information est une cartographie structurée et standardisée de tous les accords contractuels qu’une entité financière entretient avec des prestataires de services TIC (technologies de l’information et de la communication). Il doit couvrir non seulement les prestataires directement contractualisés par l’entité elle-même, mais aussi, dans certains cas, les sous-traitants de ces prestataires lorsque leur défaillance pourrait affecter significativement les services fournis à l’entité financière.

Ce registre se décline en plusieurs niveaux : un registre au niveau de chaque entité individuelle, et pour les groupes, un registre consolidé au niveau du groupe qui doit rester cohérent avec les registres individuels de chaque filiale. Cette exigence de cohérence entre niveaux est précisément l’un des points techniques les plus difficiles à satisfaire, et l’une des causes principales des 116 non-conformités testées lors de l’exercice à blanc de 2024, notamment pour les groupes ayant grandi par acquisitions successives sans jamais harmoniser leurs référentiels contractuels internes.

La Structure du Registre : les Modèles de Données

Techniquement, le Registre d’Information s’appuie sur des modèles de données (templates) standardisés définis par les autorités européennes de supervision, couvrant plusieurs catégories d’informations : l’identification de l’entité financière elle-même, l’identification de chaque prestataire TIC tiers (y compris ses identifiants légaux standardisés comme le LEI lorsqu’applicable), la nature précise du service fourni selon une taxonomie prédéfinie, les caractéristiques contractuelles (durée, conditions de résiliation, droits d’audit), et enfin l’évaluation de criticité de chaque prestataire et de chaque fonction sous-traitée.

Ces modèles de données ne sont pas de simples suggestions de bonnes pratiques — ils sont contraignants dans leur structure exacte, avec des formats de champs précis, des listes de valeurs autorisées fermées pour de nombreux champs, et des règles de validation croisée entre champs qui, si elles ne sont pas respectées, génèrent automatiquement les non-conformités mesurées lors des contrôles qualité.

Ce Qu’il Faut Fournir, Champ par Champ

Pour chaque accord contractuel avec un prestataire TIC, le registre exige a minima : l’identité complète et les identifiants légaux du prestataire, le pays où le service est réellement fourni (qui peut différer du pays du siège social du prestataire), la date de début et de fin du contrat, une description structurée de la nature du service selon la taxonomie DORA, une indication claire si le service supporte une fonction critique ou importante de l’entité, les modalités de sous-traitance éventuelle par le prestataire lui-même, et les clauses contractuelles essentielles concernant la résiliation, la portabilité des données, et les droits d’audit et d’accès de l’entité et des autorités de supervision.

Un point technique souvent sous-estimé : chaque prestataire doit être identifié de manière rigoureusement cohérente à travers l’ensemble des contrats déclarés, y compris lorsque plusieurs filiales de l’entité travaillent avec le même prestataire sous des noms légaux légèrement différents ou via des filiales locales du prestataire lui-même. Cette exigence de cohérence des identifiants est précisément l’un des points les plus fréquemment ratés lors du test blanc de 2024.

Au-delà de ces champs obligatoires, le registre distingue également les fonctions supportant directement une activité critique ou importante de celles jouant un rôle secondaire ou de support général — une distinction qui détermine le niveau de détail attendu pour chaque entrée. Un contrat de fourniture de licences bureautiques standard n’exige pas le même niveau de granularité descriptive qu’un contrat d’hébergement du système de paiement central, même si les deux doivent techniquement figurer dans le registre dès lors qu’ils dépassent certains seuils de matérialité définis par l’entité elle-même dans sa méthodologie documentée.

La question de la localisation géographique réelle du service mérite également une attention particulière. De nombreux contrats de service cloud ou d’hébergement impliquent une architecture technique distribuée sur plusieurs pays, parfois plusieurs continents, pour des raisons de résilience ou de performance — le registre exige de documenter précisément où les données et les traitements ont effectivement lieu, pas seulement le pays du siège social du prestataire contractant, une nuance qui demande une collaboration technique étroite avec les équipes d’architecture pour être correctement renseignée, et qui constitue en pratique l’un des champs les plus souvent mal documentés faute de coordination entre juridique et technique.

Le Lien Entre le Registre et les Tests d’Intrusion Ciblés

Le Registre d’Information ne fonctionne pas de manière isolée par rapport aux autres piliers de DORA. Les prestataires classés critiques dans le registre deviennent potentiellement des cibles du périmètre des tests d’intrusion ciblés par la menace (TLPT) exigés pour les entités les plus significatives — un lien direct qui signifie qu’une classification de criticité erronée, trop permissive ou trop restrictive, a des conséquences bien au-delà du seul registre lui-même.

Une classification trop permissive, sous-estimant la criticité réelle d’un prestataire, expose l’entité à un risque non couvert par les tests de résilience appropriés — le prestataire échappe au périmètre de test alors qu’une défaillance réelle aurait un impact significatif sur la continuité des fonctions critiques concernées. À l’inverse, une classification trop restrictive, sur-classant des prestataires en réalité secondaires, dilue l’attention et les ressources de test sur un périmètre inutilement large, au détriment de la profondeur d’analyse portée aux prestataires réellement critiques.

La Classification de Criticité, Étape la Plus Sensible

Déterminer si un prestataire ou un service sous-traité est « critique » ou « important » au sens de DORA n’est pas affaire de jugement informel. La méthodologie doit s’appuyer sur des critères objectifs et documentés : l’impact d’une défaillance du service sur la continuité des fonctions critiques de l’entité, l’existence ou l’absence d’alternatives de substitution rapide, la concentration du risque (plusieurs fonctions critiques dépendant du même prestataire unique), et la sensibilité des données traitées par ce prestataire.

Une classification de criticité informelle ne résiste jamais à l’examen d’un régulateur exigeant une justification documentée.

Cette classification a des conséquences concrètes bien au-delà du seul registre : un prestataire classé critique entre dans le périmètre potentiel des tests d’intrusion ciblés par la menace, fait l’objet d’exigences contractuelles renforcées (droits d’audit, plans de sortie documentés, clauses de portabilité), et peut, pour les prestataires les plus significatifs à l’échelle sectorielle, être directement supervisé par les autorités européennes elles-mêmes au titre du cadre de supervision des prestataires critiques tiers introduit par DORA.

Les Échéances Pays par Pays

Bien que DORA soit un règlement européen directement applicable, les modalités pratiques de soumission du Registre d’Information — portails techniques, formats de dépôt, dates limites précises — restent gérées au niveau national par chaque autorité compétente, ce qui produit un calendrier hétérogène malgré l’harmonisation du fond réglementaire.

Aux Pays-Bas, l’Autoriteit Financiële Markten (AFM) a fixé une échéance de soumission au 31 mars 2026 pour les entités sous sa supervision. Au Luxembourg, la Commission de Surveillance du Secteur Financier (CSSF) a ouvert son portail de soumission dès le 11 février 2026, avec une échéance de dépôt qui suit. Au niveau consolidé européen, les autorités européennes de supervision (ESA) ont fixé une échéance de référence au 30 avril 2026 pour l’ensemble du secteur, une date qui sert de filet de sécurité même dans les pays où l’autorité nationale n’a pas encore précisé de calendrier propre.

Cette hétérogénéité calendaire crée un défi particulier pour les groupes multinationaux : une même entité mère peut devoir soumettre des registres cohérents mais synchronisés sur des dates différentes selon les pays où ses filiales sont supervisées, ce qui exige une préparation centralisée bien en amont de la première échéance nationale applicable, plutôt qu’une approche pays par pays traitée indépendamment, avec le risque réel de découvrir une incohérence entre deux registres nationaux seulement après que le premier ait déjà été soumis officiellement.

Pourquoi les Échéances Varient Malgré un Règlement Unique

Cette variation nationale des modalités pratiques, bien que déroutante au premier abord, découle d’une distinction juridique précise : DORA harmonise les exigences de fond (quelles données, sous quel format, avec quelle méthodologie de classification), mais laisse aux autorités nationales compétentes la responsabilité opérationnelle de la collecte, y compris le choix des outils techniques de soumission et l’organisation de leur calendrier de supervision propre.

Cette répartition des responsabilités reflète l’architecture plus large de la supervision financière européenne, où les autorités nationales conservent un rôle opérationnel de premier niveau, coordonné mais non remplacé par les autorités européennes centrales. Pour une entreprise opérant dans plusieurs pays, ignorer cette nuance revient à risquer de manquer une échéance nationale spécifique en se fiant uniquement à la date consolidée européenne, qui n’est parfois qu’un plafond maximal, pas la référence opérationnelle réelle pour chaque marché.

La Date de Référence du 31 Décembre 2025

Un point technique déterminant pour la soumission de 2026 : le Registre d’Information doit refléter la situation contractuelle de l’entité telle qu’elle existait au 31 décembre 2025 — une photographie à une date précise, pas un état courant au moment de la soumission elle-même. Cette exigence de rétrospection pose un défi réel pour toute organisation n’ayant pas mené sa collecte de données de façon continue tout au long de 2025.

Reconstituer rétrospectivement une situation contractuelle à une date passée exige de retrouver les contrats effectivement en vigueur à cette date précise, y compris ceux résiliés depuis, et d’exclure ceux signés après cette date même s’ils sont aujourd’hui actifs. Cette reconstruction rétrospective est nettement plus coûteuse en temps qu’une collecte menée en continu, et constitue une raison supplémentaire de ne pas repousser la mise en place d’un processus de mise à jour continue pour les cycles suivants.

Le Piège de la Sous-Traitance en Cascade

L’une des difficultés les plus sous-estimées de la construction du Registre d’Information concerne la sous-traitance en cascade : un prestataire principal, correctement identifié et classé par l’entité financière, fait lui-même appel à des sous-traitants pour tout ou partie du service fourni, sous-traitants qui peuvent eux-mêmes ne pas être visibles ni documentés dans les contrats initiaux signés par l’entité.

DORA exige que cette chaîne de sous-traitance soit documentée dès lors que la défaillance d’un sous-traitant en cascade pourrait affecter significativement une fonction critique ou importante de l’entité financière — ce qui signifie concrètement qu’une entité ne peut pas se contenter de documenter ses relations contractuelles directes, elle doit activement interroger ses prestataires principaux sur leur propre chaîne de sous-traitance, une démarche qui demande une coopération contractuelle explicitement prévue dans les accords, souvent absente des contrats signés avant l’entrée en application de DORA.

Construire la Gouvernance Avant l’Outil

Face à la complexité technique du Registre d’Information, le réflexe naturel consiste à chercher un outil logiciel capable d’automatiser sa production. Ce réflexe, bien que compréhensible, inverse l’ordre des priorités qui fonctionne réellement : sans gouvernance préalable claire sur qui possède quelle donnée, qui valide la classification de criticité, et qui est responsable de la mise à jour continue, aucun outil ne produit un registre fiable — il ne fait qu’automatiser la production d’un registre construit sur des fondations incertaines.

La gouvernance qui fonctionne combine un responsable de programme unique avec un mandat clair couvrant à la fois la gestion des risques TIC et la coordination du registre, des propriétaires de données nommés pour chaque grande catégorie de prestataires, un comité incluant le juridique, les achats, la DSI et la gestion des risques pour arbitrer les décisions de classification, et un sponsor exécutif ayant l’autorité de trancher les désaccords entre fonctions.

Ce sponsor exécutif joue un rôle souvent sous-estimé dans la réussite du programme. Sans une autorité claire au-dessus des fonctions techniques et juridiques, les désaccords sur la classification de criticité d’un prestataire donné — par exemple entre une équipe achats souhaitant éviter les obligations contractuelles renforcées associées à une classification critique, et une équipe risques insistant sur une classification plus stricte — tendent à se résoudre en faveur de la réponse organisationnellement la plus commode plutôt que la réponse factuellement correcte. C’est précisément ce type de dérive silencieuse qui produit les incohérences détectées lors des contrôles qualité.

Un autre élément de gouvernance fréquemment négligé concerne la formation des équipes achats et juridiques qui négocient au quotidien les nouveaux contrats TIC. Ces équipes, en première ligne de la relation avec les prestataires, doivent comprendre suffisamment les exigences DORA pour intégrer dès la négociation contractuelle les clauses nécessaires — droits d’audit, plans de sortie documentés, obligations de notification de sous-traitance — plutôt que de découvrir a posteriori qu’un contrat signé ne permet pas de répondre aux exigences du registre faute de clause appropriée.

Le Coût d’une Non-Conformité Découverte Tardivement

Au-delà des sanctions formelles prévues par le règlement, variables selon les États membres et pouvant inclure des astreintes, des suspensions d’activité, voire un retrait d’agrément dans les cas les plus graves, le coût réel d’une non-conformité du Registre d’Information découverte lors d’une inspection de supervision dépasse largement celui d’une correction menée en amont.

Une entité qui découvre ses lacunes lors d’un contrôle réel doit produire un plan de remédiation sous un calendrier imposé par le régulateur, avec un niveau de scrutin renforcé sur les cycles de soumission suivants — une charge de travail concentrée dans l’urgence, sous observation externe, plutôt qu’un correctif mené discrètement à son propre rythme. Cette différence de contexte n’est pas seulement une question de confort organisationnel : elle affecte directement la crédibilité de l’entité aux yeux de son superviseur pour les années suivantes, un capital de confiance qui met du temps à se reconstruire une fois entamé.

Un plan de remédiation mené sous pression réglementaire coûte toujours plus cher qu’une correction proactive.

Maintenir le Registre Vivant Après la Première Soumission

La première soumission du Registre d’Information n’est qu’un jalon, pas une fin en soi. DORA exige une mise à jour continue du registre à mesure que de nouveaux contrats sont signés, que des contrats existants sont modifiés ou résiliés, et que la classification de criticité de certains prestataires évolue avec les changements organisationnels de l’entité elle-même.

Un processus de mise à jour continue bien conçu déclenche automatiquement une revue du registre à chaque signature de nouveau contrat TIC, plutôt que de dépendre d’un rappel périodique manuel facilement oublié. Les organisations qui réussissent ce chantier durablement intègrent cette revue directement dans leur processus de validation contractuelle standard, de sorte qu’aucun nouveau contrat TIC ne peut être finalisé sans une évaluation DORA associée.

Un registre construit une fois puis jamais mis à jour se périme dès le contrat suivant signé.

Les Erreurs les Plus Coûteuses

Attendre la date de soumission pour découvrir les incohérences de données. Un audit interne mené plusieurs mois avant l’échéance laisse le temps de corriger sans pression réglementaire directe.

Laisser chaque filiale gérer sa propre liste de prestataires sans référentiel central. C’est la cause la plus fréquente d’incohérence d’identifiants constatée lors du test blanc de 2024.

Ignorer la sous-traitance en cascade au-delà des contrats directs. Une chaîne de sous-traitance non documentée expose l’entité à un risque non couvert par son propre registre.

Choisir un outil logiciel avant d’avoir clarifié la gouvernance et les définitions. L’outil automatise ce qui existe déjà — il ne corrige jamais une gouvernance absente en amont.

Traiter la classification de criticité comme un exercice isolé plutôt qu’une méthodologie documentée et réutilisable. Sans critères objectifs écrits, chaque nouvelle évaluation repart de zéro et produit des incohérences avec les classifications précédentes.

Négliger la formation des équipes achats et juridiques qui négocient les contrats au quotidien. Un contrat signé sans les clauses DORA appropriées (droits d’audit, plans de sortie, notification de sous-traitance) crée un manque impossible à corriger rétroactivement sans renégociation.

Sous-estimer le temps nécessaire à la reconstruction rétrospective pour la date de référence du 31 décembre 2025. Une collecte non continue tout au long de l’année impose un travail d’archéologie contractuelle bien plus long qu’anticipé initialement.

Étude de Cas : un Assureur Multi-Pays

Un assureur européen opérant dans quatre pays engage la construction de son Registre d’Information début 2025, convaincu que son système de gestion des achats, utilisé depuis plusieurs années, couvre déjà l’essentiel des données nécessaires. La première extraction révèle rapidement les limites de cette hypothèse : le système d’achat couvre correctement les contrats signés au niveau du siège, mais chaque filiale nationale gère une part significative de ses propres contrats informatiques locaux, notamment pour des services d’hébergement régional et de support technique de proximité, entièrement absents du système central.

L’entreprise engage alors une revue systématique impliquant les responsables achats et juridiques de chaque filiale, avec un référentiel central nouvellement construit pour consolider l’ensemble. La classification de criticité, initialement réalisée de façon informelle par la DSI centrale, est reprise selon une méthodologie documentée validée par le comité des risques, incluant des critères écrits sur la concentration du risque et la disponibilité d’alternatives de substitution.

Le processus prend sept mois au total, avec une charge de travail concentrée sur les trois premiers mois de cartographie et les deux derniers mois de validation croisée entre les registres nationaux et le registre consolidé du groupe. Le registre final soumis présente un taux de cohérence interne validé à plus de 96% lors d’un audit blanc mené juste avant la soumission officielle — un résultat que l’assureur attribue directement à l’implication précoce des équipes juridiques locales, plutôt qu’une tentative de construction centralisée sans relais dans chaque pays.

Un enseignement secondaire mais précieux de cette expérience concerne la communication interne pendant le chantier. Les équipes locales, initialement réticentes face à ce qu’elles percevaient comme une charge administrative supplémentaire imposée par le siège, ont changé d’attitude une fois qu’elles ont compris que le référentiel central leur simplifierait aussi, à terme, leur propre gestion contractuelle locale — un bénéfice secondaire souvent négligé dans la communication initiale de ce type de programme, qui se limite trop souvent au seul argument de la conformité réglementaire sans valoriser les gains opérationnels concrets pour les équipes qui doivent fournir l’effort de collecte.

Checklist de Préparation

Cette checklist reprend les points de vigilance identifiés tout au long de cet article, à utiliser comme base d’un premier diagnostic avant tout audit plus formel.

• Un référentiel central unique de tous les prestataires TIC du groupe existe-t-il, incluant les contrats gérés localement par chaque filiale ?
• La méthodologie de classification de criticité est-elle documentée avec des critères objectifs et écrits ?
• La chaîne de sous-traitance en cascade des prestataires principaux a-t-elle été activement recherchée, pas seulement supposée absente ?
• La situation contractuelle au 31 décembre 2025 peut-elle être reconstituée fiablement si la collecte n’a pas été continue ?
• Les échéances nationales spécifiques à chaque pays d’opération sont-elles connues et suivies dans un calendrier partagé ?
• Un processus de mise à jour continue est-il intégré au processus de validation contractuelle standard ?

FAQ

Faut-il inclure tous les prestataires informatiques, même les plus mineurs ?
Non — DORA se concentre sur les prestataires supportant des fonctions critiques ou importantes, mais la difficulté réside précisément dans l’évaluation rigoureuse de ce qui est réellement critique, pas dans une inclusion exhaustive de tout contrat informatique existant.

Le Registre d’Information doit-il être public ?
Non, il est soumis aux autorités de supervision compétentes, pas publié publiquement, mais il peut être consulté dans le cadre d’inspections ou de demandes d’information des autorités.

Que se passe-t-il en cas d’erreur découverte après la soumission ?
Une correction reste possible, mais elle attire davantage l’attention du superviseur qu’une soumission propre dès le départ — d’où l’intérêt d’un audit interne préalable rigoureux.

Les contrats en devise étrangère ou hors zone euro posent-ils une difficulté particulière ?
La structure du registre accepte différentes devises, mais la cohérence de déclaration (montants, pays de fourniture réelle du service) doit rester rigoureuse pour éviter les incohérences de contrôle qualité.

Une fusion ou acquisition récente complique-t-elle la construction du registre ?
Oui significativement — les contrats hérités de l’entité acquise doivent être intégrés au référentiel central et reclassés selon la méthodologie de criticité du groupe acquéreur, un chantier souvent sous-estimé dans les plans d’intégration post-fusion.

Comment gérer les contrats historiques dont la documentation est incomplète ou introuvable ?
Une reconstruction fondée sur les meilleures preuves disponibles (factures, correspondances, accès systèmes effectifs) reste préférable à une omission pure et simple, à condition de documenter explicitement la méthode de reconstitution utilisée pour chaque contrat concerné, ce qui permet de justifier la démarche auprès d’un superviseur en cas de question.

Le registre doit-il inclure les prestataires de conseil ou d’audit externe ?
Cela dépend de la nature exacte du service rendu — un cabinet de conseil fournissant un simple avis ponctuel n’entre généralement pas dans le périmètre, mais un prestataire opérant ou administrant un système d’information critique pour le compte de l’entité y entre bien, la distinction se faisant sur la nature opérationnelle du service, pas sur la catégorie commerciale du prestataire.

Regard d’Expert

Ayant structuré des dictionnaires de données et des comités de gouvernance dans des contextes multi-pays, je reconnais dans la construction du Registre d’Information DORA un schéma que j’observe systématiquement sur ce type de chantier : la difficulté n’est jamais la compréhension du texte réglementaire, elle est dans la capacité organisationnelle à produire une donnée cohérente, tra��able et à jour à travers des filiales qui ont historiquement fonctionné en silos.

Écrit par Steeve Vignissy, consultant senior en transformation digitale chez Notoriti, avec une expérience de coordination d’audits de conformité et de structuration de dictionnaires de données dans des contextes multi-pays.

👉 Contactez Notoriti pour structurer votre Registre d’Information DORA avant la prochaine échéance, qu’il s’agisse d’un premier cycle de conformité ou d’une refonte après un premier exercice révélant des lacunes structurelles.

Pour Aller Plus Loin

• Test d’Intrusion Ciblé par la Menace (TLPT) : Ce Que DORA Exige
• Incident Reporting Under DORA (EN)
• DORA Third-Party Risk (EN)

Références

• Orbiq, DORA Compliance Guide 2026: Requirements & Deadlines, mars 2026
• Mitratech, What Is DORA? What Financial Institutions Need to Know in 2026, juin 2026
• Autorités de supervision nationales (AFM, CSSF), calendriers de soumission 2026