Le context engineering : architecturer ce que l'IA voit

On a beaucoup parlé de prompt engineering ces dernières années, comme s’il s’agissait de trouver la bonne formule, la phrase magique qui débloque le bon comportement. Cette vision a vieilli très vite. Sur les systèmes sérieux, ceux qui tournent en production avec de vrais enjeux, ce qui détermine la qualité d’une réponse n’est presque jamais l’élégance de la consigne. C’est ce que le modèle a effectivement sous les yeux au moment précis où il répond.

Un LLM ne sait rien de votre métier au-delà de ce que contient sa fenêtre de contexte à l’instant T. Il ne « connaît » pas votre client, votre historique, vos règles internes, l’état de votre commande. Il voit un certain texte, et il raisonne sur ce texte, strictement. Tout l’enjeu se déplace donc, et c’est un déplacement majeur, vers une question d’architecture : qu’est-ce qu’on lui montre, dans quel ordre, et surtout qu’est-ce qu’on lui cache. C’est ce qu’on appelle désormais le context engineering, et ce n’est pas un réglage de surface, c’est un vrai travail de conception.

La fenêtre de contexte est une ressource rare

Première chose à intégrer, parce qu’elle est contre-intuitive : le contexte n’est pas gratuit, et il n’est pas extensible à l’infini malgré les fenêtres qui s’agrandissent. Chaque élément qu’on y place a un coût en tokens, donc en argent et en latence, ce qui rejoint directement la discipline du token que je défendais sur le plan budgétaire. Mais le coût financier n’est pas le pire. Le pire, c’est l’effet sur la qualité du raisonnement.

Un contexte surchargé dégrade la réponse, et c’est mesurable. Noyez l’information utile sous trois mille lignes de documents ramenés « au cas où », et le modèle perd le fil. Il accorde de l’importance au mauvais passage, se laisse distraire par un détail saillant mais hors sujet, ou rate purement l’élément décisif coincé au milieu d’une masse de texte. La tentation du « mettons tout, il fera le tri lui-même » est exactement l’inverse de ce qu’il faut faire. Le tri, c’est votre travail, pas le sien. Un bon contexte n’est jamais un contexte complet. C’est un contexte pertinent, et aussi court que la tâche le permet.

Cette idée a une conséquence directe sur la façon de concevoir. Ajouter de l’information au contexte n’est pas un geste neutre qu’on peut multiplier sans risque. C’est un arbitrage : chaque élément ajouté doit gagner sa place contre le bruit qu’il introduit. Un architecte qui raisonne ainsi conçoit des contextes maigres et précis, là où une implémentation naïve empile par prudence et dégrade par accumulation.

RAG : récupérer le bon fragment, pas tout le document

Le RAG, dont je décrivais le flux dans l’intégration des LLM en .NET, est trop souvent réduit à une technique pour donner accès à des données externes. C’est passer à côté de l’essentiel. Le RAG est d’abord une stratégie de context engineering. Son intérêt profond n’est pas qu’il permet de chercher dans une base, mais qu’il permet de ne mettre dans le contexte que les fragments qui comptent pour la question posée, au lieu d’y déverser des documents entiers dont 95 % sont hors sujet.

La qualité d’un système RAG ne se joue donc pas tant sur le modèle de génération que sur l’étape de récupération, et c’est un renversement utile pour l’architecte. Si vous ramenez les mauvais fragments, le meilleur modèle du monde répondra mal, parce qu’il répondra fidèlement à un contexte trompeur, avec aplomb. Si vous ramenez les bons, un modèle modeste fera souvent parfaitement l’affaire. L’effort doit donc se concentrer là où il paie : le découpage des documents en fragments cohérents, la pertinence du classement, la capacité à écarter ce qui ressemble à la question sans y répondre. La course au modèle le plus puissant masque souvent une étape de récupération bâclée, qu’aucune puissance de génération ne rattrape.

Le découpage décide de tout

Un point technique qu’on sous-estime presque toujours : la façon dont on découpe les documents en fragments conditionne tout le reste. Un fragment trop petit perd son contexte et devient ininterprétable. Un fragment trop gros ramène du bruit avec le signal et dilue la pertinence. Un découpage qui coupe au milieu d’une idée rend les deux moitiés inutiles. Je passe, sur les systèmes sérieux, plus de temps sur la stratégie de découpage et sur l’évaluation de la récupération que sur le prompt de génération lui-même, parce que c’est là que se gagne ou se perd la qualité finale.

Hiérarchiser ce qui entre dans le contexte

Je raisonne sur le contexte comme sur une mémoire à plusieurs niveaux, du plus stable au plus volatil. Cette hiérarchie aide à décider, à chaque instant, ce qui mérite sa place.

Au sommet, les instructions de système et les règles invariantes : qui est l’agent, ce qu’il doit et ne doit pas faire, le format attendu. Cela change rarement et ne se sacrifie jamais. En dessous, les connaissances de fond pertinentes pour la tâche, récupérées dynamiquement selon la requête : c’est la part servie par le RAG. Puis l’état de la conversation ou de la tâche en cours, ce qui a déjà été dit, décidé, tenté. Enfin, tout en bas et tout récent, la requête immédiate à laquelle il faut répondre.

Cette hiérarchie n’est pas cosmétique, elle est opérationnelle. Elle dicte quoi garder et quoi retirer quand la place vient à manquer. Les instructions de système ne se sacrifient sous aucun prétexte. L’historique ancien d’une longue conversation, lui, peut être condensé ou écarté. Et faire ce choix proprement suppose une décision explicite, codée, pas une troncature aveugle qui couperait mécaniquement au début du contexte et supprimerait peut-être l’information la plus structurante.

Compacter plutôt que tronquer

C’est le point que les implémentations naïves ratent le plus systématiquement, et celui qui cause le plus d’incidents subtils. Quand une conversation ou une tâche s’allonge, le contexte finit par dépasser la fenêtre disponible. La réaction paresseuse consiste à couper le plus ancien, parce que c’est trivial à implémenter. Le problème, c’est que le plus ancien contient parfois la décision structurante prise au tout début, celle dont tout le reste découle. On coupe la racine en croyant tailler une branche morte.

La bonne approche est la compaction. Plutôt que de jeter l’historique, on le résume : on en extrait les décisions prises, les faits durables, les contraintes établies, et on remplace le détail verbeux des échanges par cette synthèse dense. On garde le sens, on libère la place. C’est exactement l’esprit de la spécification du comportement réel que je défendais pour le legacy : ce qui compte, ce n’est pas la trace brute de tout ce qui s’est dit, c’est le savoir qu’on en extrait et qu’on choisit de conserver.

Un contexte bien tenu est donc un contexte qu’on raffine en continu, pas un contexte qu’on laisse gonfler jusqu’à le tronquer dans la panique au moment où il déborde. Cela demande du travail, une logique de compaction à concevoir et à tester, et c’est précisément ce travail qui sépare un agent qui tient une longue tâche cohérente d’un agent qui perd le fil au bout de quelques minutes et se contredit.

Le contexte se conçoit, il ne s’improvise pas

Tout cela dessine une responsabilité claire, et une définition. La fenêtre de contexte est une interface, au sens fort du terme : c’est la frontière par laquelle votre système parle au modèle, le seul canal par lequel votre métier existe pour lui. Comme toute interface qui compte, elle se conçoit avec soin, elle se documente, elle se teste, elle se gouverne. Ce qu’on y fait entrer, l’ordre dans lequel on l’organise, ce qu’on en retire quand la place manque, tout cela relève de décisions d’ingénierie qui méritent d’être explicites et défendues, pas laissées au hasard d’une concaténation.

L’erreur serait de croire que le context engineering est une affaire de bricolage, qu’on ajuste à l’instinct jusqu’à ce que « ça marche » sur les quelques cas qu’on a sous la main. C’est tout l’inverse. C’est l’endroit où se décide, concrètement et à chaque appel, ce que l’IA sait et ne sait pas au moment d’agir. Or décider ce qu’un composant voit de son environnement, et avec quelles garanties, c’est la définition même du travail d’architecture, qu’il s’agisse d’IA ou d’autre chose.

Le modèle, lui, on en changera plusieurs fois dans les années qui viennent, et chaque fois on espérera qu’il soit meilleur. La discipline avec laquelle on lui présente le monde, elle, est ce qui fera durablement la différence entre un système qui répond juste et un système qui répond à côté avec assurance. C’est sur cette discipline, bien plus que sur le choix du modèle du moment, que se mesure la valeur de celui qui conçoit le système.