Ingénierie de contexte souveraine : un manifeste pour l'IA régulée

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

Nous donnons un nom à ce qui manque à l'IA régulée

Tout le monde s'accorde désormais : le goulot d'étranglement d'une IA utile n'est pas le modèle, c'est le contexte. L'industrie appelle la réponse l'ingénierie de contexte : la discipline qui consiste à assembler exactement la bonne information pour qu'un agent raisonne au lieu d'halluciner. C'est juste, et c'est insuffisant.

Car pour une banque, un assureur ou une institution publique régulés, la question n'est jamais seulement « de quel contexte l'agent a-t-il besoin ? ». C'est aussi « où va ce contexte, qui le gouverne, et puis-je prouver ce que l'agent a eu le droit de voir ? ». Il existe un nom pour l'ingénierie de contexte menée sous ces contraintes, et nous allons le définir et le revendiquer.

Nous l'appelons ingénierie de contexte souveraine : l'ingénierie de contexte pratiquée sous contrainte de résidence des données, de gouvernance et d'auditabilité, pour les entreprises régulées. Voici le manifeste.

La carte est l'arme

Partons de ce qui est réellement en jeu. Un modèle d'architecture d'entreprise n'est pas un schéma. C'est un plan quasi complet de l'organisation : chaque système, chaque dépendance critique, chaque composant obsolète, chaque flux de données sensible, parfois les mesures de sécurité elles-mêmes.

C'est précisément le contexte dont un agent IA a besoin pour être utile — et précisément le contexte dont vous ne pouvez pas perdre le contrôle. Connecter directement un LLM en cloud américain à cette carte, comme la voie commode vous y invite, peut transformer votre actif interne le plus précieux en votre plus grande surface d'attaque et votre exposition réglementaire la plus nette au titre de DORA, NIS2, RGPD et du Règlement IA de l'UE.

L'ingénierie de contexte souveraine commence par prendre cela au sérieux. Le même contexte qui rend l'IA puissante est celui qui rend une fuite catastrophique. On ne règle pas cela avec un avertissement. On le règle avec des principes.

Les cinq principes

Un manifeste ne vaut que les lignes que vous défendriez lors d'un audit CSSF. Voici les nôtres. Chacune est un choix entre deux réalités — et la déclaration de celle que nous retenons quand elles s'opposent.

• Le contexte avant le protocole. MCP est de la plomberie ; aucun connecteur ne sauve personne. La valeur est la qualité, la fraîcheur et la gouvernance du contexte qui y circule. Nous ingénierons le contexte d'abord, le protocole en dernier.
• Le vivant avant l'instantané. Un référentiel vieux de dix-huit mois rendra un agent confiant et faux. Le contexte souverain est rafraîchi en continu — un modèle agent-ready, pas un artefact archivé.
• Le gouverné avant l'exposé. Chaque accès tient compte des permissions. Un agent voit ce à quoi son appelant a droit, et pas un nœud de plus. L'exposition est le défaut à concevoir pour le supprimer, pas la commodité à accepter.
• Le souverain avant le commode. L'intégration la plus rapide envoie votre plan dans la juridiction d'un autre. Nous choisissons la voie où le contexte reste en UE et sous votre contrôle — même quand elle est plus difficile.
• L'auditable avant l'opaque. Si vous ne pouvez pas montrer à un auditeur ce que l'agent a vu, vous n'avez pas ingénieré du contexte — vous l'avez fait fuir avec des étapes en plus. Chaque réponse doit être traçable jusqu'à un accès gouverné.

Ce que ce n'est pas

Un manifeste gagne la confiance en énonçant ses limites aussi clairement que ses prétentions. Donc, en clair :

C'est une conviction, pas un produit fini. Une couche de contexte souveraine et un MCP conscient de la résidence des données sont la direction vers laquelle nous construisons — nous ne prétendons pas les avoir livrés. Ce qui existe aujourd'hui : un modèle EA hébergé en région UE ou on-premise sous votre contrôle, le français et l'anglais natifs, un prix publié, et une évaluation gratuite de maturité EA.

Et c'est une discipline de documentation, pas une garantie de conformité. L'ingénierie de contexte souveraine aide à documenter et à prouver comment l'IA touche les données sensibles d'architecture ; elle soutient un dossier de conformité. Elle ne rend, à elle seule, aucune organisation conforme. Ce verdict appartient à votre régulateur et à votre conseil juridique, pas à un outil.

Pourquoi les géants ne le feront pas pour vous

Les éditeurs qui se précipitent pour greffer MCP sur un référentiel EA — et ils se précipitent — partagent un postulat tacite : que connecter Claude, ChatGPT, Gemini ou Copilot à votre architecture est acceptable. Pour beaucoup d'organisations, ça l'est. Pour une institution européenne régulée, souvent non.

Cet écart n'est pas un oubli que les géants s'empresseront de combler, car le combler signifie optimiser pour la souveraineté plutôt que pour la portée — rétrécir le marché au lieu de l'élargir. L'intersection du contexte vivant, du raisonnement réglementaire et de la souveraineté, pour la finance régulée de l'UE, est précisément l'espace qu'une plateforme mondiale est structurellement peu encline à bien servir. L'ingénierie de contexte souveraine est la discipline qui le comble.

Ce que cela signifie pour une banque ou un assureur régulé

Concrètement, pour un RSSI ou un responsable d'architecture en institution régulée, adopter l'ingénierie de contexte souveraine change la façon de dire oui à l'IA. Vous cessez de choisir entre « interdire les agents » et « envoyer le plan à l'étranger », et vous traitez le contexte comme un actif gouverné.

Cela signifie que votre modèle d'architecture devient le système de contexte sur lequel raisonnent vos agents — maintenu vivant, hébergé là où vos auditeurs l'acceptent, accédé sous les mêmes permissions que les humains qu'il sert, et journalisé pour que chaque réponse assistée par l'IA porte une trace de preuve. Quand le régulateur demande comment l'IA touche votre carte la plus sensible, vous avez une réponse défendable, pas un espoir.

C'est le pari de ce manifeste : dans l'IA régulée, les gagnants ne seront pas ceux qui ont connecté un agent le plus vite. Ce seront ceux qui pouvaient prouver, sur demande, exactement ce que l'agent avait le droit de savoir. Si c'est l'institution que vous comptez être, partez de l'état réel de votre pratique d'architecture aujourd'hui — notre évaluation gratuite de maturité EA note dix dimensions et renvoie un plan priorisé en environ dix minutes.

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