Moi, et le machin IA

Context engineering : décider ce que le modèle voit

Le context engineering est la discipline qui consiste à décider quels tokens remplissent la fenêtre du modèle à chaque étape d’une tâche. Pas un prompt bien tourné. L’ensemble mouvant des informations que le modèle lit, choisi à neuf à chaque exécution. Si le modèle est un instrument, le context engineering écrit la partition qu’il joue. Et la partition est réécrite à chaque mesure.

Le terme a une date de naissance. Il a été nommé à la mi-2025, et ceux qui l’ont nommé ont été précis sur les raisons. Cet article porte sur cette discipline : ce qu’elle est, ce qu’elle couvre, et où elle s’arrête. Son jumeau, la machine qui fait tourner le modèle, fait l’objet d’un article distinct. Je trace ici la frontière depuis le versant du contenu.

TL;DR Le context engineering consiste à décider quels tokens le modèle voit à chaque étape d’inférence, pas à rédiger un bon prompt. Le nom n’a que quelques mois : Tobi Lütke l’a lancé le 19 juin 2025, Andrej Karpathy l’a défini quelques jours plus tard, Anthropic l’a formalisé en septembre. La taxonomie de LangChain nomme quatre gestes : écrire, sélectionner, compresser, isoler. C’est une discipline de décision, un goût humain qui choisit la configuration de contexte la plus susceptible de produire le comportement voulu. Son jumeau, le harness engineering, construit la machine autour du modèle ; je trace ici la frontière fonctionnelle (contenu contre machine) et je dis franchement que je la trace. Sur les évaluations internes d’Anthropic, l’édition de contexte et la mémoire ont réduit la consommation de tokens de 84 % sur une évaluation à 100 tours et amélioré la performance jusqu’à 39 %.

Les quatre gestes du context engineering, écrire, sélectionner, compresser et isoler, disposés autour d'une fenêtre de contexte centrale qui contient le modèle.

Une discipline nommée, avec une date de naissance

Le context engineering est assez jeune pour qu’on puisse le dater. Il n’a pas dérivé peu à peu dans le vocabulaire. Deux personnes l’y ont installé, publiquement, en l’espace d’une semaine.

Tobi Lütke a ouvert le bal, sur X, le 19 juin 2025. « J’aime beaucoup le terme “context engineering” plutôt que “prompt engineering” », écrit-il. « Il décrit mieux la compétence centrale : l’art de fournir tout le contexte nécessaire pour que la tâche soit plausiblement résoluble par le LLM. » Notez ce qu’il fait. Il ne baptise pas une nouvelle astuce. Il rebaptise la compétence pour la faire pointer vers le bon objet.

Quelques jours plus tard, Andrej Karpathy lui donne la définition qui est restée. Le context engineering, écrit-il, est « l’art délicat, et la science, de remplir la fenêtre de contexte avec exactement les bonnes informations pour l’étape suivante ». Deux expressions portent tout le poids. « Exactement les bonnes informations », donc pas tout ce dont vous disposez. « Pour l’étape suivante », donc pas une fois, mais encore et encore.

En septembre, la définition s’était durcie en prose d’ingénieur. Anthropic parle de « l’ensemble des stratégies permettant de curer et de maintenir l’ensemble optimal de tokens (d’informations) pendant l’inférence d’un LLM » (Anthropic, Effective context engineering for AI agents, 2025). Curer et maintenir. Voilà le travail.

Une frise chronologique horizontale : une longue ère du prompt engineering, puis Lütke forgeant le terme le 19 juin 2025, Karpathy le définissant vers le 25 juin 2025, et Anthropic le formalisant le 29 septembre 2025.

Du prompt au contexte : une progression, pas un changement d’étiquette

Il est tentant d’y voir une vieille recette sous un nom neuf. Ce n’en est pas une. C’est un changement de ce que l’on optimise.

Un prompt, ce sont les mots d’une instruction. Vous le rédigez une fois, vous le formulez bien, vous l’envoyez. Le prompt engineering traitait cette chaîne de caractères comme l’unité de travail. La formulation était juste, vous aviez fini.

Le context engineering prend pour unité un objet bien plus large. Anthropic en dresse le périmètre sans détour : le contexte, ce sont les instructions système, les outils, les éventuelles connexions MCP, les données externes, l’historique des messages, la mémoire, et chaque ligne de sortie d’outil (Anthropic, 2025). Votre instruction soigneusement formulée n’est qu’un élément de cette liste. Elle partage la fenêtre avec tout ce que l’agent a fait, lu et appelé depuis le début de l’exécution.

L’objet a donc grossi, et il s’est mis à bouger. Un prompt est statique. Un contexte est un ensemble de tokens vivant, qui s’accumule et qui n’a plus la même tête à l’étape 40 qu’à l’étape 1. Le « pour l’étape suivante » de Karpathy, c’est tout le basculement. Vous ne composez pas un message. Vous gouvernez un état qui change sous vos pieds. Le prompt engineering en est un sous-ensemble, comme accorder une corde est un sous-ensemble de l’écriture de la partition.

Les quatre gestes : écrire, sélectionner, compresser, isoler

Si le context engineering consiste à gouverner cet état, quels sont les gestes concrets ? LangChain a donné au domaine sa taxonomie de travail : écrire, sélectionner, compresser, isoler (write, select, compress, isolate) (LangChain, Context Engineering for Agents, 2025). Quatre verbes, et toute décision de contexte est l’un d’eux.

Écrire, c’est sauvegarder du contexte hors de la fenêtre pour qu’il survive. Brouillons, fichiers de mémoire, notes sur lesquelles l’agent pourra revenir. Vous ne dépensez pas de l’espace de fenêtre pour vous souvenir ; vous le mettez de côté et vous le rappelez à la demande.

Sélectionner, c’est le geste de récupération : ramener les bons tokens quand l’étape en a besoin. Le fichier pertinent, le souvenir pertinent, le résultat d’outil pertinent. Pas tous. Les bons.

Compresser, c’est réduire ce qui est déjà là. Résumer une longue transcription, dégraisser une sortie d’outil obèse, garder le signal et jeter le reste. C’est le geste qui combat l’accumulation.

Isoler, c’est découper le travail pour qu’aucune fenêtre n’ait à tout porter. Des sous-agents, des contextes séparés, chacun repartant d’une ardoise vierge pour sa part de la tâche.

LangChain cadre l’ensemble par une analogie avec un système d’exploitation : le modèle est le processeur, la fenêtre est la RAM, et le context engineering fait ce que fait un bon OS, décider de ce qui reste résident dans une mémoire rare (LangChain, 2025). Les quatre gestes, c’est votre façon de gérer la RAM.

C’est une discipline de décision

Voici la partie qui résiste à l’automatisation. Les quatre gestes ne forment pas un pipeline que l’on lance une fois pour toutes. Chacun est un jugement, refait à chaque étape, sur la configuration de contexte la plus susceptible de produire le comportement voulu.

C’est pour cela que Karpathy parlait d’un « art délicat et d’une science », pas d’une procédure. Harrison Chase, de LangChain, met la même insistance sur le jugement : le context engineering, c’est « construire des systèmes dynamiques qui fournissent les bonnes informations et les bons outils, dans le bon format, pour que le LLM puisse plausiblement accomplir la tâche ». Dynamiques. Les bonnes informations, le bon format. Plausiblement. Aucun de ces mots ne décrit une recette figée.

Pensez à ce qu’exige réellement une seule sélection. Lequel de ces quarante fichiers est pertinent ici ? Quelles trois lignes de ce journal de test comptent, et lesquelles des quatre cents autres sont du bruit ? Compresser cette transcription maintenant, ou la garder un tour de plus parce que l’étape suivante aura besoin du détail ? Ce sont des décisions de goût. Elles dépendent de la tâche, du modèle, du moment. Une machine sait exécuter la compaction une fois que vous avez décidé de compresser. Décider de compresser, et décider de ce qui y survit, c’est du travail humain. La discipline, c’est le fait de décider.

Où s’arrête le context engineering, où commence le harnais

Alors, où est-ce que ça s’arrête ? Tracez la frontière par l’objet. Le context engineering façonne le contenu : quels tokens entrent dans la fenêtre, curés, sélectionnés, compressés, ordonnés. Son jumeau, le harness engineering, façonne la machine : l’échafaudage d’exécution autour du modèle, la boucle, les outils, les garde-fous, l’orchestration, le code qui lance effectivement une passe de compaction. Contenu contre machine. Partition contre instrument.

Les deux se rejoignent sur une couture : la gestion de contexte, la compaction et la troncature qui taillent une fenêtre en cours d’exécution. Cette couture est une capacité du harnais qui exécute une décision de context engineering. Vous décidez de ce que la fenêtre doit contenir. La machine l’applique. La partition dit de jouer plus doucement ; c’est l’instrument qui fait le son.

Un schéma à deux couches : une boîte harnais extérieure qui enveloppe une fenêtre de contexte intérieure contenant le modèle, le context engineering possédant le contenu et le harness engineering possédant la machine, les deux se rejoignant à la gestion de contexte.

Je dois être honnête : le domaine n’est pas d’accord sur la façon dont ces deux notions s’emboîtent. LangChain traite le harnais comme le contenant, et qualifie les harnais de « mécanismes de livraison d’un bon context engineering, pour l’essentiel » (LangChain, Anatomy of an Agent Harness). Birgitta Böckeler, sur le site de Martin Fowler, les emboîte dans l’autre sens : « un harnais est une forme particulière de context engineering ». Anthropic les garde séparés et n’emploie jamais le mot harnais dans son article sur le context engineering. Trois points de vue respectables, trois schémas différents. Je ne prétends donc pas détenir la vraie topologie. Je trace une frontière fonctionnelle par l’objet, contenu contre machine, parce que c’est celle qui vous aide à décider sur quoi travailler. Le versant machine est une discipline à part entière, et un article à part entière : le harness engineering, le versant machine.

Et ça paie

Rien de tout cela n’est esthétique. Curer l’ensemble de tokens fait bouger les chiffres, et les chiffres sont gros.

🔬 La curation fait bouger les chiffres. Sur les évaluations internes d’Anthropic, l’édition de contexte a réduit la consommation de tokens de 84 % sur une tâche de recherche web à 100 tours (Anthropic / Claude Developer Platform, Managing context, 2025). Le même travail, pour un sixième des tokens. Sur une évaluation interne de recherche agentique, la mémoire combinée à l’édition de contexte a amélioré la performance de 39 %, et l’édition de contexte seule l’a améliorée de 29 %.

Trois barres horizontales issues des évaluations internes d'Anthropic : 84 % de tokens économisés sur une évaluation de recherche web à 100 tours, 39 % de gain avec la mémoire plus l'édition de contexte, et 29 % de gain avec l'édition de contexte seule.

Lisez ces chiffres avec leur étiquette. Ce sont les évaluations internes d’Anthropic, rapportées sans tailles d’échantillon, et je ne les ai vues reproduites nulle part de façon indépendante. Prenez-les comme l’indication directionnelle d’un fournisseur, pas comme un banc d’essai établi. Même en les escomptant, la direction reste le point important : le même modèle, sur la même tâche, fait mesurablement mieux quand la fenêtre est curée plutôt que laissée à se remplir toute seule. Une bonne partition, pas un plus gros instrument.

Ce que cet article laisse à d’autres

Cet article nomme la discipline et en trace la frontière. Il s’appuie sur d’autres textes pour ce qu’il ne porte pas.

Pour le mécanisme sous-jacent, pourquoi la fenêtre est finie, pourquoi une fenêtre plus longue coûte plus que linéairement, et pourquoi capacité n’est pas fiabilité, voyez l’article consacré au terme lui-même : ce qu’est une fenêtre de contexte. Le context engineering est la pratique ; cet article-là décrit la machinerie sur laquelle il opère.

Côté technique, deux articles vont plus loin qu’une définition ne le peut. Garder délibérément une fenêtre légère en cours d’exécution, et comprendre pourquoi une fenêtre plus grande ne fait que masquer la pourriture, c’est un sujet à part entière. Savoir quels tokens méritent vraiment leur place dans le préchargement, le lexique d’abord, en est un autre.

Retenez la seule idée qui compte. Le context engineering n’est pas un prompt que l’on perfectionne. C’est une partition que l’on réécrit sans cesse, en décidant à chaque étape quels tokens le modèle a le droit de lire. L’instrument a toujours été capable. C’est dans la partition que se trouve le travail.

Sources

context-engineering notions
Newsletter

Un email par mois — ce sur quoi je travaille, et les articles qui en sortent. Désinscription en un clic.Pour l'instant, les envois sont en anglais.

Malo Couaran
Une réaction, une correction, une meilleure idée ? Répondez par email.