Ce qu'un auditeur vous demandera sur l'accès de votre IA aux données d'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

Le jour où l'IA accède à votre architecture, le compteur de l'audit démarre

Un référentiel d'architecture d'entreprise est l'une des cartes les plus sensibles que détient votre organisation : l'inventaire des systèmes, les dépendances critiques, les composants obsolètes, les vulnérabilités connues, les flux de données sensibles. Dès qu'un agent IA peut interroger ce référentiel, vous avez créé une nouvelle surface de contrôle — et un régulateur, l'audit interne ou une inspection CSSF la traitera comme telle.

Ce n'est pas une raison pour bannir l'IA de votre architecture. C'est une raison de savoir, avant que la conversation ait lieu, exactement ce qu'un auditeur demandera et quelle preuve y répond. La bonne nouvelle : ces questions sont prévisibles. La réserve honnête : produire la preuve est votre travail, pas une case à cocher chez un éditeur. Cet article est une aide à la préparation de l'audit — il aide à préparer la preuve — et il ne constitue ni une conformité légale ni un avis juridique.

Voici les six questions à anticiper, formulées comme l'audit les formule réellement : la question, puis ce à quoi ressemble une bonne preuve.

Question 1 — Qui et quoi peut interroger les données d'architecture ?

La première question porte sur le modèle d'accès. Un auditeur n'acceptera pas « l'IA peut lire le référentiel » — il demandera quels agents, agissant pour quels utilisateurs, peuvent interroger quels objets, et sous quelle autorisation.

Le piège : l'accès IA est souvent greffé en dehors de votre modèle d'identité et de permissions habituel. Si l'agent voit tout indépendamment de qui demande réellement, vous avez de fait accordé un accès illimité à votre carte la plus sensible. Une bonne preuve est un modèle d'accès explicite qui relie chaque requête à un utilisateur authentifié et à ses droits, de sorte qu'un agent ne renvoie que ce que cet utilisateur est autorisé à voir.

• Preuve : un modèle d'accès documenté reliant agents et utilisateurs aux objets du référentiel
• Preuve : une application des permissions par utilisateur, pas un compte de service unique qui voit tout
• Preuve : un processus de revue des droits d'interrogation IA accordés, et leur révocation

Question 2 — Où vont les données, et à travers quelles frontières ?

C'est la question de la résidence et des transferts, et pour la finance régulée de l'UE elle est souvent décisive. Quand un agent répond, votre contexte d'architecture devient l'entrée d'un modèle. Si ce modèle s'exécute hors de votre contrôle — un LLM en cloud américain, par exemple — alors votre inventaire de systèmes, vos dépendances et vos vulnérabilités peuvent quitter votre région et votre périmètre de gouvernance.

Un auditeur voudra voir le chemin de la donnée tracé, pas décrit dans l'abstrait. Une bonne preuve est une région d'hébergement documentée, un compte rendu clair de tout transfert transfrontalier, les termes contractuels et de traitement qui l'encadrent, et — là où cela compte le plus — la capacité à maintenir l'inférence dans un environnement que vous contrôlez. Soyez précis sur ce que vous pouvez prouver aujourd'hui versus ce qui relève de l'ambition ; les auditeurs voient la différence.

• Preuve : la région d'hébergement documentée du modèle et du contexte qu'il reçoit
• Preuve : une cartographie des transferts et la base légale de tout flux transfrontalier
• Preuve : des accords de traitement couvrant le fournisseur du modèle
• Preuve : si requis, une inférence en région UE ou on-premise sous votre contrôle

Question 3 — Qu'est-ce qui est journalisé, et pouvez-vous le reconstituer ?

L'auditabilité des prompts et des réponses est ce qui distingue une capacité IA gouvernée d'une capacité opaque. Un auditeur investiguant un incident — une conception fuitée, une recommandation erronée suivie d'effet — vous demandera de reconstituer qui a demandé quoi, quand, et ce que l'agent a renvoyé.

Si ces interactions ne sont pas journalisées, vous ne pouvez ni investiguer ni démontrer un contrôle proportionné. Une bonne preuve est un journal durable et infalsifiable des requêtes et réponses, conservé sur une durée définie, interrogeable pendant une investigation, et protégé pour que le journal lui-même ne puisse être discrètement modifié. Traitez-le comme un artefact de premier rang dès le départ : rajouter la journalisation après un incident, c'est ainsi qu'on échoue à un audit.

• Preuve : un journal requête-réponse capturant utilisateur, horodatage, demande et réponse
• Preuve : une durée de conservation définie, alignée sur vos obligations de tenue de registres
• Preuve : des contrôles d'intégrité du journal pour que la trace ne soit pas altérée en silence

Question 4 — Comment les objets sensibles sont-ils classifiés et protégés ?

Tous les objets du référentiel ne portent pas le même risque. Une cartographie des capacités est une chose ; un inventaire de vulnérabilités non corrigées ou les flux de données touchant des données personnelles ou prudentielles en est une autre. Un auditeur demandera comment vous les distinguez et comment les objets sensibles sont protégés d'un agent qui pourrait les exposer sans précaution.

Une bonne preuve commence par la classification : un schéma qui étiquette les objets d'architecture par sensibilité, appliqué de façon cohérente. Par-dessus vient la rédaction ou la rétention — la capacité à maintenir les attributs les plus sensibles (faiblesses connues, mesures de sécurité, flux de données régulés) hors des réponses d'un agent sauf autorisation explicite. « L'IA a simplement résumé tout ce qu'elle a trouvé » n'est pas une réponse qu'un auditeur acceptera pour vos objets les plus critiques.

• Preuve : un schéma de classification appliqué aux objets et attributs d'architecture
• Preuve : des règles de rédaction ou de rétention pour les objets à forte sensibilité
• Preuve : une justification défendable de ce qu'un agent peut et ne peut pas exposer

Question 5 — Qui est responsable d'une décision influencée par l'IA ?

C'est généralement la question la plus difficile, et celle qui expose le plus vite une gouvernance faible. Si une décision d'architecture a été façonnée par la réponse d'un agent, un auditeur demandera qui détient cette décision et si la réponse peut être tracée jusqu'à une source gouvernée — un objet réel de votre référentiel — plutôt qu'à l'improvisation plausible d'un modèle.

Une bonne preuve est un modèle de responsabilité avec humain dans la boucle : un propriétaire nommé pour les décisions que l'IA informe, et une traçabilité de la réponse de l'agent jusqu'aux objets sources sur lesquels elle s'appuie. Le but n'est pas que des humains approuvent tout ; c'est que la responsabilité ne s'évapore jamais dans le modèle. Si vous ne pouvez pas nommer un responsable et citer une source, le reste de vos contrôles se lit comme de la décoration.

• Preuve : un modèle avec humain dans la boucle nommant les responsables des décisions informées par l'IA
• Preuve : une traçabilité de la réponse d'un agent jusqu'à des objets sources citables
• Preuve : une frontière nette entre suggestion de l'IA et décision humaine de référence

Question 6 — Comment le risque tiers et ICT est-il gouverné (DORA) ?

Un agent IA qui atteint vos données d'architecture est, presque toujours, une dépendance ICT tierce. Sous DORA, cela l'inscrit dans votre gestion du risque lié aux prestataires tiers de TIC : il devrait figurer dans votre registre d'information, avec les considérations de concentration, de sous-traitance et de sortie qu'attire tout prestataire critique.

Un auditeur demandera si le fournisseur d'IA est gouverné comme tout autre prestataire TIC — évalué, contractualisé, surveillé, et réversible. Une bonne preuve est une entrée dans votre registre des prestataires tiers de TIC, des termes contractuels conformes aux attentes DORA, et une réponse testée à « que se passe-t-il si ce prestataire défaille ou doit être remplacé ? ». Le référentiel d'architecture aide ici : c'est là que la dépendance à la capacité IA devrait être modélisée, pour que le risque soit visible plutôt que caché dans un dossier achats.

• Preuve : la capacité IA inscrite dans votre registre d'information des prestataires tiers de TIC
• Preuve : des termes contractuels et un suivi alignés sur les attentes DORA
• Preuve : un plan de sortie / substitution documenté et testé

Préparez la preuve avant d'en avoir besoin

Ces six questions ne sont pas une raison de tenir l'IA à l'écart de votre architecture — elles sont l'ordre du jour pour le faire de façon défendable. Chacune a une réponse, et chacune est bien moins coûteuse à préparer avant une inspection que pendant. Nous construisons ArchiLU vers une couche de contexte souveraine et consciente de la résidence des données pour exactement cette conversation ; cette couche MCP est une conviction et une feuille de route, pas un produit livré, et nous ne le masquerons pas. Ce qui existe aujourd'hui : un modèle EA connecté, un hébergement en région UE ou on-premise sous votre contrôle, le FR/EN natif, et une structure conçue autour des besoins de documentation DORA/CSSF.

Partez de l'état réel de votre pratique. L'évaluation gratuite de maturité EA d'ArchiLU note dix dimensions et renvoie un plan d'action priorisé en environ dix minutes — un moyen concret de voir à quel point votre gouvernance d'architecture est prête pour les questions qu'un auditeur apportera dès que des agents IA commenceront à demander des réponses à votre référentiel.

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