Module 2 — L'anatomie du contexte — Context Engineering — le pack Praktik

Objectif

À la fin de ce module, tu sauras identifier les 5 composants qui mangent tes tokens et comment les auditer.

Les 5 composants du contexte

Composant	% typique	Ce que ça contient
System prompt	5-15%	Instructions, persona, règles
Tool definitions	10-25%	Schémas JSON des outils disponibles
Message history	30-50%	Conversation, appels d’outils, résultats
Retrieved documents	10-30%	Docs RAG, fichiers lus, codebase
Tool outputs	20-40%	Résultats bruts des outils (grep, read, test)

Total : souvent 80-100% de la fenêtre, même si tu n’as rien demandé de fou.

Le coupable #1 : les tool outputs

Les résultats d’outils dominent souvent les trajectoires d’agents (80%+ des tokens). Exemple :

# Un grep sur un gros repo
$ grep -r "function auth" src/
# → 500 lignes de résultat
# → ~3000 tokens dans le contexte
# → Pour une seule commande

Astuce : Après traitement, remplace l’output brut par une référence compacte :

[Obs:grep-001 masqué. Clé: 12 fichiers trouvés, 3 pertinents. 
Détail: auth.ts, middleware.ts, config.ts. Complet récupérable.]

Le coupable #2 : les tool definitions

Les schémas JSON des outils gonflent 2-3x après sérialisation. 10 outils avec des schémas modérés = 5000-8000 tokens avant le premier message.

Exemple de gonflement :

{"name": "read_file", "parameters": {"path": "string"}}
# En JSON sérialisé : ~40 tokens
# 10 outils x 10 paramètres = facile 5000+ tokens

Astuce : Minimiser le nombre d’outils. Fusionner les outils qui se chevauchent.

Le coupable #3 : l’historique de messages

Chaque tour de conversation ajoute :

Ta question
La réponse du modèle
Les appels d’outils
Les résultats des outils

Après 20-30 itérations, l’historique peut occuper 70-80% de la fenêtre. Le pire : l’agent ne montre aucun symptôme visible jusqu’à ce que la qualité de raisonnement s’effondre d’un coup.

Audit rapide de ton contexte

Dans Claude Code :

# Voir l'utilisation par composant
/claude context --breakdown

Si tu n’as pas cette commande, estime manuellement :

Compte les lignes de system prompt
Compte les outils définis
Compte les messages dans l’historique
Identifie les gros outputs récents

Budget type à allouer

budgets:
  system_prompt: 10%      # ~20K sur 200K
  tool_definitions: 15%   # ~30K sur 200K
  message_history: 35%    # ~70K sur 200K
  retrieved_documents: 25% # ~50K sur 200K
  tool_outputs: 10%       # ~20K sur 200K
  reserved_buffer: 5%     # ~10K sur 200K (marge de sécurité)

Checklist de validation

Je connais les 5 composants du contexte
Je sais quel composant domine typiquement (tool outputs)
Je peux estimer l’utilisation par composant
J’ai un budget alloué pour chaque catégorie

Sous-estimer les tool definitions. → Ils semblent petits dans le code source, mais gonflent énormément en JSON. 10 outils bien écrits peuvent consommer 8000 tokens rien qu’en schémas. Vérifier le compte de tokens sérialisés, pas le nombre de lignes de code.

Prochaine étape

→ Module 3 (Courbe d’attention en U) pour savoir où placer l’info critique