L'ingénierie de contexte expliquée aux DSI et RSSI

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

Pourquoi ce sujet arrive sur votre bureau maintenant

Si vous dirigez l'IT ou la sécurité d'une institution régulée, on vous a probablement posé une variante de la même question cette année : peut-on pointer un agent IA vers nos propres systèmes ? La réponse honnête n'est ni oui ni non — c'est une question de contexte. Un agent IA ne vaut, et n'est sûr, que dans la mesure du contexte qu'il peut atteindre. L'ingénierie de contexte est la discipline qui décide quel est ce contexte, d'où il vient, et avec quelle rigueur il est gouverné.

Ce n'est pas un texte de promesse. On n'affirme pas ici que les agents remplaceront vos architectes, ni qu'un modèle lira votre patrimoine et vous remettra un certificat de conformité. Le propos est plus étroit et plus utile : la valeur et le risque de l'IA d'entreprise se concentrent au même endroit — la couche de contexte — et cette couche est désormais un sujet de décideur, pas un détail laissé à qui a câblé l'intégration.

Ce que l'ingénierie de contexte signifie réellement

Une façon utile de distinguer les termes : le prompt dit au modèle quoi faire ; l'ingénierie de contexte gouverne ce sur quoi il a le droit de raisonner. Le prompt, c'est la question. Le contexte, c'est tout ce que le modèle peut voir en répondant — votre portefeuille applicatif, vos cartes de dépendances, vos décisions d'architecture, vos politiques. L'essentiel de la qualité d'une réponse, et presque tout le risque, vit dans cette seconde partie.

Pour une entreprise régulée, le foyer naturel de ce contexte est le modèle d'architecture d'entreprise : l'image connectée des capacités, applications et dépendances qui décrit comment l'organisation fonctionne vraiment. Bien traité, il devient ce que nous appelons un système de contexte — une couche gouvernée que les agents interrogent — aux côtés des systèmes de référence (ERP, CRM, ITSM) plutôt qu'à leur place. L'ingénierie de contexte, c'est le travail qui rend cette couche assez fraîche, cadrée, en région et redevable pour qu'un agent puisse l'utiliser sans que personne n'en perde le contrôle.

• Prompt = ce qu'on demande au modèle de faire
• Contexte = ce que le modèle a le droit de voir en répondant
• L'essentiel de la qualité, et du risque, vit dans le contexte
• Pour l'EA, le système de contexte est le modèle connecté que les agents interrogent

Pourquoi la couche de contexte est aussi la couche de risque

Voici la partie inconfortable. Une carte d'architecture d'entreprise est, en pratique, un plan de l'organisation : l'inventaire complet des systèmes, les dépendances critiques, les composants obsolètes que personne n'a retirés, les flux de données sensibles, parfois les mesures de sécurité elles-mêmes. C'est précisément le document que vous voudriez le moins confier à un tiers.

Aussi la version désinvolte de la question — « peut-on connecter Claude ou ChatGPT à notre référentiel EA ? » — en cache une bien plus grande. Connecter un modèle généraliste hors région à cette carte peut revenir à envoyer une description quasi complète de votre institution hors de votre contrôle. Au regard du RGPD, de DORA, de NIS2 et de l'EU AI Act, ce n'est pas un acte neutre. Le métier de l'ingénierie de contexte, pris au sérieux, c'est de gouverner où va le contexte — pas seulement qui a le droit de poser la question.

Cinq questions qu'un décideur devrait poser

Vous n'avez pas besoin de devenir ingénieur prompt pour bien gouverner cela. Vous devez poser les cinq bonnes questions à tout agent IA qui touchera votre architecture, et exiger des réponses défendables devant un auditeur. Le schéma ci-dessus les organise autour de la couche de contexte gouvernée.

• D'où vient le contexte ? Des sources nommées et possédées que vous pouvez désigner — pas un scraping ni une boîte noire.
• Est-il frais ? Un modèle vivant qui reflète le patrimoine d'aujourd'hui, pas un instantané de dix-huit mois qui produira des réponses assurées et fausses.
• Est-il gouverné ? Contrôle d'accès, cadrage par rôle, et une piste d'audit de ce qui a été interrogé et renvoyé.
• Sort-il de notre région ? Une résidence des données que vous pouvez prouver — où va physiquement le contexte quand un agent l'utilise.
• De quoi peut-il répondre ? Une redevabilité claire : quelles questions l'agent est autorisé à traiter, et qui assume les conséquences.

L'angle conformité, dit honnêtement

Il existe un lien réel et défendable avec votre documentation réglementaire. Les attentes DORA et CSSF reposent largement sur la capacité à montrer vos dépendances ICT, vos fonctions critiques et les décisions derrière votre architecture. Une couche de contexte gouvernée et à jour rend cette documentation plus facile à produire, à maintenir et à défendre en revue. C'est une valeur authentique.

C'est aussi là que les éditeurs en font trop, alors soyons précis. Une couche de contexte est une aide à la documentation et à la preuve. Ce n'est pas une garantie de conformité, et aucun logiciel ne peut l'être. Votre conformité reste une appréciation de vos auditeurs et de votre régulateur, sur l'ensemble du tableau — pas quelque chose qu'un outil certifie. Quiconque vous vend l'inverse vous vend la mauvaise chose.

Par quoi commencer

Vous n'avez besoin ni d'un serveur MCP ni d'un déploiement d'agents pour démarrer. En réalité, vous ne devriez pas commencer par là. Le premier geste est de rendre votre contexte digne d'être atteint : un modèle connecté et à jour de vos capacités, applications et dépendances, hébergé là où vous pouvez prouver qu'il reste, avec un accès que vous contrôlez. Réussissez cela, et le reste — copilotes, agents, une future interface souveraine — aura une base sûre sur laquelle se poser. Pour être clair sur notre propre position : un MCP souverain, conscient de la résidence des données, est la direction vers laquelle nous construisons chez ArchiLU, pas une fonctionnalité que nous livrons aujourd'hui.

Un premier pas concret est de mesurer à quel point votre contexte est déjà gouvernable. L'évaluation gratuite de maturité EA d'ArchiLU note dix dimensions de votre pratique d'architecture et renvoie un plan d'action priorisé en une dizaine de minutes — une façon concrète de voir si votre contexte est frais, gouverné et prêt à être atteint en sécurité, avant qu'un agent ne s'en approche.

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