Context engineering : définition et 4 échecs

Ce qu'est le context engineering

Le context engineering est la pratique qui consiste à décider, assembler et livrer tout ce dont un modèle d'IA a besoin pour bien accomplir une tâche, avant qu'il ne s'exécute. Cela couvre le system prompt, les documents que vous joignez, ce que le modèle retient de vous, les outils qu'il peut appeler et ce qui figure déjà dans la conversation. Le prompt engineering règle une phrase. Le context engineering règle toute la pile d'entrée.

La définition d'Anthropic est la plus resserrée en circulation : "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference", soit l'ensemble des stratégies permettant de sélectionner et d'entretenir le jeu de tokens optimal pendant l'inférence d'un LLM. Le principe directeur qu'ils énoncent mérite d'être mémorisé, car il sert aussi de test pour savoir si vous vous y prenez bien : trouver "the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome", le plus petit ensemble possible de tokens à fort signal qui maximise les chances d'obtenir le résultat voulu. (Anthropic, 2025)

Voyez cela comme le briefing d'un nouveau consultant. Un mauvais brief tient en un e-mail d'une ligne. Un bon brief comprend le contexte de l'entreprise, l'historique pertinent, les fichiers dont le consultant aura besoin, l'identité des parties prenantes, ce à quoi ressemble la réussite et ce qui sort du périmètre. Si vous recrutez un consultant brillant et que vous lui donnez un mauvais brief, vous obtenez un livrable médiocre. C'est exactement pareil avec l'IA.

Remarquez ce qui ne figure pas dans la définition : l'astuce. Il n'y a pas de formulation magique, pas de mot secret qui vous donnerait un meilleur modèle. Le travail tient davantage de l'édition que de l'incantation. Vous décidez de ce qui a le droit d'être dans la pièce avant que la conversation ne commence et, tout aussi important, de ce qui n'y entre pas.

---

Le tweet qui lui a donné son nom

Le 19 juin 2025, Tobi Lütke, le PDG de Shopify, a publié sur X qu'il préférait le terme « context engineering » à « prompt engineering ». Il l'a décrit comme "the art of providing all the context for the task to be plausibly solvable by the LLM", l'art de fournir tout le contexte nécessaire pour que la tâche soit plausiblement résoluble par le LLM. Six jours plus tard, Andrej Karpathy, l'une des voix les plus respectées du domaine, a amplifié le terme. Sa définition était plus tranchante : "context engineering is the delicate art and science of filling the context window with just the right information for the next step", soit l'art et la science délicats de remplir la fenêtre de contexte avec exactement la bonne information pour l'étape suivante. (Karpathy, 2025)

L'expression elle-même n'était pas nouvelle. Walden Yan, chez Cognition, l'équipe derrière l'agent de codage autonome Devin, avait publié « Don't Build Multi-Agents » une semaine plus tôt, le 12 juin, en qualifiant le context engineering de "effectively the #1 job of engineers building AI agents", autrement dit la mission numéro un des ingénieurs qui construisent des agents IA. Mais ce sont les publications de Lütke et de Karpathy qui ont fait passer le label dans le grand public. Le mois suivant, Gartner publiait un rapport intitulé « Lead the Shift to Context Engineering as Prompt Engineering Fades », assorti de ce résumé sans détour : « Context engineering is in, and prompt engineering is out », le context engineering entre et le prompt engineering sort. La prévision qui l'accompagnait : d'ici 2028, des fonctionnalités de context engineering seront intégrées à 80 % des outils logiciels servant à construire des applications d'IA, ce qui améliorera la précision de l'IA agentique d'au moins 30 %. (Gartner, 2025)

Ce qui s'est produit n'était pas un changement de marque. C'était une correction. La communauté de l'IA a discrètement admis que la compétence appelée « prompt engineering » avait toujours été un sous-ensemble de quelque chose de plus vaste, et que ce sous-ensemble n'était plus la partie intéressante. Un prompt est un composant. Le contexte, c'est toute la pièce.

Cela compte, parce que les travailleurs du savoir ont passé deux ans à apprendre la mauvaise chose. Ils ont mémorisé des modèles de prompts. Ils ont collectionné les fils Twitter du « prompt ultime ». Ils ont traité le prompt comme une formule magique. Cet effort n'est pas inutile, mais il ne suffit plus. La question n'est pas de savoir comment vous formulez votre demande. La question est de savoir ce que vous placez à côté d'elle.

---

Le prompt engineering est-il vraiment mort ?

Réponse courte : l'intitulé de poste est mort, les techniques ne le sont pas.

Il est tentant de voir là un basculement générationnel où tout ce qui est ancien serait faux. C'est un cadrage paresseux. La chaîne de pensée, les exemples few-shot, l'attribution d'un rôle et les formats de sortie explicites font tous encore une vraie différence, et on les retrouve à l'intérieur des contextes bien construits.

Ce qui a changé, c'est le plafond. En 2023, un prompt bien tourné pouvait doubler la qualité d'une réponse, parce que les modèles sous-jacents se laissaient facilement dérouter par l'ambiguïté. Avec la bonne structure de phrase, vous pouviez transformer GPT-3.5 d'un stagiaire maladroit en analyste cohérent. Cet écart était réel, et le prompt engineering l'exploitait.

Les modèles de pointe de 2026 n'ont plus besoin qu'on leur tienne la main. Claude Opus 5, GPT-5.6 et Gemini 3.1 Pro traitent raisonnablement bien les demandes ambiguës. Le rendement marginal de la formulation a chuté. En revanche, celui d'un matériel source pertinent, d'une mémoire bien cadrée et d'exemples choisis a fortement augmenté. Le levier a changé de place.

Voici la comparaison, posée noir sur blanc.

Regardez la dernière ligne. Le prompt engineering n'est pas mort parce qu'il avait tort. Il est mort parce que le goulet d'étranglement s'est déplacé ailleurs.

---

Le context engineering est-il mort lui aussi ?

Réponse courte : le label s'efface, la pratique non.

Le contrecoup est assez réel pour avoir son propre genre littéraire. Joe Reis a publié « Gartner Declares 2026 The Year of Context™ » en mars 2026, où il moque le Context Engineer, mélange de "data engineer, ontologist, librarian, corporate anthropologist, and therapist" (ingénieur data, ontologue, bibliothécaire, anthropologue d'entreprise et thérapeute) dont le vrai métier consiste à "updating a YAML file", mettre à jour un fichier YAML. Une fois les blagues mises de côté, trois objections tiennent debout, et deux d'entre elles contiennent une part de vérité.

« Les modèles vont l'absorber. » L'argument est que les harnais d'agents gèrent désormais automatiquement la compaction, la récupération et la mémoire, si bien que l'humain n'aurait plus à penser au contexte. Il y a là du fond. La compaction automatique et la récupération juste-à-temps ont réellement supprimé une catégorie de travail manuel. Mais l'automatisation a déplacé le travail, elle ne l'a pas effacé. Quelqu'un décide toujours ce qui entre dans le fichier de mémoire, quelles sources le moteur de récupération a le droit de toucher, et ce que l'agent doit ignorer. La plomberie a été automatisée. Le jugement, non.

« Ça n'a jamais été qu'un mot à la mode pour dire des entrées de qualité. » En partie juste. Sélectionner ses entrées n'est pas une idée neuve, et le terme a bel et bien été étiré jusqu'à recouvrir à peu près n'importe quoi par les vendeurs de produits « contexte ». Mais nommer une chose change le sérieux avec lequel on la traite. Personne n'auditait systématiquement ses entrées d'IA en 2023. Beaucoup d'équipes le font aujourd'hui, et elles le font parce que le nom a donné une forme à la pratique.

« Le context rot prouve qu'on ne peut pas s'en sortir par l'ingénierie. » Celle-là est à l'envers. Le fait que les modèles se dégradent à mesure que l'entrée grossit est l'argument en faveur d'un travail délibéré sur le contexte, pas contre lui. Si davantage de contexte valait toujours mieux, la curation n'aurait aucun intérêt et vous pourriez tout déverser d'un coup.

La lecture honnête, à la mi-2026 : l'expression a passé son pic de hype, et l'intitulé autonome de « context engineer » relève de l'émergent plutôt que du standard. Adobe publie des offres portant exactement ce nom, mais dans la plupart des entreprises le travail est logé à l'intérieur des postes existants d'ingénierie IA, data ou plateforme. La pratique sous-jacente, elle, est plus installée que jamais. Attendez-vous à ce que le label s'efface à l'arrière-plan comme l'a fait le « responsive design », absorbé dans la définition par défaut du travail bien fait.

---

Les six couches du contexte

Pour faire du context engineering délibérément, il faut savoir ce que l'on construit. Toute interaction moderne avec une IA puise dans six couches, que vous y pensiez ou non. La compétence consiste à savoir lesquelles ajuster.

Un contexte bien construit utilise les six délibérément. Un contexte mal construit déverse tout dans une seule couche (généralement les pièces jointes, souvent l'historique de conversation) et espère que le modèle fera le tri.

L'erreur que commettent la plupart des travailleurs du savoir est de traiter l'IA comme une interface de chat alors qu'elle est en réalité un assembleur de contexte. Presque tout ce qui détermine la réponse s'est déjà joué au moment où vous commencez à taper.

Pour un angle voisin sur la façon dont l'architecture de votre information personnelle conditionne l'utilité de l'IA, voir la gestion du contexte personnel.

---

Pourquoi les fenêtres de contexte plus grandes ont empiré les choses

En 2023, une fenêtre de contexte de 100 000 tokens relevait de l'exotisme. En 2026, le million de tokens est la référence ordinaire : environ 1 050 000 pour GPT-5.6, 1 048 576 pour Gemini 3.6 Flash et 1 000 000 pour Claude Opus 5. Llama 4 Scout en annonce 10 millions. Vous pouvez glisser le texte intégral de Guerre et Paix dans un seul prompt, et même plusieurs fois. L'hypothèse naturelle est donc que le context engineering devient plus facile. Plus de place, moins de tri, non ?

Faux. C'est devenu plus difficile.

L'article fondateur ici est Liu et al. (2024), « Lost in the Middle: How Language Models Use Long Contexts », publié dans TACL. Les chercheurs ont testé la capacité des modèles à trouver et à utiliser une information précise selon l'endroit où elle était placée dans un long contexte. La conclusion est inconfortable : la performance dessine un U. Les modèles accordent le plus d'attention à l'information située tout au début et tout à la fin du contexte. Celle du milieu est systématiquement sous-pondérée, parfois purement et simplement ignorée. (Liu et al., 2024)

Placez une instruction critique au milieu d'un document de 50 pages, et le modèle pourra se comporter comme s'il ne l'avait jamais vue. Ce n'est pas un bug dont vous vous sortirez par le prompt.

Puis, en juillet 2025, Chroma a publié « Context Rot: How Increasing Input Tokens Impacts LLM Performance », signé Kelly Hong, Anton Troynikov et Jeff Huber. Ils ont testé 18 modèles de pointe, dont GPT-4.1, Claude 4, Gemini 2.5 et Qwen3. Le résultat est le même pour tous : la performance se dégrade à mesure que l'entrée grossit, bien avant que la fenêtre de contexte ne soit près d'être pleine. Les modèles n'utilisent pas leur contexte de façon uniforme. La justesse perd plusieurs dizaines de points de pourcentage entre environ 10 000 et 100 000 tokens, ce qui, sur un modèle à un million de tokens, correspond au premier dixième de la fenêtre.

Le détail décisif est que le seuil suit un nombre absolu de tokens, pas une proportion de la fenêtre. Databricks a mesuré une justesse qui décroche autour de 32 000 tokens pour Llama 3.1 405B, et plus tôt encore sur des modèles plus petits. Acheter une fenêtre plus grande ne déplace pas ce nombre. Une fenêtre d'un million de tokens ne vous achète pas un million de tokens utilisables, elle vous achète seulement plus de place pour aggraver le problème. Meta publie des résultats de récupération quasi parfaits au test de l'aiguille dans une botte de foin, sur l'intégralité des 10 millions de tokens de Llama 4 Scout, mais retrouver un fait planté n'a rien à voir avec raisonner sur un corpus, et aucun benchmark publié ne montre que la qualité du raisonnement tient à cette longueur.

Anthropic formule la cause profonde d'une manière qui rend le remède évident. Le contexte est "a finite resource with diminishing marginal returns", une ressource finie à rendements marginaux décroissants, et les modèles fonctionnent avec un "attention budget", un budget d'attention, où "every new token introduced depletes this budget by some amount", chaque nouveau token entamant un peu ce budget. L'architecture explique pourquoi : un transformeur doit calculer n² relations deux à deux pour n tokens, si bien que l'attention s'amincit à mesure que l'entrée grossit. (Anthropic, 2025)

Voilà le coût caché de l'ère du million de tokens. La fenêtre a grandi plus vite que la capacité des modèles à s'en servir, et elle a fait de « qu'est-ce que je dois laisser de côté ? » la question la plus précieuse de toute la pile. Pour la version architecturale du problème, et notamment pour savoir quand recourir plutôt à la récupération, voir Context Rot, RAG et long contexte.

---

Les quatre façons dont le contexte échoue

La pollution du contexte est le terme générique qui désigne un contexte dégradé par du matériel qui n'aurait pas dû s'y trouver. C'est une expression utile et un diagnostic inutile, car savoir que votre contexte est pollué ne vous dit pas ce qu'il faut en retirer. La décomposition la plus utile vient de Drew Breunig, qui a publié « How Long Contexts Fail » le 22 juin 2025. Il a scindé la pollution du contexte en quatre modes de défaillance distincts, et si la taxonomie s'est imposée, c'est parce que chacun appelle un correctif différent.

Les exemples derrière tout cela sont concrets. Pour l'empoisonnement, Breunig cite un agent Gemini 2.5 jouant à Pokémon qui hallucinait des états de jeu, les inscrivait dans sa section d'objectifs, puis passait de longues périodes à poursuivre des buts impossibles. Pour la distraction, il s'appuie sur le résultat de Databricks déjà évoqué plus haut : la justesse commence à glisser autour de 32 000 tokens sur un modèle dont la fenêtre est plusieurs fois plus grande.

C'est la confusion qui dispose des preuves les plus actionnables. Sur le Berkeley Function-Calling Leaderboard, résume Breunig, "every model performs worse when provided with more than one tool", tous les modèles font moins bien dès qu'on leur donne plus d'un outil, et il arrive que certains appellent des outils sans aucun rapport avec la demande. Lors d'un test du benchmark GeoEngine, un Llama 3.1 8B quantifié échouait à la tâche avec 46 outils à disposition et réussissait avec 19. Même modèle, même tâche, moins d'options.

Pour le conflit, Breunig cite des travaux de Microsoft et de Salesforce sur les prompts « fragmentés », où la même information est étalée sur plusieurs messages au lieu d'être livrée d'un coup. La performance a chuté de 39 % en moyenne, et o3 est passé de 98,1 à 64,1 sur les tâches concernées.

Voici le schéma à intérioriser : trois de ces quatre modes empirent quand vous ajoutez du contexte. Un seul, celui du fait réellement manquant, s'améliore. Cette asymétrie est à elle seule tout l'argument en faveur de la curation.

---

Ce que dit la recherche : les travaux qui comptent

Quatre documents portent ici l'essentiel du poids, et si vous ne lisez que ceux-là, vous aurez une longueur d'avance sur presque tous ceux qui en débattent en ligne. Le point d'ancrage est « A Survey of Context Engineering for Large Language Models » (arXiv:2507.13334), soumis le 17 juillet 2025. Il fait 166 pages et passe en revue 1 411 articles cités, ce qui en fait ce que le domaine possède de plus proche d'une carte.

Le cadrage de cette revue est que le context engineering "transcends simple prompt design to encompass the systematic optimization of information payloads for LLMs", qu'il dépasse la simple conception de prompts pour englober l'optimisation systématique des charges d'information fournies aux LLM. Elle découpe le champ en composants fondamentaux (récupération et génération du contexte, traitement du contexte, gestion du contexte), puis en implémentations système bâties par-dessus : RAG, systèmes de mémoire, raisonnement outillé et architectures multi-agents. Si vous vous êtes déjà demandé où se situe le RAG par rapport au context engineering, la voici, la réponse : la récupération est une machine parmi d'autres à l'intérieur d'une discipline plus vaste.

Le résultat le plus intéressant est un manque que les auteurs signalent comme "a defining priority for future research", une priorité structurante pour la recherche à venir. Les modèles dotés d'un bon context engineering "demonstrate remarkable proficiency in understanding complex contexts", ils font preuve d'une remarquable aisance à comprendre des contextes complexes, mais ils "exhibit pronounced limitations in generating equally sophisticated, long-form outputs", ils butent nettement dès qu'il s'agit de produire des textes longs d'une sophistication équivalente. En clair : nous sommes devenus bien meilleurs à nourrir les modèles qu'à en faire ressortir un travail long et de qualité. Quiconque a vu une IA produire un résumé brillant puis un brouillon médiocre de 3 000 mots l'a éprouvé personnellement.

L'autre document à lire en entier est « Effective context engineering for AI agents » d'Anthropic, publié le 29 septembre 2025. C'est lui qui a donné aux praticiens le vocabulaire de travail que la plupart des outils reprennent aujourd'hui :

• Récupération juste-à-temps : gardez dans le contexte des identifiants légers (chemins de fichiers, requêtes, liens) et chargez les données réelles au moment de l'exécution, plutôt que de tout précharger.
• Compaction : quand une conversation approche de la limite de la fenêtre, résumez-la et réinitialisez une nouvelle fenêtre. Anthropic note que toute la difficulté tient à la sélection, puisqu'une "overly aggressive compaction", une compaction trop agressive, fait perdre des éléments subtils dont l'importance n'apparaît que plus tard.
• Prise de notes structurée : faites écrire à l'agent des notes dans une mémoire persistante, hors de la fenêtre de contexte, puis faites-les lui relire au besoin.
• Architectures de sous-agents : confiez des tâches ciblées à des agents spécialisés dotés de fenêtres de contexte propres, et laissez un agent principal en synthétiser les résultats.

Ces quatre techniques ont été conçues pour des agents autonomes. Toutes les quatre ont un équivalent manuel qu'une personne peut exécuter dans une fenêtre de chat, ce qui fait l'objet des deux sections suivantes. Pour voir comment ces idées se traduisent dans l'outillage d'agents au quotidien, voir Skills, sous-agents et hooks.

---

La compétence que personne n'a nommée : la curation

Si le context rot est le problème, la curation est la solution. Et il se trouve que la curation est une compétence que la plupart des travailleurs du savoir pratiquent déjà, sans lui donner ce nom.

Chaque fois que vous surlignez un passage dans un article, vous faites de la curation. Vous dites : ceci compte. Le reste est du décor. Quand vous annotez un PDF, mettez un article en favori ou sauvegardez une citation, vous faites la même chose. Vous construisez un filtre signal sur bruit au-dessus d'un monde saturé de texte.

Le problème, jusqu'à récemment, c'est que cette curation restait prisonnière. Vos surlignages vivaient dans une application. Vos notes Kindle dans une autre. Vos recherches web dans l'historique de votre navigateur. Au moment de briefer une IA, vous ne pouviez rien en tirer efficacement vers la fenêtre de contexte. Vous finissiez par tout relire ou, pire, par coller des sources brutes en espérant que ça passe.

Le context engineering, en tant que discipline, a un trou béant exactement à cet endroit. Les entreprises l'ont comblé en bâtissant des bases de connaissances internes et des pipelines RAG. Mais les travailleurs du savoir isolés n'ont pas d'équipe d'ingénierie. Ils ont le même problème (trop de matériel source, pas assez de signal) et aucune de ces infrastructures.

C'est pourquoi les outils de lecture qui capturent durablement les surlignages sont devenus, discrètement, une infrastructure d'IA. Le surligneur web de Glasp existe précisément pour cela : il transforme votre lecture en contexte structuré et récupérable. Quand vous surlignez un paragraphe dans un billet de blog, ce surlignage devient un morceau de contexte que vous pourrez confier plus tard à n'importe quelle IA, filtré par sujet, par source ou par date.

Le même principe vaut pour la lecture au long cours. Vos surlignages Kindle sont sans doute le signal de meilleure qualité que vous ayez jamais produit sur ce qui compte pour vous. Vous avez prêté attention assez longtemps pour les surligner. C'est un filtre coûteux, et il est gaspillé si les surlignages restent enfermés dans un système clos.

---

Le context engineering pour les individus (pas seulement les ingénieurs)

La plupart des textes sur le context engineering visent les développeurs. Il y est question de construire des systèmes d'IA en production : comment façonner un system prompt pour un agent de codage, comment découper des documents pour la récupération, comment brancher les appels d'outils. C'est utile si vous livrez du logiciel. Ça l'est moins si vous êtes consultant, chercheur, rédacteur, analyste ou étudiant et que vous cherchez simplement de meilleures sorties d'IA.

Mais la même discipline s'applique. Vous l'exécutez simplement à la main.

Vous concevez des system prompts, de façon informelle. Chaque GPT personnalisé, chaque projet Claude, chaque fichier d'instructions de type claude.md que vous mettez en place est un system prompt. Quand vous écrivez « tu es mon assistant de recherche, je travaille sur la politique des énergies renouvelables, privilégie les synthèses sceptiques », vous faites de la conception de system prompt. Faites-le délibérément.

Vous gérez la mémoire. La mémoire de ChatGPT et les projets de Claude vous permettent tous deux d'épingler des faits qui persistent d'une conversation à l'autre. La plupart des gens soit ignorent cette possibilité (et perdent toute continuité), soit y déversent tout (et fabriquent du bruit). Le bon geste est de traiter la mémoire comme un CV : uniquement ce que vous voulez que le modèle utilise à chaque fois.

Vous faites de la récupération, manuellement. Coller le bon article dans un chat, c'est du RAG à la main. La question est de savoir d'où sort « le bon article ». S'il sort d'un défilement frénétique dans l'historique de votre navigateur, vous n'avez pas de système de récupération. S'il sort d'une bibliothèque de passages que vous aviez déjà signalés comme intéressants, vous en avez un.

Vous chargez les pièces jointes intentionnellement. La tentation est de téléverser le livre entier. Le meilleur geste est de téléverser les 40 pages que vous avez réellement surlignées. Vous contournez le context rot en faisant le filtrage en amont.

Restent les quatre techniques d'agents tirées du manuel d'Anthropic, dont chacune possède une version manuelle :

C'est la compaction qui manque le plus souvent à l'appel. Les longs fils se dégradent avec le temps parce que les vieux messages dominent le contexte sans rien apporter, et c'est exactement le mode « distraction » du tableau précédent. Ouvrir un nouveau fil pour une nouvelle sous-tâche, avec un brief propre, vaut généralement mieux que de prolonger le méga-fil.

Rien de tout cela n'exige de compétences en ingénierie. Cela exige la compétence que les bons chercheurs et les bons journalistes possèdent déjà : savoir quoi inclure, quoi couper, et où aller chercher quoi.

---

Vos surlignages sont votre contexte compétitif

Voici la partie sous-estimée.

La plupart des gens traitent leurs notes et leurs surlignages comme des aides-mémoire. Des choses sur lesquelles revenir un jour. Ce cadrage avait du sens en 2010, quand y revenir était le seul moyen de s'en servir. Il est périmé en 2026.

Vos surlignages sont désormais un flux que l'on peut remettre à une IA. Chaque passage que vous avez signalé, chaque citation que vous avez sauvegardée, chaque annotation que vous avez portée est un morceau de contexte. Et parce que vous l'avez produit en prêtant attention, son signal est plus élevé que celui de n'importe quel texte ramassé au hasard sur le web.

Pensez à ce que cela implique sur le plan concurrentiel. Deux travailleurs du savoir utilisent le même modèle d'IA. L'un a trois ans de lecture et de surlignage structurés derrière lui. L'autre a trois ans d'onglets de navigateur qu'il n'a jamais rouverts. Quand ils posent la même question à l'IA, le premier peut lui fournir son propre corpus organisé. Le second reste coincé avec les données d'entraînement génériques du modèle et ce qu'il parvient à recoller de mémoire. L'écart n'est pas un écart de prompt. C'est un écart de contexte.

C'est pourquoi Glasp a fait évoluer son positionnement. La promesse initiale était celle d'un surligneur web social : surligner, voir ce que d'autres ont surligné, se construire une identité de lecteur. Tout cela reste vrai. Mais la valeur profonde, aujourd'hui, c'est que chaque surlignage est un token de contexte en attente d'usage. Votre historique de lecture s'accumule, paragraphe après paragraphe, en un corpus RAG personnel.

Quand vous associez cela au chat IA de Glasp, le flux de travail se rapproche de ce que les ingénieurs bâtissent pour leur entreprise. Vous surlignez au fil de votre lecture. Plus tard, vous posez des questions et l'IA puise dans ce qui vous a réellement intéressé, pas dans un index web générique. C'est du context engineering, sauf que le contexte est votre propre bibliothèque.

Pour aller plus loin sur la façon dont cela inverse la relation entre lecture et IA, voir les assistants de lecture IA.

---

Un cadre simple pour construire le contexte de n'importe quelle tâche IA

Assez de théorie. Voici un déroulé concret à appliquer la prochaine fois que vous ouvrez un chat.

Étape 1 : définissez le travail avant de taper. Une phrase. À quoi ressemble « terminé » ? « Rédige une note de 500 mots résumant les trois principaux arguments contre la semaine de quatre jours, à destination d'un directeur des opérations sceptique. » Ça, c'est un travail. « Aide-moi avec cet article », non.

Étape 2 : rassemblez vos sources, puis coupez. Réunissez le matériel qui porte réellement sur la tâche. Si vous avez des surlignages sur le sujet, commencez par là, pas par les articles complets. Si vous avez configuré une mémoire, vérifiez si elle contient déjà des éléments utiles. Laissez de côté tout ce qui n'est que tangentiellement lié. Le context rot est bien réel.

Étape 3 : posez le rôle et les règles. Avant la tâche, dites au modèle qui il est et quelles règles s'appliquent. « Tu relis pour un directeur des opérations sceptique. Pas de jargon. Pas de circonvolutions. Les chiffres avant les adjectifs. » C'est la couche system prompt. Cela prend dix secondes et change le ton de tout ce qui suit.

Étape 4 : fournissez la tâche et l'ensemble du matériel, dans l'ordre. Placez le contexte le plus important en premier et la tâche en dernier. À cause de l'effet Lost in the Middle, vous voulez l'instruction et le matériel le plus tranchant au début et à la fin. Le milieu est un marécage.

Étape 5 : diagnostiquez avant d'itérer. Si la sortie est mauvaise, résistez à l'envie de réécrire votre prompt de douze façons. Passez plutôt les quatre modes de défaillance en revue, comme une checklist. Y a-t-il un fait erroné qui revient sans cesse (empoisonnement) ? Le fil est-il long et répétitif (distraction) ? Avez-vous joint trois sources quand une seule était pertinente (confusion) ? Avez-vous donné deux instructions qui se contredisent (conflit) ? Chacun appelle un correctif différent, et aucun ne consiste à reformuler.

Faites cela quelques dizaines de fois et le geste devient réflexe. Vous cesserez de vous demander « comment je formule ça ? » pour vous demander « que doit voir le modèle avant de répondre ? ». Ce basculement, c'est toute la discipline.

---

Questions fréquentes

Qu'est-ce que le context engineering, en termes simples ?

C'est décider ce qu'un modèle d'IA voit avant de répondre. Cela comprend les instructions que vous lui donnez, les documents que vous joignez, ce qu'il retient de vous, les outils qu'il peut utiliser et la conversation jusqu'ici. Le prompt engineering ne couvre que la formulation de votre demande, qui n'est qu'une entrée parmi beaucoup d'autres.

Le prompt engineering est-il vraiment mort ?

L'expression prend sa retraite. Les techniques qu'elle recouvre fonctionnent toujours. La chaîne de pensée, les exemples few-shot et des formats de sortie clairs restent utiles. Ce qui est mort, c'est l'idée qu'une bonne formulation suffit à obtenir une excellente sortie. En 2026, la formulation est un levier mineur. L'assemblage du contexte est le levier majeur. Quand les gens disent « le prompt engineering est mort », c'est ce qu'ils veulent dire.

Le context engineering est-il mort, ou juste un mot à la mode ?

Le terme a passé son pic de hype, et l'intitulé autonome de « context engineer » relève de l'émergent plutôt que du standard : Adobe publie des offres portant exactement ce nom, mais dans la plupart des entreprises le travail est logé à l'intérieur des postes existants d'ingénierie IA, data ou plateforme. La pratique, elle, est plus installée que jamais, et elle se fond dans le travail normal sur l'IA au lieu de disparaître. La compaction et la récupération automatiques des outils d'agents modernes ont supprimé quelques étapes manuelles, mais quelqu'un décide toujours ce qui entre en mémoire et quelles sources le modèle a le droit de voir. Cette décision, c'est le métier.

Qu'est-ce que la pollution du contexte ?

C'est le terme général désignant un contexte dégradé par du matériel qui n'aurait pas dû s'y trouver. La taxonomie de Drew Breunig la découpe en quatre modes : l'empoisonnement (une erreur entre et se répète), la distraction (le contexte devient si long que le modèle s'y appuie à l'excès), la confusion (du contenu hors sujet tire la réponse vers le bas) et le conflit (deux éléments de contexte se contredisent). Savoir lequel vous frappe compte, car les correctifs diffèrent.

Quels sont les meilleurs travaux à lire sur le context engineering ?

Commencez par « A Survey of Context Engineering for Large Language Models » (arXiv:2507.13334), une revue de 166 pages portant sur 1 411 articles. Pour les preuves de défaillance en long contexte, lisez Liu et al. (2024), « Lost in the Middle », dans TACL, ainsi que le rapport technique « Context Rot » de Chroma (2025). Côté pratique appliquée, « Effective context engineering for AI agents » d'Anthropic (septembre 2025) est le document non universitaire le plus utile.

Quelle est la différence entre context engineering et RAG ?

Le RAG (retrieval-augmented generation) est une couche du context engineering, précisément la couche de récupération. C'est la machinerie qui va chercher les fragments pertinents dans une base de connaissances quand il le faut. Le context engineering est la discipline plus large qui englobe le RAG, plus les system prompts, la mémoire, l'utilisation d'outils, les pièces jointes et l'historique de conversation.

Les fenêtres de contexte plus grandes ne finiront-elles pas par régler le problème ?

Elles ne l'ont pas fait jusqu'ici, et les données suggèrent qu'elles ne le feront pas. Liu et al. (2024) ont montré que les modèles ignorent le milieu des longs contextes. L'étude de Chroma (2025) a montré que les 18 modèles de pointe testés se dégradent bien avant que la fenêtre ne soit pleine. Les fenêtres annoncées à 10 millions de tokens affichent des résultats sur le test de l'aiguille dans une botte de foin, mais aucun benchmark publié ne montre que la qualité du raisonnement tient à cette longueur. Le goulet d'étranglement n'est pas la taille de la fenêtre. C'est l'allocation de l'attention à l'intérieur de la fenêtre.

Faut-il un profil technique pour faire du context engineering ?

Non. La métaphore de l'ingénierie en déroute certains, mais elle signifie seulement faire le travail délibérément plutôt que par accident. Un consultant qui prépare un brief, un journaliste qui documente un sujet, un étudiant qui organise ses sources pour une dissertation : c'est du context engineering déguisé. La compétence centrale, c'est la curation et le jugement.

Quel rapport avec les fonctionnalités de « mémoire » des IA ?

La mémoire (comme la mémoire persistante de ChatGPT ou les projets de Claude) est une couche du contexte. C'est ce que le modèle sait de vous d'une session à l'autre. Le context engineering inclut la mémoire, mais il est plus large. La mémoire est la couche toujours active. La récupération, les pièces jointes et les system prompts sont les couches propres à chaque tâche. Un bon context engineer les utilise toutes ensemble.

N'est-ce pas simplement de la prise de notes améliorée ?

En partie. La différence, c'est que la prise de notes traditionnelle est optimisée pour que vous relisiez vos notes. Le context engineering est optimisé pour qu'un modèle les consomme. Les exigences de format ne sont pas les mêmes (structure, atomicité et récupérabilité comptent davantage), mais la pratique sous-jacente, capturer ce qui mérite d'être retenu, est identique. Ceux qui prennent bien des notes partent ici avec une longueur d'avance.

---

Conclusion : la nouvelle littératie

Chaque ère de l'informatique a eu sa littératie, celle qui séparait les amateurs des utilisateurs sérieux. Dans les années 2000, c'était apprendre à bien chercher sur Google. Dans les années 2010, c'était apprendre à structurer l'information dans des outils comme Notion ou Airtable. En 2026, c'est apprendre à construire le contexte des IA.

Ceux qui l'auront compris prendront une large avance sur ceux qui ne l'auront pas compris. Non parce qu'ils accèdent à de meilleurs modèles (tout le monde a les mêmes), mais parce qu'ils arrivent à chaque tâche avec un meilleur matériel. Ils savent quoi fournir. Ils savent quoi laisser de côté. Ils savent où se trouve leur meilleure source sur un sujet, parce qu'ils ont pris la peine de la capturer des mois plus tôt.

C'est pour cela que la curation devient discrètement la méta-compétence la plus précieuse de l'ère de l'IA. Chaque surlignage que vous sauvegardez, chaque passage que vous annotez, chaque lecture que vous traitez vraiment est un dépôt sur votre moteur de contexte personnel. L'avenir de la productivité avec l'IA n'appartient pas aux gens qui détiennent des prompts secrets. Il appartient à ceux qui ont des bibliothèques réfléchies.

Vous faites déjà la lecture. Vous avez déjà des opinions sur ce qui compte. La seule question est de savoir si tout cela survivra assez longtemps pour être utile à celui ou celle que vous serez demain, et à l'IA qui travaille à vos côtés. Les outils existent. L'habitude, c'est la partie difficile.

Choisissez aujourd'hui quelque chose qui vaut la peine d'être lu. Surlignez les parties qui comptent. Voilà le context engineering. Tout le reste n'est que technique.