L'ingénierie du contexte
L'ingénierie de prompt porte sur les mots que vous choisissez. L'ingénierie du contexte porte sur l'espace de travail que vous remettez au modèle — ce qu'il contient, dans quel ordre, et ce que vous avez délibérément laissé de côté.
La distinction compte parce qu'une fenêtre de contexte n'est pas un bloc-notes. C'est une ressource attentionnelle limitée et coûteuse. La façon dont vous la remplissez change ce sur quoi le modèle se concentre, combien elle vous coûte, et si elle reste utile à mesure que les sessions s'allongent.
Le budget de contexte
Chaque modèle a une taille de contexte maximale — un plafond strict mesuré en tokens. Voyez-le comme un budget. Vous le dépensez en :
- Votre prompt système et vos instructions permanentes
- Documents récupérés, extraits de base de code, définitions d'outils
- Historique de conversation
- La sortie du modèle (qui compte elle aussi dans la fenêtre lors de sessions multi-tours)
Quand vous êtes à court, quelque chose doit céder. Soit l'ancien contenu est abandonné, soit la session se heurte à un mur.
La plupart des guides pour débutants traitent la fenêtre de contexte selon le principe « plus, c'est mieux ». L'ingénierie du contexte la traite comme une ressource à allouer avec soin : dépensez-la sur ce dont le modèle a réellement besoin pour ce tour, pas sur tout ce qui pourrait être pertinent.
La pourriture du contexte et le « perdu au milieu »
Il existe un phénomène bien documenté chez les LLM à long contexte : les modèles accordent une attention disproportionnée au contenu situé près du début et de la fin de leur contexte, et leur capacité à retrouver le contenu enfoui au milieu se dégrade. Les chercheurs étudiant cet effet l'ont appelé « lost in the middle » (perdu au milieu).
La conséquence pratique : si vous bourrez un contexte de 100 000 tokens de documents et enterrez l'instruction la plus critique à la position 60 000, le modèle peut l'ignorer de fait — non parce qu'il est incapable de lire aussi loin, mais parce que l'attention n'est pas répartie uniformément dans la fenêtre.
La « pourriture du contexte » est le schéma plus large : à mesure qu'une session grandit, la qualité des réponses tend à dériver. Les instructions initiales se diluent. Les allers-retours répétés évincent la tâche d'origine. Le modèle commence à se montrer évasif, à se répéter, ou à perdre le fil de ce que vous demandiez réellement.
Ce ne sont pas des bugs que vous pouvez entièrement corriger avec un meilleur prompt. Ce sont des propriétés structurelles du fonctionnement de l'attention à grande échelle. La réponse de l'ingénierie est de garder le contexte plus petit et plus net, pas de le remplir en espérant.
L'ordre compte
L'endroit où vous placez le contenu est aussi important que ce que vous y incluez. Bonne pratique établie :
| Position | Quoi y mettre |
|---|---|
| Tout en haut (prompt système) | Instructions stables et durables. Persona, règles, exigences de format. |
| Après le prompt système | La tâche actuelle, en termes clairs. |
| Juste avant le dernier tour de l'utilisateur | Le contexte le plus critique et le plus spécifique à cette requête exacte. |
| Milieu | Documents de support, extraits récupérés — ordonnés par pertinence, pas par chronologie. |
| Historique de conversation | Uniquement ce qui est nécessaire à la continuité. Élaguez agressivement. |
La règle générale : plus c'est proche du tour actuel, plus cela reçoit d'attention. Les instructions critiques qui ne vivent qu'au milieu d'un long historique sont en danger.
La récupération plutôt que le bourrage
La tentation est de tout mettre : tous les docs, la base de code complète, l'intégralité de la conversation. Résistez-y.
La meilleure approche est la récupération sélective : identifier ce dont le modèle a réellement besoin pour cette requête spécifique, et n'injecter que cela. Un extrait bien récupéré de 2 000 tokens du bon document surpasse un déversement de 40 000 tokens où la réponse se trouve quelque part au milieu.
C'est la raison d'être de la génération augmentée par récupération (RAG) — non seulement pour dépasser les limites de contexte, mais pour améliorer la qualité en gardant le contexte curé.
Pour les sessions interactives, la même logique s'applique : au lieu de tout accumuler, compactez ou videz périodiquement l'historique pour retirer le contenu qui n'est plus pertinent pour la tâche actuelle. Les commandes /compact et /clear de Claude Code sont des outils d'ingénierie du contexte, pas seulement de gestion de session.
L'angle du coût
Les tokens que vous envoyez sont des tokens que vous payez — en argent comme en latence. Bourrer le contexte de matière vaguement pertinente gonfle les deux. Ingénierie du contexte et efficacité des coûts sont le même problème.
Plus concrètement :
- Un prompt système boursouflé que vous copiez-collez depuis un modèle est payé à chaque appel.
- L'ancien historique de conversation que vous traînez parce que « ça pourrait être utile » est payé à chaque appel.
- Les documents que vous injectez « au cas où » sont payés à chaque appel.
Élaguer ce qui n'a pas besoin d'être là est simultanément meilleur pour la qualité et moins coûteux à faire tourner.
Tactiques concrètes pour les utilisateurs de Claude
Dans Claude.ai :
- Utilisez des conversations distinctes pour des tâches distinctes. Ne laissez pas une après-midi de digressions polluer le contexte d'un projet ciblé.
- Résumez les longs fils avant de poser une question complexe qui en dépend. Un résumé explicite est souvent plus utile que l'historique brut.
- Mettez la chose précise que vous voulez à la fin d'un long message, pas enfouie au milieu.
Dans Claude Code :
- Gardez votre fichier
CLAUDE.mdléger. Chaque ligne qu'il contient est injectée dans chaque session. Voir CLAUDE.md et Gestion du contexte. - Utilisez
/clearquand vous basculez vers une tâche véritablement différente. Utilisez/compactquand vous voulez continuer mais que la session grandit. - Référencez les fichiers par chemin plutôt que de coller leur contenu lorsque le fichier complet n'est pas nécessaire à l'étape actuelle.
Au niveau de l'API :
- Concevez les prompts système pour qu'ils ne contiennent que ce dont chaque requête a véritablement besoin. Déplacez les instructions spécifiques à la tâche dans le tour de l'utilisateur.
- Pour les cas d'usage riches en documents, récupérez et injectez les extraits pertinents plutôt que de téléverser un corpus entier.
- Structurez le prompt de sorte que le préfixe stable et réutilisable vienne en premier — cela active aussi le cache de prompt, un compagnon naturel de l'ingénierie du contexte.
Le changement de mentalité
L'ingénierie de prompt demande : « Que devrais-je dire ? » L'ingénierie du contexte demande : « Que devrait voir le modèle, dans quel ordre, et que devrais-je délibérément tenir à l'écart ? »
La seconde question est plus difficile, mais c'est celle qui détermine réellement la qualité à grande échelle.