En bref

Le context engineering est la discipline qui consiste à décider, pour chaque appel à un modèle, quelles informations placer dans la fenêtre de contexte, dans quel ordre et sous quelle forme. Le terme a été popularisé en juin 2025, porté notamment par Andrej Karpathy et Tobi Lütke (Shopify). La distinction avec le prompt engineering est nette : le prompt est une instruction ; le contexte est l’état informationnel complet transmis au modèle.

Pourquoi le terme a émergé

En juin 2025, Tobi Lütke (PDG de Shopify) tweete que “context engineering” décrit mieux que “prompt engineering” la compétence centrale : fournir tout le contexte pour que la tâche soit soluble par le modèle. Andrej Karpathy emboîte le pas : dans toute application LLM en production, le travail réel est “l’art délicat et la science de remplir la fenêtre de contexte avec les bonnes informations pour la prochaine étape”.

Simon Willison, qui avait défendu le terme “prompt engineering”, reconnaît le problème : le public a associé “prompt” à une simple saisie dans un chatbot. Le terme “context engineering” bénéficierait d’une définition publique plus proche de l’intention technique réelle.

Ce glissement terminologique reflète une évolution pratique : dans les systèmes agents complexes, le prompt système ne représente qu’une fraction de ce que reçoit le modèle. L’historique de conversation, les résultats d’outils, les données récupérées en temps réel, les exemples sélectionnés dynamiquement — tout cela forme un contexte dont la construction est un travail d’ingénierie à part entière.

Ce que le context engineering recouvre

Plusieurs taxonomies circulent. Celle d’Anthropic (septembre 2025) distingue cinq composants du contexte d’un agent :

  1. System prompt — les instructions de base. Anthropic recommande un niveau d’abstraction “Goldilocks” : ni trop rigide pour bloquer l’adaptation, ni trop vague pour perdre le modèle.
  2. Tools — les définitions d’outils doivent retourner des informations token-efficaces. Un retour verbeux pollue la fenêtre.
  3. Examples — des exemples bien choisis valent mieux qu’une longue instruction explicative.
  4. Message history — l’historique s’accumule. Purger et synthétiser régulièrement est une décision d’ingénierie, pas un détail.
  5. External data — récupération “just-in-time” plutôt que tout charger en amont.

LangChain propose quatre stratégies complémentaires : Write (sauvegarder hors fenêtre, mémoire persistante), Select (récupérer les bonnes informations au bon moment via RAG), Compress (résumer ou tronquer ce qui peut l’être), Isolate (multi-agents avec contextes séparés pour éviter la contamination).

Phil Schmid (HuggingFace, 30 juin 2025) formule la définition la plus opérationnelle : “la discipline de concevoir et construire des systèmes dynamiques qui fournissent la bonne information, aux bons outils, dans le bon format, au bon moment.”

Context rot : les preuves empiriques

Le terme “context rot” désigne la dégradation des performances d’un modèle à mesure que le contexte s’allonge. Ce n’est pas une intuition — c’est documenté par plusieurs études indépendantes.

Lost in the Middle (Liu et al., Stanford/UC Berkeley/Samaya AI, TACL 2024) : les modèles performent mieux quand l’information utile est placée en début ou en fin de contexte. La performance suit une courbe en U — un biais de primauté et un biais de récence combinés. Quand l’information passe du début ou de la fin vers le milieu, la dégradation dépasse 30 %. Sur GPT-3.5-Turbo en question-réponse multi-documents, la chute dépasse 20 %.

RULER (NVIDIA, COLM 2024) : 17 modèles évalués de 4K à 128K tokens sur 13 tâches représentatives. Résultat : seule la moitié des modèles déclarant gérer 32K tokens ou plus atteignent le seuil de qualité à cette longueur. Presque tous les modèles voient leurs performances chuter significativement avec la longueur, même ceux qui affichent des scores quasi-parfaits sur des tâches de type “aiguille dans une botte de foin” (NIAH).

Chroma Research (juillet 2025) : 18 modèles testés, dégradation consistante avec la longueur d’entrée sur tous les modèles. Un résultat contre-intuitif : les contextes désordonnés améliorent la performance par rapport aux contextes cohérents — peut-être parce que la structure implicite oriente le modèle vers certaines parties plutôt que d’autres.

LongCodeBench (Rando et al., 2025) : sur des tâches de code, Claude 3.5 Sonnet passe de 29 % à 3 % de précision quand le contexte passe de 32K à 256K tokens.

Ces données invalident l’hypothèse selon laquelle des fenêtres plus grandes résoudraient le problème. Gemini 1.5 Pro, GPT-4.1, Llama 4 annoncent des fenêtres d’un million de tokens ou plus. Mais la performance effective diverge de la fenêtre déclarée : la taille nominale ne garantit pas la capacité réelle à exploiter l’ensemble de cette fenêtre.

Vers une gestion automatisée du contexte

Le framework ACE (Agentic Context Engineering, Zhang et al., arXiv 2510.04618, octobre 2025) propose de traiter le contexte comme un “playbook évolutif” qui se met à jour en fonction des retours de performance. Sans supervision étiquetée, avec un petit modèle open-source, ACE gagne +10,6 % sur des benchmarks d’agents et +8,6 % sur des tâches financières.

Le framework 12-Factor Agents (humanlayer, GitHub), inspiré des 12-Factor Apps de Heroku, pose un principe proche : “Own your context window” — gérer explicitement quelles données sont incluses, comment elles sont résumées. Les agents sont conçus comme des “stateless reducers” : chaque opération est indépendante et reproductible.

Limites documentées : Anthropic (septembre 2025) note qu’une compaction trop agressive entraîne la perte d’un contexte subtil dont l’importance n’apparaît qu’ultérieurement. Le tradeoff compression/rétention n’est pas résolu algorithmiquement à ce jour.

Discipline émergente ou rebranding ?

La critique existe. Plusieurs développeurs expérimentés notent que l’importance du contexte était déjà connue avant que le terme circule. Un argument plus radical (Serge Liatko, LAWXER) : prompt engineering et context engineering sont tous deux déjà dépassés — le vrai travail est l’architecture de workflows automatisés où chaque élément de contexte est généré, géré et livré par du code.

La position contraire est défendue par LangChain et Anthropic : le prompt engineering optimise une instruction isolée ; le context engineering est une discipline système qui gère l’état informationnel complet à l’inférence. Phil Schmid formule : les défaillances d’agents sont des “context failures”, pas des “model failures”.

La tension est réelle. LangChain reconnaît lui-même que “même avec tout le contexte, la façon de l’assembler dans le prompt continue d’avoir de l’importance”. Le context engineering ne remplace pas le soin apporté à la rédaction des instructions — il l’englobe dans un périmètre plus large.

Ce qui manque actuellement : aucun framework de mesure standardisé de la “qualité du contexte” n’existe. Les benchmarks disponibles (RULER, NIAH, LoCoBench) sont task-specific et ne se transfèrent pas facilement à la pratique générale.

Ce qu’il faut retenir

  • Le context engineering désigne la gestion de l’ensemble de ce que reçoit le modèle à l’inférence — pas seulement le prompt, mais l’historique, les données récupérées, les retours d’outils, les exemples.
  • Des études peer-reviewed (Lost in the Middle, RULER) documentent des dégradations de performance de 20 à 30 % selon la position de l’information dans le contexte, et des chutes plus sévères avec l’allongement de la fenêtre.
  • Des fenêtres de contexte plus grandes ne résolvent pas le problème : la performance effective diverge systématiquement de la fenêtre déclarée.
  • L’automatisation de la gestion du contexte (ACE) montre des gains mesurés sur benchmarks, mais le tradeoff entre compaction et rétention du contexte critique reste ouvert.
  • La question “nouvelle discipline ou rebranding ?” n’est pas tranchée dans la littérature — l’absence de métriques standardisées de qualité du contexte laisse le débat empiriquement irresolu.

Sources