SECTEUR · LA MACHINE · WILLIAM LEEMANS
Tokens, fenêtres et attention
Lecture ~7 min
Le modèle ne reçoit pas votre texte : il reçoit ce qu’un découpage en a fait.
Trois notions suffisent à expliquer la plupart des comportements déroutants d’un agent, et elles décident toutes de la même chose — ce que vous chargez dans la fenêtre. Le token, l’unité que le modèle lit et que vous payez. La fenêtre, la limite dure. L’attention, la ressource qui se dilue.
C’est quoi un token ?
Un fragment tiré d’un vocabulaire fini, fixé une fois pour toutes avant l’entraînement. Le modèle ne voit ni caractères ni mots : il voit ça. Et le découpage qui produit ces fragments a été appris sur un corpus, par fréquence — les suites de caractères qui revenaient souvent sont devenues des tokens entiers, les autres se brisent en morceaux plus petits, jusqu’à la lettre s’il le faut.
Ce n’est donc pas un découpage grammatical, et c’est la première chose à désapprendre. Les pièces ne sont ni des syllabes, ni des racines, ni des morphèmes : ce sont les fragments que le corpus a rendus fréquents. Un mot courant tient en une pièce ; un mot rare se paye morceau par morceau, quelle que soit sa structure. Le découpage ne connaît pas le français, il connaît ce qu’il a vu. On appelle ça un découpage en sous-mots — sous le mot, jamais dans sa grammaire.
Texte découpé : Le développeur aguerri délègue sans perdre le contrôle. Interdire cette délégation serait anticonstitutionnellement absurde : l'outil est déjà là, et il écrit du code.
Texte découpé : The seasoned developer delegates without losing control. Banning that delegation would be unconstitutionally absurd: the tool is already here, and it writes code.
Texte découpé : [ { "user_name": "Ada", "user_role": "developer" }, { "user_name": "Alan", "user_role": "reviewer" }, { "user_name": "Grace", "user_role": "developer" } ]
Une pièce jade est un morceau de mot : le vocabulaire ne contient pas ce mot entier. Un filet ambre marque un fragment déjà payé plus haut dans le même texte.
Même propos, presque le même nombre de signes (167 contre 162) : 44 tokens contre 30, soit 47 % de plus. Le mot le plus long n'y est pour rien — « anticonstitutionnellement » se brise en 5 pièces, « unconstitutionally » en 3 : 2 tokens sur les 14 d'écart. Le reste vient des mots ordinaires — « aguerri » coûte 3 pièces là où « seasoned » en vaut 1. Le bloc JSON, lui, tient en 19 fragments distincts, payés 54 fois.
Trois conséquences, et elles se prennent toutes avant d’envoyer quoi que ce soit.
- Le prix d’un texte suit sa représentation dans le corpus, pas sa longueur. L’anglais est la langue la moins chère parce que c’est la plus vue : la phrase ci-dessus coûte 44 tokens en français et 30 en anglais pour le même propos et presque autant de signes, soit 47 % de plus. Un ratio de phrase, pas une moyenne de corpus. Le code s’en tire bien : les identifiants et les mots-clés courants sont des tokens entiers. Ce qui s’en tire mal, c’est tout ce qui est fait pour la machine et jamais lu — logs, JSON, stack traces, UUID, hachages, chaînes encodées. Ils sont composés exactement de ce que le corpus n’a pas rendu fréquent, et une clé répétée mille fois se repaye mille fois : le bloc ci-dessus tient en 19 fragments distincts, payés 54 fois.
- Le modèle ne sait pas compter des lettres qu’il ne voit pas. Vérifier qu’un identifiant fait huit caractères, inverser une chaîne, compter les occurrences d’une lettre : ces demandes se posent sous son unité de perception. Il produira une réponse assurée, souvent fausse, et la reformuler n’y changera strictement rien. Ce genre de vérification se délègue à trois lignes de code, jamais au modèle.
- Estimer un volume en tokens, c’est estimer le coût d’un workflow. La facturation et les limites sont dans cette unité, à l’entrée comme à la sortie. Tant que vous raisonnez en lignes ou en fichiers, vous raisonnez dans la mauvaise.
Un ordre de grandeur suffit pour ça, et il se relève sur les deux amorces de l’Étape 1 : 61 caractères de Python pour 12 tokens, 133 pour 37 — soit trois à cinq caractères par token, sur du code, avec le tokeniseur de Qwen2.5-Coder-1.5B.
Retenez quatre. C’est le seul chiffre que j’ai en tête en session, et il suffit : un fichier de 300 lignes tourne autour de 3 000 tokens, et vous savez déjà si l’ouvrir « au cas où » est une dépense raisonnable. Le quatre vaut pour du code — la figure ci-dessus donne le même compteur ailleurs, près de cinq caractères et demi par token en anglais, moins de trois sur du JSON. Ce que ça donne sur une session entière, où le même contexte repart à chaque tour, est le sujet du coût et de la latence.
Une fenêtre d’un million de tokens, ça veut dire quoi ?
Que le modèle accepte un million de tokens en entrée. Rien de plus. La fenêtre de contexte, c’est le nombre maximal de tokens qu’il peut recevoir en une fois, et c’est une limite architecturale dure : au-delà, ça ne « déborde » pas élégamment. Votre outillage tronque, résume, ou échoue.
Mais 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 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.
Pourquoi un contexte plus gros n’est pas mieux informé ?
Parce que l’attention est une ressource en compétition. Pour produire chaque token, le modèle met en relation l’ensemble des tokens de la fenêtre et pondère leur influence — et ce calcul est refait à chaque token produit. Plus il y a de tokens candidats, moins chacun pèse.
J’aime bien l’image de la salle de réunion. À trois, tout le monde est entendu. À quarante, il faut crier pour exister, et les gens les plus utiles ne sont pas forcément ceux qui crient.
Cette dilution est ce qui borne la fenêtre utile de la section précédente, et la borne ne suit pas la fenêtre annoncée. Matt Pocock a nommé les deux parts : la smart zone, celle où le rappel tient, et la dumb zone, ce qui vient après — accepté en entrée, mal exploité. La figure ci-dessous les trace à la même échelle sur deux fenêtres nominales, et donne l’ordre de grandeur de la frontière avec ses sources.
D’où un critère de choix qui va contre l’intuition : deux modèles ne se comparent pas par leur fenêtre annoncée, puisque la décupler n’élargit pas la smart zone — elle allonge la dumb zone.
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 la smart zone : ça allonge surtout la dumb zone.
Deux régularités empiriques en découlent, et ce sont elles qui décident du rangement de votre contexte.
- La position compte. Le début et la fin sont mieux exploités que le milieu, le 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.
Ces deux régularités se constatent en session, et cette Étape ne dit pas d’où elles viennent. Elles sortent de la façon dont chaque token en interroge d’autres et pondère ce qu’ils lui apportent — « Ce que fait une couche » déroule ce mécanisme, et la dilution cesse alors d’être une régularité pour devenir une arithmétique.
C’est la base mécanique de l’Étape suivante : le contexte n’est pas un sac à remplir, c’est un budget d’attention à allouer.
En pratique
- Comptez en tokens, pas en fichiers. Quatre caractères par token sur du code suffit à décider si un ajout au contexte vaut sa place.
- Ne demandez jamais au modèle un travail au niveau du caractère. C’est du ressort d’un script, et le résultat sera juste.
- 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.
Comment le modèle choisit-il quoi regarder ?
Cette Étape décrit l’attention par ses effets : elle se dilue, la position compte, le bruit se paye. « Le modèle de bout en bout » ouvre le mécanisme dessous. Deux de ses sections reprennent exactement d’ici :
- Ce que fait une couche — ce qu’un token demande aux autres, ce qu’ils lui répondent, et pourquoi la réponse s’appauvrit quand ils sont plus nombreux.
- Pourquoi les empiler — la même opération répétée des dizaines de fois, et ce que chaque répétition ajoute.
Vérifiez votre modèle
Quatre questions pour voir si la mécanique tient. Cliquez une réponse : le verdict s’affiche.
jack in — choisissez votre réponse
Vous demandez à l’agent de vérifier que chaque identifiant du fichier fait bien huit caractères. Le résultat est douteux, parce que…
Un modèle annonce une fenêtre d’un million de tokens. Vous pouvez donc…
Vos instructions critiques sont noyées au milieu d’un long historique. Le risque, c’est…
Pourquoi un contexte deux fois plus gros n’est-il pas deux fois mieux informé ?