Le context engineering est la pratique consistant a gerer sciemment ce qu'un AI agent detient a un instant donne dans son context window, pour qu'il reste precis et rapide sur une longue tache au lieu de deriver lentement dans la confusion. Le context window est la memoire de travail du modele: le system prompt, vos regles, les fichiers qu'il a lus, les tools disponibles, la conversation jusqu'ici. Il est fini, et le fait le plus important a son sujet est que la qualite baisse a mesure qu'il se remplit, pas doucement, mais avec une falaise. Le context engineering est la facon dont vous gardez les bonnes choses dans le window et les mauvaises dehors: via la compaction, le retrieval, l'ordre et le prompt caching pour maitriser les couts. Ce guide explique ce qui remplit le window, pourquoi un window plein nuit, et les techniques qui gardent le travail agentique fiable. Tout ici est a jour en juin 2026 et accompagne la lecon Context Engineering du cours 2.
Ce que le context window detient vraiment
Le context window est tout ce que le modele peut voir quand il genere sa prochaine reponse, mesure en tokens (des morceaux de texte, environ quatre caracteres par token). Pour un coding agent, il se remplit de plus que votre dernier message: le system prompt qui definit l'agent, vos regles CLAUDE.md ou AGENTS.md, les definitions de chaque tool et serveur MCP connecte, chaque fichier que l'agent a lu, chaque sortie de commande qu'il a vue, et toute la conversation jusqu'ici. Tout cela se dispute le meme budget fini. Le modele mental qui compte: le contexte est une ressource rare que vous depensez, et tout ce que vous chargez (un serveur MCP bavard, un fichier enorme, un long va-et-vient) est du budget que la tache reelle n'a plus. Voir le glossaire sur le context window pour la definition formelle.
- Le system prompt et vos regles CLAUDE.md / AGENTS.md, recharges a chaque tour.
- Les definitions de tools et de serveurs MCP, ce qui explique pourquoi connecter beaucoup de serveurs est couteux.
- Chaque fichier lu et chaque sortie de commande, ce qui s'accumule vite pendant une tache.
- Tout l'historique de conversation; les longues sessions portent tout leur passe.
Pourquoi un window plein nuit: la falaise de performance
Il est tentant de penser qu'un context window plus grand veut dire que vous n'avez plus a vous soucier de rien, mais l'inverse est vrai: la qualite du modele baisse nettement avant que le window ne soit techniquement plein, et elle baisse abruptement. A mesure que le window se remplit de fichiers, d'historique et de bruit, le modele a plus a prendre en compte et est plus susceptible de perdre le fil, de contredire une instruction anterieure ou d'oublier une contrainte du debut de la conversation. C'est la "falaise de performance", et c'est pourquoi un window d'un million de tokens ne veut pas dire que vous devriez y deverser un million de tokens. La lecon pratique est contre-intuitive mais fiable: un contexte plus petit et bien cure surpasse en general un plus grand et bourre. Le context engineering existe precisement pour vous garder du bon cote de cette falaise.
- La qualite chute avant que le window ne soit plein, et la chute est une falaise, pas une pente douce.
- Un window bourre fait perdre au modele des fils, se contredire et laisser tomber des contraintes.
- Un grand contexte maximal est un plafond, pas un objectif; ne le remplissez pas parce que vous pouvez.
- Un petit contexte cure bat un grand gonfle, la regle centrale du context engineering.
Lost in the middle
Le "lost in the middle" est un comportement bien documente des modeles de langage: ils prennent en compte le plus fiablement l'information au debut et a la fin de leur contexte, et le moins fiablement l'information enfouie au milieu. Une instruction cruciale ou l'unique fait pertinent, laisse tomber au milieu d'un long prompt ou d'une longue conversation, est ce qui est le plus susceptible d'etre ignore. La consequence pratique faconne la facon dont vous ordonnez le contexte. Mettez les instructions les plus importantes et le materiau le plus pertinent la ou le modele regarde: pres du debut (vos regles permanentes) et pres de la fin (la tache immediate et le fichier cle). Ne supposez pas que le modele utilise quelque chose juste parce que c'est quelque part dans le window. La position est un levier.
- Les modeles prennent en compte le mieux le debut et la fin du contexte, le milieu le moins bien.
- Une instruction cle enfouie au milieu du prompt est la plus susceptible d'etre ignoree.
- Mettez les regles permanentes pres du debut et la tache immediate et le fichier cle pres de la fin.
- Etre dans le window ne veut pas dire etre utilise; la position determine l'attention.
Compaction, handovers et resets
Quand une session dure longtemps, il vous faut des moyens de larguer du poids sans perdre le fil. Trois techniques font l'essentiel. La compaction resume la conversation jusqu'ici sous une forme compacte et continue, liberant le window; le piege est que la compaction automatique laisse tomber silencieusement des details qui vous importaient, donc pilotez-la en disant a l'agent ce qu'il doit preserver avant la compaction. Un handover termine une session et en demarre une fraiche avec un resume propre et delibere que vous ecrivez, ce qui vous donne un contexte bien plus net que de laisser une session s'etaler des heures. Un reset jette un contexte confus et repart avec un prompt etroit, ce qui est souvent plus rapide que de ramener un agent deraille sur les rails par l'argumentation. Savoir quand recourir a laquelle est le coeur pratique de la competence.
- Compaction: resumer et continuer pour liberer le window; pilotez-la pour qu'elle garde ce qui compte.
- Handover: terminer la session et repartir a neuf avec un resume propre que vous controlez.
- Reset: jeter un contexte confus et repartir avec un prompt etroit plutot qu'argumenter.
- Les subagents aident aussi: deleguez le travail bruyant, pour que son output n'atterrisse jamais dans votre window principal.
Retrieval: ne faire entrer que ce qui est necessaire
Le mode d'echec inverse du window bourre est que la bonne information n'arrive jamais. Le retrieval est la facon dont vous faites entrer exactement le morceau pertinent au besoin, au lieu de tout precharger. Pour un coding agent, c'est en general concret et peu glamour: laissez l'agent chercher dans la codebase et ne lire que les fichiers qu'une tache touche, au lieu de coller tout le repo; montrez-lui l'unique page de doc dont il a besoin; laissez-le grep la fonction au lieu de charger le repertoire. Le principe derriere les patterns retrieval-augmented est le meme, que ce soit une base de donnees vectorielle ou un agent qui execute grep: recuperez exactement ce dont la tache a besoin, quand elle en a besoin, pour que le window garde du signal plutot qu'un tas plein d'espoir de materiau peut-etre pertinent.
- Recuperez le fichier, la doc ou l'enregistrement specifique dont la tache a besoin, pas tout ce qui est potentiellement pertinent.
- Laissez un coding agent chercher et lire au besoin, au lieu de precharger tout le repo.
- Le retrieval garde le window plein de signal, ce qui garde le modele du bon cote de la falaise.
- La meme idee passe a l'echelle jusqu'a la recherche vectorielle; l'objectif est toujours pertinent-au-besoin, pas tout-au-cas-ou.
Prompt caching: maitriser le cout d'un grand contexte
Un grand contexte stable est couteux, parce que le modele retraite chacun de ses tokens a chaque requete, et vous payez ces tokens d'input a chaque fois. Le prompt caching resout le cote cout: vous marquez un prefixe stable (votre system prompt, vos regles, vos definitions de tools, un gros document de reference) comme cachable, et les requetes suivantes qui commencent par les memes octets exacts le lisent depuis le cache au lieu de le recalculer. Sur l'API Claude, l'economie en juin 2026 est claire: une ecriture de cache coute environ 1,25 fois un token d'input normal pour la duree de vie standard de cinq minutes (ou 2 fois pour l'option d'une heure), et une lecture de cache ne coute qu'environ 0,1 fois, un dixieme du prix. Un prefixe cache s'amortit donc en quelques reutilisations. Le cache est un cache de prefixe, donc l'ordre compte: mettez votre contenu stable en premier et votre contenu changeant en dernier, et un seul token modifie avant le breakpoint force une reecriture complete. Le caching ne reduit pas la quantite de contexte que le modele prend en compte, seulement ce que vous payez pour l'envoyer, donc il complete la curation plutot que la remplacer.
- Le caching reutilise l'etat encode d'un prefixe stable, pour qu'il ne soit pas recalcule a chaque requete.
- Sur l'API Claude (juin 2026): ecritures de cache environ 1,25x l'input (standard 5 minutes, 2x pour 1 heure), lectures de cache environ 0,1x.
- C'est un cache de prefixe: gardez le contenu stable en premier et le changeant en dernier, sinon vous forcez une reecriture.
- Le caching baisse les couts, pas l'attention; vous continuez de curer le window. Voir le glossaire sur le prompt caching.
Une checklist de context engineering pratique
Assemblez les idees en habitudes que vous executez sans y penser. Rien de tout cela n'exige d'outillage special; c'est de la discipline sur ce que vous chargez et quand vous nettoyez. Un compagnon a venir est l'outil d'estimation de tokens et de contexte de ce campus, avec lequel vous collerez du texte et verrez combien d'un window de modele il remplit avant de l'envoyer; pour l'instant, les regles ci-dessous vous portent.
- Gardez les regles permanentes dans CLAUDE.md ou AGENTS.md, et gardez ce fichier court; il se charge a chaque tour.
- Chargez les fichiers dont la tache a besoin, pas tout le repo; laissez l'agent recuperer au besoin.
- Mettez l'instruction la plus importante pres du debut et la tache immediate pres de la fin.
- Compactez, faites un handover ou un reset quand une session devient longue ou confuse; ne la laissez pas s'etaler.
- Cachez les gros prefixes stables pour maitriser les couts, avec le contenu stable en premier.
- Deleguez le travail annexe bruyant a un subagent, pour que son output reste hors de votre window principal.