Context Engineering : la compétence qui a remplacé le prompt engineering

Il y a deux ans, le métier consistait à trouver les mots magiques. "Think step by step." "You are an expert." On testait les formulations en A/B comme des alchimistes médiévaux, et parfois ça marchait même.

Cette époque est terminée. Les modèles sont devenus assez bons pour que la formulation compte bien moins qu'avant. Ce qui décide si une fonctionnalité IA est utile aujourd'hui est une question tout autre : au moment où le modèle génère une réponse, qu'y a-t-il exactement dans sa context window, et est-ce le bon matériau ?

Cette question a désormais un nom, le context engineering, et elle est discrètement devenue l'essentiel de mon travail.

Détails produit anonymisés. Patterns d'ingénierie réels.

Un échec concret

Sur une plateforme publicitaire sur laquelle je travaille, les utilisateurs discutent avec un agent qui gère leurs campagnes. Première version : un system prompt correct, l'ensemble des tools, et c'est parti. Un utilisateur demande "pourquoi la performance a-t-elle chuté la semaine dernière ?"

L'agent n'a aucune idée de laquelle des 40 campagnes de l'utilisateur il s'agit. Alors soit il pose des questions de clarification (agaçant), soit il devine (dangereux), soit il appelle cinq tools pour tout lister avant de commencer le vrai travail (lent, et il inonde sa propre context de données de campagne non pertinentes, dégradant tout ce qui suit).

Aucune formulation de prompt ne corrige ça. Le problème, c'est que la context pertinente (quelle campagne, quelle période, ce que cette marque considère comme une "bonne performance") n'a jamais été dans la window.

Ce qu'on a réellement construit

Trois mécanismes, dont aucun n'est un prompt.

Les mentions comme injection de context. Les utilisateurs peuvent @mentionner une campagne dans le chat, comme on mentionnerait un collègue dans Slack. La mention se résout en un bloc de context structuré (config de la campagne, métriques récentes, statut) injecté avant l'exécution du modèle. Une seule interaction, et l'ambiguïté ci-dessus disparaît. L'UI est devenue l'outil d'assemblage de la context.

Le context de marque comme tool, pas comme copier-coller. Chaque workspace a un brand kit : couleurs, ton, produits, extraits automatiquement du site web de l'entreprise. On ne fourre pas ça dans chaque conversation. L'agent dispose d'un tool getBrandKit et le récupère quand la tâche l'exige : générer une accroche publicitaire, oui ; sortir un rapport de dépenses, non. Le context à la demande l'emporte sur le context par défaut.

Le SQL plutôt que l'inondation de context. Pour les questions analytiques, l'agent enchaînait auparavant des appels API paginés, chaque réponse déversant des kilo-octets de JSON dans la window. La donnée dont le modèle avait besoin était un aggregate de 10 lignes ; ce qu'il recevait, c'était 4 000 lignes d'entités brutes. On a remplacé la chaîne par un seul tool qui exécute du SQL sur l'entrepôt analytique et ne renvoie que l'aggregate. La context reste petite et dense, et la qualité des réponses a bondi plus que n'importe quel changement de prompt n'a jamais réussi à le faire.

Remarquez le motif : chaque correction portait sur la sélection et la compression, pas sur la formulation.

Les principes sur lesquels je reviens sans cesse

La context est un budget, pas un sac. Chaque token entre en concurrence avec tous les autres tokens pour l'attention du modèle. Les longues context windows ont rendu possible de tout y entasser ; elles n'en ont pas fait une bonne idée. Une context non pertinente ne coûte pas seulement de l'argent, elle dégrade activement la sortie, parce que le modèle y prête attention.

Curer à la source. Le meilleur endroit pour filtrer la context, c'est avant qu'elle n'entre dans la window : une étape de retrieval qui rerank, un tool qui agrège au lieu de lister, un système de mention qui laisse l'utilisateur pointer. Le pire endroit, c'est d'espérer que le modèle ignore le bruit.

La structure l'emporte sur la prose. Un bloc labellisé, <campaign id="..."> status: paused, spend_7d: ... </campaign>, surpasse la même information sous forme de paragraphe. Le modèle parse la structure de façon plus fiable, et vous pouvez valider la structure par programmation.

La récence et la position comptent. Les modèles prêtent davantage attention au début et à la fin de la window. L'instruction critique ou la donnée clé va aux extrémités ; le matériau de référence va au milieu. Banal, mesurable, et ça marche.

Écrire pour le prochain call, aussi. Dans les agent loops, vos sorties de tool sont la context de demain. Un tool qui renvoie des résultats propres, compacts et labellisés rend chaque étape suivante plus intelligente. Un tool qui renvoie des dumps API bruts empoisonne le reste de la conversation.

Où est passé le prompt engineering

Il n'a pas disparu, il s'est déplacé. Les prompts à plus fort levier dans notre système aujourd'hui ne sont pas le system prompt. Ce sont les descriptions de tools (qui décident si l'agent choisit le bon tool) et les messages d'erreur (qui décident s'il se remet de ses échecs). Les deux sont des prompts lus par le modèle au moment précis où il prend une décision. On itère dessus constamment. Le system prompt, lui, n'a quasiment pas changé depuis des mois.

Ce que je dirais à mon moi du début

Arrête de polir les instructions et commence à auditer la window. Pour toute sortie décevante, vide la context complète que le modèle a réellement reçue et lis-la comme une code review : qu'y a-t-il là-dedans qui ne devrait pas y être ? Qu'est-ce qui manque ? Qu'est-ce qui est en prose et devrait être structuré ? Qu'est-ce qui est arrivé à la mauvaise position ?

Neuf fois sur dix, la solution est là, et c'est une solution d'ingénierie, pas de rédaction. Ce qui est une bonne nouvelle pour nous, car le retrieval, l'agrégation, l'injection et la compression sont des problèmes de systèmes. C'est le travail qu'on sait déjà faire.