Que sont les tokens d'un LLM ? Explication simple

Un token est l'unité de texte de base qu'un grand modèle de langage (LLM) lit et produit. Avant que le modèle ne voie votre prompt, le texte est découpé en tokens : les mots courants forment souvent un seul token, les mots plus longs ou plus rares sont découpés en plusieurs morceaux, et les espaces, la ponctuation et les nombres sont eux aussi des tokens ou des parties de tokens. En anglais courant, un token correspond à environ quatre caractères ou trois quarts de mot. Les tokens comptent en pratique car ils déterminent le coût d'une requête, la quantité de texte qui tient dans la fenêtre de contexte du modèle et le temps nécessaire pour générer une réponse.

Pourquoi les modèles utilisent des tokens plutôt que des mots ou des lettres

Un modèle a besoin d'un vocabulaire fixe d'unités qu'il peut représenter en interne. Des mots entiers exigeraient un vocabulaire énorme et échoueraient malgré tout face aux mots nouveaux, aux noms et aux fautes de frappe. Des caractères isolés transformeraient les textes en séquences très longues et ralentiraient tout.

Les tokens sont le compromis. Un tokenizer apprend, sur de grandes quantités de texte, quelles suites de caractères reviennent souvent et en fait des entrées de vocabulaire. Les mots fréquents deviennent un seul token. Les mots moins fréquents sont assemblés à partir de morceaux plus petits. Le modèle peut ainsi représenter n'importe quel texte, même des mots inventés, tout en gardant le texte courant compact.

Chaque famille de modèles a son propre tokenizer : une même phrase peut donc produire un nombre de tokens différent selon le modèle. C'est pourquoi les décomptes exacts doivent toujours venir du tokenizer du modèle que vous utilisez réellement.

À quoi ressemble la tokenisation

Le découpage exact dépend du tokenizer, mais un schéma typique ressemble à ceci (illustration, pas la sortie d'un modèle précis) :

Texte	Tokens possibles	Nombre
The invoice is due	The invoice is due	4
Unbelievably	Un believ ably	3
2026-10-04	202 6 - 10 - 04	6
Kundenzufriedenheit	K unden zuf ried enheit	5

Quelques constats :

• L'espace qui précède fait souvent partie du token. « invoice » précédé d'un espace est un autre token que « invoice » en début de ligne.
• Les mots longs sont découpés. C'est particulièrement fréquent dans les langues à mots composés.
• Nombres et dates peuvent coûter étonnamment cher. Les chiffres sont souvent regroupés en petits blocs.

Les règles empiriques pour estimer les tokens

Pour une estimation rapide, ces règles approximatives suffisent à planifier :

Contenu	Estimation approximative
Prose anglaise	1 token ≈ 4 caractères ≈ 0,75 mot
1 000 mots anglais	environ 1 300 à 1 400 tokens
Une page de texte anglais (environ 500 mots)	environ 650 à 700 tokens
Allemand, français, espagnol	souvent nettement plus de tokens que le même contenu en anglais
Code source, JSON, tableaux	souvent plus de tokens par caractère que la prose, à cause des symboles et des espaces
Langues à écriture non latine	parfois beaucoup plus, selon le tokenizer

Ce sont des estimations : pour un budget, mesurez de vrais échantillons. Le calculateur de coût d'API LLM comprend un estimateur rapide : collez un prompt ou une réponse typique et il donne un nombre approximatif de tokens à reporter dans le calcul des coûts.

Tokens d'entrée et tokens de sortie

Chaque requête comporte deux décomptes :

• Tokens d'entrée : tout ce que vous envoyez, c'est-à-dire le prompt système, les tours précédents, les documents insérés, les définitions d'outils et le message de l'utilisateur.
• Tokens de sortie : tout ce que le modèle génère en réponse. Certains modèles produisent aussi des tokens de raisonnement internes avant la réponse visible, qui peuvent être facturés comme sortie.

La distinction compte car la plupart des fournisseurs les tarifient différemment, la sortie étant généralement plus chère par token. Notre article sur la tarification des API LLM montre, exemple chiffré à l'appui, comment les deux composent votre facture.

La fenêtre de contexte : les tokens comme capacité

La fenêtre de contexte est le nombre maximal de tokens qu'un modèle peut prendre en compte dans une requête, entrée et sortie confondues. Si un modèle a par exemple une fenêtre de 128 000 tokens, votre prompt et la réponse doivent y tenir ensemble.

En pratique :

• Les longs documents peuvent ne pas tenir. Un gros ensemble de contrats ou un long fil d'e-mails peut dépasser la fenêtre.
• Les conversations ont une mémoire limitée. Dans un long échange, les tours anciens finissent par devoir être supprimés ou résumés.
• Une grande fenêtre n'est pas gratuite. Chaque token envoyé coûte de l'argent et du temps. Envoyer tout un manuel quand une seule section est utile est du gaspillage.
• Plus de contexte n'est pas toujours mieux. Les modèles peuvent manquer des détails enfouis dans des entrées très longues. Un contexte ciblé donne généralement des réponses plus fiables.

Quand les documents sont trop volumineux ou trop nombreux, la solution habituelle est la récupération : rechercher d'abord les passages pertinents et n'envoyer que ceux-là. Notre comparatif RAG ou fine-tuning explique comment cela fonctionne.

Tokens et rapidité

Les modèles génèrent la sortie un token à la fois. Deux conséquences pratiques :

1. Les réponses longues prennent plus de temps. Si les utilisateurs attendent, demander des réponses concises améliore l'expérience.
2. Les entrées longues ajoutent aussi du délai. Traiter un très long prompt prend du temps avant l'apparition du premier token de sortie, même si c'est généralement moins par token que la génération.

Application lente ? Vérifiez les tokens avant de changer de fournisseur.

Pourquoi le même contenu peut coûter plus cher dans d'autres langues

Les tokenizers sont entraînés sur de grandes collections de textes où l'anglais est généralement bien représenté. Le texte anglais est donc souvent tokenisé efficacement, alors que d'autres langues peuvent exiger plus de tokens pour le même sens. Les langues riches en mots composés comme l'allemand, ou à flexion riche, peuvent coûter nettement plus par phrase.

Pour une entreprise qui travaille en plusieurs langues, cela a deux implications :

• Budgéter par langue. Un assistant support qui répond en français peut consommer plus de tokens par conversation que le même assistant en anglais.
• Tester avec de vrais contenus locaux. N'extrapolez pas à partir d'échantillons anglais.

Exemple chiffré : des mots au coût

Prenons un assistant interne qui résume des rapports. Tous les chiffres sont des hypothèses d'exemple.

• Longueur du rapport : 3 000 mots anglais, soit environ 4 000 tokens.
• Instructions : 300 tokens.
• Résumé : 250 mots, soit environ 330 tokens.
• Volume : 400 rapports par mois.

Entrée par requête : environ 4 300 tokens. Sortie : environ 330 tokens.

Avec des prix d'exemple de 1,00 € par million de tokens d'entrée et 4,00 € par million de tokens de sortie :

• Entrée : 4 300 × 1,00 € ÷ 1 000 000 = 0,0043 €
• Sortie : 330 × 4,00 € ÷ 1 000 000 = 0,00132 €
• Par rapport : environ 0,0056 €
• Par mois : environ 2,25 €

Le coût est faible ici, mais le même calcul appliqué à un chat client à fort volume, ou à un agent qui multiplie les appels par tâche, atteint vite des montants plus importants. D'où l'intérêt de mesurer les tokens tôt. Pour réduire leur nombre, voir notre article pour réduire les coûts d'API LLM.

Compter précisément les tokens

• Outils des fournisseurs : la plupart proposent un tokenizer, un point d'accès de comptage ou un environnement de test affichant les décomptes.
• Réponses de l'API : chaque réponse inclut généralement le nombre de tokens d'entrée et de sortie utilisés. Les journaliser est le moyen le plus fiable de connaître votre consommation réelle.
• Bibliothèques open source : pour certaines familles de modèles, le tokenizer existe sous forme de bibliothèque exécutable en local.

Pour planifier, les règles empiriques suffisent ; pour budgéter et suivre, les vrais décomptes.

Les idées reçues

• « Un token, c'est un mot. » Souvent, pas toujours. Beaucoup de mots valent plusieurs tokens, et espaces et ponctuation comptent.
• « Seule ma question compte. » Prompts système, historique et documents comptent comme entrée à chaque requête.
• « Une plus grande fenêtre de contexte règle tout. » Elle augmente la capacité, pas la précision, et fait monter le coût quand on l'utilise.
• « Le nombre de tokens est identique d'un modèle à l'autre. » Chaque tokenizer est différent.
• « Un prompt plus court est toujours meilleur. » Supprimer du contexte nécessaire économise des tokens mais peut coûter plus en mauvais résultats et corrections.

L'essentiel à retenir

Les tokens sont la monnaie des LLM : ils fixent le prix, la capacité et la rapidité. Estimez avec des règles empiriques, mesurez avec de vrais échantillons, et souvenez-vous que l'entrée inclut tout ce que vous envoyez, pas seulement les mots de l'utilisateur. Pour voir ce que coûteraient vos propres volumes, essayez le calculateur de coût d'API LLM, et lisez notre article sur la tarification des API LLM pour une vue complète de la facturation.