Connecter l'IA à votre référentiel EA : une checklist de conformité

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

Avant de connecter un agent, gouvernez où va la donnée, qui peut la voir, et comment chaque réponse est loggée et auditée.

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: Connecter l'IA à votre référentiel EA : une checklist de conformité
• 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

Pourquoi un référentiel EA est le mauvais actif à laisser fuir

Il y a beaucoup d'enthousiasme à connecter un assistant généraliste — ChatGPT, Microsoft Copilot, Claude, Gemini — aux systèmes internes pour que chacun puisse poser ses questions en langage naturel. Pour la plupart des bases de connaissances, c'est un gain de productivité raisonnable. Pour un référentiel d'architecture d'entreprise, cela mérite d'abord un examen plus exigeant.

Un référentiel EA n'est pas une source de données comme une autre. Il est proche d'un plan complet de l'organisation : l'inventaire des systèmes, les dépendances critiques entre applications, les composants obsolètes, l'emplacement des vulnérabilités connues, la façon dont les données sensibles circulent entre systèmes, et parfois les mesures de sécurité elles-mêmes. Confié à un modèle externe, c'est exactement la carte qu'un attaquant, un concurrent ou un initié curieux voudrait le plus obtenir.

La question, pour une organisation régulée de l'UE, n'est donc pas « pouvons-nous connecter une IA à notre architecture ? » — techniquement, c'est l'affaire d'un après-midi. C'est « qu'est-ce qui sort de notre contrôle quand nous le faisons, et pouvons-nous prouver à un auditeur que nous l'avons gouverné ? » La checklist ci-dessous traduit cela en points concrets. Chacun est formulé comme ce qu'il faut vérifier et pourquoi un régulateur ou un auditeur y prête attention.

Résidence des données : où vont réellement les prompts et les réponses ?

Le premier point est le plus matériel. Quand un utilisateur interroge l'agent sur votre architecture, le prompt — et souvent le contenu du référentiel récupéré — voyage là où s'exécute le modèle, et peut y être traité, mis en cache ou temporairement conservé. Pour une cartographie EA sensible, « quelque part dans une région cloud américaine » est rarement une réponse acceptable.

Établissez, par écrit, où a lieu l'inférence, où réside toute donnée conservée, et si des sous-traitants la déplacent plus loin. Un régulateur y prête attention parce que le traitement transfrontalier de données opérationnelles sensibles engage les règles de transfert et des enjeux de concentration ; un auditeur y prête attention parce que « nous ne savons pas où cela va » constitue, en soi, un constat.

• Vérifier : la ou les régions exactes où prompts et contenu récupéré sont traités, et toute rétention temporaire.
• Vérifier : si des sous-traitants ou régions de repli peuvent déplacer la donnée hors de votre périmètre voulu.
• Pourquoi c'est important : une architecture opérationnelle sensible quittant l'UE engage règles de transfert, risque de concentration et attentes de souveraineté.

Conscience des permissions : l'agent ne voit-il que ce que l'utilisateur peut voir ?

C'est le point que la plupart des intégrations ratent. Un connecteur naïf indexe une fois l'ensemble du référentiel et répond à tout le monde à partir de cet index : un utilisateur peut alors lire des objets qu'il n'aurait jamais le droit d'ouvrir dans l'outil EA. Le confort du « demandez n'importe quoi » dissout discrètement votre modèle de contrôle d'accès.

L'agent doit appliquer la même autorisation que le référentiel sous-jacent : il ne doit voir que ce à quoi l'utilisateur demandeur a droit, requête par requête. Vérifiez-le par un test délibéré — faites interroger un domaine restreint par un utilisateur peu privilégié et confirmez que l'agent refuse ou ne renvoie rien. Un auditeur lit l'absence de ce contrôle comme une frontière de contrôle d'accès rompue, l'un des constats les plus sérieux que vous puissiez collecter.

• Vérifier : la récupération est cadrée par utilisateur, pas un index partagé unique interrogé par tous.
• Vérifier : un utilisateur peu privilégié ne peut pas extraire d'objets restreints via l'agent.
• Pourquoi c'est important : une IA qui contourne votre modèle d'accès est une défaillance de contrôle d'accès, quelle que soit la formulation de la réponse.

Classification et redaction des types d'objets sensibles

Tous les objets d'un référentiel EA ne portent pas le même risque. Les plus dangereux à exposer sont en général les vulnérabilités connues et leur statut de remédiation, les contrôles de sécurité, les points uniques de défaillance nommés, et les flux de données détaillés touchant des données personnelles ou régulées. Avant toute connexion, classez vos types d'objets et décidez lesquels ne doivent jamais atteindre un modèle externe dans leur intégralité.

Puis appliquez la redaction ou la rétention de ces catégories à la frontière, afin que l'agent raisonne sur une vue délibérément réduite plutôt que sur la carte brute et complète. Un régulateur y prête attention parce qu'exposer votre cartographie de vulnérabilités à l'extérieur peut en soi créer un risque opérationnel ; un auditeur y prête attention parce qu'il attend que la classification gouverne le traitement, et non l'inverse.

• Vérifier : une classification des types d'objets EA par sensibilité existe et est appliquée au connecteur.
• Vérifier : les catégories à plus haut risque (vulnérabilités, contrôles, points uniques de défaillance, flux de données régulées) sont caviardées ou retenues.
• Pourquoi c'est important : un traitement piloté par la classification est une attente de base ; exposer une carte des vulnérabilités peut être en soi un événement de risque opérationnel.

Journalisation, auditabilité et un humain dans la boucle

Si vous ne pouvez pas reconstituer qui a demandé quoi à l'agent, quand, et ce qu'il a répondu, vous ne pouvez ni investiguer un incident ni démontrer le contrôle. Journalisez prompts et réponses avec l'identité du demandeur, conservez-les selon votre politique, et rendez-les interrogeables — la norme que vous appliqueriez à tout accès à des données sensibles.

Maintenez l'agent fermement en lecture-et-conseil, pas en action. Pour un référentiel sensible, une IA capable d'écrire d'elle-même dans le modèle, de déclencher des changements ou d'appeler d'autres systèmes démultiplie la surface de risque ; un humain doit revoir et assumer toute action conséquente. Un régulateur y prête attention parce que l'auditabilité et la supervision humaine reviennent dans DORA comme dans le règlement IA ; un auditeur y prête attention parce que « nous n'avons aucune trace » clôt mal la plupart des investigations.

• Vérifier : prompts et réponses sont journalisés avec l'identité, conservés et recherchables pour investigation.
• Vérifier : l'agent n'a aucune capacité d'écriture ou d'action autonome sur le référentiel ou les systèmes avals.
• Pourquoi c'est important : auditabilité et supervision humaine sont des attentes réglementaires récurrentes ; une action conséquente exige un propriétaire humain nommé.

La couche réglementaire : DORA, RGPD, règlement IA et conditions de l'éditeur

Au-dessus des contrôles techniques se trouve le cadrage réglementaire, et c'est là que la plupart des équipes doivent ralentir. Traitez le fournisseur d'IA comme un tiers TIC au sens de DORA : évaluez le risque de concentration, documentez une stratégie de sortie, et vérifiez le droit contractuel d'audit et de notification d'incident. Un assistant généraliste branché sur votre architecture est exactement le type de dépendance que DORA attend que vous gériez explicitement.

Au titre du RGPD, identifiez une base légale pour toute donnée personnelle dans les flux que l'agent peut atteindre, et confirmez si et comment la donnée est transférée. Au titre du règlement IA, placez le cas d'usage dans la bonne classe de risque et appliquez les obligations correspondantes plutôt que de supposer qu'une fenêtre de chat est automatiquement à faible risque. Et lisez attentivement les conditions LLM de l'éditeur sur une question avant toutes les autres : vos données servent-elles à entraîner ou améliorer leurs modèles, et pouvez-vous le désactiver contractuellement ? « Cela paraissait correct dans l'interface » n'est pas la preuve qu'attend un auditeur — le contrat l'est.

• Vérifier (DORA) : le fournisseur d'IA est traité comme un tiers TIC — risque de concentration, stratégie de sortie, droits d'audit et de notification d'incident.
• Vérifier (RGPD) : base légale pour toute donnée personnelle atteignable par l'agent, et mécanisme de transfert pour le traitement transfrontalier.
• Vérifier (règlement IA) : le cas d'usage est classé par risque et porte les obligations correspondantes.
• Vérifier (conditions éditeur) : si vos prompts et données entraînent les modèles du fournisseur, et si vous pouvez vous y opposer contractuellement.

Vers où cela va — et un avertissement honnête

Le motif qui émerge de cette checklist est une porte de gouvernance entre l'agent et le référentiel : une couche qui impose la résidence, applique les permissions par utilisateur, caviarde les types d'objets les plus sensibles et journalise tout — pour que l'IA puisse raisonner sur votre architecture sans que vous en perdiez le contrôle. C'est la direction que nous visons avec une approche de contexte souveraine, et nous le disons honnêtement : un MCP pleinement souverain et conscient de la résidence des données pour le référentiel ArchiLU est une conviction et une feuille de route, pas un produit livré aujourd'hui.

Utilisez les points ci-dessus pour structurer la discussion entre vos équipes architecture, sécurité et conformité, et pour rassembler les preuves qu'un auditeur réclamera. Important et incontournable : cet article est une aide à la documentation et au cadrage du risque, 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. Validez chaque décision avec vos fonctions juridique, DPO et risque, au regard de votre situation précise, avant de connecter toute IA à votre référentiel EA.

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