Aller au contenu principal
Débutant10 min

Module 1 — La fenêtre de contexte : mythes et réalités


Objectif

À la fin de ce module, tu sauras pourquoi un modèle avec 200K tokens de contexte ne peut pas réellement utiliser 200K tokens. Tu arrêteras de croire la taille annoncée.

@diagram:context-engineering

Le mythe de la taille nominale

Les vendeurs annoncent des chiffres impressionnants :

Modèle Taille annoncée Capacité effective réelle
Claude 3.5 Sonnet 200K ~120K
Claude 4.7 Opus 200K ~120K
Claude 4.8 Opus 256K ~150K
GPT-4o 128K ~80K
Codex GPT-5.5 1M ~600K

Pourquoi cet écart ? Parce que la taille annoncée est une limite physique (nombre de tokens que le modèle peut recevoir), pas une garantie de performance. Au-delà de 60-70% de cette limite, la qualité de réponse dégrade de façon prévisible et mesurable.


La courbe de dégradation

La performance ne baisse pas progressivement. Elle reste stable, puis chute brutalement :

100% ┤                              ╭──────
 80% ┤                         ╭────╯
 60% ┤                    ╭────╯
 40% ┤               ╭────╯
 20% ┤          ╭────╯
  0% ┼────╮╭────╯
     0K   60K  100K  150K  200K

    Début de la dégradation

Benchmark RULER : seulement 50% des modèles annonçant 32K+ maintiennent des performances satisfaisantes à cette longueur.


Pourquoi ça dégrade ?

1. Mécanique d’attention

Pour n tokens, le mécanisme d’attention calcule n² relations par paires. Plus le contexte grandit, plus le modèle peine à maintenir ces relations.

2. “Lost in the middle”

L’information placée au milieu du contexte subit 10-40% de perte de recall par rapport aux bords. C’est pas un bug, c’est une conséquence de la mécanique d’attention (Liu et al., 2023).

3. Position encoding

L’interpolation des encodages de position au-delà des longueurs d’entraînement réduit la précision positionnelle.


Le vrai budget

Geoff Huntley résume bien :

“Tu as environ 170K de context window réellement utilisable. Plus tu utilises la fenêtre, plus les résultats empirent.”

Règle d’or : Ne jamais dépasser 60-70% de la taille annoncée pour des tâches complexes. Pour du code review ou de la recherche dans un codebase, viser 40-50%.


Test rapide

Dans Claude Code, regarde l’indicateur de contexte en bas de l’écran :

# Vérifier l'utilisation actuelle
/claude context

Si tu dépasses 70%, c’est le moment de compacter. Pas après.


Checklist de validation

  • Je connais la différence entre taille nominale et capacité effective
  • Je sais que la dégradation commence à 60-70%
  • Je connais les 3 causes de dégradation (attention, lost-in-middle, position encoding)
  • Je vérifie mon utilisation de contexte régulièrement

Piège courant

Croire que “plus de contexte = mieux”. → Un contexte de 400K coûte exponentiellement plus cher (temps + compute) qu’un contexte de 200K. Et la qualité est pire. Mieux vaut un contexte de 80K bien curré qu’un contexte de 200K bourré de bruit.


Prochaine étape

→ Module 2 (Anatomie du contexte) pour savoir ce qui mange tes tokens