Claude Code et Codex changent la donne : l'ingénierie de contexte supplante le prompt

Habr AI a publié une longue analyse sur le Context Engineering dont la thèse centrale est très pragmatique : dans les outils agentiques comme Claude Code, Codex et Cursor, la qualité du résultat dépend moins de la formulation de la requête que de tout l'environnement qui entoure le modèle. Le texte de l'utilisateur n'occupe qu'une part minuscule du contexte. L'influence décisive revient au prompt système, aux instructions du projet, à la mémoire entre sessions, aux outils, à l'historique du dialogue et aux résultats des appels. Autrement dit, l'ère du « prompt magique » touche à sa fin et laisse place à la conception du contexte.

L'idée clé tourne autour de la nature de la fenêtre de contexte. L'auteur propose de la voir comme le bureau du modèle : plus il y traîne de papiers inutiles, plus l'attention se répartit mal entre les signaux réellement importants. Un contexte long ne coûte pas seulement plus cher.

Il dégrade aussi la qualité par deux effets. Le premier est le context rot : l'attention se dilue, le modèle oublie les contraintes initiales, s'attarde sur de vieux points et répond de façon plus floue. Le second est le reasoning shift : à mesure que le contexte grandit, une partie de la puissance de calcul sert à traiter l'entrée plutôt qu'à raisonner, si bien que la réponse peut sembler assurée tout en étant moins bien fondée.

L'article cite une estimation selon laquelle un contexte long peut, sans avertissement, réduire jusqu'à 50 pour cent la profondeur du raisonnement.

L'auteur explique ce phénomène par l'architecture Transformer. Dans sa forme de base, l'attention a une complexité quadratique O(n^2) : chaque token doit être mis en relation avec tous les autres. Ajouter des documents, des fichiers et de longues conversations fait donc croître le coût non pas de façon linéaire, mais quadratique. En pratique, cela touche quatre paramètres à la fois : la vitesse de réponse, le coût, les limites et la précision. D'où la thèse principale : un bon context engineering ne consiste pas à « tout fourrer dans le modèle », mais à sélectionner l'ensemble minimal de tokens à fort signal qui maximise les chances d'obtenir le résultat voulu.

L'article détaille ensuite de quoi se compose le contexte dans les systèmes agentiques. Outre les poids du modèle lui-même, il existe au moins plusieurs couches pilotables : le prompt système, les fichiers de projet comme CLAUDE.md ou AGENTS.

md, la mémoire sur l'utilisateur et le projet, des skills avec des processus prêts à l'emploi, les intégrations MCP, les fichiers chargés de façon ciblée et tout l'historique de tool_result. L'accent est mis sur le fait que le modèle ne « se souvient » pas de la conversation par lui-même : le harness reconstitue l'historique et le lui renvoie à chaque fois. Dès lors, chaque description d'outil superflue, chaque serveur MCP inutile et chaque long fichier système consomment des tokens à répétition.

Pour économiser, il faut du prompt cache, un compact réfléchi, de nouvelles sessions via clear et l'isolation des recherches lourdes dans des subagents, afin que l'agent principal reçoive une courte synthèse plutôt que des montagnes de données intermédiaires.

La partie la plus concrète porte sur le coût du mode agentique. Une seule requête à un agent peut ne pas correspondre à un unique appel au modèle, mais à toute une chaîne de plusieurs appels avec tool use. Dans l'exemple de l'analyse d'un déploiement en échec, un message de l'utilisateur se transforme en quatre appels au modèle et trois exécutions d'outils. Sans cache, un tel cycle devient vite économiquement absurde ; avec le prompt cache, le prix chute nettement, mais il faut rappeler que les tokens de sortie et le thinking caché coûtent plus cher que l'input ordinaire, et que les longues définitions d'outils et les instructions système sont incluses à chaque tour.

D'où la conclusion de l'auteur : le maître ne se distingue pas par des prompts plus astucieux, mais par le fait de bâtir une seule fois un environnement reproductible, avec règles de projet, mémoire, outils pertinents et processus, puis de contraindre l'agent à travailler selon ce contrat.

Pour le marché du développement assisté par IA, le changement est important. La concurrence se joue de moins en moins sur une requête bien tournée et de plus en plus sur la qualité de l'assemblage du contexte, la discipline sur les tokens et l'ingénierie de l'environnement agentique. Les équipes qui sauront gérer la mémoire, les outils et l'historique aussi soigneusement qu'elles géraient jadis les prompts obtiendront non seulement des réponses plus précises, mais aussi des coûts prévisibles. L'étape suivante de l'évolution des outils d'IA sera donc définie non par la magie de la requête, mais par l'architecture du contexte.