CSSF et architecture d'entreprise : une seule carte pour la documentation IT, sous-traitance et résilience

Ce que la CSSF attend des entités supervisées de savoir montrer

Si vous êtes supervisé par la CSSF — banque, PSF, entreprise d'investissement, acteur de fonds ou autre entité régulée établie au Luxembourg — un thème récurrent traverse les attentes portées sur vous : savoir montrer comment fonctionnent vos systèmes d'information, qui les exploite, ce que vous avez sous-traité, et comment vous continueriez d'opérer si quelque chose tombait. La substance est reconnaissable même sans citer une circulaire particulière : gouverner votre risque IT, documenter et superviser vos arrangements de sous-traitance et de tiers IT, et savoir prouver votre résilience opérationnelle.

Cet article est une aide à la préparation et à la documentation, pas un conseil juridique, et nous ne citerons ni numéros ni dates de circulaires précis — le texte exact et son application à votre type d'entité relèvent d'un conseil qualifié et de votre fonction conformité. Ce qu'il montre, c'est où l'architecture d'entreprise donne une colonne vertébrale à ces attentes, car presque chacune présuppose la même chose : que vous savez réellement voir vos capacités, vos applications, vos flux de données et les tiers derrière eux, comme une seule image à jour et connectée plutôt que des documents éparpillés.

Chaque attente repose sur une question préalable : savez-vous montrer votre architecture ?

Gestion du risque IT, supervision de la sous-traitance et résilience opérationnelle sonnent comme des dossiers séparés possédés par des personnes séparées. Ils partagent un prérequis caché. On n'évalue pas le risque d'un système qu'on n'a pas inventorié. On ne supervise pas un arrangement de sous-traitance dont on ne sait pas tracer le prestataire jusqu'à la fonction qu'il soutient. On ne prouve pas la résilience d'une fonction critique si l'on ignore de quoi elle dépend. La question préalable — savez-vous montrer votre architecture, à jour et connectée — se tient sous toute la conversation de supervision.

Pour la plupart des entités, cette connaissance existe, mais dispersée : une CMDB qui a dérivé, des schémas réseau dans un wiki, un registre de sous-traitance à la conformité, des contrats fournisseurs au juridique, des niveaux de criticité dans une présentation de l'an dernier. Rien ne se relie, et c'est précisément la jointure dont une discussion CSSF a besoin. Un référentiel d'architecture d'entreprise est, au fond, l'endroit où ces fils deviennent un seul modèle connecté — les capacités, les applications qui les soutiennent, les flux de données entre elles, les dépendances, et les tiers et chaînes de sous-traitance derrière eux.

• La gestion du risque IT présuppose un vrai inventaire des applications et systèmes
• La supervision de la sous-traitance présuppose de tracer les fonctions jusqu'à leurs prestataires et sous-traitants
• La résilience opérationnelle présuppose de savoir de quoi dépend une fonction critique
• Le prérequis commun est une vue connectée et à jour — pas plusieurs registres qui dérivent

Cartographier capacités, applications et flux de données

Le point de départ est un modèle qui relie ce que fait le métier à ce qui le fait tourner. Les capacités métier — paiements, entrée en relation, administration de fonds, reporting réglementaire — se tiennent en haut. Chacune est soutenue par des applications, chaque application repose sur de la technologie et détient ou déplace de la donnée, et les flux entre applications sont les artères qui intéressent une conversation de résilience. Une liste d'actifs plate ne sait pas l'exprimer ; un modèle connecté le sait.

Dans un référentiel EA, chaque objet porte des attributs qui le rendent analysable — propriétaire, criticité, hébergement, technologie sous-jacente — et pointe vers les capacités qu'il soutient et les applications et flux de données auxquels il se relie. Avec cela en place, vous pouvez répondre aux questions qui reviennent dans les revues CSSF et de résilience : quelles applications soutiennent cette fonction critique ou importante, où va sa donnée, et ce qui serait affecté si un maillon tombait. La réserve honnête vaut comme toujours : le modèle ne vaut que par les données que vous y mettez, et les appréciations restent du côté de vos fonctions risque, conformité et IT. Le référentiel leur donne de la visibilité, pas un verdict.

• Carte de capacités reliant les fonctions métier aux applications qui les soutiennent
• Registre des applications avec propriétaire, criticité, hébergement et empreinte technologique
• Flux de données entre applications, pour suivre où circule la donnée
• Un modèle interrogeable qui rend visibles les dépendances des fonctions critiques, pas devinées

Chaînes de sous-traitance et tiers IT, rendus visibles

La supervision de la sous-traitance est l'un des domaines où les attentes de la CSSF sont les plus concrètes, et l'un de ceux où la réalité dérive le plus vite de la paperasse. Les entités sont attendues pour savoir à qui elles ont sous-traité, quels arrangements soutiennent des fonctions critiques ou importantes, et — point crucial — les chaînes derrière eux, là où un prestataire s'appuie lui-même sur des sous-traitants. On ne supervise pas une exposition qu'on ne voit pas, et l'exposition de sous-traitance est précisément de celles qui s'accumulent invisiblement : chaque arrangement pris isolément paraissait raisonnable au moment de la signature.

Un modèle cartographié transforme cette accumulation invisible en quelque chose de dénombrable. Reliez chaque application aux fournisseurs et prestataires de sous-traitance derrière elle, puis tracez chaque fonction critique ou importante jusqu'à ces tiers et aux sous-traitants derrière eux. Les amas apparaissent : le prestataire qui se tient derrière une part disproportionnée de ce qui compte, la concentration que vous n'auriez pas choisie délibérément mais avez héritée. C'est aussi exactement l'analyse qui recoupe le travail DORA sur le risque tiers IT et de concentration — un modèle, deux conversations réglementaires. Pour être clair sur la frontière : le référentiel révèle et documente les relations et la chaîne ; l'appréciation d'un prestataire, et la posture contractuelle et de notification autour, restent vôtres et celles de vos conseils.

• Chaque application reliée à ses fournisseurs et prestataires de sous-traitance
• Chaînes de sous-traitance traçables jusqu'aux sous-traitants derrière une fonction
• Concentration visible là où de nombreuses fonctions s'appuient sur le même prestataire
• Une documentation qui reste à jour parce qu'elle vit à côté de l'architecture

Résilience opérationnelle : cadrer les fonctions critiques depuis une carte vivante

La résilience opérationnelle, c'est au fond la capacité à continuer de délivrer des fonctions critiques ou importantes à travers la perturbation — et à montrer que vous y avez réfléchi. Le plus lent dans cette préparation n'est rarement les contrôles eux-mêmes ; c'est le cadrage : déterminer quelles fonctions sont critiques, ce qui les soutient, et ce qui se passerait si une dépendance tombait. Fait depuis des documents éparpillés, c'est de l'archéologie sous pression de délai.

Un modèle d'architecture à jour escamote cette étape. Tracez une fonction critique vers le bas, vers les applications, flux de données, technologies et tiers dont elle dépend, et l'image de ce qui doit rester debout — et de ce qui le menace — est à l'écran plutôt que dans une tête. Le même modèle rend le récit de résilience défendable : vous montrez, depuis une source versionnée, quelles fonctions vous avez traitées comme critiques et pourquoi, et de quoi chacune dépend. Nous sommes précis sur la limite : un référentiel EA soutient la documentation de résilience en fournissant le contexte de dépendances ; il n'effectue ni la continuité d'activité, ni la réponse aux incidents, ni les tests. Ceux-ci vivent dans vos opérations et vos plans, et le modèle d'architecture les alimente plutôt qu'il ne les remplace.

• Tracez les fonctions critiques vers les applications, données et tiers dont elles dépendent
• Cadrez l'impact d'une dépendance défaillante depuis un modèle, pas de mémoire
• Montrez, depuis une source versionnée, quelles fonctions ont été traitées comme critiques et pourquoi
• Une aide à la documentation de résilience — pas la continuité, la réponse ou les tests eux-mêmes

Pourquoi un référentiel souverain, hébergeable en UE ou on-premise convient spécifiquement au Luxembourg

Trois propriétés d'ArchiLU comptent davantage dans un contexte CSSF que presque partout ailleurs. Il peut être hébergé dans l'UE ou en on-premise, si bien que la carte sensible des applications qui soutiennent quelles fonctions critiques — proche d'un plan de vos points les plus exposés — ne quitte pas un périmètre que vous contrôlez, ce qui compte dans une juridiction où la localisation et le contrôle de la donnée sont pris au sérieux. Il est disponible nativement en français et en anglais, ce qui colle à un marché luxembourgeois 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 carte de dépendances ne sont pas bridées par un nombre de sièges ; le détail commercial vit sur la page des tarifs plutôt qu'ici.

La frontière honnête, redite parce qu'elle compte : ArchiLU est un référentiel d'architecture d'entreprise qui produit de la documentation et de la preuve et les rend plus simples à assembler et à tenir à jour. Ce n'est pas une certification CSSF, pas une bibliothèque de contrôles approuvée par la CSSF, et nous restons transparents sur les certifications que nous ne détenons pas encore. Ce qu'il donne à une entité supervisée par la CSSF, c'est un modèle souverain, multilingue et connecté de ses capacités, applications, flux de données et tiers — le socle sur lequel reposent à la fois les conversations CSSF, DORA et NIS2. 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.