Du tableur au modèle vivant : le registre des tiers IT et de la sous-traitance comme architecture d'entreprise

Le registre que tout le monde tient, et que presque personne ne tient à jour

Si vous êtes une entité régulée de l'UE — banque, établissement de paiement ou d'investissement, acteur de fonds, entité essentielle ou importante au titre du régime de sécurité des réseaux et de l'information — vous êtes attendu pour tenir une forme de registre de vos tiers IT et arrangements de sous-traitance. DORA le présente comme un registre des arrangements de tiers IT ; la CSSF porte de longue date des attentes de documentation de la sous-traitance pour les entités supervisées au Luxembourg ; NIS2 ajoute par-dessus des attentes de sécurité de la chaîne d'approvisionnement. Des mots différents, un même artefact récurrent : une liste de qui vous dépend, et pour quoi.

La difficulté est rarement de produire le registre une fois. La difficulté est de le garder vrai. La plupart des registres vivent dans un tableur, et un tableur est un instantané : le jour où il est terminé, il commence à dériver. Une application est mise hors service, un prestataire est changé, un sous-traitant est ajouté derrière un prestataire, une fonction est reclassée — et le fichier ne bouge pas, car le mettre à jour est la corvée trimestrielle de quelqu'un plutôt qu'un sous-produit de la façon dont l'organisation change réellement. Cet article parle de refermer cet écart en traitant le registre non comme un document mais comme une vue d'un modèle d'architecture vivant. C'est une aide à la documentation, pas un conseil juridique, et nous ne citerons ni numéros d'articles ni dates précis — le texte exact et son application à votre entité relèvent de votre fonction conformité et d'un conseil qualifié.

Pourquoi un registre-tableur dérive — et pas un modèle

Un registre-tableur a un défaut structurel : c'est une copie. Il réénonce, dans ses propres cellules, des faits qui vivent déjà ailleurs — l'inventaire applicatif, les contrats fournisseurs, les niveaux de criticité. Chaque copie d'un fait est un fait qui peut se désynchroniser, et un registre n'est que copies. Pire, les relations qui comptent le plus — quelle fonction ce prestataire soutient vraiment, quel sous-traitant se tient derrière lui — sont aplaties en texte libre, où elles ne peuvent être ni interrogées, ni comptées, ni réconciliées.

Un modèle inverse cela. Au lieu de réénoncer les faits, il relie les objets qui les portent : une fonction critique ou importante pointe vers les applications qui la soutiennent ; chaque application pointe vers les tiers et prestataires de sous-traitance derrière elle ; chaque prestataire peut pointer vers ses sous-traitants. Le registre devient une vue sur ces liens plutôt qu'un fichier séparé. Changez le fournisseur d'une application une fois, et la carte de dépendances, le décompte de concentration et l'entrée du registre le reflètent tous, car ils lisent tous le même objet. La limite honnête tient : quelqu'un maintient encore le modèle, et il ne vaut que par les données saisies. Ce qui disparaît, c'est la taxe de réconciliation silencieuse de plusieurs copies qui dérivent.

• Un tableur réénonce les faits ; un modèle relie les objets qui les portent
• Les relations (fonction-prestataire, prestataire-sous-traitant) deviennent interrogeables, pas du texte libre
• Un seul changement de fournisseur met à jour ensemble dépendances, concentration et registre
• Toujours vos données à maintenir — mais plus plusieurs copies à réconcilier à la main

Relier fonctions critiques aux applications aux tiers

Le modèle a une forme naturelle qui reflète ce dont la réglementation se soucie. En haut se tiennent les fonctions critiques ou importantes — paiements, entrée en relation, administration de fonds, reporting réglementaire. Chaque fonction est soutenue par une ou plusieurs applications. Chaque application repose sur de la technologie, déplace de la donnée et dépend de tiers : l'éditeur logiciel, l'hébergeur ou fournisseur cloud, l'opérateur externalisé. Disposé en modèle connecté plutôt qu'en liste plate, cela vous laisse suivre n'importe quelle fonction critique vers le bas, vers tout ce sur quoi elle s'appuie.

Chaque objet porte les attributs qui rendent le registre signifiant — propriétaire, criticité, lieu d'hébergement, nature de l'arrangement — et, point crucial, les liens vers ce qui se tient au-dessus et en dessous. Avec cela en place, les questions qu'une conversation de supervision ou d'audit pose deviennent des requêtes plutôt que des projets de recherche : quels tiers soutiennent cette fonction critique, quelles applications seraient affectées si ce prestataire tombait, et quels arrangements soutiennent plus d'une fonction critique. Le référentiel organise et relie cette image ; il ne classe pas vos fonctions à votre place ni ne juge si un arrangement est dans le périmètre — ces appréciations restent du côté de vos fonctions risque et conformité et de vos conseils.

• Fonctions critiques ou importantes reliées aux applications qui les soutiennent
• Chaque application reliée à ses tiers et prestataires de sous-traitance
• Les attributs qui comptent pour un registre : propriétaire, criticité, hébergement, type d'arrangement
• Questions de supervision traitées comme des requêtes sur le modèle, pas comme une recherche neuve

Chaînes de sous-traitance et concentration, rendues dénombrables

Le plus difficile à garder honnête dans un registre, c'est la profondeur derrière un prestataire. Un prestataire de premier rang est visible ; le sous-traitant sur lequel il s'appuie — la quatrième partie de votre chaîne — est celui qui disparaît discrètement d'un tableur, capté au mieux comme une note dans une cellule que personne ne revisite. Or c'est précisément là que se concentre le risque moderne de chaîne d'approvisionnement, et précisément ce sur quoi les superviseurs interrogent de plus en plus.

Dans un modèle connecté, la chaîne est un chemin, pas une note. Un objet prestataire peut pointer vers les sous-traitants derrière lui, si bien que vous pouvez tracer une fonction critique non seulement jusqu'à son prestataire de premier rang mais le long de la chaîne. Une fois les liens établis, la concentration devient de l'arithmétique plutôt qu'une affirmation. Suivez chaque fonction critique jusqu'aux prestataires — et sous-traitants — derrière elle et les amas remontent : le prestataire qui se tient derrière une part disproportionnée de ce qui compte, la plateforme devenue porteuse sans décision, la quatrième partie que deux de vos prestataires prétendument indépendants partagent en secret. C'est exactement l'analyse que cernent à la fois le travail DORA sur le risque de concentration et les attentes NIS2 de chaîne d'approvisionnement. Pour être clair sur la frontière : le modèle révèle et documente la chaîne et la concentration ; l'appréciation d'un prestataire, et la posture contractuelle et de notification autour, restent vôtres et celles de vos conseils.

• Chaînes de sous-traitance modélisées en chemins, traçables au-delà du premier rang
• Concentration comptée, pas affirmée, là où de nombreuses fonctions partagent un prestataire
• Chevauchement caché de quatrième partie entre prestataires nominalement indépendants, révélé
• Documente et révèle la chaîne — l'appréciation du risque reste à vos fonctions

Garder le registre vivant : le changement passe par le modèle

Un registre gagne son utilité au moment où quelque chose change, car c'est là qu'un registre obsolète devient dangereux. L'intérêt de le tenir comme un modèle, c'est que le même geste qui change la réalité met à jour le registre. Quand l'équipe d'architecture met une application hors service, change d'hébergeur ou intègre un nouveau service externalisé dans le modèle, la vue du registre change avec lui — il n'y a pas de fichier séparé attendant un rattrapage trimestriel qui pourrait ne jamais venir.

Cela rend aussi le registre défendable. Parce que le modèle est versionné, vous pouvez montrer, depuis une source unique, à quoi ressemblait votre image de dépendances à un instant donné, ce qui a changé, et quand — la différence entre un récit que vous reconstruisez sous pression de délai et un récit que vous savez prouver à la demande. Nous sommes précis sur ce que c'est et ce que ce n'est pas : un référentiel EA tient la documentation à jour et connectée et rend la preuve plus simple à assembler. Il n'effectue pas la classification légale, ne mène pas votre diligence sur les tiers, et ne garantit pas que chaque champ requis du registre soit complet. La complétude et la suffisance légale du registre restent de la responsabilité de votre institution, avec votre fonction conformité et un conseil qualifié.

• Le changement qui met à jour la réalité met à jour la vue du registre — pas de corvée trimestrielle séparée
• Modèle versionné : montrez l'image de dépendances, ce qui a changé, et quand
• Preuve assemblée à la demande, pas reconstruite sous pression de délai
• La complétude et la suffisance légale du registre restent de la responsabilité de l'institution

Pourquoi un modèle souverain, hébergeable en UE ou on-premise convient aux entités régulées

Un registre de vos fonctions critiques et des tiers derrière elles est proche d'un plan de vos points les plus exposés — ce qui fait de l'endroit où il vit une question en soi. Trois propriétés d'ArchiLU comptent davantage ici que presque partout ailleurs. Il peut être hébergé dans l'UE ou en on-premise, si bien que cette carte sensible ne quitte pas un périmètre que vous contrôlez. Il est disponible nativement en français et en anglais, ce qui colle à un marché européen régulé où le même modèle doit servir un organe de direction francophone et un audit ou un échange de supervision en anglais. Et il est licencié pour des utilisateurs illimités, si bien que les personnes du risque, de la conformité, de l'IT et de l'architecture qui doivent toutes lire la même image de dépendances ne sont pas bridées par un nombre de sièges.

La frontière honnête, redite parce qu'elle compte : ArchiLU est un référentiel d'architecture d'entreprise qui organise et relie ces données et rend la preuve plus simple à assembler et à tenir à jour. Ce n'est pas un produit de registre réglementaire, pas une certification de conformité, et nous restons transparents sur les certifications que nous ne détenons pas encore. Ce qu'il donne à une entité régulée, c'est un modèle souverain, multilingue et connecté de ses fonctions critiques, applications et chaînes de tiers — la colonne vertébrale sur laquelle reposent les conversations DORA, NIS2 et CSSF, tandis que la complétude légale du registre reste vôtre. Pour situer le plus vite votre propre pratique sur les dimensions portefeuille, gouvernance et risque, l'évaluation gratuite de maturité EA note dix dimensions et renvoie un plan priorisé en une dizaine de minutes — une première étape sensée avant de décider de voir le modèle sur vos propres données lors d'une démo.