Tokenisation : fonctionnement, pièges et réglages pratiques

Quand vous tapez un prompt dans un LLM, le modèle ne lit pas vos mots. Il commence par découper votre texte en fragments appelés tokens : des mots entiers, des morceaux de mots, parfois des caractères isolés. Chaque token est ensuite converti en un identifiant numérique. Cette opération, la tokenisation, se produit avant toute « réflexion » du modèle et détermine trois choses concrètes : ce que le modèle peut comprendre, ce que chaque requête vous coûte, et où le système va échouer.

Ce que fait concrètement la tokenisation

Le texte brut passe par un tokenizer (l’algorithme de découpe), qui produit une séquence de tokens, puis convertit chaque token en un identifiant numérique. Ces identifiants alimentent une couche d’embedding (représentation vectorielle dense) qui devient l’entrée réelle du réseau de neurones.

Prenons un exemple concret ^[1]. La phrase « The quick brown fox jumps » peut être découpée de trois façons :

• Par mot : [« The », « quick », « brown », « fox », « jumps »]. Cinq tokens, un par mot. Intuitif, mais le vocabulaire explose (chaque conjugaison, chaque faute, chaque mot rare est un token distinct) et les mots inconnus sont tout simplement impossibles à traiter.
• Par caractère : [« T », « h », « e »,  » « , « q », « u », …]. Vocabulaire minuscule (quelques centaines de symboles), mais les séquences deviennent très longues, ce qui ralentit le traitement et réduit la fenêtre de contexte utile.
• Par sous-mot (subword) : [« The », « quick », « brown », « fox », « jump », « s »]. Les mots courants restent entiers ; les mots rares ou longs sont découpés en pièces reconnaissables. Le vocabulaire reste gérable (généralement entre 30 000 et 100 000 tokens), et le modèle peut recomposer n’importe quel mot à partir de morceaux connus ^[1].

La quasi-totalité des LLMs modernes utilisent la tokenisation par sous-mots. Le choix de la méthode de découpe a des conséquences directes sur la qualité, le coût et les limites du système.

BPE, Unigram, SentencePiece : trois approches pour un même objectif

Toutes les méthodes de tokenisation par sous-mots répondent à la même question : à partir d’un corpus de textes, comment construire un vocabulaire de 30 000 à 100 000 tokens qui capture efficacement la structure de la langue ?

BPE : la méthode derrière les modèles GPT

Le Byte-Pair Encoding (encodage par paires d’octets) était à l’origine un algorithme de compression de données ^[2]. Son fonctionnement en quatre étapes :

1. Commencer avec les caractères individuels comme vocabulaire de base
2. Identifier la paire de tokens adjacents la plus fréquente dans le corpus
3. Fusionner cette paire en un nouveau token
4. Répéter jusqu’à atteindre la taille de vocabulaire ciblée

Concrètement, si « t » et « h » apparaissent très souvent côte à côte dans votre corpus, ils fusionnent en « th ». Puis « th » et « e » fusionnent en « the ». Les mots courants émergent naturellement ; les mots rares restent découpés en sous-pièces fréquentes. BPE est la méthode derrière la famille GPT (GPT-2, GPT-3.5, GPT-4). L’implémentation OpenAI s’appelle tiktoken ^[3]. WordPiece, la méthode utilisée par BERT, fonctionne sur un principe voisin (maximiser la vraisemblance plutôt que la simple fréquence de paires).

Unigram : l’approche inverse

Le tokenizer Unigram procède dans l’autre sens : partir d’un vocabulaire initial énorme (des millions de tokens candidats) et élaguer progressivement les moins utiles jusqu’à atteindre la taille cible. Bloomberg a choisi cette méthode avec une variante byte-based (fonctionnant au niveau des octets) pour son modèle financier entraîné sur FinPile, son corpus de documents financiers, parce qu’elle gère mieux la terminologie spécialisée ^[4].

Les outils que vous allez utiliser

SentencePiece n’est pas une méthode mais une bibliothèque logicielle qui implémente à la fois BPE et Unigram ^[2][5]. Son avantage clé : elle peut travailler directement sur du texte brut sans supposer que les espaces délimitent les mots. C’est indispensable pour le chinois, le japonais ou le thaï. Lors de l’enrichissement d’un tokenizer avec des noms de marque composés de plusieurs mots, vous le configurez avec l’option split_by_whitespace=False pour que ces expressions soient reconnues comme un seul token ^[2].

	BPE	Unigram
Logique	Bottom-up : fusion itérative de paires fréquentes	Top-down : élagage d’un gros inventaire initial
Utilisé par	GPT-2, GPT-3.5, GPT-4	Certains modèles multilingues, le modèle financier de Bloomberg [4]
Bibliothèque	tiktoken [3], SentencePiece	SentencePiece
Point fort	Rapide, déterministe	Meilleure adaptation aux domaines spécialisés

Les autres outils à connaître :

• tiktoken ^[3] : l’implémentation BPE d’OpenAI, rapide et déterministe, utilisée pour GPT-3.5 et GPT-4.
• HuggingFace AutoTokenizer ^[5] : une interface unifiée qui charge automatiquement le bon tokenizer pour n’importe quel modèle du Hub HuggingFace, sans que vous ayez à gérer les spécificités de chaque méthode.

Ce que la tokenisation casse

Les nombres

Le défaut le mieux documenté : BPE tokenize les nombres selon la fréquence de co-occurrence des caractères, pas selon la logique numérique. Le nombre 42235630 pourrait être découpé en [422, 35, 630] ^[6]. Changez un seul chiffre et la tokenisation entière se recompose différemment. C’est pourquoi les LLMs peinent avec l’arithmétique : ils ne voient pas les nombres comme des nombres, mais comme des fragments arbitraires de caractères dont le sens numérique est perdu.

Le vocabulaire spécialisé

Quand un nom de marque ou un terme technique est absent du vocabulaire du tokenizer, il est haché en morceaux dénués de sens. Un nom de composé pharmaceutique peut devenir cinq tokens qui ne signifient rien individuellement. La solution : ajouter ces termes comme tokens spéciaux lors de la configuration ^[7][2]. Le Contextual Graph Transformer, par exemple, utilise des tokens « sensibles à la structure » (structure-aware tokens) pour représenter la hiérarchie documentaire, en complément du vocabulaire BPE standard GPT-2 de 50 257 tokens ^[7].

Le multilingue

Les tokenizers entraînés principalement sur l’anglais produisent disproportionnellement plus de tokens pour les scripts non latins. Un seul mot ukrainien peut consommer trois ou quatre tokens là où son équivalent anglais n’en utilise qu’un, augmentant directement le coût et réduisant la longueur effective du contexte exploitable ^[8]. Ce problème est particulièrement marqué pour l’arabe, le hindi et les langues à alphabet cyrillique.

Le texte brouillé

Même les modèles les plus avancés montrent des fragilités liées à la tokenisation. Le papier EvolKV ^[9] rapporte que si GPT-4 parvient à lire du texte volontairement mélangé (les lettres internes de chaque mot sont réarrangées), la robustesse de la tokenisation par sous-mots demeure un problème systémique à travers les LLMs. Les tokens appris sur un schéma d’entraînement standard réagissent mal quand la structure caractère par caractère est perturbée.

Configurer et enrichir son tokenizer

Taille du vocabulaire

Le Contextual Graph Transformer utilise un vocabulaire de 50 257 tokens, hérité du tokenizer BPE de GPT-2 ^[7]. C’est une base courante. L’arbitrage est le suivant : plus de tokens (100 000+) couvrent davantage de langues et de domaines mais augmentent la consommation mémoire du modèle ; moins de tokens (30 000) sont plus légers mais découpent le texte en davantage de fragments, ce qui allonge les séquences et réduit la fenêtre de contexte disponible.

Tokens spéciaux : l’adaptation à votre domaine

C’est ici que vous transformez un tokenizer générique en outil adapté à votre métier :

• Termes métier : ajoutez vos noms de marque, noms de produits, acronymes et termes techniques comme tokens uniques ^[2]. Sans cette étape, un nom de marque composé (« Air Max », « Réponse IA ») sera découpé en fragments séparés, perdant son identité sémantique.
• Marqueurs structurels : pour des documents techniques, ajoutez des tokens qui représentent la hiérarchie (titres, sections, métadonnées) ^[7].
• Expressions multi-mots : configurez SentencePiece avec split_by_whitespace=False pour reconnaître ces expressions comme un seul token ^[2].

L’expérience décrite dans le système de recherche lexicale multi-termes ^[2] a comparé des tokenizers enrichis de noms de marque prédéfinis (variantes dites « multi-token ») contre des versions standards. L’ajout de vocabulaire de domaine comme tokens spéciaux a amélioré les métriques de retrieval : la précision moyenne à 12 résultats (mAP@12) et le rappel à 1 000 résultats (R@1k).

Longueur maximale de séquence et padding

Le Contextual Graph Transformer plafonne à 512 tokens par séquence, un réglage adapté aux documents techniques ^[7]. Les modèles récents supportent bien davantage (8 000, 128 000 tokens), mais chaque augmentation implique un coût en mémoire et en latence. Quand vous traitez des lots de textes de longueurs différentes, les textes les plus courts sont complétés (paddés) à droite pour atteindre la longueur du plus long ; un masque d’attention garantit que le modèle ignore ces tokens de remplissage ^[7].

Tokens = argent : l’impact direct sur votre facture

Chaque appel API à un LLM est facturé au nombre de tokens. Les tokens d’entrée (votre prompt) et les tokens de sortie (la réponse) sont comptabilisés séparément, souvent à des tarifs différents ^[10]. Chaque appel LLM dans une trace capture précisément ces deux compteurs, permettant un suivi des coûts au niveau de chaque opération ^[10].

La consommation de tokens domine l’équation d’efficacité globale, bien plus que la latence de calcul ^[11]. Un même contenu sémantique peut consommer 100 tokens avec un tokenizer et 180 avec un autre. Multipliez par des milliers de requêtes quotidiennes et l’écart de coût devient considérable.

La métrique qui compare vraiment les modèles

Les bits par octet (BPB, bits per byte) constituent la métrique la plus standardisée pour comparer l’efficacité de tokenisation entre modèles ^[12]. Elle mesure combien de bits un modèle a besoin pour représenter un octet de données originales, quelle que soit la méthode de tokenisation utilisée. Si un modèle a besoin de 6 bits par token et que chaque token représente en moyenne 2 caractères, son BPB dépend de l’encodage caractère (7 bits en ASCII, 8 à 32 bits en UTF-8). Un modèle à 3 BPB est deux fois plus efficace qu’un modèle à 6 BPB. C’est la métrique à regarder quand vous comparez des modèles qui utilisent des tokenizers différents.

Découpage pour le RAG

Lorsque vous découpez des documents pour de la génération augmentée par retrieval (RAG), la taille des segments (chunks) se mesure en tokens. Le framework de question-réponse domaine-spécifique ^[13] a identifié une taille optimale de 1 000 tokens avec 100 tokens de chevauchement entre segments consécutifs. Trop petit et vous perdez le contexte nécessaire à la compréhension ; trop grand et le retrieval devient imprécise, car le contenu pertinent se noie dans l’information.

Checklist avant de déployer

☐ Vérifier la couverture de votre vocabulaire métier : vos termes techniques, noms de marque et acronymes figurent-ils dans le tokenizer ? Sinon, ajoutez-les comme tokens spéciaux ^[7][2]. C’est la différence entre « Air Max » tokenisé en un seul bloc et « Air » + « Max » traités comme deux mots indépendants.

☐ Tester sur vos cas limites : envoyez des prompts contenant des nombres, du texte multilingue, des abréviations et observez le découpage réel. Utilisez tiktoken ^[3] ou HuggingFace AutoTokenizer ^[5] pour visualiser les tokens. Si un nombre important pour votre métier est découpé de façon absurde, envisagez de le reformater ou de le remplacer par du texte.

☐ Mesurer le coût réel : comptez les tokens de vos 10 prompts les plus fréquents et calculez le coût mensuel projeté. Un même prompt peut coûter significativement plus cher selon le modèle choisi, simplement parce que le tokenizer est différent ^[11][10].

☐ Anticiper la migration : si vous changez de modèle, le tokenizer change aussi. Vos stratégies de découpage en chunks, vos exemples few-shot et vos coûts vont bouger. Testez avant de basculer.

☐ Choisir le bon outil : tiktoken pour les modèles OpenAI ^[3], SentencePiece pour les modèles Google ou les corpus multilingues ^[2][5], AutoTokenizer pour une interface unifiée qui s’adapte automatiquement au modèle cible.

Sources

• [1] The AI Product Playbook Strategies, Skills, and Frameworks for the AI-Driven Product Manager · livre · Amazon
• [2] Multi-word Term Embeddings Improve Lexical Product Retrieval · Viktor Shcherbakov et al. · 2024 · preprint · arXiv:2406.01233
• [3] Building Generative AI Services with FastAPI A Practical Approach to Developing Context-Rich Generative AI Applications · livre · Amazon
• [4] Large Language Models The Hard Parts Open Source AI Solutions for Common Pitfalls · livre · Amazon
• [5] LLMOps Managing Large Language Models in Production · livre · Amazon
• [6] Transformers · livre · Amazon
• [7] Contextual Graph Transformer: A Small Language Model for Enhanced Engineering Document Information Extraction · preprint · arXiv:2508.02532
• [8] An End-to-End Ukrainian RAG for Local Deployment. Optimized Hybrid Search and Lightweight Generation · Mykola Trokhymovych et al. · 2026 · preprint · arXiv:2604.22095
• [9] EvolKV: Evolutionary KV Cache Compression for LLM Inference · preprint · arXiv:2509.08315
• [10] GenAI on Google Cloud Enterprise Generative AI Systems and Agents · livre · Amazon
• [11] HAPS: Hierarchical LLM Routing with Joint Architecture and Parameter Search · preprint · arXiv:2601.05903
• [12] AI Engineering Building Applications with Foundation Models · livre · Amazon
• [13] Domain-specific Question Answering with Hybrid Search · Dewang Sultania et al. · 2024 · preprint · arXiv:2412.03736