FONDAMENTAUX · GUIDE 02 · LECTURE ~7 MIN · WILLIAM LEEMANS
Tokens, fenêtres et attention
Trois notions mécaniques suffisent à expliquer la plupart des comportements déroutants d’un agent : le token (l’unité que vous payez), la fenêtre (la limite dure), l’attention (la ressource qui se dilue).
Je les pose ici sans mathématiques, mais avec leurs conséquences économiques et pratiques. Et elles n’ont rien de théorique.
Le token : l’unité que vous payez
Le modèle ne voit ni caractères ni mots : il voit des tokens, des fragments de texte issus d’un découpage statistique appris sur le corpus. En ordre de grandeur, un token vaut trois quarts d’un mot anglais. Le français, moins représenté dans les corpus, se découpe un peu moins efficacement : comptez 10 à 20 % de tokens en plus qu’en anglais pour le même texte. Le code se découpe bien (les identifiants fréquents deviennent des tokens entiers). Les sorties verbeuses comme les logs, le JSON ou les stack traces, beaucoup moins bien. Et ça coûte cher.
Trois conséquences directes :
- La facturation et les limites sont en tokens, entrée et sortie. Savoir estimer un volume en tokens, c’est savoir estimer le coût d’un workflow.
- Le modèle raisonne mal sous le niveau du token. Compter les lettres d’un mot ou manipuler des chaînes caractère par caractère lui est étrangement difficile : il ne voit littéralement pas les caractères.
- Tout ce qui entre dans la session se paye à chaque tour (on y revient plus bas). Le fichier de 2 000 lignes ouvert « au cas où » n’est pas gratuit.
La fenêtre : une limite dure, pas une promesse
La fenêtre de contexte, c’est le nombre maximal de tokens que le modèle peut recevoir en une fois. C’est une limite architecturale dure : au-delà, ça ne « déborde » pas élégamment. Votre outillage tronque, résume ou échoue.
La nuance que le marketing omet : la fenêtre annoncée est une capacité, pas une performance. Un modèle qui accepte un million de tokens ne les exploite pas tous également bien. La fenêtre utile (celle où le rappel reste fiable) est plus petite que la fenêtre nominale, et elle dépend de la tâche. Retrouver un fait précis dans un long document fonctionne bien. Raisonner en croisant des informations dispersées dans tout le contexte se dégrade beaucoup plus vite.
Le tips Craftomancer
Ne dimensionnez jamais un workflow sur la fenêtre annoncée. « Ça tient dans le contexte » et « le modèle s’en sert correctement » sont deux propriétés différentes. La première se lit dans la fiche produit, la seconde se mesure sur votre tâche.
La zone utile est la même en absolu (~100 000 tokens) dans les deux cas. Doubler, décupler la fenêtre annoncée n’élargit pas le smart zone : ça allonge surtout le "dumb zone". « Annoncer 1M de contexte, c’est souvent livrer plus de dumb zone. »
L’attention : la ressource qui se dilue
Pour produire chaque token, le modèle met en relation l’ensemble des tokens de la fenêtre et pondère leur influence : c’est l’attention. Elle est recalculée à chaque token produit, et c’est une ressource en compétition. Plus il y a de tokens candidats, moins chacun pèse.
Deux régularités empiriques à connaître :
- La position compte. Le début et la fin du contexte sont mieux exploités que le milieu, le fameux lost in the middle. Les instructions importantes noyées au milieu d’un long historique sont les premières sacrifiées.
- Le bruit coûte. Une information non pertinente ne se contente pas d’occuper de la place : elle entre en compétition avec les informations pertinentes. Un contexte deux fois plus gros n’est pas deux fois mieux informé. Il est souvent moins bien lu.
C’est la base mécanique du guide suivant : le contexte n’est pas un sac à remplir, c’est un budget d’attention à allouer.
Le coût réel d’une session d’agent
La boucle d’inférence n’a pas de mémoire, donc tout le contexte est renvoyé à chaque tour : instructions, historique, fichiers, résultats d’outils. Une session d’agent de cinquante tours ne coûte pas cinquante requêtes. Elle coûte cinquante fois un contexte qui grossit à chaque tour.
Les fournisseurs atténuent ça avec le cache de prompt : les préfixes déjà vus sont retraités à coût réduit, tant qu’ils sont strictement identiques et que le cache n’a pas expiré. D’où deux règles d’hygiène. La première : ce qui est stable (instructions, conventions) reste en tête de contexte et ne bouge pas. La seconde : ne pas laisser une session s’éterniser, car elle cumule vite les deux malus, le coût qui monte et l’attention qui se dilue. Repartir d’une session fraîche avec un contexte reconstruit est souvent plus efficace que de s’acharner.
En pratique
- Apprenez à estimer en ordre de grandeur : une page de texte ≈ 500 tokens, un fichier de 300 lignes de code ≈ 3 000 à 4 000 tokens. Ça suffit pour raisonner coût et fenêtre.
- Placez les instructions critiques au début ou à la fin du contexte, jamais noyées au milieu d’un historique.
- Traitez chaque ajout au contexte comme une dépense d’attention. Est-ce que ça aide la tâche en cours ? Sinon, ça lui nuit.
- Méfiez-vous des sessions interminables : coût croissant, attention décroissante. Reconstruire un contexte propre est une compétence, pas un aveu d’échec.
Vérifiez votre modèle
Quatre questions pour voir si la mécanique tient. Cliquez une réponse : le verdict s’affiche.
01 Vous collez 800 lignes de logs JSON dans le contexte « au cas où ». Côté coût, c’est…
02 Un modèle annonce une fenêtre d’un million de tokens. Vous pouvez donc…
03 Vos instructions critiques sont noyées au milieu d’un long historique. Le risque, c’est…
04 Pourquoi un contexte deux fois plus gros n’est-il pas deux fois mieux informé ?