Quand une application Claude fonctionne pendant quelques tours seulement, la gestion du contexte paraît simple.
On envoie :
- un
system prompt; - quelques messages ;
- éventuellement quelques tools ;
- puis on reçoit une réponse.
Mais lorsque la conversation s’allonge, que les tools retournent beaucoup de données, que l’on ajoute des documents, des logs, des résultats de recherche ou des sous-tâches, un problème apparaît progressivement :
tout ce contexte consomme le budget de tokens disponible.
C’est là qu’intervient le context engineering.
L’objectif n’est pas simplement de « garder l’historique ».
Il s’agit de décider quelles informations doivent rester dans le contexte, lesquelles peuvent être supprimées, résumées ou déplacées, et lesquelles doivent être confiées à un subagent.
1. La Context Window est un budget
La context window représente la quantité totale d’information que Claude peut prendre en compte dans une requête.
Elle contient notamment :
system prompt
+
messages
+
tool definitions
+
tool results
+
documents
+
images
+
previous assistant responses
+
current user request
Tous ces éléments consomment des tokens.
Il faut donc raisonner ainsi :
Context window
=
budget total disponible
Ce budget n’est pas uniquement consommé par le message utilisateur.
2. Les Tools consomment eux aussi du contexte
C’est une source fréquente de surprise.
Supposons qu’un agent appelle :
search_logs
et que le tool retourne :
20 000 lignes de logs
Même si Claude n’a besoin que de trois lignes réellement importantes, les 20 000 lignes peuvent être injectées dans le contexte.
Puis l’agent appelle :
read_file
et reçoit plusieurs milliers de lignes supplémentaires.
Puis :
search_repository
Puis :
run_tests
Puis encore un autre tool.
Le contexte peut rapidement devenir :
Prompt
+ History
+ Tool schemas
+ Huge tool result
+ Huge tool result
+ Huge tool result
+ ...
Le problème n’est alors plus seulement le prompt.
Le problème devient l’architecture du contexte.
3. Pourquoi les longues sessions deviennent difficiles
Au fur et à mesure que le contexte grossit :
- le coût augmente ;
- la latence augmente ;
- le système se rapproche de la limite de contexte ;
- les informations vraiment importantes représentent une part plus faible du contexte global.
Le module insiste notamment sur un cas de production classique :
Prototype
→ fonctionne avec petits tool results
Production
→ tool results beaucoup plus gros
Résultat
→ contexte saturé beaucoup plus vite que prévu
Le problème ne vient donc pas nécessairement du modèle.
Il peut venir de la quantité d’information accumulée.
4. Premier réflexe : mesurer les Tokens
Avant d’envoyer une requête, l’application peut estimer combien de tokens seront consommés.
Le module mentionne l’utilisation d’un endpoint de token counting.
L’idée est simple :
Construire la requête
↓
Compter les tokens
↓
Comparer au budget disponible
↓
Décider de compacter / supprimer / déléguer
↓
Envoyer la requête
Cela permet d’éviter de découvrir le problème uniquement au moment où la requête devient trop grande.
5. Context Engineering ≠ conserver tout l’historique
Une erreur fréquente consiste à faire :
messages.append(everything_forever)
et à envoyer systématiquement tout l’historique à Claude.
Cette stratégie peut fonctionner pour :
- une courte conversation ;
- une démonstration ;
- un workflow limité.
Mais elle devient fragile dès que la session dure longtemps.
Le contexte doit être géré comme une ressource.
6. Les quatre grandes stratégies
Le module présente quatre approches principales :
Pruning
Compaction
Clearing
Subagent handoffs
Elles répondent à des besoins différents.
7. Pruning : supprimer ce qui n’est plus nécessaire
Le pruning consiste à retirer du contexte certaines informations devenues inutiles.
Par exemple :
Tool result initial
→ utilisé pour prendre une décision
→ décision déjà prise
→ résultat détaillé plus nécessaire
On peut donc conserver :
Décision retenue
et supprimer :
15 000 lignes de données brutes
8. Exemple de Pruning
Supposons qu’un agent analyse des logs.
Il reçoit :
12 000 lignes
Il conclut :
The failures are caused by an expired OAuth certificate.
Une fois cette conclusion validée, conserver l’intégralité des logs dans tous les tours suivants peut être inutile.
On peut préférer conserver :
Key finding:
Authentication failures are caused by an expired OAuth certificate.
Le contexte devient beaucoup plus compact.
9. Limite du Pruning
Le pruning détruit de l’information.
Si vous supprimez :
logs détaillés
et que Claude doit plus tard vérifier :
la ligne exacte contenant l’erreur
il faudra peut-être refaire un tool call.
Le pruning doit donc être utilisé lorsque l’on accepte de perdre les détails retirés.
10. Compaction : résumer au lieu de supprimer
La compaction consiste à remplacer une longue portion de contexte par un résumé.
Par exemple :
40 messages
+
5 tool results
+
3 décisions
peuvent devenir :
Summary:
- Authentication migration targets service X.
- Legacy endpoint must remain available.
- Database schema has already been migrated.
- Current blocker is certificate rotation.
- Previous attempt failed because environment variable AUTH_CERT was stale.
Le contexte est réduit, tout en conservant l’essentiel.
11. Une bonne Compaction doit préserver l’état critique
Le module recommande de conserver notamment :
- les chemins de fichiers ;
- les décisions prises ;
- les erreurs rencontrées ;
- les solutions déjà testées ;
- les résultats importants.
Mauvais résumé :
We investigated the bug and made progress.
Bon résumé :
Investigated authentication failure.
Key findings:
- failing file: src/auth/config.ts
- current certificate path: /etc/auth/cert.pem
- production still references old variable AUTH_CERT_V1
- staging already uses AUTH_CERT_V2
- restart alone did not fix the issue
- next step: update deployment configuration before rerunning tests
Le second résumé permet réellement de continuer le travail.
12. Le risque de la Compaction
Une compaction produit nécessairement une perte.
Le résumé conserve ce que le système considère important.
Il abandonne le reste.
Le problème est donc :
ce qui paraît secondaire maintenant peut devenir important plus tard.
Il faut choisir soigneusement les informations à préserver.
13. Compaction dans Claude Code
Le module mentionne notamment la commande :
/compact
dans Claude Code.
L’objectif est de réduire l’historique actif en produisant une version condensée permettant de poursuivre le travail avec davantage d’espace disponible.
Il faut retenir le principe général :
Long context
↓
Summarize critical state
↓
Continue with compacted context
14. Clearing : repartir proprement
Parfois, la meilleure solution n’est ni de supprimer quelques blocs ni de résumer.
Il faut simplement démarrer un nouveau contexte.
C’est le clearing.
Exemple :
Task A completed
↓
Task B unrelated
Pourquoi conserver :
- tous les logs de Task A ;
- tous les tool calls ;
- toutes les décisions ;
- tout l’historique ;
si Task B n’en a pas besoin ?
On peut repartir avec :
New session
15. Clearing dans Claude Code
Le module cite notamment :
/clear
dans Claude Code.
Cette approche élimine le contexte précédent.
Elle est adaptée lorsque le travail suivant ne dépend plus réellement de l’historique existant.
16. Le compromis du Clearing
Le clearing offre le maximum d’espace.
Mais il supprime aussi toute continuité.
Après :
/clear
Claude ne connaît plus les détails du travail précédent, sauf si vous les réintroduisez.
C’est donc un choix volontaire :
maximum de contexte disponible
↔
perte de l’état précédent
17. Subagent Handoffs
La quatrième stratégie consiste à déléguer une tâche à un subagent disposant de son propre contexte.
Conceptuellement :
Main agent
↓
Scoped task
↓
Subagent
↓
Independent context
↓
Result summary
↓
Main agent
Le main agent n’a pas besoin de contenir toutes les étapes intermédiaires du travail du subagent.
18. Pourquoi les Subagents économisent du contexte
Supposons que le main agent doive :
Analyze repository and propose migration
Il délègue :
Subagent A
→ inspect authentication code
Subagent B
→ inspect deployment configuration
Subagent C
→ inspect tests
Chaque subagent peut parcourir beaucoup de données dans sa propre context window.
Le main agent reçoit uniquement :
summary A
summary B
summary C
Au lieu de recevoir tout leur historique.
19. Le prix des Subagents
Comme pour la compaction, on perd une partie du chemin intermédiaire.
Le main agent reçoit :
conclusion
mais pas nécessairement :
every intermediate observation
Il faut donc définir clairement ce que le subagent doit retourner.
20. Comment donner une bonne tâche à un Subagent
Le module recommande une tâche bien délimitée.
Elle doit inclure :
- l’objectif ;
- le minimum de contexte nécessaire ;
- les résultats antérieurs pertinents ;
- les tools autorisés ;
- les conditions de sortie.
Par exemple :
Inspect the authentication module only.
Goal:
Identify all dependencies on the legacy authentication API.
Relevant context:
The target replacement is Identity Service v2.
Tools:
- search_repository
- read_file
Return:
- file paths
- dependency list
- migration risks
Stop once all direct dependencies have been identified.
C’est beaucoup plus efficace que :
Investigate the codebase.
21. Comparer les quatre stratégies
| Stratégie | Avantage | Inconvénient |
|---|---|---|
| Pruning | Très simple | Perte de détails |
| Compaction | Conserve l’essentiel | Résumé imparfait |
| Clearing | Libère presque tout le contexte | Perte totale de continuité |
| Subagent | Isole un travail complexe | Résumé intermédiaire nécessaire |
Le bon choix dépend du workflow.
22. Règle pratique
On peut retenir :
Information inutile ?
→ prune
Information utile mais trop volumineuse ?
→ compact
Nouvelle tâche indépendante ?
→ clear
Sous-tâche complexe et isolable ?
→ subagent
23. Prompt Caching
Une autre technique importante concerne le coût des parties stables du contexte.
Supposons que vous envoyiez à chaque requête :
large system prompt
+
tool definitions
+
large reference document
+
new user message
Les trois premiers éléments changent rarement.
Le prompt caching permet de tirer parti de cette stabilité.
Le principe est de mettre en cache une partie du préfixe stable afin de réduire le coût de ses réutilisations.
24. Que mettre en cache ?
Les meilleurs candidats sont généralement les blocs stables.
Par exemple :
system prompt
tool definitions
long reference documentation
Plutôt que :
current user request
qui change à chaque tour.
Conceptuellement :
[ stable prefix ] [ dynamic suffix ]
cache new
25. Cache ≠ Mémoire
C’est une distinction importante.
Le prompt caching ne constitue pas une mémoire applicative.
Il sert principalement à optimiser le traitement de contenus réutilisés.
Il ne signifie pas :
Claude se souvient automatiquement de la conversation
L’application doit toujours gérer son contexte et son état.
26. Context Window et RAG
Le Retrieval-Augmented Generation permet d’éviter d’insérer une base documentaire entière dans le contexte.
Au lieu de :
all company documentation
on recherche :
only relevant passages
Puis on fournit ces passages à Claude.
Conceptuellement :
User question
↓
Retrieval
↓
Relevant chunks
↓
Claude
C’est une forme essentielle de context engineering.
27. Où un système RAG peut échouer
Le module identifie plusieurs niveaux possibles d’échec.
Chunking
Le document a été découpé de manière inadaptée.
Retrieval
Les mauvais morceaux ont été récupérés.
Context assembly
Les bons morceaux ont été trouvés mais mal présentés ou insuffisamment contextualisés.
Il ne faut donc pas automatiquement conclure :
Claude hallucine
Le problème peut venir du pipeline de récupération.
28. Chunking
Le module recommande comme point de départ raisonnable de découper par :
- phrases ;
- sections ;
avec un certain chevauchement.
Pourquoi ?
Parce qu’un découpage arbitraire peut casser le sens.
Exemple :
Chunk 1:
The authentication token expires after
Chunk 2:
24 hours unless refresh is enabled.
Les deux morceaux séparés sont moins utiles que la phrase complète.
29. Retrieval hybride
Le module mentionne également l’intérêt potentiel d’une approche hybride combinant :
lexical search
+
semantic search
Le lexical est utile lorsque l’on cherche des termes précis :
AUTH_CERT_V2
Le semantic search est utile lorsque la question est conceptuellement liée mais formulée différemment.
Les deux peuvent donc se compléter.
30. Gros Tool Results : ne pas tout conserver
Un principe de production particulièrement utile est :
Un tool result n’a pas nécessairement besoin de rester intégralement dans le contexte après avoir servi.
Exemple :
search_repository
→ 300 results
Claude identifie :
3 relevant files
Il peut être préférable de conserver :
Relevant files:
- src/auth/client.ts
- src/auth/config.ts
- tests/auth.test.ts
et de supprimer le reste.
31. Exemple de Postmortem
Le module décrit un scénario où une équipe avait correctement prévu un plafond d’environ :
40k tokens
dans ses tests.
Le prototype fonctionnait.
Mais en production, les tool outputs étaient beaucoup plus volumineux.
Résultat :
larger tool outputs
↓
faster context growth
↓
degraded behavior / context pressure
Le vrai problème n’était pas nécessairement le prompt ou le modèle.
C’était l’accumulation de contexte.
32. Correction du problème
La solution proposée combine notamment :
Prune bulky tool outputs
+
Compact proactively
Le mot important est :
proactively
Il vaut mieux gérer le contexte avant d’atteindre la limite.
Pas une fois le système déjà saturé.
33. Ne pas confondre dégradation et disparition magique des instructions
Lorsqu’un contexte devient énorme, il faut éviter une explication simpliste du type :
Claude oublie automatiquement les anciennes instructions.
Le problème pratique est plutôt que l’application accumule trop de contenu et doit décider comment gérer son budget de contexte.
Si elle supprime, compacte ou remplace certaines informations, celles-ci peuvent effectivement disparaître ou être résumées.
La responsabilité du context engineering reste donc largement côté application.
34. Context Engineering et Agents
Les agents rendent le problème encore plus important.
Un agent peut enchaîner :
tool call
→ tool result
→ reasoning
→ tool call
→ tool result
→ reasoning
...
Chaque tour peut augmenter le contexte.
Sans stratégie, un agent long-running peut progressivement accumuler :
- observations obsolètes ;
- logs ;
- résultats temporaires ;
- plans anciens ;
- erreurs déjà résolues.
Le contexte devient alors une sorte de journal complet.
Ce n’est pas toujours souhaitable.
35. Conserver l’état, pas nécessairement le journal complet
Pour un agent, il est souvent plus utile de conserver :
Current state
que :
Complete historical transcript
Exemple :
Mauvais état :
20 pages describing every failed attempt
Meilleur état :
Current objective:
Migrate authentication.
Completed:
- identity client implemented
- unit tests passing
Failed:
- production deployment due to stale certificate env var
Next:
- update deployment secret
- rerun integration tests
Le second contexte est beaucoup plus actionnable.
36. Context Engineering et Coût
Le contexte influence directement le coût.
Si vous envoyez à chaque tour :
100k tokens of history
même pour poser une question simple, vous payez pour retraiter ce contexte.
Réduire le contexte n’est donc pas seulement une optimisation technique.
C’est aussi une optimisation économique.
37. Context Engineering et Latence
Même logique pour la latence.
Plus l’entrée est importante, plus le système doit traiter de données.
Réduire les informations inutiles peut donc améliorer :
cost
+
latency
+
robustness
C’est pour cela que le context engineering est un sujet de production, pas uniquement un problème de limite maximale.
38. Comment diagnostiquer un problème de Context
Si une application fonctionne parfaitement au début mais se dégrade après plusieurs tours, il faut examiner :
context size
tool output size
conversation history
repeated documents
redundant instructions
Avant de conclure :
model is inconsistent
Le problème peut être architectural.
39. Une boucle de contrôle pratique
Une application peut surveiller :
Current token count
↓
Below threshold?
↙ ↘
Yes No
↓ ↓
Continue Context maintenance
↓
prune / compact /
clear / subagent
Cette logique peut faire partie du runtime de l’application.
40. Ce qu’il faut retenir pour la certification
Principe 1 — La Context Window est un budget partagé
Elle contient :
system
messages
tools
tool results
documents
output
Tout consomme des tokens.
Principe 2 — Les Tool Results peuvent être très coûteux
Ne supposez pas que seul l’historique conversationnel fait grossir le contexte.
Principe 3 — Utiliser Pruning lorsque les détails ne sont plus nécessaires
remove unnecessary data
Principe 4 — Utiliser Compaction lorsque l’état doit être conservé
large history
→ summary of critical state
Principe 5 — Utiliser Clearing pour une nouvelle tâche indépendante
Inutile de transporter tout l’ancien contexte lorsque le travail suivant n’en dépend pas.
Principe 6 — Utiliser des Subagents pour isoler des sous-tâches
Un subagent peut consommer beaucoup de contexte localement et ne retourner qu’un résumé utile au main agent.
Principe 7 — Mesurer les Tokens
Ne gérez pas la context window uniquement à l’intuition.
Principe 8 — Le Prompt Caching optimise les préfixes stables
Il ne remplace pas une stratégie de mémoire ou de gestion de contexte.
Pièges fréquents à l’examen
Piège 1
« Tant que la conversation reste sous la limite maximale, il n’y a aucun problème de contexte. »
Faux.
Un contexte énorme peut déjà augmenter coût et latence bien avant la limite.
Piège 2
« Pour conserver l’état d’un agent, il faut garder l’intégralité de tous les tool results. »
Non.
Il est souvent préférable de conserver les conclusions et l’état réellement utile.
Piège 3
« Compaction et Clearing sont équivalents. »
Non.
Compaction conserve un résumé.
Clearing repart sans le contexte précédent.
Piège 4
« Un Subagent partage forcément tout l’historique du Main Agent. »
Non.
L’intérêt est justement de lui fournir un contexte ciblé et isolé.
Piège 5
« Prompt caching permet à Claude de mémoriser les conversations précédentes. »
Non.
Il s’agit d’une optimisation de réutilisation du contexte stable, pas d’une mémoire applicative.
Piège 6
« Une dégradation après 30 tours signifie forcément qu’il faut un meilleur modèle. »
Non.
Examinez d’abord :
context growth
tool outputs
redundant history
La règle à mémoriser
Pour le context engineering, retenez :
Context is a budget
↓
Measure it
↓
Keep only what is useful
↓
Prune details
Compact state
Clear unrelated work
Delegate isolated work
↓
Continue with a smaller,
higher-value context
La qualité d’un système Claude ne dépend donc pas seulement de ce que l’on ajoute au contexte.
Elle dépend aussi de ce que l’on décide de ne plus y conserver.
Le context engineering consiste précisément à maintenir le meilleur rapport possible entre :
information useful
/
tokens consumed
C’est une compétence essentielle dès que l’on construit des agents, des workflows longs ou des applications Claude destinées à la production.
Article suivant
Construire un agent Claude en production : workflow, agent loop et Human-in-the-Loop
Nous verrons comment distinguer un simple appel LLM, un workflow déterministe et un véritable agent, comment construire une agent loop, définir des conditions d’arrêt et placer les validations humaines aux bons endroits.
