Module 9 — Context engineering par modèle — Context Engineering — le pack Praktik

Objectif

À la fin de ce module, tu sauras adapter ta stratégie de contexte selon le modèle que tu utilises.

Claude Code 4.7 Opus

Caractéristique	Valeur
Contexte annoncé	200K
Capacité effective	~120K
Degradation onset	~120K (60%)
Force	Raisonnement complexe, code review
Faiblesse	Coût élevé, latence

Stratégie recommandée

budget_allocation:
  system_prompt: 15%      # Opus gère bien les instructions longues
  tool_definitions: 20%   # Schémas détaillés OK
  message_history: 30%    # Compacter tôt
  retrieved_documents: 20%
  tool_outputs: 10%       # Masking agressif
  buffer: 5%

compaction_trigger: 65%   # Opus dégrade tôt
workflow: research-plan-implement  # Nécessaire pour complexité
subagents: Oui            # Opus coûte cher, isoler les tâches simples

Astuce spécifique

Opus a une bonne gestion des instructions au début mais dégrade vite au milieu
Privilégier les prompts structurés avec XML tags
Le “extended thinking” réduit les hallucinations mais augmente latence et coût

Claude Code 4.8 Opus

Caractéristique	Valeur
Contexte annoncé	256K
Capacité effective	~150K
Degradation onset	~150K (60%)
Force	Meilleure gestion du long contexte
Faiblesse	Coût encore plus élevé

Stratégie recommandée

budget_allocation:
  system_prompt: 12%
  tool_definitions: 18%
  message_history: 32%
  retrieved_documents: 23%
  tool_outputs: 10%
  buffer: 5%

compaction_trigger: 70%   # Légèrement plus tolérant que 4.7
workflow: research-plan-implement
subagents: Oui

Différences avec 4.7

Meilleure rétention au milieu (mais pas parfait)
Peut tenir plus longtemps avant compaction
Même principe : ne pas dépasser 60% pour du code complexe

Codex GPT-5.5

Caractéristique	Valeur
Contexte annoncé	1M
Capacité effective	~600K
Degradation onset	~600K (60%)
Force	Énorme fenêtre, bon pour gros codebases
Faiblesse	Moins précis sur le raisonnement profond

Stratégie recommandée

budget_allocation:
  system_prompt: 8%       # GPT-5.5 préfère prompts concis
  tool_definitions: 15%   # Moins de tools = mieux
  message_history: 35%    # Peut tenir plus longtemps
  retrieved_documents: 27%
  tool_outputs: 10%
  buffer: 5%

compaction_trigger: 75%   # Plus tolérant
workflow: plan-implement  # Research optionnel pour tâches simples
subagents: Moins souvent   # Grande fenêtre = moins besoin

Astuce spécifique

GPT-5.5 est moins sensible au placement (courbe U moins prononcée)
Mais attention : plus de contexte = plus de bruit
Préférer la qualité à la quantité même avec 1M

Tableau comparatif

Critère	Claude 4.7 Opus	Claude 4.8 Opus	Codex GPT-5.5
Fenêtre effective	~120K	~150K	~600K
Trigger compaction	65%	70%	75%
Courbe U	Forte	Modérée	Faible
Coût relatif	Élevé	Très élevé	Moyen
Précision code	Très haute	Très haute	Haute
Besoin de subagents	Élevé	Élevé	Modéré
Format préféré	XML tags	XML tags	Markdown simple

Règles transversales

Quel que soit le modèle :

Ne jamais dépasser 60% pour du code complexe
Compacter à 70% pour du code simple
Placer les contraintes au début ET à la fin
Mesurer les tokens-per-task, pas tokens-per-request
Review humain sur research et plan

Checklist de validation

Je connais la capacité effective de chaque modèle
Je connais le trigger de compaction adapté
Je sais quel format de prompt privilégier
J’ai ajusté mon budget selon le modèle
Je ne change pas de modèle mid-session sans re-compacter

Penser que GPT-5.5 avec 1M résout tous les problèmes de contexte. → Une fenêtre de 1M ne supprime pas la dégradation, elle la retarde. À 600K tokens, GPT-5.5 dégrade aussi. Et traiter 600K tokens coûte exponentiellement plus cher que 200K. Le principe reste le même : curation > quantité.

Prochaine étape

→ Module 10 (Playbooks et seuils de production) pour les templates copier-coller