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 son propre contexte 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 le contexte pertinent (quelle campagne, quelle période, ce que cette marque considère comme une "bonne performance") n'a jamais été dans la fenêtre.

Ce qu'on a réellement construit

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

Les mentions comme injection de contexte. 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 contexte 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 du contexte.

Le contexte 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 contexte à la demande l'emporte sur le contexte par défaut.

Le SQL plutôt que l'inondation de contexte. Pour les questions analytiques, l'agent enchaînait auparavant des appels API paginés : la donnée dont le modèle avait besoin était un agrégat de 10 lignes, ce qu'il recevait, c'était des milliers de 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'agrégat (je raconte l'histoire complète dans l'article MCP). Le point côté context engineering : la fenêtre 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

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

Trier à la source. Le meilleur endroit pour filtrer le contexte, c'est avant qu'il n'entre dans la fenêtre : 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 fenêtre (moins que les générations précédentes, mais l'effet n'a pas disparu). 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 le contexte 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.

Lire la fenêtre comme une code review

Arrêtez de polir les instructions et commencez à auditer la fenêtre. Pour toute sortie décevante, videz le contexte complet que le modèle a réellement reçu et lisez-le 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.