Comptage de tokens dans les LLM : pourquoi tout développeur doit le comprendre

Lorsque les développeurs commencent à travailler avec les API de grands modèles de langage, une question surgit presque immédiatement : « Quelle est la limite ? » Ils pensent en mots, en paragraphes ou en caractères — mais le modèle, lui, pense en tokens. Comprendre ce que sont les tokens, comment ils sont comptés et pourquoi ce comptage est important est l'une des choses les plus pratiquement utiles que vous puissiez apprendre avant de construire quoi que ce soit de sérieux par-dessus un LLM.

Vous pouvez utiliser le Compteur de tokens BrowseryTools — gratuit, sans inscription, tout reste dans votre navigateur — pour compter les tokens de n'importe quel texte avant de l'envoyer à une API.

Qu'est-ce qu'un token ? (Ni un mot, ni un caractère)

Un token est l'unité fondamentale de texte qu'un modèle de langage traite. Ce n'est pas un mot. Ce n'est pas un caractère. C'est un fragment de texte que le tokeniseur du modèle a appris à traiter comme une unité unique — et ce fragment peut aller d'un seul caractère à un fragment de mot ou à un mot courant complet.

Voici quelques exemples de la façon dont une phrase pourrait être découpée en tokens par un tokeniseur de la famille GPT :

"Hello, world!"
→ ["Hello", ",", " world", "!"]  — 4 tokens

"unbelievable"
→ ["un", "believ", "able"]  — 3 tokens

"ChatGPT"
→ ["Chat", "G", "PT"]  — 3 tokens

"2026-03-22"
→ ["2026", "-", "03", "-", "22"]  — 5 tokens

Notez comment les mots courts courants comme « Hello » correspondent à un seul token, tandis que les mots plus longs ou peu courants sont découpés en plusieurs tokens. La ponctuation, les chiffres et les caractères spéciaux sont souvent leurs propres tokens. Le tokeniseur ne se contente pas de découper sur les espaces ou la ponctuation — il utilise un vocabulaire appris d'unités sub-lexicales pour atteindre le meilleur équilibre entre taille du vocabulaire et efficacité de la représentation.

Comment fonctionnent les tokeniseurs : le Byte-Pair Encoding

La plupart des LLM modernes — GPT-4, Claude, Gemini, Llama — utilisent une variante du Byte-Pair Encoding (BPE) ou un algorithme étroitement lié appelé SentencePiece. Le BPE a été développé à l'origine pour la compression de données ; il a été adapté au traitement du langage naturel car il résout élégamment le problème du vocabulaire ouvert.

Le processus d'entraînement du BPE commence avec des caractères individuels (ou octets) comme vocabulaire de base. Il trouve ensuite de manière répétée la paire de symboles co-occurrente la plus fréquente dans le corpus d'entraînement et les fusionne en un nouveau symbole unique. Après des milliers de telles fusions, le vocabulaire résultant contient des mots courants comme tokens uniques, des préfixes et suffixes courants comme tokens, et des mots rares comme séquences de tokens plus petits. La taille finale du vocabulaire est généralement de 32 000 à 100 000 tokens.

Cela signifie que la tokenisation de n'importe quel texte dépend entièrement du vocabulaire spécifique avec lequel ce modèle a été entraîné. GPT-4, Claude et Gemini utilisent tous des tokeniseurs différents — le même texte peut donner des nombres de tokens différents sur chaque modèle. Ne supposez jamais qu'un nombre de tokens mesuré pour un modèle s'applique à un autre.

La règle des 750 mots pour 1 000 tokens

Vous verrez souvent citer l'approximation « 1 000 tokens ≈ 750 mots » pour les textes en anglais. C'est une heuristique raisonnable pour de la prose typique — articles de blog, articles, documentation. Elle découle de l'observation que dans un corpus anglais équilibré, la longueur moyenne d'un token est d'environ 4 à 5 caractères, et le mot anglais moyen fait environ 5 caractères plus un espace. Un mot correspond donc en moyenne à environ 1,3 token.

Mais « règle de base » est le bon cadrage — elle s'effondre rapidement en pratique :

• Le code se tokenise plus densément — Les langages de programmation utilisent beaucoup de mots-clés courts, d'opérateurs et d'identifiants qui sont souvent des tokens uniques. Un bloc Python peut se tokeniser en moins de tokens par caractère que de la prose anglaise.
• Les URL et les chaînes techniques sont coûteuses — Une longue URL comme https://api.example.com/v2/users/84219/preferences?include=notifications peut se tokeniser en plus de 20 tokens malgré une apparence courte à l'écran.
• Les nombres sont étonnamment coûteux — Chaque chiffre dans un long nombre est souvent un token séparé. Le nombre « 1738371600 » peut devenir 5 à 7 tokens.
• Les espaces et la mise en forme répétées — Le JSON avec indentation, les tableaux Markdown et le code profondément imbriqué ajoutent tous des tokens issus des espaces.

Langues non anglaises : arabe, chinois et la différence de coût en tokens

La règle des 750 mots pour 1 000 tokens est une heuristique pour l'anglais. Pour d'autres langues, le ratio peut être radicalement différent — et cela a des implications réelles en termes de coûts pour les applications multilingues.

L'arabe et l'hébreu utilisent une morphologie de radical et de schème, où un seul radical génère des dizaines de formes dérivées par préfixes, suffixes et changements vocaliques internes. Des mots comme « وسيستخدمونها » (ils l'utiliseront) sont des mots orthographiques uniques mais peuvent se tokeniser en 5 à 8 tokens car le vocabulaire BPE a été entraîné majoritairement sur des données anglaises et n'a pas ces formes arabes comme tokens uniques.

Le chinois et le japonais posent un défi différent. Les caractères sont logographiques — chaque caractère est une unité porteuse de sens — mais le vocabulaire de tokens couvre les caractères uniques courants et certains mots courants multi-caractères. Le texte chinois génère typiquement 1,5 à 2 fois plus de tokens par « équivalent de mot » que l'anglais. Le japonais, avec son mélange de hiragana, katakana et kanji, peut être encore plus élevé.

Une implication pratique : si vous construisez une application pour l'arabe, le chinois ou d'autres langues à écriture non latine, vos estimations de coûts basées sur des tests en anglais sous-estimeront significativement les coûts réels de l'API. Mesurez toujours les nombres de tokens avec votre contenu réel en utilisant le Compteur de tokens BrowseryTools ou une bibliothèque de tokenisation avant de faire des projections budgétaires.

Limites de la fenêtre de contexte : pourquoi les dépasser fait tout échouer

Chaque LLM a une fenêtre de contexte — le nombre maximum de tokens qu'il peut traiter dans une seule requête, comptant à la fois votre entrée et la sortie du modèle. Début 2026 :

• GPT-4o — 128 000 tokens
• Claude 3.5 Sonnet — 200 000 tokens
• Gemini 1.5 Pro — 1 000 000 tokens
• Llama 3.1 70B — 128 000 tokens

Si votre entrée dépasse la limite de la fenêtre de contexte, l'API retournera une erreur — la requête échoue purement et simplement. Il n'y a pas de dégradation gracieuse par défaut ; vous devez gérer cela dans la logique de votre application. Plus subtilement, même à l'intérieur de la fenêtre de contexte, il existe un phénomène appelé le problème du « perdu au milieu » : les modèles ont tendance à mieux rappeler les informations au début et à la fin de leur contexte que les informations enfouies au milieu. Une fenêtre de contexte de 200K ne signifie pas que chaque token qu'elle contient est traité de façon équivalente.

Pour les applications de chat, la fenêtre de contexte se remplit à mesure que les conversations s'allongent. Après suffisamment d'échanges, vous devez soit tronquer les anciens messages, les résumer, soit atteindre la limite et échouer. Connaître votre nombre de tokens à chaque étape est ce qui vous permet de prendre cette décision de manière proactive.

Implications pour la conception de prompts

La conscience des tokens change la façon dont vous rédigez vos prompts. Quelques implications concrètes :

• Les prompts système se cumulent sur chaque requête — Un prompt système de 500 tokens coûte 500 × votre nombre de requêtes × votre prix d'entrée. Sur 10 000 requêtes quotidiennes, réduire votre prompt système de 500 à 300 tokens génère de vraies économies chaque mois.
• Les exemples few-shot sont chers mais efficaces — Inclure 3 exemples dans votre prompt peut ajouter 300 à 500 tokens. Évaluez si cette amélioration de qualité vaut le coût par rapport à un fine-tuning unique du modèle.
• La longueur de sortie est contrôlable — Utilisez max_tokens pour plafonner la sortie du modèle. Ajoutez des instructions explicites dans votre prompt : « Répondez en moins de 100 mots. » Les modèles suivent généralement bien les instructions de longueur de sortie, ce qui réduit directement les coûts des tokens de sortie.
• Le formatage JSON ajoute de la surcharge — Si vous utilisez la sortie structurée (mode JSON), les guillemets, crochets et noms de clés ajoutent des tokens en plus de vos valeurs de données réelles. Une réponse avec 5 champs courts peut facilement représenter 40 % de tokens de formatage en surcharge.

Comptez vos tokens avant d'envoyer

La meilleure habitude à développer lorsqu'on travaille avec les API LLM est de compter vos tokens avant de vous engager sur une architecture ou de passer en production. Collez votre prompt système, un message utilisateur représentatif et tout contexte que vous prévoyez d'inclure dans le Compteur de tokens BrowseryTools. Vous verrez immédiatement si votre conception est bien dans les limites de la fenêtre de contexte ou dangereusement proche — et vous aurez les chiffres nécessaires pour estimer les coûts avec précision.