Context Engineering : pourquoi le prompt engineering est mort (et ce qui l'a remplacé pour les travailleurs du savoir)

Le tweet qui a tué le prompt engineering

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 « 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 en IA, a amplifié le terme. Sa définition était plus tranchante : « le context engineering est l'art et la science délicats de remplir la fenêtre de contexte avec juste 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, en parlait plus tôt dans l'année. Mais juin 2025 a été le moment où le label est devenu grand public. À la mi-2025, Gartner l'avait intégré dans ses briefings d'analystes avec une ligne simple : « le context engineering est in, le prompt engineering est out ». (Gartner, 2025)

Ce qui s'est passé n'était pas un rebranding. C'était une correction. La communauté IA a admis tranquillement que la compétence appelée « prompt engineering » avait toujours été un sous-ensemble de quelque chose de plus grand, 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 templates de prompts. Ils ont collecté des threads Twitter « prompt ultime ». Ils ont traité le prompt comme une formule magique. Cet effort n'est pas inutile, mais il n'est plus suffisant. La question n'est pas comment vous formulez votre demande. La question est ce que vous placez à côté de votre demande.

---

Ce que signifie réellement le context engineering

Voici la définition la plus claire : 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 faire une tâche, avant que le modèle ne tourne.

Pensez-y comme briefer un nouveau consultant. Un mauvais brief est un e-mail d'une ligne. Un bon brief inclut le contexte de l'entreprise, l'historique pertinent, les fichiers dont ils auront besoin, qui sont les parties prenantes, à quoi ressemble le succès et ce qui est hors périmètre. Si vous engagez un consultant brillant et lui donnez un mauvais brief, vous obtenez un livrable médiocre. Il en va de même pour l'IA.

L'analogie du consultant est d'Addy Osmani, tirée de son essai « Context Engineering: Bringing Engineering Discipline to Prompts », qui reste l'un des comptes rendus les plus nets sur le basculement. Son point est que le prompt engineering optimisait l'e-mail d'une ligne. Le context engineering optimise tout le paquet de briefing.

En pratique, cela couvre beaucoup de terrain. Cela inclut le system prompt (qui est le modèle), la couche de récupération (quels documents il peut voir), la mémoire persistante (ce qu'il retient de vous), l'utilisation d'outils (quelles actions il peut prendre), les pièces jointes (quels fichiers vous avez chargés pour cette session) et l'historique de conversation (ce qui a déjà été dit). Chacun de ces éléments est un levier. Chaque levier affecte la sortie.

La raison pour laquelle ce paquet a reçu un nouveau nom est que vous ne pouvez plus obtenir de grands résultats en n'optimisant qu'un seul levier. Vous devez penser à toute la pile.

---

Le prompt engineering n'était pas faux. Il était juste incomplet.

Il est tentant de traiter cela comme un basculement générationnel où tout ce qui est vieux est faux. C'est un cadrage paresseux. Les techniques de prompt engineering fonctionnent toujours. Chain-of-thought, exemples few-shot, attribution de rôle, formats de sortie explicites, tout cela fait encore bouger l'aiguille.

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

Les modèles de frontière en 2026 n'ont pas besoin qu'on leur tienne la main. Claude, GPT-5 et Gemini 2.5 comprennent raisonnablement bien les demandes ambiguës. Le rendement marginal de la formulation a chuté. Mais le rendement marginal de fournir du matériel source pertinent, de la mémoire cadrée et des exemples organisés a fortement augmenté. Le levier a bougé.

Voici la comparaison, posée.

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

---

Les 6 couches du contexte

Pour faire du context engineering délibérément, vous devez savoir ce que vous ingéniez. Chaque interaction IA moderne tire de six couches, que vous y pensiez ou non. La compétence est de savoir lesquelles ajuster.

Un contexte bien ingénié utilise les six délibérément. Un contexte mal ingénié balance tout dans une seule couche (habituellement les pièces jointes, souvent l'historique de conversation) et espère que le modèle s'en sortira.

L'erreur que font 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. Le chat est la pointe. L'iceberg est ce que vous fournissez avant de taper.

Pour un angle connexe sur la façon dont l'architecture d'information personnelle façonne l'utilité de l'IA, voir Personal Context Management: The Missing Layer Between You and AI.

---

Pourquoi les fenêtres de contexte plus grandes ont aggravé la chose, pas arrangé

En 2023, une fenêtre de contexte de 100K tokens était exotique. En 2026, les fenêtres de 1M de tokens sont courantes. Vous pouvez déposer le texte intégral de Guerre et Paix dans un seul prompt. L'hypothèse naturelle est donc que le context engineering devient plus facile. Plus de place, moins de triage, 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é si les modèles pouvaient trouver et utiliser une information spécifique selon l'endroit où elle était placée dans un long contexte. La conclusion était inconfortable : la performance est en U. Les modèles portent le plus d'attention à l'information au tout début et à la toute fin du contexte. L'information au milieu est systématiquement sous-pondérée, parfois complètement ignorée. (Liu et al., 2024)

Placez une instruction critique au milieu d'un document de 50 pages et le modèle peut agir comme s'il ne l'avait jamais vue. Ce n'est pas un bug que vous pouvez corriger par le prompting.

Puis, en 2025, Chroma a publié « Context Rot: How Increasing Input Tokens Impacts LLM Performance ». Ils ont testé 18 modèles de frontière, dont GPT-4.1, Claude Opus 4 et Gemini 2.5. Le résultat était cohérent sur tous les modèles : la performance se dégradait à mesure que l'entrée grandissait, bien avant que la fenêtre de contexte n'approche de son plein. Une fenêtre de 200K tokens pouvait présenter un sérieux rot dès 50K tokens. Le modèle « voyait » techniquement tout. Il agissait comme si ce n'était pas le cas.

C'est pourquoi plus de contexte n'est pas un meilleur contexte. C'est pourquoi balancer tout votre Google Drive dans un prompt ne marche pas, même quand la fenêtre le permet. La discipline d'ingénierie consiste à savoir ce qu'il faut exclure, pas seulement ce qu'il faut inclure.

C'est le coût caché de l'ère des 1M tokens. La fenêtre a grandi plus vite que la capacité des modèles à l'utiliser. Et elle a transformé « qu'est-ce que je dois laisser de côté ? » en la question la plus précieuse de la pile.

---

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 la curation se trouve être une compétence que la plupart des travailleurs du savoir pratiquent déjà, sans l'appeler ainsi.

Chaque fois que vous surlignez un passage dans un article, vous curatez. Vous dites : ceci compte. Le reste est toile de fond. Quand vous annotez un PDF, mettez en favori un article ou sauvegardez une citation, vous faites la même chose. Vous construisez un filtre signal-sur-bruit sur un monde plein de texte.

Le problème jusqu'à récemment était que cette curation était emprisonnée. Vos surlignages vivaient dans une app. Vos notes Kindle dans une autre. Vos recherches web dans votre historique de navigateur. Quand vous vous asseyiez pour briefer une IA, vous ne pouviez pas vraiment tirer tout cela efficacement dans la fenêtre de contexte. Vous finissiez par tout relire, ou pire, par coller des sources brutes en espérant le meilleur.

Le context engineering en tant que discipline a un immense écart exactement ici. Les entreprises l'ont résolu en construisant des bases de connaissances internes et des pipelines RAG. Mais les travailleurs du savoir individuels 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 infrastructure.

C'est pourquoi les outils de lecture qui capturent les surlignages de manière durable sont devenus discrètement une infrastructure IA. Le surligneur web de Glasp existe pour résoudre exactement cela : il transforme votre lecture en contexte structuré et récupérable. Quand vous surlignez un paragraphe dans un article de blog, ce surlignage devient un morceau de contexte que vous pouvez remettre à n'importe quelle IA plus tard, filtré par sujet, par source, par date.

Le même principe s'applique à la lecture en format long. Vos surlignages Kindle sont sans doute le signal de la plus haute qualité que vous ayez jamais généré 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 dans un système fermé.

Pour un traitement plus large de pourquoi la lecture organisée surpasse les documents balancés, voir The Hidden Cost of Information Overload: Why Your Brain Needs a Second Layer.

---

Context engineering pour les individus (pas seulement les ingénieurs)

La plupart des écrits sur le context engineering ciblent les développeurs. Il s'agit de construire des systèmes IA de production : comment façonner un system prompt pour un agent de codage, comment chunker des documents pour la récupération, comment câbler les appels d'outils. C'est utile si vous livrez des logiciels. C'est moins utile si vous êtes consultant, chercheur, rédacteur, analyste ou étudiant essayant d'obtenir une meilleure sortie IA.

Mais la même discipline s'applique. Vous la faites simplement à la main.

Vous concevez des system prompts, informellement. Chaque GPT personnalisé, chaque Claude Project, 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 d'énergie renouvelable, préfère les résumés sceptiques », vous faites de la conception de system prompt. Faites-le délibérément.

Vous gérez la mémoire. La fonctionnalité mémoire de ChatGPT et les projets de Claude vous permettent tous deux d'épingler des faits qui persistent entre conversations. La plupart des gens soit ignorent cela (et perdent la continuité), soit balancent tout dedans (et créent du bruit). Le bon mouvement est de curater la mémoire comme vous curateriez un CV : seulement les choses 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 est du RAG manuel. La question est d'où vient « le bon article ». S'il vient du défilement frénétique de votre historique de navigateur, vous n'avez pas de système de récupération. S'il vient d'une bibliothèque de passages que vous avez 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 tout le livre. 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.

Vous gérez l'historique de conversation. Les longs fils empirent avec le temps parce que les vieux messages dominent le contexte de manière peu utile. Démarrer un nouveau fil pour une nouvelle sous-tâche, avec un brief propre, surpasse souvent la continuation du méga-fil.

Rien de cela ne requiert de compétences en ingénierie. Cela requiert la même compétence que les bons chercheurs et les bons journalistes ont déjà : savoir quoi inclure, quoi couper et d'où tirer.

---

Vos surlignages sont votre contexte compétitif

Voici la partie sous-estimée.

La plupart des gens traitent leurs notes et surlignages comme des aides à la mémoire. Des choses à relire un jour. Ce cadrage avait du sens en 2010, quand y revenir était le seul moyen de les utiliser. Il est obsolète en 2026.

Vos surlignages sont désormais un flux qui peut être remis à l'IA. Chaque passage que vous avez signalé, chaque citation que vous avez sauvegardée, chaque annotation que vous avez faite est un morceau de contexte. Et parce que vous l'avez généré en prêtant attention, il a un signal plus élevé que tout ce qui serait scrappé au hasard du web.

Pensez à ce que cela signifie en termes compétitifs. Deux travailleurs du savoir utilisent le même modèle d'IA. L'un a trois ans de lecture et de surlignage structurés. L'autre a trois ans d'onglets de navigateur qu'il n'a jamais revisités. Quand ils posent la même question à l'IA, la première personne peut lui fournir son propre corpus organisé. La seconde est coincée avec les données d'entraînement génériques du modèle et ce dont elle peut se souvenir pour le coller. L'écart n'est pas un écart de prompting. C'est un écart de contexte.

C'est pourquoi Glasp a évolué dans son positionnement. Le pitch initial était un surligneur web social : surligner des choses, voir ce que d'autres ont surligné, construire une identité de lecteur. Tout cela reste vrai. Mais la valeur plus profonde aujourd'hui est que chaque surlignage est un token de contexte en attente d'utilisation. Votre histoire de lecture se compose en un corpus RAG personnel, un paragraphe à la fois.

Quand vous associez cela au chat IA de Glasp, le flux de travail devient plus proche de ce que les ingénieurs construisent pour leurs entreprises. Vous surlignez en lisant. Plus tard, vous posez des questions et l'IA tire de ce à quoi vous vous êtes vraiment intéressé, pas d'un index web générique. C'est du context engineering, sauf que le contexte est votre propre bibliothèque.

Pour en savoir plus sur comment cela renverse la relation lecture-IA, voir The AI Reading Assistant That Doesn't Do the Reading for You.

---

Un cadre simple pour ingénier le contexte de toute tâche IA

Assez de théorie. Voici un flux de travail concret que vous pouvez exécuter 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 arguments principaux contre la semaine de quatre jours, écrite pour un directeur financier sceptique. » Ça, c'est un travail. « Aide-moi avec cet article » ne l'est pas.

Étape 2 : rassemblez vos sources, puis coupez-les. Tirez 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à du contexte utile. Laissez de côté tout ce qui n'est que tangentiellement lié. Le context rot est 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 édites pour un directeur financier sceptique. Pas de jargon. Pas de réserves. Chiffres avant 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 plus le paquet, dans l'ordre. Mettez le contexte le plus important en premier et la tâche à la fin. À cause de l'effet Lost in the Middle, vous voulez l'instruction et le matériel le plus net au début et à la fin. Le milieu est un marécage.

Étape 5 : itérez sur le contexte, pas sur la formulation. Si la sortie est mauvaise, résistez à l'envie de réécrire votre prompt douze fois. Demandez plutôt : lui ai-je donné le bon matériel ? Y avait-il un passage que j'ai oublié ? Y avait-il une source trompeuse ? Ajustez les entrées, relancez, et regardez la qualité bondir.

Faites cela quelques dizaines de fois et ça devient réflexe. Vous cesserez de demander « comment je prompt ça ? » et commencerez à demander « que doit voir le modèle avant de répondre ? ». Ce basculement est toute la discipline.

---

Questions fréquemment posées

Le prompt engineering est-il vraiment mort ?

L'expression prend sa retraite. Les techniques derrière l'expression fonctionnent encore. Chain-of-thought, exemples few-shot et formats de sortie clairs sont toujours utiles. Ce qui est mort est l'idée qu'une bonne formulation seule vous donne une excellente sortie. En 2026, la formulation est un levier mineur. L'assemblage de contexte est le majeur. Quand les gens disent « le prompt engineering est mort », c'est ce qu'ils veulent dire.

Faut-il être technique pour faire du context engineering ?

Non. La métaphore de l'ingénierie en déconcerte certains, mais cela signifie simplement faire le travail délibérément au lieu d'accidentellement. Un consultant qui prépare un brief, un journaliste qui recherche un sujet, un étudiant qui organise du matériel source pour une dissertation, ce sont tous du context engineering déguisé. La compétence centrale est la curation et le jugement. La version technique n'est que la même compétence appliquée aux system prompts, pipelines RAG et stores de mémoire.

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 tire des chunks pertinents d'une base de connaissances au besoin. Le context engineering est la discipline plus large qui inclut le RAG, plus les system prompts, la mémoire, l'utilisation d'outils, les pièces jointes et l'historique de conversation. Le RAG est une technique. Le context engineering est la pratique.

Les fenêtres de contexte plus grandes ne résoudront-elles pas cela à terme ?

Elles ne l'ont pas fait jusqu'à présent, et les preuves 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 2025 de Chroma a montré que les 18 modèles de frontière testés se dégradent bien avant que la fenêtre ne se remplisse. Le goulet d'étranglement n'est pas la taille de la fenêtre. C'est l'allocation d'attention à l'intérieur de la fenêtre. La curation reste précieuse même si les fenêtres grossissent encore 10 fois.

Comment cela se rapporte-t-il aux fonctionnalités de « mémoire » 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 entre sessions. Le context engineering inclut la mémoire mais 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 par tâche. Un bon context engineer les utilise toutes ensemble.

Qu'est-ce que je dois arrêter de faire ?

Arrêtez d'accumuler des templates de prompts. Arrêtez de coller des documents complets quand des passages surlignés feraient l'affaire. Arrêtez de démarrer des conversations sans system prompt et de vous demander pourquoi le ton est faux. Arrêtez de traiter la boîte de chat comme la seule surface. La boîte de chat est le dernier centimètre d'un pipeline bien plus long, et c'est ce pipeline qui abrite les gains de qualité.

Où s'inscrivent les surlignages dans tout cela ?

Les surlignages sont la forme la plus brute et la moins chère de contexte personnel. Chaque fois que vous surlignez quelque chose, vous pré-filtrez le bruit de vos futures sessions IA. Les outils qui capturent les surlignages de manière durable (à travers articles, PDF, livres Kindle et transcriptions YouTube) transforment votre lecture en contexte réutilisable. C'est pourquoi les outils de capture de lecture et les outils IA convergent.

N'est-ce pas juste de la prise de notes stylée ?

En partie. La différence 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 consomme vos notes. Les exigences de format sont différentes (structure, atomicité, récupérabilité comptent davantage), mais la pratique sous-jacente de capturer ce qui vaut la peine d'être retenu est la même. Les bons preneurs de notes ont une longueur d'avance ici.

---

Conclusion : la nouvelle littératie

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

Les gens qui comprendront cela tireront loin devant ceux qui ne le comprendront pas. Pas parce qu'ils ont un meilleur accès aux modèles (tout le monde a les mêmes modèles), mais parce qu'ils se présentent à 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 il y a des mois.

C'est pourquoi 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 dans un moteur de contexte personnel. Le futur de la productivité IA n'est pas des gens avec des prompts secrets. C'est des gens avec 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 tient assez longtemps pour être utile à votre moi futur, et à l'IA qui travaille à vos côtés. Les outils existent. L'habitude est la partie difficile.

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