Token : comprendre l'unité de base des modèles de langage

Ou : Pourquoi « anticonstitutionnellement » coûte plus cher que « chat » quand on parle à une IA

Vous savez compter les mots. Vous l’avez appris en primaire, et depuis, ça marche plutôt bien. Un mot, c’est un truc avec des espaces autour. « Le chat dort » : trois mots. Facile.

Les LLM ne comptent pas les mots. Ils comptent les tokens. Et un token, ce n’est pas un mot. Ce n’est pas une syllabe non plus. Ce n’est pas un caractère. C’est un morceau de texte dont la taille dépend de la fréquence à laquelle il apparaît dans les données d’entraînement. « Chat » est un token. « Anti » est un token. « constitution » est un token. « nellement » est un token. Trois tokens pour un seul mot, parce que « anticonstitutionnellement » n’apparaît pas assez souvent pour mériter son propre jeton.

C’est comme si vous deviez payer un livreur au nombre de colis, sauf que chaque colis peut contenir un mot entier ou un seizième de mot, selon une logique que personne ne vous a expliquée.

Tokenization, BPE et vocabulaire : comment les modèles découpent le texte

D’accord, mais concrètement, c’est quoi un token ?

Un token est l’unité atomique de texte que manipule un modèle de langage. Quand vous envoyez « Bonjour, comment allez-vous ? » à Claude ou ChatGPT, le modèle ne voit pas huit mots. Il voit une séquence de tokens — des identifiants numériques qui correspondent chacun à un fragment de texte dans son vocabulaire.

Le vocabulaire, c’est le dictionnaire du modèle. Pas un dictionnaire au sens du Larousse — un tableau de correspondance entre des morceaux de texte et des nombres. Le tokenizer de GPT-4 (cl100k_base) a un vocabulaire d’environ 100 000 tokens. LLaMA 2 en avait 32 000, LLaMA 3 est monté à 128 000. Chaque entrée peut être un mot entier (« bonjour »), un bout de mot (« tion »), un caractère isolé (« ç »), ou même un symbole (« \n »).

La question évidente : comment décide-t-on quels morceaux de texte méritent d’être dans le vocabulaire ?

Le BPE, ou comment un algorithme de compression des années 90 a conquis le NLP

La réponse s’appelle BPE — Byte Pair Encoding. L’algorithme a été inventé par Philip Gage en 1994 comme méthode de compression de données. Personne n’imaginait qu’il finirait par être la fondation de la tokenization dans les modèles de langage modernes¹.

Le principe est élégant dans sa simplicité :

1. On commence avec un vocabulaire minimal : tous les caractères individuels (a, b, c, …, z, à, é, …)
2. On parcourt un immense corpus de texte et on compte les paires de caractères adjacents les plus fréquentes
3. On fusionne la paire la plus fréquente en un nouveau token
4. On répète jusqu’à atteindre la taille de vocabulaire voulue

Concrètement, si « th » apparaît très souvent en anglais, le BPE va créer le token « th ». Puis « the » si « th » + « e » est fréquent. Puis « the\s » (le mot « the » suivi d’un espace). Et ainsi de suite. Les mots courants finissent par être un seul token. Les mots rares sont découpés en morceaux.

C’est un algorithme glouton. Il ne cherche pas la solution optimale — il fusionne les paires une par une, dans l’ordre de fréquence. Et pourtant, le résultat est remarquablement bon. Les mots que vous utilisez tous les jours tiennent en un token. Les mots que vous utilisez une fois par an sont découpés en trois ou quatre morceaux. L’algorithme a naturellement appris une version rudimentaire de la morphologie sans qu’on lui explique quoi que ce soit sur les langues.

BPE n’est pas seul

Il existe d’autres algorithmes de tokenization. WordPiece, développé pour Google et utilisé par BERT, fonctionne de façon similaire au BPE mais utilise un critère de vraisemblance plutôt que la fréquence brute pour décider quelles paires fusionner. SentencePiece, de Google également, traite le texte comme une séquence brute d’octets — pas besoin de pré-découper en mots, ce qui est particulièrement utile pour les langues sans espaces entre les mots (chinois, japonais, thaï).

En pratique, tous ces algorithmes produisent des résultats assez similaires pour les cas courants. Les différences émergent dans les cas limites : langues rares, émojis, code source, caractères spéciaux.

Pourquoi des vocabulaires de tailles aussi différentes ? C’est un compromis fondamental. Un vocabulaire plus grand signifie une meilleure compression du texte (moins de tokens par phrase), mais aussi un modèle plus lourd (la couche d’embedding doit stocker un vecteur pour chaque token du vocabulaire). Un vocabulaire plus petit est plus léger, mais découpe davantage les mots — ce qui ralentit l’inférence, puisque le modèle doit prédire plus de tokens pour dire la même chose. C’est le genre de décision d’ingénierie qui ne passionne personne jusqu’au jour où votre modèle découpe un émoji drapeau en six tokens et que votre facture d’API explose.

Le ratio tokens/mots : la surprise linguistique

Voici la partie qui rend les francophones légèrement amers.

En anglais, un token correspond à environ 0,75 mot — ou, dit autrement, un mot anglais moyen fait environ 1,3 token. La phrase « The cat sat on the mat » fait 6 tokens pour 6 mots². C’est presque un ratio 1:1. La vie est belle.

En français, c’est moins rose. Notre grammaire est plus complexe, nos mots sont plus longs, nos accents ajoutent des caractères, et nos conjugaisons sont un cauchemar. Le ratio tourne plutôt autour de 1 mot ≈ 1,5 à 1,8 token. « Anticonstitutionnellement » fait 3-4 tokens à lui seul. « Aujourd’hui » en fait 2 ou 3 (l’apostrophe ne simplifie rien). Le même prompt coûte mécaniquement 20 à 40% plus cher en français qu’en anglais.

Et en chinois, en japonais, en arabe ? C’est encore pire. Les tokenizers sont principalement entraînés sur des corpus anglophones, ce qui signifie que l’anglais bénéficie de la meilleure compression. Les langues sous-représentées dans les données d’entraînement paient un surcoût en tokens. C’est un biais structurel rarement discuté.

Compter les tokens : pourquoi c’est important

Les tokens sont la monnaie des LLM. Tout se compte en tokens :

La facturation. Les fournisseurs d’API facturent au million de tokens. Les prix varient selon le modèle et la direction (entrée vs sortie). Les tokens de sortie coûtent généralement 3 à 5 fois plus cher que les tokens d’entrée — logique : le modèle travaille plus pour générer que pour lire.

La fenêtre de contexte. La fenêtre de contexte d’un modèle — la quantité maximale de texte qu’il peut « voir » en même temps — se mesure en tokens. Claude offre jusqu’à un million de tokens sur certains modèles. GPT-4 Turbo monte à 128 000. Ces chiffres incluent tout : le prompt système, l’historique de conversation, les documents injectés, et la réponse du modèle.

La vitesse. Les métriques de performance se mesurent en tokens par seconde (TPS). Un modèle qui génère 100 TPS sur un texte courant peut tomber à 60 TPS sur du code complexe, parce que les tokens de code sont plus courts et les calculs par token restent constants.

Le token dans tous ses états

Il y a une ironie dans le mot « token » lui-même. En anglais, token signifie « jeton » — un objet qui représente une valeur sans la contenir directement. Un jeton de casino n’est pas de l’argent. Un jeton de métro n’est pas un trajet. Un token de LLM n’est pas un mot. Mais dans chaque cas, c’est l’unité d’échange du système.

Et cette ambiguïté se retrouve dans l’informatique au sens large. Si vous lisez des articles sur la sécurité des API REST, vous tomberez sur des « tokens d’authentification » — des JWT, des OAuth tokens, des API keys. Ces tokens-là n’ont rien à voir avec la tokenization des LLM. Ce sont des jetons cryptographiques qui prouvent votre identité. Quand un article de sécurité parle de « tokens volés »³, il ne parle pas de morceaux de mots — il parle de clés d’accès compromises.

Deux sens du même mot, deux mondes différents. Le contexte est tout. Ce qui est, quand on y pense, exactement ce qu’un LLM essaie de comprendre.

Les tokens spéciaux : la signalisation invisible

En plus des tokens de texte, les modèles utilisent des tokens spéciaux — des signaux de contrôle qui ne correspondent à aucun texte lisible. Les plus courants :

• <BOS> / <EOS> (Beginning/End of Sequence) : marquent le début et la fin d’un texte
• <PAD> : remplissage pour aligner des séquences de longueurs différentes dans un batch
• <UNK> : le token « je ne connais pas ce caractère » — de plus en plus rare avec les tokenizers modernes qui gèrent l’UTF-8 au niveau des octets
• Tokens de rôle : dans les modèles de chat, des tokens spéciaux délimitent les messages système, utilisateur, et assistant

Vous ne les voyez jamais. Mais ils sont là, dans chaque requête, et ils comptent dans votre fenêtre de contexte. C’est la signalisation routière du texte : invisible pour le passager, indispensable pour le conducteur.

Implications pratiques : ce que ça change pour vous

Si vous utilisez un LLM via une interface (Claude, ChatGPT, Copilot), la tokenization est transparente. Vous tapez du texte, le modèle répond, la magie opère. Le seul moment où les tokens deviennent visibles, c’est quand vous atteignez la limite de la fenêtre de contexte et que le modèle commence à « oublier » le début de votre conversation.

Si vous développez avec une API de LLM, les tokens deviennent votre obsession quotidienne :

• Optimiser les prompts pour dire la même chose en moins de tokens (chaque token d’entrée a un coût)
• Gérer la fenêtre de contexte en décidant quoi inclure et quoi élaguer dans l’historique de conversation
• Estimer les coûts avant de lancer un batch de 10 000 requêtes (multiplier le nombre moyen de tokens par le prix unitaire, puis ajouter 20% de marge parce que les estimations sont toujours optimistes)
• Choisir le bon modèle : un modèle plus petit avec un vocabulaire plus compact peut être plus rentable pour des tâches simples

Si vous faites du RAG (Retrieval-Augmented Generation), les tokens deviennent un budget. Chaque document injecté dans le prompt consomme des tokens. Si votre base de connaissances contient 500 documents et que vous en injectez 10 par requête, le coût de l’injection dépasse souvent le coût de la question elle-même.

Le dialogue de la facturation

DevOps Dave : J’ai mis en prod le chatbot support. Ça marche du tonnerre.

Security Sarah : Combien de tokens par requête en moyenne ?

DevOps Dave : Aucune idée. On a un prompt système de 3 000 tokens, on injecte les 5 derniers messages de conversation, et on fait du RAG avec 3 documents.

Security Sarah : Donc à la louche… 3 000 tokens système, plus ~2 000 de conversation, plus ~4 000 de documents RAG, plus la réponse. Tu es à 10-12 000 tokens par requête. À 1 000 requêtes par jour, ça fait 10-12 millions de tokens quotidiens.

DevOps Dave : …

Security Sarah : Tu avais budgété combien ?

DevOps Dave : J’avais budgété « pas beaucoup, c’est du texte ».

Tableau récapitulatif

Le mot de la fin

Le token est le pixel du texte. Trop petit pour signifier quoi que ce soit seul. Trop fondamental pour être ignoré. Chaque mot que vous envoyez à un LLM est découpé en tokens, chaque token est converti en nombre, chaque nombre traverse des milliards de paramètres, et à l’autre bout sort un nouveau token, qui est reconverti en texte, et qui donne l’illusion que quelqu’un vous a compris.

Toute cette infrastructure — les tokenizers, le BPE, les vocabulaires, les fenêtres de contexte — existe pour résoudre un problème que les humains ne se posent jamais : comment transformer du texte en nombres. C’est le genre de problème qui semble trivial jusqu’à ce que vous réalisiez que « 🤦‍♂️ » fait quatre tokens et que « cat » en fait un, et que cette asymétrie a des conséquences économiques réelles à l’échelle de milliards de requêtes par jour.

La prochaine fois qu’un modèle de langage vous facture plus cher pour une phrase en français qu’en anglais, vous saurez pourquoi. Et la prochaine fois que quelqu’un vous dit « c’est juste un détail technique », vous saurez que les détails techniques sont ceux qui déterminent la facture.