Anatomie d’un contexte

Le token comme unité de mesure

page2-tokenizer.png

Avant de parler de ce qu’on met dans un contexte, il faut comprendre de quoi il est constitué. Un LLM ne manipule ni des caractères ni des mots : il manipule des tokens, des fragments produits par un tokenizer. Le prompt, le code source qu’on lui montre, sa propre réponse sont ramenés à des tokens avant d’entrer dans le LLM. Le token est l’unité avec laquelle on mesure ce que manipule le modèle, et tout praticien doit avoir en tête trois grandeurs : la taille du contenu, son coût et sa latence.

La taille : En anglais, un token couvre environ quatre caractères, soit 0,75 mot. En français, le ratio se dégrade (accents, élisions, mots plus longs) et tombe autour de 3 caractères par token, soit 0,5 mot. Dans le code, c’est pire : un identifiant snake_case_un_peu_long peut éclater en cinq ou six tokens. Conséquence : un même texte coûte 30 à 50 % plus de tokens en français qu’en anglais, et un repo bien commenté pèse plus lourd qu’on ne croit.

Le coût : Un appel d’API facture séparément les tokens d’entrée (ce qu’on envoie) et les tokens de sortie (ce que le modèle produit), à des prix très différents : la sortie est typiquement quatre à cinq fois plus chère. Cette asymétrie inverse l’intuition courante : un gros contexte d’entrée coûte souvent moins qu’une réponse moyennement longue. Et dans le cas des modèles à raisonnement (extended thinking, reasoning tokens), une partie de la sortie reste invisible à l’utilisateur mais s’ajoute quand même à la facture.

La latence : Les modèles modernes génèrent 50 à 100 tokens par seconde. Une réponse de 4 000 tokens prend donc une quarantaine de secondes, indépendamment de son coût et de la taille du modèle. Le token est l’unité du temps perçu par l’utilisateur.

Sous le capot, chaque token traverse un pipeline en quatre temps : tokenisation, embeddings, transformer, unembedding (voir Annexe — Sous le capot : comment un LLM consomme un contexte).

De quoi est composé un contexte

« Context engineering = curating what the model sees so that you get a better result. » Martin Fowler — Context Engineering for Coding Agents

À chaque instant, l’agent travaille à partir d’une fenêtre limitée qui contient tout ce qu’il sait (c.f. le modèle mental de la fonction sans état. Cette fenêtre comporte deux flux :

Ces tokens d’entrée se rangent en cinq familles selon leur origine et leur durée de vie. Comprendre ce qui occupe cette fenêtre, et qui décide d’y mettre quoi, c’est la première discipline du context engineering.

context anatomy

Qui décide de charger et de prendre en compte le contexte ?

Trois acteurs se partagent cette responsabilité, chacun avec ses forces et ses angles morts :

Le bon design combine généralement les trois.

Combien de contexte ?

Le bon dosage, pas le maximum. Les fenêtres élargies ne sont pas une permission de tout déverser : l’efficacité d’un agent chute quand on le sature, et chaque token coûte. Compter qu’au-delà de 70 % de la fenêtre, la qualité décroche, et même bien avant si on mélange du contenu d’espaces sémantiques très différents.

D’où une règle simple : construire ses rules, skills et CLAUDE.md incrémentalement. Partir minimal, observer ce qui manque pour enfin ajouter, jamais l’inverse. Évaluer ses skills sérieusement : un benchmark à contexte et instruction identiques, avec et sans le skill, dit en quelques runs si l’ajout vaut son coût (voir agent-skills-eval pour automatiser).

La transparence aide : dans Claude Code, /context affiche qui occupe quoi dans la fenêtre. Mais une part de l’optimisation reste invisible comme la compaction d’historique, les outils de recherche, le progressive disclosure des skills.