Accueil › Glossaire › Tokenization

Tokenization : comment les modèles de langage découpent le texte

La tokenization (ou tokenisation) est le processus qui découpe un texte brut en unités plus petites appelées « tokens » (mots, sous-mots, caractères ou octets) pour permettre aux modèles de langage comme GPT, Claude ou Gemini de le traiter numériquement. C’est la toute première étape du pipeline de tout LLM : sans tokenization, le modèle ne peut rien lire.

Si vous avez déjà utilisé un LLM et remarqué que certaines réponses sont coupées à une « limite de tokens », ou que les prix des API sont facturés en tokens, vous avez déjà croisé ce concept. Un token n’est pas un mot : c’est l’unité fondamentale que le modèle traite. Comprendre la tokenization vous aide à optimiser vos prompts, à estimer les coûts d’API et à comprendre pourquoi les modèles se comportent parfois de façon surprenante sur certains textes.

Pourquoi la tokenization est essentielle

Les modèles de langage ne comprennent pas le texte. Ils comprennent des nombres. La tokenization est le pont entre le langage humain et les représentations numériques que le modèle manipule. Chaque token est associé à un identifiant numérique (token ID), qui est ensuite converti en un vecteur d’embeddings multidimensionnel. Ce vecteur est ce que le modèle traite réellement pour comprendre le sens, la grammaire et le contexte.

La façon dont le texte est découpé en tokens affecte directement la capacité du modèle à comprendre les relations sémantiques, l’efficacité computationnelle (moins de tokens = traitement plus rapide et moins cher), la taille de la fenêtre de contexte effective (un contexte de 128 000 tokens contient plus de texte si la tokenization est efficace) et la gestion des langues et des vocabulaires spécialisés.

C’est pour cela que la tokenization n’est pas un simple détail technique : c’est une décision architecturale qui impacte les performances, le coût et les capacités d’un modèle de langage.

Les quatre types de tokenization

Tokenization par mots (word-level)

L’approche la plus intuitive : chaque mot est un token. « J’aime le machine learning » devient [« J’aime », « le », « machine », « learning »]. Simple, mais problématique : le vocabulaire explose rapidement (des centaines de milliers de mots dans une seule langue), les mots inconnus (OOV, out-of-vocabulary) ne peuvent pas être traités, et les langues agglutinantes comme l’allemand ou le turc posent des problèmes avec leurs mots composés très longs.

Cette approche est désormais abandonnée dans les LLM modernes au profit des méthodes sous-mots.

Tokenization par sous-mots (subword)

C’est la méthode dominante en 2026. Le texte est découpé en unités intermédiaires entre le mot et le caractère. Les mots courants (« the », « de », « est ») restent des tokens uniques. Les mots rares ou inconnus sont décomposés en sous-mots reconnaissables. Par exemple, « unhappiness » peut être tokenisé en [« un », « happiness »], et « tokenization » en [« token », « ization »].

Les avantages sont considérables : le vocabulaire reste de taille gérable (30 000 à 200 000 tokens), les mots inconnus ne posent plus problème (ils sont décomposés en parties connues), et le modèle peut inférer le sens de mots jamais vus à partir de leurs composants.

Tokenization par caractères

Chaque caractère est un token. « Bonjour » → [« B », « o », « n », « j », « o », « u », « r »]. Le vocabulaire est minuscule (quelques dizaines de caractères), ce qui élimine tout risque d’OOV. Mais les séquences deviennent très longues, ce qui augmente le coût computationnel et rend l’apprentissage de dépendances à longue distance difficile. Cette approche est parfois utilisée pour les langues sans espaces (chinois, japonais) ou pour des tâches spécifiques (correction orthographique).

Tokenization par octets (byte-level)

Variante moderne où le vocabulaire de base est composé des 256 valeurs possibles d’un octet. Puisque tout texte en UTF-8 est une séquence d’octets, cette approche garantit qu’aucun caractère, aucun emoji et aucun symbole ne sera inconnu. C’est l’approche utilisée par GPT-2, GPT-3 et GPT-4 (byte-level BPE). Elle fonctionne nativement dans toutes les langues et tous les systèmes d’écriture.

Les algorithmes de tokenization

Byte-Pair Encoding (BPE)

BPE est l’algorithme de tokenization le plus utilisé dans les LLM modernes. Originalement un algorithme de compression de données (Gage, 1994), il a été adapté au NLP par Sennrich, Haddow et Birch en 2016.

Le fonctionnement est élégant. On commence avec un vocabulaire de base (tous les caractères ou tous les octets). On compte les paires de tokens adjacentes les plus fréquentes dans le corpus d’entraînement. On fusionne la paire la plus fréquente en un nouveau token. On répète jusqu’à atteindre la taille de vocabulaire désirée (typiquement 30 000 à 200 000).

Exemple simplifié : si le corpus contient beaucoup d’occurrences de la paire « e » + « r », BPE crée le token « er ». Puis « er » + « s » peut devenir « ers », etc. Après des milliers de fusions, les mots courants et les sous-mots significatifs émergent naturellement du processus statistique.

BPE est utilisé par les modèles GPT (OpenAI), RoBERTa, BART et de nombreux autres. ChatGPT utilise des variantes de BPE (cl100k_base pour GPT-4, o200k_base pour GPT-4o) avec des vocabulaires de 100 000 à 200 000 tokens.

WordPiece

Proposé par Google en 2016, WordPiece est similaire à BPE mais utilise une formule de vraisemblance (likelihood) plutôt que la fréquence brute pour décider quelles paires fusionner. La différence pratique : WordPiece tend à conserver les mots courants comme tokens uniques, tandis que BPE peut les décomposer. WordPiece préfixe les sous-mots internes avec « ## » pour indiquer qu’ils font partie d’un mot plus grand. C’est l’algorithme utilisé par BERT et ses variantes.

SentencePiece

Développé par Google, SentencePiece est un tokenizer « language-agnostic » qui traite les espaces comme des caractères normaux (au lieu de les utiliser comme séparateurs de mots). Cela le rend particulièrement adapté aux langues sans espaces (chinois, japonais, thaï) et au traitement multilingue. SentencePiece peut implémenter BPE ou Unigram comme algorithme sous-jacent. Il est utilisé par T5, Gemini, LLaMA et Mistral.

Unigram Language Model

Contrairement à BPE (approche bottom-up : fusion de paires), Unigram utilise une approche top-down. Il commence avec un très grand vocabulaire (tous les sous-mots possibles) et élague progressivement les tokens les moins utiles selon un score de log-vraisemblance. Le résultat est souvent plus probabiliste et mieux calibré que BPE, mais la différence de performance en pratique est minime.

Impact pratique de la tokenization

Coût des API et facturation en tokens

Les API de modèles de langage (OpenAI, Anthropic, Google) facturent à l’utilisation en tokens, pas en mots ni en caractères. Comprendre votre taux de tokenization est essentiel pour estimer vos coûts. Règle approximative : 1 token ≈ 4 caractères en anglais, soit environ 0,75 mot. En français, le ratio est plus défavorable (environ 0,5 mot par token) car les mots français sont en moyenne plus longs et la tokenization est optimisée pour l’anglais.

Concrètement, un texte de 1 000 mots en anglais consomme environ 1 300 tokens. Le même texte traduit en français peut consommer 1 800 à 2 000 tokens, soit 40 à 50 % de plus. C’est un facteur non négligeable pour les utilisateurs francophones des API.

Fenêtre de contexte

Quand un modèle annonce une fenêtre de 128 000 tokens, la quantité de texte que vous pouvez y placer dépend de l’efficacité de la tokenization. Un tokenizer plus efficace (comme les versions récentes d’OpenAI avec o200k_base) permet de « caser » plus de texte dans la même fenêtre. C’est un avantage concurrentiel discret mais significatif.

Glitch tokens et artefacts

Un phénomène documenté : certains tokens existent dans le vocabulaire du tokenizer (parce qu’ils étaient fréquents dans les données d’entraînement du tokenizer) mais sont rares dans les données d’entraînement du modèle lui-même. Le modèle n’a donc jamais appris ce que ces tokens signifient, et leurs embeddings contiennent des valeurs quasi-aléatoires. Le cas le plus célèbre est « SolidGoldMagikarp », un nom d’utilisateur Reddit qui avait son propre token dans GPT-3 mais provoquait des comportements erratiques quand il était utilisé dans un prompt.

Des recherches récentes (GlitchMiner, AAAI 2026) ont montré qu’environ 4,3 % des entrées de vocabulaire dans les modèles testés (GPT-4, LLaMA 2, Mistral, DeepSeek) sont des « glitch tokens ». C’est un problème actif de recherche.

Impact multilingue

La tokenization est souvent biaisée vers l’anglais. Les tokenizers entraînés principalement sur du texte anglais produisent des tokens plus longs (et donc plus efficaces) pour l’anglais et des tokens plus courts (moins efficaces) pour les autres langues. Cela signifie que le même contenu en hindi, arabe ou japonais peut consommer 2 à 4 fois plus de tokens qu’en anglais, augmentant proportionnellement le coût et réduisant la fenêtre de contexte effective.

Des approches comme SentencePiece avec un entraînement multilingue atténuent ce biais, mais ne l’éliminent pas complètement. Mistral et d’autres modèles français bénéficient d’une tokenization mieux calibrée pour le français.

Évolutions récentes (2025-2026)

SuperBPE (COLM 2025). Un BPE en deux passes qui apprend d’abord des tokens standard, puis des « super-tokens » inter-mots. Résultat : 33 % de tokens en moins et une amélioration moyenne de 4 % sur 30 benchmarks, simplement grâce à une meilleure tokenization.

BoundlessBPE (COLM 2025). Supprime la contrainte de pré-tokenization qui empêche les fusions entre mots, améliorant l’efficacité de 15 % en octets par token.

LiteToken (février 2026). Identifie et supprime les « résidus de fusion » : des tokens fréquents pendant l’entraînement du tokenizer mais rares dans le texte final tokenisé. Ces tokens gaspillent des slots de vocabulaire. LiteToken est compatible avec n’importe quel tokenizer existant.

Tokenization dynamique (ADAT, NeurIPS 2024). Ajuste itérativement le vocabulaire en fonction du feedback du modèle pendant l’entraînement, au lieu de figer la tokenization avant l’entraînement.

Ces travaux montrent que la tokenization, longtemps considérée comme un problème résolu, est redevenue un axe de recherche actif. Des améliorations significatives des performances des LLM peuvent être obtenues uniquement en optimisant la façon dont le texte est découpé, sans changer l’architecture du modèle ni augmenter sa taille.

Outils et librairies

Pour expérimenter avec la tokenization ou l’intégrer dans vos projets, voici les principales librairies :

Pour compter les tokens d’un texte avant de l’envoyer à une API, utilisez tiktoken (pour les modèles OpenAI) ou le tokenizer correspondant au modèle que vous utilisez via Hugging Face. Pour en savoir plus sur l’utilisation des API IA, consultez notre guide API IA pour débutants.

Exemple concret : comment GPT tokenise une phrase

Prenons la phrase « L’intelligence artificielle transforme le monde du travail. » et voyons comment un tokenizer BPE (type GPT-4) la traite :

Le tokenizer byte-level BPE commence par encoder chaque caractère en octets UTF-8. Puis il applique ses règles de fusion apprises. Le résultat typique ressemble à : [« L », « ‘ », « intelligence »,  » artificielle »,  » transforme »,  » le »,  » monde »,  » du »,  » travail », « . »]. Cela fait environ 10 tokens pour 7 mots. En anglais, la même phrase (« Artificial intelligence transforms the world of work. ») serait tokenisée en environ 7-8 tokens.

Cet écart illustre le biais anglophone de la tokenization. Le mot « artificielle » est plus long et moins fréquent dans le corpus d’entraînement que « artificial », donc il peut être découpé en davantage de sous-mots. Les accents, les apostrophes et les caractères spéciaux du français ajoutent aussi des tokens supplémentaires.

Pour visualiser comment votre texte est tokenisé, utilisez le Tokenizer d’OpenAI en ligne (platform.openai.com/tokenizer) : collez votre texte et chaque token apparaît dans une couleur différente. C’est un excellent outil pédagogique pour comprendre concrètement ce que « coût en tokens » signifie.

Verdict

La tokenization est la fondation invisible de tous les LLM. Chaque mot que vous tapez dans ChatGPT, Gemini ou Claude est d’abord découpé en tokens avant d’être traité. Comprendre ce processus n’est pas indispensable pour utiliser ces outils, mais c’est essentiel pour optimiser vos coûts d’API, comprendre les limites de contexte, et saisir pourquoi les modèles se comportent différemment selon les langues.

En 2026, la tokenization par sous-mots (BPE et ses variantes) domine, mais les recherches récentes (SuperBPE, LiteToken, tokenization dynamique) montrent que des gains significatifs restent possibles. C’est un domaine à surveiller pour quiconque travaille avec des LLM en production.

Avant de comprendre votre texte, un LLM doit d’abord le découper. La tokenization décide comment.