DORA 2026 : pourquoi un contrat connu reste-t-il introuvable dans le registre ?

Le contrat existe au service achats, la facture chez finance et le fournisseur dans un inventaire technique. Pourtant, personne ne peut expliquer rapidement quelle entité utilise quel service TIC, pour quelle fonction et avec quelles dépendances. DORA oblige les entités financières à tenir et mettre à jour un registre des accords contractuels avec leurs prestataires tiers TIC. En 2026, la CSSF a demandé une soumission annuelle via eDesk et a signalé que seulement 40 % des entités attendues avaient transmis au 16 mars, avant les contrôles supplémentaires des autorités européennes. Ce chiffre ne prouve pas une non-conformité individuelle ; il révèle une friction de production et de correction. Cette lecture construit une offre d'entrée sur un échantillon de contrats, puis une acquisition B2B ciblée sur les établissements et prestataires dont la donnée fournisseur change souvent. Le résultat vendu n'est pas une certification DORA : c'est un registre rejouable, des erreurs attribuées et un plan de correction avant le prochain cycle.

Le registre rassemble, aux niveaux pertinents, les accords contractuels portant sur des services TIC fournis par des tiers. Il doit rester à jour et permettre l'identification des entités, prestataires, services, fonctions et caractéristiques attendues selon les modèles et contrôles applicables.

La ligne n'est pas un résumé libre du contrat. Elle dépend d'un schéma, d'identifiants et de relations cohérentes entre tables.

Les validations évoluent et peuvent être appliquées à davantage de champs. La CSSF a averti en 2026 qu'un registre accepté précédemment pouvait être rejeté ; la traçabilité de la source et la capacité de corriger comptent donc autant que le premier fichier.

Le premier achat sélectionne dix à vingt contrats, reconstruit leurs relations dans le registre, exécute les contrôles disponibles et classe les écarts par donnée, décision ou format. Il livre un backlog attribué et un protocole de correction.

L'échantillon mélange un prestataire majeur, un service récent, un contrat modifié et une dépendance indirecte. Il ne prétend pas couvrir tout le groupe.

Un identifiant manquant se corrige dans la donnée ; la qualification d'une fonction, d'un service ou d'une dépendance peut exiger un arbitrage. Le pilote sépare ces catégories pour éviter qu'un prestataire technique ne tranche silencieusement une décision réglementaire.

Une fusion, une migration, un renouvellement fournisseur, un changement de sous-traitant, une correction CSSF ou une centralisation des achats crée un besoin immédiat. Les prestataires TIC exposés à plusieurs clients financiers ont aussi intérêt à industrialiser leurs preuves.

Le ciblage distingue entités financières et fournisseurs : les premières portent le registre ; les seconds peuvent accélérer la réponse contractuelle et documentaire.

L'offre fournisseur prépare un dossier réutilisable : identité, services, chaînes de sous-traitance, lieux, continuité, sécurité et changements. Chaque client conserve sa qualification et ses obligations ; le prestataire réduit seulement le délai et les incohérences de réponse.

La lecture NIS 2 peut compléter le contexte pour un fournisseur exposé à plusieurs régimes, sans fusionner leurs preuves.

La mesure suit taux de lignes traçables, erreurs de validation, temps de correction, décisions en attente et contrats intégrés à temps. Elle ne produit ni note réglementaire ni garantie d'acceptation par la CSSF ou les autorités européennes.

Le parcours d'entrée collecte dès la signature identifiants, services, entités utilisatrices, sous-traitants, lieux, dates et propriétaires de décision. Il crée une ligne provisoire, signale les champs non tranchés et empêche leur transformation silencieuse en valeur par défaut.

Achats ne devient pas responsable de la qualification réglementaire, ni IT du contrat. Un formulaire partagé orchestre les contributions si chaque champ garde sa source et son propriétaire. Le test suit le temps entre signature, validation et disponibilité dans le registre.

L'équipe regroupe les erreurs par cause racine, corrige d'abord le référentiel commun, rejoue les contrôles puis traite les exceptions. Corriger ligne par ligne masque souvent une seule règle ou une source défectueuse.

Chaque lot conserve son journal afin de prouver ce qui a changé et pourquoi.

Le registre change avec les contrats, services, entités et sous-traitants. Une maintenance événementielle traite les changements au fil de l'eau ; une répétition annuelle prépare la soumission et vérifie les contrôles actualisés.

Elle améliore données et processus ; elle ne décide pas seule du périmètre DORA, de la criticité, de la qualification réglementaire ou de l'acceptation d'un registre. Les textes, modèles et consignes CSSF en vigueur prévalent.

Une dernière revue rapproche le registre, l'inventaire fournisseur et les changements contractuels intervenus depuis la date de référence. Elle recherche les entrées tardives, les résiliations et les services déplacés. Les écarts deviennent des tâches datées ; ils ne sont pas corrigés automatiquement sans confirmation de leur propriétaire.

Le journal conserve également les contrôles exécutés, leur version et le résultat obtenu afin que le cycle suivant puisse expliquer toute différence.

Oui, si elle résout une rupture précise et laisse la décision à son propriétaire. Le test offert évalue la compatibilité de cette approche avec vos difficultés d'acquisition et nos synergies possibles.