Une banque régulée doit-elle connecter des agents IA à son architecture ?

Modèle opératoire du contexte souverain

Un agent IA ne vaut que le contexte qu'il peut atteindre. Pour une entreprise régulée, ce contexte — le référentiel d'architecture — est aussi l'un de ses actifs les plus sensibles.

Le modèle opératoire qui compte n'est pas « exposer le référentiel via MCP » ; c'est « gouverner quel contexte sort, vers qui, et sous quelles contraintes de résidence et d'audit ».

• Décider quels types d'objets sont interrogeables, et lesquels ne sont jamais exposés
• Garder le contexte frais : réconcilier le référentiel avec les sources vivantes, pas un snapshot annuel
• Rendre chaque réponse traçable vers une source gouvernée que l'utilisateur a le droit de voir

La question que se posent vraiment les DSI et RSSI

Le marché répète « parlez à votre architecture ». Les éditeurs se précipitent pour connecter Claude, Copilot, ChatGPT ou Gemini au référentiel EA afin qu'un architecte pose ses questions en langage naturel. Pour une banque régulée, ce pitch résonne autrement. La personne qui doit valider n'est pas enthousiasmée par la démo — elle calcule ce qui vient de sortir de l'établissement.

La vraie question n'est donc pas « l'IA est-elle utile sur notre architecture ? ». Elle l'est presque certainement. La question est de savoir si connecter un agent au référentiel EA est une décision défendable pour une institution supervisée DORA/CSSF, et si oui, à quelles conditions. Ceci est un cadre de décision et de risque, pas une recommandation de connecter ou de s'abstenir. C'est une aide à la documentation et au cadrage du risque — pas un conseil juridique, et il ne vous rend pas conforme à DORA, au RGPD, au règlement IA ou aux attentes de la CSSF.

L'opportunité — pourquoi la conversation en vaut la peine

Si le risque était trivial, personne ne s'y opposerait, et si la valeur l'était, personne n'insisterait. La valeur est réelle. Un agent qui raisonne sur un modèle EA vivant peut compresser un travail qui dévore aujourd'hui des semaines de temps d'architecte.

Trois usages tendent à justifier toute la conversation. L'analyse d'impact : « si nous décommissionnons ce composant central, qu'est-ce qui casse et quelles fonctions critiques sont touchées ? » — répondu sur le graphe de dépendances en quelques secondes plutôt qu'en quinze jours d'entretiens. La rationalisation : faire émerger les applications redondantes ou obsolètes comme candidates au retrait. Le reporting de conformité : rédiger les sections architecture d'un registre DORA ou d'une soumission CSSF à partir du modèle plutôt que de mémoire. Rien de tout cela n'est du hype hypothétique ; c'est le travail ordinaire dont le référentiel EA détient déjà les réponses.

• Analyse d'impact sur le graphe de dépendances — des minutes au lieu de semaines
• Rationalisation : applications redondantes et obsolètes émergées comme candidates au retrait
• Reporting de conformité et d'audit rédigé depuis le modèle, pas depuis la mémoire tribale
• Onboarding accéléré : un nouvel architecte interroge le patrimoine sans visite guidée

L'exposition — ce qu'est réellement la cartographie EA

Voici la partie que la démo escamote. Une cartographie EA n'est pas un schéma propret ; c'est un plan quasi complet de la banque. Elle contient l'inventaire système complet, les dépendances critiques, les composants obsolètes encore en production, les vulnérabilités connues, les flux de données sensibles, et parfois les mesures de sécurité elles-mêmes.

Assemblé, c'est le document le plus utile qu'un attaquant pourrait obtenir — et la divulgation qu'un superviseur a le plus de chances de questionner. Quand vous attachez du contexte EA à un prompt envoyé à un LLM généraliste en cloud américain, ce contexte quitte votre contrôle et franchit une frontière pays tiers. L'agent a répondu à une question ; vous avez aussi exporté le plan. C'est l'asymétrie au cœur de cette décision.

• Inventaire système complet et dépendances critiques — le système nerveux de la banque
• Composants obsolètes et vulnérabilités connues — une carte d'attaque prête à l'emploi
• Flux de données sensibles et, parfois, les contrôles de sécurité eux-mêmes
• Un plan quasi complet qui, une fois envoyé, ne peut plus être rappelé

Le cadre réglementaire : DORA, RGPD, règlement IA, CSSF

Quatre régimes façonnent cette décision, et ils se chevauchent plutôt qu'ils ne s'empilent proprement. Considérez le résumé ci-dessous comme la carte d'une conversation avec vos deuxième et troisième lignes de défense, pas comme un feu vert.

DORA met en jeu le risque tiers TIC et la concentration : un fournisseur de LLM généraliste peut devenir un tiers TIC critique, et faire transiter votre contexte le plus sensible par un seul modèle concentre le risque d'une manière que la réglementation attend que vous maîtrisiez. Le RGPD s'applique dès qu'une donnée personnelle apparaît dans le contexte et encadre le transfert lorsque l'inférence se produit hors UE. Le règlement IA superpose des obligations qui croissent selon la classe de risque de l'usage. Les attentes de la CSSF s'ajoutent pour les entités supervisées au Luxembourg, où les circulaires sur l'externalisation et le risque TIC donnent le ton de la supervision. Aucun ne dit « jamais » ; tous disent « gouvernez-le, et soyez capable d'en apporter la preuve ».

• DORA — risque tiers TIC et concentration quand un modèle externe devient critique
• RGPD — données personnelles dans le contexte, et transfert UE vers pays tiers à l'inférence
• Règlement IA — obligations croissant avec la classe de risque de l'usage
• CSSF — attentes sur l'externalisation et le risque TIC pour les entités supervisées au Luxembourg

Comment décider : quelles questions sont sûres, quels objets ne doivent jamais sortir

La décision n'est pas « IA ou pas d'IA ». C'est un jugement question par question et objet par objet, ce qui est exactement pourquoi une interdiction absolue et un chèque en blanc sont tous deux faux. Découpez l'espace entre ce qui peut être répondu sans risque et ce qui doit rester dans le périmètre.

Beaucoup de questions sont à faible risque : décomptes agrégés, couverture des capacités, recherches de propriétaire, direction de dépendance de haut niveau. Certaines ne le sont catégoriquement pas : tout ce qui renvoie la liste des vulnérabilités vivantes d'une fonction critique, les contrôles de sécurité protégeant un système, ou un flux de données sensible lié à des personnes identifiables. La discipline consiste à définir ces classes une fois, à les encoder, et à laisser la gate — pas le jugement de l'architecte sur le moment — les faire respecter.

• Généralement sûr à demander : inventaires agrégés, couverture des capacités, propriété et dépendances de haut niveau
• Ne doit jamais sortir du référentiel : listes de vulnérabilités vivantes, contrôles de sécurité des systèmes critiques, flux de données liés à des personnes
• Décidez par type d'objet et classe de sensibilité, définis une fois — pas improvisés par requête
• Refus par défaut pour tout ce qui touche une fonction critique tant que ce n'est pas explicitement autorisé

Les quatre gates et les options souveraines

Si l'institution décide d'avancer, quatre gates transforment « connecter un agent » en quelque chose de défendable. Résidence : garder l'inférence dans l'UE ou sur une infrastructure que vous contrôlez, pour que le contexte ne franchisse pas de frontière pays tiers. Permissions : l'agent ne voit que ce à quoi l'utilisateur qui demande a droit — par utilisateur, pas un compte de service tout-puissant. Redaction : les types d'objets sensibles (vulnérabilités, contrôles de sécurité) sont retenus à la frontière, même quand le reste de la réponse circule. Traçabilité : chaque requête est enregistrée — qui a demandé quoi, quand — pour que la gouvernance soit prouvée, pas affirmée.

Ces gates ne sont pleinement atteignables qu'avec un modèle de livraison souverain. Les options sont concrètes : un modèle hébergé UE, un déploiement privé ou on-premise, ou un LLM européen. C'est ce que nous entendons par MCP conscient de la résidence des données — une interface qui gouverne où vont les données, pas seulement qui interroge. Pour être honnête sur notre propre état : un serveur MCP souverain est la direction vers laquelle ArchiLU construit, notre conviction sur la façon dont cela devrait fonctionner, pas une fonctionnalité que vous pouvez activer aujourd'hui. Ce que nous offrons aujourd'hui, c'est le contexte gouverné en dessous — un modèle EA en région UE ou on-premise que vous contrôlez, nativement FR/EN, conçu autour des besoins de documentation DORA/CSSF.

• Gate de résidence — inférence dans l'UE ou sur une infrastructure que vous contrôlez
• Gate de permissions — droits par utilisateur, jamais un compte de service tout-puissant
• Gate de redaction — retenir vulnérabilités et contrôles de sécurité à la frontière
• Gate de traçabilité — qui a demandé quoi, quand, conservé comme preuve d'audit
• Options souveraines — modèle hébergé UE, déploiement on-premise, ou LLM européen

Le verdict : oui — mais seulement gouverné et souverain

Connecter un agent IA à l'architecture d'une banque régulée n'est ni imprudent ni inévitable. C'est une décision gouvernée. Réalisée avec des gates de résidence, de permissions, de redaction et de traçabilité au-dessus d'un modèle de livraison souverain, les usages à forte valeur — analyse d'impact, rationalisation, rédaction de conformité — deviennent défendables, et vous pouvez montrer la gouvernance à votre superviseur plutôt que la promettre. Réalisée en pointant un LLM généraliste en cloud américain sur le référentiel vivant, vous avez exporté le plan de la banque et vous ne pouvez plus le reprendre.

Partez de l'état réel de votre pratique, pas d'une démo d'éditeur. L'évaluation gratuite de maturité EA d'ArchiLU note dix dimensions en environ dix minutes et donne une lecture concrète de savoir si votre contexte est seulement assez gouverné pour y connecter un agent de façon responsable. Gardez le disclaimer présent du début à la fin : ce cadre vous aide à documenter et à raisonner sur le risque ; il ne constitue pas un conseil juridique et ne vous rend pas, à lui seul, conforme à DORA, au RGPD, au règlement IA ou aux attentes de la CSSF.

KPIs du contexte IA régulé

Mesurez si votre contexte est fiable et gouverné, pas le nombre de requêtes de l'agent.

• Fraîcheur du contexte : âge médian des objets d'architecture vs réalité vivante
• Part des réponses traçables vers une source gouvernée et à périmètre de permission
• Types d'objets sensibles couverts par une politique de redaction/résidence
• Couverture d'audit : prompts et réponses loggés et revus

Common mistakes

La plupart des initiatives MCP-pour-EA échouent sur la qualité du contexte et la gouvernance bien avant d'échouer sur le protocole.

• Exposer tout le référentiel d'architecture à des LLM externes sans contrôle de résidence des données
• Traiter le MCP comme le différenciateur au lieu du contexte gouverné derrière
• Brancher un référentiel maintenu à la main vieux de 18 mois auquel l'agent ne peut pas se fier
• Aucune permission-awareness, aucun logging, aucune redaction des objets sensibles

Practical checklist

À faire avant de connecter un agent IA à votre référentiel d'architecture.

• Confirmer où vont prompts et réponses, et si la donnée reste dans votre région
• Imposer un accès permission-aware : l'agent ne voit que ce que l'utilisateur peut voir
• Classer et masquer les types d'objets sensibles (vulnérabilités, flux de données, contrôles)
• Logger prompts et réponses pour l'audit, et garder un humain dans la boucle pour tout changement