Votre cartographie d'architecture : l'actif le plus sensible que vous exposerez à l'IA

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

Perspective métier pour ce sujet

Votre carto EA est un plan quasi complet de l'organisation — l'actif le plus sensible que vous confiez à une IA externe ; donnez du contexte sans perdre le contrôle.

Utilisez cette page comme un support de décision: alignez les parties prenantes, validez les trade-offs et reliez les choix d'architecture à des outcomes business mesurables.

• Requete principale: Votre cartographie d'architecture : l'actif le plus sensible que vous exposerez à l'IA
• Périmètre de décision: stratégie, gouvernance, modèle opératoire et contraintes d'exécution
• Livrable attendu: prochaines actions claires avec ownership et indicateurs mesurables

Le document que vous voudriez le moins voir fuir

Imaginez qu'un attaquant puisse adresser une seule requête à votre organisation et recevoir un document en retour. Ni votre liste clients, ni un trimestre de chiffres — cela fait mal, mais c'est récupérable. Celui qu'il réclamerait vraiment, c'est votre cartographie d'architecture d'entreprise. C'est l'artefact unique qui transforme des faits épars en plan : il dit ce que vous exploitez, ce qui dépend de quoi, ce qui est ancien et non corrigé, où sont vos points faibles, et comment les données régulées circulent entre vos systèmes.

C'est l'actif qu'un nombre croissant d'outils EA vous invitent désormais à connecter à une IA externe pour que chacun puisse simplement l'interroger. Le bénéfice de productivité est réel et nous ne le balayons pas. Mais avant de brancher votre document le plus révélateur sur un modèle généraliste, il vaut la peine d'être précis sur ce que ce document contient vraiment — car le discours « parlez à votre architecture » des acteurs en place tend à l'enjamber.

Cet article fait deux choses. D'abord, il énonce clairement ce qu'une cartographie EA expose et pourquoi la connecter à des LLM en cloud américain est, pour une institution régulée de l'UE, l'exposition la plus sensible que la plupart des firmes feront jamais. Ensuite, il devient constructif : comment donner aux agents IA un vrai contexte architectural sans sortir du cadre DORA, CSSF, RGPD et règlement IA.

Ce que votre cartographie EA révèle réellement

Un référentiel EA n'est pas une base de connaissances avec quelques schémas. Il est proche d'un plan complet et structuré de l'organisation — et son danger tient précisément à ce qu'il corrèle des éléments seulement sensibles isolément en quelque chose de critique une fois agrégé.

Lisez la liste ci-dessous comme le ferait un attaquant. Chaque ligne est utile en soi ; ensemble, elles forment une carte indiquant exactement où pousser et ce qui s'effondre quand on le fait. Cet effet d'agrégation est au cœur de ce qui place cet actif dans une catégorie à part.

• L'inventaire complet des systèmes et applications — ce que vous exploitez, y compris les systèmes que vous préféreriez peu connus.
• Les dépendances critiques — quelles applications et services entraîneraient les autres dans leur chute, c'est-à-dire où appuyer.
• Les composants obsolètes et en fin de vie — la technologie non supportée et non corrigée, la plus difficile à défendre.
• Les vulnérabilités connues et leur statut de remédiation — parfois consignées directement en regard des systèmes concernés.
• Les flux de données sensibles et régulées — comment les données personnelles, financières ou supervisées circulent entre systèmes et vers des tiers.
• Les contrôles de sécurité eux-mêmes — dans certains référentiels, les mesures censées protéger tout ce qui précède.

Pourquoi la connecter à des LLM américains est le terrain miné

Connecter cette cartographie à un assistant généraliste — ChatGPT, Microsoft Copilot, Claude, Gemini — est techniquement l'affaire d'un après-midi. La difficulté n'est pas technique. C'est qu'au moment où un utilisateur pose une question, le prompt et souvent le contenu récupéré du référentiel voyagent là où s'exécute le modèle, où ils peuvent être traités, mis en cache ou temporairement conservés, potentiellement sous une juridiction hors UE et potentiellement sous des conditions éditeur que vous n'avez pas lues attentivement.

Pour une institution régulée de l'UE, cela atterrit sur plusieurs régimes à la fois. Au sens de DORA, un fournisseur d'IA généraliste branché sur votre architecture est un tiers TIC qui engage le risque de concentration, la stratégie de sortie et les droits d'audit. Au titre du RGPD, toute donnée personnelle dans les flux atteignables soulève des questions de base légale et de transfert transfrontalier. Au titre du règlement IA, le cas d'usage doit être placé dans sa classe de risque plutôt que supposé à faible risque parce qu'il ressemble à une fenêtre de chat. Et la CSSF, comme d'autres superviseurs, attend que vous gouverniez et documentiez exactement ce type de dépendance.

Rien de tout cela ne signifie « ne jamais connecter l'IA à l'architecture ». Cela signifie que le chemin par défaut — pointer un LLM en cloud américain vers votre cartographie la plus sensible en espérant que les conditions conviennent — est l'exact opposé de ce qu'un CISO ou un DPO peut défendre devant un auditeur. L'exposition est réelle et c'est la plus importante que feront la plupart des firmes. La bonne nouvelle : la valeur et le risque sont dissociables.

Ce que le discours des acteurs en place suppose en silence

Plusieurs éditeurs EA installés se disputent désormais la propriété de « parlez à votre architecture » — une interface de chat, un connecteur MCP, un récit d'ingénierie de contexte sur le référentiel. La capacité est légitime et les démos sont convaincantes. Mais presque toutes reposent sur une hypothèse non dite : que connecter votre référentiel EA à un modèle généraliste, majoritairement hébergé aux États-Unis, est acceptable.

Pour beaucoup d'organisations, ça l'est. Pour une banque, un assureur, un opérateur d'infrastructure critique ou un organisme public régulé de l'UE, ça ne l'est souvent pas — et « ça tournait sur un LLM en cloud américain, les conditions paraissaient correctes dans l'interface » n'est pas une preuve qu'un auditeur accepte. Personne sur le marché EA n'a vraiment porté le versant souverain, gouvernance d'abord, de cette conversation. C'est l'écart dont parlent cet article — et notre positionnement. Pas « nous faisons aussi du MCP », mais « voici comment l'IA raisonne sur votre architecture sans que vous en perdiez le contrôle ».

Donner du contexte à l'IA sans sortir du cadre réglementaire

Voici la moitié constructive. Le motif qui conserve la valeur en retirant le risque d'exfiltration est une porte de gouvernance — une couche de contexte souveraine — entre l'agent et le référentiel, plutôt qu'un tuyau direct d'un modèle en cloud américain vers votre cartographie. Chaque contrôle ci-dessous répond à une préoccupation précise qu'un auditeur ou un régulateur soulèvera.

Aucun n'est exotique ; ensemble, ils font la différence entre une divulgation incontrôlée et une capacité gouvernée et défendable. L'idée : la valeur de l'IA n'exige pas d'abandonner la carte — elle exige de placer une porte devant elle.

• Résidence des données : maintenir l'inférence et toute donnée conservée dans l'UE ou sur une infrastructure que vous contrôlez, et savoir exactement où vont prompts et contenu récupéré — pas de « quelque part dans une région américaine ».
• Conscience des permissions : l'agent ne voit que ce à quoi l'utilisateur demandeur a droit, requête par requête, pour ne pas devenir un contournement de votre modèle de contrôle d'accès.
• Redaction des types d'objets sensibles : classez vos objets et retenez les catégories à plus haut risque — vulnérabilités, contrôles, points uniques de défaillance, flux de données régulées — pour que l'agent raisonne sur une vue délibérément réduite.
• Journalisation et auditabilité : consignez qui a demandé quoi, quand, et ce qui a été renvoyé, conservé et recherchable, à la même norme que tout accès à des données sensibles.
• Humain dans la boucle : gardez l'agent en lecture-et-conseil, pas en action — aucune écriture ni action aval autonome sur votre architecture sans propriétaire humain nommé.
• Options souveraines : déploiement hébergé en UE ou on-premise et choix de LLM européens, pour que le cadre réglementaire soit une propriété de déploiement, pas une arrière-pensée.

La couche de contexte souveraine : la valeur de l'IA sans perdre le contrôle

Prenez du recul et les contrôles ci-dessus décrivent une seule chose : un système de contexte aux côtés de vos systèmes de référence, gouverné pour la résidence, les permissions, la redaction et l'audit, qu'un agent IA peut interroger et qu'un auditeur acceptera. C'est ce que nous entendons par couche de contexte souveraine — et c'est, selon nous, la façon dont une institution régulée tire de la valeur de l'IA depuis son architecture sans que la cartographie sensible quitte son contrôle.

Nous sommes délibérément honnêtes sur le statut. ArchiLU propose aujourd'hui un modèle EA connecté — capacités, portefeuille applicatif, dépendances — avec un hébergement en région UE ou on-premise sous votre contrôle, le français et l'anglais natifs, et une évaluation gratuite de maturité EA, conçus autour des besoins de documentation DORA et CSSF. Une couche de contexte pleinement souveraine et consciente de la résidence des données pour les agents IA — un MCP souverain et gouverné sur ce modèle — est notre conviction et notre feuille de route, la direction que nous visons. Ce n'est pas un produit livré, et nous ne laisserons pas entendre le contraire.

Si vous ne retenez qu'une décision de cet article, que ce soit celle-ci : traitez votre cartographie d'architecture comme l'actif à plus haute sensibilité qu'elle est réellement, et exigez une porte de gouvernance avant qu'une IA y touche. La fonctionnalité « parlez à votre architecture » vaut la peine — à des conditions qu'un CISO peut défendre.

Un avertissement honnête

Cet article est une aide à la documentation et au cadrage du risque pour aider vos équipes architecture, sécurité et conformité à structurer la discussion et à rassembler des preuves — pas un avis juridique ou de conformité. Il ne vous rend conforme ni à DORA, ni à NIS2, ni au RGPD, ni au règlement IA, ni aux attentes de la CSSF, ni à aucun autre régime. L'hébergement souverain, la redaction et la journalisation couvrent une partie du risque ; la conformité s'établit par votre propre gouvernance, vos contrats, vos preuves et vos contrôles, au regard de votre périmètre réglementaire précis.

Validez chaque décision avec vos fonctions juridique, DPO et risque, au regard de votre situation précise, avant de connecter toute IA à votre cartographie d'architecture. Si vous voulez éprouver l'approche pour votre contexte, l'évaluation de maturité et une démo sont la façon la plus rapide d'amorcer une conversation ancrée.

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