Claude Code et Codex changent les règles : les prompts cèdent la place à l'ingénierie du contexte

Sur Habr AI, une grande analyse sur Context Engineering a été publiée, et sa thèse principale est extrêmement pratique : dans les outils d'agents comme Claude Code, Codex et Cursor, la qualité des résultats dépend désormais non pas tant de la formulation de la requête, mais de tout l'environnement autour du modèle. Le texte propre de l'utilisateur n'occupe qu'une fraction minuscule du contexte, tandis que l'influence décisive provient du prompt système, des instructions du projet, de la mémoire entre les sessions, des outils, de l'historique des dialogues et des résultats des appels d'outils. En d'autres termes, l'ère du « prompt magique » se termine, et l'ingénierie de contexte prend sa place.

L'idée clé tourne autour de la nature de la fenêtre de contexte. Il est proposé de la percevoir comme le bureau du modèle : plus il y a de papiers aléatoires dessus, plus l'attention est mal distribuée entre les vrais signaux importants. Un contexte long n'est pas seulement plus coûteux.

Il réduit la qualité en raison de deux effets. Le premier est context rot, lorsque l'attention s'étale, le modèle commence à oublier les contraintes antérieures, reste bloqué sur d'anciens points et donne des réponses plus vagues. Le second est reasoning shift : à mesure que le contexte s'étend, une partie de la ressource informatique va au traitement de l'entrée plutôt qu'au raisonnement, de sorte que la réponse peut sembler confiante mais être moins bien justifiée.

L'article fournit une estimation selon laquelle un contexte long peut réduire inopinément la profondeur du raisonnement jusqu'à 50 pour cent. Pourquoi cela se produit, l'auteur l'explique par l'architecture Transformer. Attention sous sa forme basique a une complexité quadratique O(n^2) : chaque token doit se rapporter à chaque autre.

Par conséquent, l'ajout de documents, de fichiers et de correspondance longue redimensionne le coût non pas linéairement, mais quadratiquement. En pratique, cela affecte les quatre paramètres à la fois : vitesse de réponse, coût, limites et précision. D'où la thèse principale : une bonne ingénierie de contexte ne consiste pas à « fourrer tout dans le modèle », mais à sélectionner l'ensemble minimal de tokens à haut signal qui maximise la probabilité du résultat souhaité.

En outre, le matériel discute de ce dont est composé le contexte dans les systèmes d'agents. Au-delà des poids du modèle lui-même, il existe au moins plusieurs couches gérables : prompt système, fichiers de projet comme CLAUDE.md ou AGENTS.

md, mémoire utilisateur et projet, skills avec processus prêts à l'emploi, intégrations MCP, fichiers chargés spécifiquement et tout l'historique tool_result. Un accent particulier est mis sur le fait que le modèle ne « se souvient » pas de la conversation par lui-même : le harness réassemble et renvoie l'historique à chaque fois. Pour cette raison, chaque description d'outil inutile, chaque serveur MCP inutilisé et chaque long fichier système commencent à consommer les tokens de nombreuses fois.

Pour économiser les tokens, il faut prompt cache, compact délibéré, nouvelles sessions via clear et isolement de la recherche lourde dans les subagents, afin que l'agent principal reçoive non pas des montagnes de données intermédiaires, mais un bref résumé. La partie la plus pratique concerne le coût du mode agent. Une demande à un agent peut ne pas être un seul appel au modèle, mais toute une chaîne de plusieurs appels avec tool use.

Dans l'exemple d'analyse d'un déploiement échoué, un message utilisateur devient quatre appels au modèle et trois exécutions d'outils. Sans cache, un tel cycle devient rapidement économiquement dénué de sens ; avec prompt cache le prix chute drastiquement, mais même alors il est important de se souvenir que les tokens de sortie et le thinking caché coûtent plus cher que l'entrée régulière, et les longues définitions d'outils et les instructions système se retrouvent à chaque tour. D'où la conclusion de l'auteur : un maître ne se distingue pas par l'écriture de prompts plus ingénieux, mais par l'assemblage une seule fois d'un environnement reproductible — avec les règles du projet, la mémoire, les outils pertinents et les processus — et ensuite faire en sorte que l'agent travaille selon ce contrat.

Pour le marché du développement de l'IA, c'est un changement important. La compétition porte de moins en moins sur la belle formulation des requêtes et de plus en plus sur la qualité de l'assemblage du contexte, la discipline des tokens et l'ingénierie de l'environnement de l'agent. Les équipes qui apprendront à gérer la mémoire, les outils et l'historique aussi soigneusement qu'elles géraient autrefois les prompts obtiendront non seulement des réponses plus précises, mais aussi des coûts prévisibles.

Cela signifie que le prochain stade de l'évolution des outils d'IA sera déterminé non pas par la magie du prompt, mais par l'architecture du contexte.