Du prompt engineering à l’ingénierie de contexte : le tournant 2026

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 tournant en quatre ans : du prompt au contexte

En 2023, la compétence vedette était le prompt engineering — bien formuler l’instruction suffisait à faire faire des choses impressionnantes à un seul modèle. En 2024, la conversation s’était déplacée vers la génération augmentée par la récupération (RAG) : on ne demandait plus au modèle de tout savoir, on lui fournissait les documents pertinents au moment de la requête. En 2025, les projecteurs se sont tournés vers l’agent engineering — des systèmes multi-étapes qui planifient, appellent des outils et agissent, plutôt que de simplement répondre. Et en 2026, la discipline sous-jacente a un nom : l’ingénierie de contexte.

Chaque étape n’a pas tant remplacé la précédente qu’elle en a révélé le vrai goulot d’étranglement. De meilleurs prompts ont montré que le modèle manquait de connaissances — d’où le RAG. Une meilleure récupération a montré qu’une réponse unique ne suffisait pas — d’où les agents. Et des agents capables ont révélé la contrainte la plus profonde de toutes : un agent ne vaut jamais que le contexte sur lequel il peut raisonner. C’est la thèse de 2026.

Pourquoi le goulot s’est déplacé vers le contexte

À mesure que les modèles de pointe sont devenus excellents pour suivre les instructions, la formulation astucieuse a cessé d’être le facteur différenciant. Deux systèmes faisant tourner le même modèle ne divergent désormais presque que sur ce qu’ils lui présentent : quelles sources, avec quelle fraîcheur, dans quelle structure, sous quelles permissions. C’est cela, l’ingénierie de contexte — décider et fournir la bonne information dans le contexte de travail d’un agent.

Le vocabulaire mérite d’être récupéré délibérément, car des éditeurs le revendiquent déjà. Ardoq, parmi d’autres, a contribué à populariser le terme d’ingénierie de contexte pour l’architecture d’entreprise, et le cadrage est juste : en entreprise, le plus dur n’est jamais le prompt, c’est d’assembler un contexte fiable à travers un patrimoine tentaculaire. Nous créditons ce cadrage — puis nous le poussons là où il n’est pas encore allé.

• Prompt engineering (2023) : optimiser l’instruction envoyée à un modèle
• RAG (2024) : fournir au modèle des documents pertinents à la requête
• Agent engineering (2025) : planifier, appeler des outils, agir sur plusieurs étapes
• Ingénierie de contexte (2026) : concevoir la connaissance sur laquelle l’agent raisonne

Le contexte d’entreprise structuré vit déjà dans l’EA

Voici la partie que la plupart des discussions sur l’ingénierie de contexte sautent. Le contexte d’entreprise le plus riche dont un agent a besoin n’est pas éparpillé en vrac dans des wikis et des tickets — une grande partie est déjà modélisée. Quelles applications existent, quelles capacités métier elles soutiennent, ce qui dépend de quoi, quelles données circulent où, ce qui est obsolète ou à risque : c’est précisément le contenu d’un modèle d’architecture d’entreprise.

Cela fait de l’EA le système de contexte naturel — la couche qu’un agent interroge pour raisonner sur l’ensemble du patrimoine — aux côtés des systèmes de référence (CRM, ERP, ITSM) qui répondent chacun pour un seul domaine. Un système de référence vous dit ce qui s’est passé dans un silo. Le système de contexte vous dit ce qui casse si un composant tombe, ce qui est redondant et ce qui est exposé. Le RAG sur des documents épars est un contexte superficiel ; un graphe EA connecté est un contexte profond et structuré.

• Portefeuille applicatif et capacités soutenues par chaque système
• Dépendances — ce qui casse si un composant tombe
• Flux de données — où va réellement la donnée sensible
• Signaux de cycle de vie — ce qui est obsolète, redondant ou à risque

La condition : le contexte doit être vivant

Il y a un prérequis impératif. Un référentiel EA ne fonctionne comme système de contexte que s’il est à jour. Un agent qui raisonne avec assurance sur un instantané vieux de dix-huit mois donnera des réponses assurées et fausses — et en environnement régulé, une réponse assurée et fausse est pire qu’une absence de réponse.

L’ingénierie de contexte en entreprise n’est donc pas un pipeline de récupération ponctuel ; c’est un engagement envers un référentiel vivant et agent-ready, continuellement rafraîchi. Le modèle derrière l’agent est une commodité interchangeable. La fraîcheur, la structure et la gouvernance de votre contexte sont l’actif durable. Mettez l’ordre dans le bon sens : le contexte d’abord, le reste ensuite.

Ingénierie de contexte souveraine : le prisme régulé

Ajoutez maintenant la contrainte que les géants ont tendance à esquiver. Une cartographie d’architecture d’entreprise est, de fait, un plan quasi complet de l’organisation : inventaire complet des systèmes, dépendances critiques, composants obsolètes, faiblesses connues, flux de données sensibles. La fournir par défaut à un modèle hébergé sur un cloud américain est une mine DORA, NIS2, RGPD et règlement IA de l’UE pour une banque, un assureur ou un organisme public régulé.

L’ingénierie de contexte menée sous contraintes de résidence des données et de gouvernance mérite son propre nom : l’ingénierie de contexte souveraine. Elle garde le contexte au sein de l’UE ou de votre propre infrastructure, rend l’accès conscient des permissions et laisse une trace d’audit qu’un auditeur acceptera. La question n’est plus l’IA peut-elle parler à votre architecture mais l’IA peut-elle raisonner sur votre architecture sans que vous en perdiez le contrôle. Pour la finance régulée, cette seconde question est la seule qui compte.

• Conscient de la résidence : le contexte reste dans l’UE ou sur une infrastructure que vous contrôlez
• Conscient des permissions : qui peut interroger quoi est appliqué, pas supposé
• Auditable : une trace défendable face au regard DORA / CSSF / NIS2

L’EA comme système de contexte — et le garde-fou d’honnêteté

Assemblez les pièces et le tableau 2026 est net : l’agent est une commodité, le prompt un petit levier, et l’actif décisif une couche de contexte vivante, gouvernée et souveraine. L’architecture d’entreprise est le foyer naturel de cette couche — le système de contexte qui rend les réponses d’un agent dignes de confiance et l’acceptation d’un auditeur possible.

Nous serons précis sur ce qui existe. Un serveur MCP souverain connectant les agents à ce contexte est une direction qu’ArchiLU construit — une conviction sur la façon dont les entreprises régulées devraient procéder, pas un produit livré que nous prétendons disposer aujourd’hui. Ce qui est réel dès maintenant, c’est la fondation : un modèle EA vivant, un hébergement en région UE ou on-premise sous votre contrôle, le français et l’anglais natifs, un prix publié. Construisez d’abord le système de contexte ; le protocole par-dessus vient en dernier, et seulement une fois que le contexte vaut la peine d’être interrogé.

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