Aux échecs, le roi est la pièce qu’on protège. Il ne prend presque rien, il ne menace personne, mais s’il tombe, la partie est finie. La reine, elle, traverse l’échiquier dans tous les sens. C’est elle qui gagne les parties. Vos données sont le roi. Le contexte est la reine. Et depuis dix ans, vous avez tout investi dans la protection du roi.
Dix ans à couronner le roi
Data lakes, warehouses, gouvernance, catalogues, pipelines. Les entreprises ont dépensé une décennie et des budgets considérables pour collecter, stocker et sécuriser leurs données. Ce n’était pas une erreur. Sans roi, pas de partie : une IA branchée sur une base vide ou fausse ne produit rien d’utile.
Mais posséder n’est pas manipuler. La donnée empilée dans un warehouse est une pièce immobile au centre de l’échiquier. Elle a de la valeur, elle est protégée, et elle ne fait rien. Ce qui la rend jouable, c’est tout ce qui l’entoure : sa définition, son origine, son usage légitime, ses exceptions. Autrement dit, son contexte.
Ce déséquilibre est resté supportable tant que des humains servaient d’interface. Un analyste qui connaît la maison compense les trous de documentation sans même s’en rendre compte. Le jour où vous branchez une IA directement sur les systèmes, cette compensation silencieuse disparaît, et le déséquilibre devient visible.
Le champ pays_1, ou la donnée sans contexte
Prenez un CRM qui a vécu. Dans l’objet contact, deux champs cohabitent : pays et pays_1. Lequel fait foi ? Le premier vient du formulaire du site, le second d’un import de 2021 jamais nettoyé. L’un est alimenté en continu, l’autre est figé. Les workflows de scoring pointent sur le premier, les rapports de la direction commerciale sur le second.
Aucune de ces informations n’est écrite dans le CRM. Elle vit dans la tête de la personne qui administre l’outil depuis trois ans. Un humain qui arrive sur la base fait des erreurs pendant des semaines. Une IA branchée dessus fait les mêmes erreurs, mais à la vitesse d’une API et avec un aplomb parfait.
C’est exactement le point. La donnée existe, elle est même redondante. Ce qui manque, c’est le savoir tacite qui dit quel champ pour quel usage. Et ce cas n’a rien d’exceptionnel : la propriété de chiffre d’affaires qui existe en trois devises, le statut de deal dont deux valeurs signifient la même chose, la date de dernière activité qui compte les emails automatiques. Multipliez par des centaines de propriétés, d’objets et d’outils, et vous obtenez le vrai plafond de verre des projets IA en entreprise.
La gouvernance avait la bonne intuition
La gouvernance des données était pourtant censée jouer ce rôle de pont. Dictionnaires de données, catalogues, lineage, data stewards : sur le papier, le problème du champ pays_1 est résolu depuis dix ans. L’intuition était juste, documenter ce qui fait foi et qui en répond.
Mais cette gouvernance a été conçue pour des humains et pour la conformité. Elle produit des catalogues que personne ne consulte, des définitions figées dans un wiki que plus personne ne met à jour, une documentation pensée pour l’audit plutôt que pour l’action. Elle répond très bien à « qui peut accéder à quoi » et « d’où vient cette donnée », rarement à « comment utiliser correctement cette donnée pour cette tâche précise ».
Le contexte, c’est cette gouvernance mise en mouvement. Le dictionnaire de données cesse d’être un document de référence dormant et devient une instruction que l’agent lit réellement avant d’agir. La gouvernance est la matière première, le contexte est son activation.
Le contexte devient une discipline
Cette activation porte un nom, le context engineering. Le prompt engineering a été l’étape un : bien formuler la question. L’étape deux consiste à construire l’environnement informationnel complet du modèle. Gartner y voit le successeur direct du prompt engineering pour les systèmes d’entreprise, et la London Business School décrit la bataille de 2026 comme celle du contexte le plus riche et le plus défendable.
Concrètement, le contexte se construit en couches :
- Les instructions : conventions, règles métier, définitions qui font foi.
- La mémoire : ce qui a été décidé avant, et pourquoi.
- Les outils : les accès du modèle aux systèmes réels, pas à des copies périmées.
- L’état : où en est la tâche, ce qui a déjà été fait, ce qui reste.
La différence avec le prompt engineering est structurelle. Un prompt est un texte qu’on rédige, le contexte est un système qu’on architecture. Un prompt se réécrit à chaque changement de règle métier, une couche de contexte se met à jour à un seul endroit et tous les agents en bénéficient. C’est ce travail, invisible dans les démos, qui sépare un agent qu’on pilote d’un agent qu’on surveille. Le même modèle, avec ou sans ces couches, produit des résultats sans commune mesure.
Tout le monde a accès aux mêmes modèles. Personne n’a accès à votre contexte.
Le context engineer, côté données
Si le contexte devient une discipline, quelqu’un doit l’exercer. Ce quelqu’un a un titre, context engineer, et nous lui avons déjà consacré un portrait complet : ni développeur, ni prompt engineer, c’est l’architecte du corpus de règles vivantes qui rend l’orchestration opérante sur votre contexte. Ce qui mérite d’être précisé ici, c’est son quotidien face à la donnée.
Car le data engineer fait circuler la donnée, le context engineer la rend intelligible. Côté données, son travail ressemble à ceci :
- Cartographier ce qui fait foi : quel champ, quelle source, quelle définition, quelle exception.
- Écrire les instructions qui encodent les conventions de l’équipe, et les maintenir comme du code.
- Brancher les agents sur les systèmes réels, avec les bons périmètres d’accès.
- Concevoir la mémoire : ce qu’un agent doit retenir d’une session à l’autre, et ce qu’il doit oublier.
- Arbitrer en continu ce qui entre dans le contexte et ce qui en sort.
Le profil qui correspond existe déjà dans vos équipes. C’est souvent l’administrateur CRM, le responsable ops ou le data steward, celui qui détient précisément le savoir tacite du champ pays_1. La compétence dominante n’est pas le code. C’est la curation, l’écriture et l’arbitrage : savoir dire ce qui compte, le formuler sans ambiguïté, et refuser d’ajouter ce qui n’apporte rien. Un métier de documentation élevé au rang d’architecture.
Data-rich, context-poor
Les chiffres racontent la suite. Gartner prévoit que 40 % des applications d’entreprise intégreront des agents fin 2026, et dans le même temps que plus de 40 % des projets agentiques seront annulés d’ici 2027. Le fil conducteur de ces échecs n’est pas la puissance des modèles. Ce sont des agents nourris de données fragmentées, sans les définitions ni la connaissance institutionnelle qui les rendent exploitables.
Ces entreprises sont riches en données et pauvres en contexte. Elles ont un roi bien gardé et aucune reine sur l’échiquier. Et comme le meilleur modèle change toutes les six semaines, miser sur le modèle plutôt que sur le contexte revient à investir dans l’actif qui se déprécie le plus vite. Le contexte suit la trajectoire inverse : chaque définition clarifiée, chaque convention écrite, chaque connexion propre survit aux modèles qui passent et prend de la valeur à chaque montée en gamme.
Plus de contexte n'est pas mieux. Les travaux sur le context rot montrent que la performance des modèles chute quand le contexte devient volumineux et bruyant. La discipline consiste à donner le bon contexte au bon moment, pas tout le contexte tout le temps.
- La donnée reste indispensable, mais elle est devenue une commodité inerte sans son contexte.
- Le savoir tacite (quel champ, quel usage, quelle exception) est le vrai goulot des projets IA.
- La gouvernance des données avait la bonne intuition, mais elle a été conçue pour l'audit. Le contexte est sa mise en mouvement.
- Le context engineering structure ce savoir en couches : instructions, mémoire, outils, état.
- Le context engineer est un métier de curation et d'arbitrage, pas de code. Il existe déjà dans vos équipes.
- Le contexte est le seul actif IA qui vous appartient vraiment et qui s'apprécie avec le temps.
Continuez à protéger le roi. Sécurisez vos données, nettoyez vos bases, gardez la main sur vos actifs. Mais ne confondez plus la pièce qu’on défend avec celle qui gagne. La partie de 2026 se joue avec la reine, et la reine s’appelle contexte.
