Le token : l'atome du langage machine

Quand vous tapez une phrase dans ChatGPT, Claude ou Gemini, le modèle ne voit pas ce que vous voyez. Il ne lit ni mots ni caractères. Il reçoit une séquence de nombres entiers, chacun représentant un fragment de texte appelé token. La phrase que vous venez de lire contient environ 80 tokens selon l'encodage utilisé par les modèles GPT-4. Ce découpage est le premier geste, invisible, que fait n'importe quel grand modèle de langage (LLM, pour Large Language Model) avant même de commencer à traiter votre requête.

La notion de token est née d'une contrainte technique fondamentale. Les modèles de type Transformer — l'architecture décrite par Vaswani et ses collègues de Google Brain en 2017 dans l'article Attention Is All You Need — traitent le texte comme une séquence d'éléments discrets. Chaque élément est converti en vecteur numérique, puis ces vecteurs sont mis en relation les uns avec les autres via le mécanisme d'attention. Ce mécanisme calcule, pour chaque position dans la séquence, à quel point elle doit « prêter attention » à toutes les autres positions. C'est ce qui donne aux modèles leur capacité à saisir des dépendances à longue distance dans un texte, mais aussi leur principale limite : la complexité de ce calcul croît de façon quadratique avec le nombre de tokens. Doubler la longueur d'un texte ne double pas la charge de calcul — elle la quadruple.

Comment fonctionne la tokenisation par BPE ?

Le découpage en tokens n'est pas intuitif. On pourrait imaginer que le mot « informatique » constitue un token unique — c'est parfois le cas, mais pas toujours. Le mécanisme standard utilisé par la plupart des LLMs s'appelle Byte Pair Encoding, ou BPE. L'algorithme a été inventé en 1994 par Philip Gage comme technique de compression de données, avant d'être adapté en 2016 par Rico Sennrich, Barry Haddow et Alexandra Birch pour la traduction automatique neuronale.

Le principe du BPE est élégant dans sa simplicité. On part d'un corpus d'entraînement et on considère d'abord chaque caractère comme un symbole distinct. On identifie ensuite la paire de symboles adjacents la plus fréquente, on la fusionne en un nouveau symbole, et on répète l'opération jusqu'à atteindre la taille de vocabulaire souhaitée. Appliqué à un texte en anglais, l'algorithme finit par représenter les mots courants comme des tokens uniques (« the », « and », « is »), et les mots rares comme des séquences de sous-mots (le mot « tokenization » devient par exemple « token », « ization » dans certains encodages GPT-4). C'est ce déséquilibre qui explique une grande partie du comportement apparent des LLMs.

OpenAI utilise une implémentation open source de ce mécanisme appelée Tiktoken. Les modèles GPT-4 et GPT-3.5 emploient l'encodage cl100k_base, qui définit un vocabulaire d'environ 100 000 tokens. GPT-4o utilise o200k_base, soit le double. Le choix du vocabulaire n'est pas anodin : un vocabulaire plus grand réduit le nombre de tokens nécessaires pour représenter un texte donné, ce qui diminue les coûts et permet de traiter des textes plus longs.

Pourquoi le français coûte plus cher que l'anglais

Le BPE a un biais structurel : il favorise les langues dominantes dans les données d'entraînement. Pour un modèle entraîné majoritairement sur de l'anglais — ce qui est le cas de tous les grands LLMs actuels, y compris Llama 3, dont 95 % du corpus d'entraînement est en anglais ou en code —, un texte en français nécessite en moyenne 20 à 30 % de tokens supplémentaires qu'un texte anglais de même contenu sémantique. Un texte en langue à morphologie riche (finnois, hongrois, arabe, ukrainien) peut nécessiter deux à trois fois plus de tokens que son équivalent anglais.

La conséquence pratique est directe : quand vous utilisez l'API d'OpenAI ou d'Anthropic, vous payez au token. Un prompt rédigé en français consommera plus de tokens qu'un prompt équivalent en anglais. Sur des volumes importants, cet écart se traduit par des surcoûts significatifs. Pour des applications de traitement documentaire massif — résumés de contrats, analyses de rapports — il vaut parfois la peine de tester si une reformulation légèrement plus concise du prompt en français, ou un passage par l'anglais pour certaines étapes de traitement, améliore le rapport coût/qualité.

Ce que le modèle voit, et ce qu'il ne voit pas

La tokenisation n'est pas neutre sur la compréhension. Des recherches publiées en 2025 dans la revue Computational Linguistics du MIT ont montré que des tokenisations différentes du même mot chinois produisent des représentations sémantiques différentes dans le modèle. En d'autres termes, la façon dont un texte est découpé en tokens influence réellement ce que le modèle « comprend ». Ce n'est pas qu'une question de représentation interne abstraite : des chercheurs ont construit un dataset adversarial (ADT, pour Adversarial Dataset for Tokenizer) qui démontre que des textes délibérément formulés pour perturber la tokenisation dégradent significativement les performances de GPT-4o, LLaMA-3 et DeepSeek-R1.

Pour un utilisateur pratique, cela a plusieurs implications. D'abord, les fautes d'orthographe et les néologismes ont un coût caché : ils génèrent des tokenisations inhabituelles, potentiellement inefficaces. Ensuite, certains formats de données numériques — timestamps, identifiants, codes postaux — sont particulièrement mal gérés par les tokenizers actuels, qui les découpent en fragments sémantiquement vides. Des chercheurs ont montré que les LLMs peinent à raisonner sur des données temporelles en partie à cause de ce problème de représentation.

La fenêtre de contexte : la mémoire à court terme du modèle

Chaque LLM dispose d'une fenêtre de contexte (context window) exprimée en tokens. C'est le volume maximal d'information qu'il peut traiter en une seule fois — l'équivalent de sa mémoire de travail. GPT-3 travaillait avec 4 096 tokens. GPT-4 Turbo a porté cette limite à 128 000 tokens. Certains modèles récents dépassent le million de tokens de contexte.

Mais cette limite n'est pas qu'un plafond technique. Elle a des implications sur la qualité du raisonnement. Des études ont montré que les LLMs ont tendance à mieux utiliser les informations placées en début et en fin de contexte qu'au milieu — un phénomène parfois appelé « lost in the middle ». Mettre les instructions importantes au début du prompt, et les éléments de données à traiter juste avant la question, n'est donc pas qu'une question de style : c'est une stratégie d'efficacité.

La fenêtre de contexte a aussi une dimension économique. Un modèle qui traite 100 000 tokens de contexte à chaque requête coûte infiniment plus à opérer qu'un modèle qui en traite 4 000. Pour des applications en production, la gestion de la fenêtre de contexte — ce qu'on y met, ce qu'on en retire, ce qu'on résume ou compresse — est souvent un paramètre d'architecture critique. C'est en partie ce qui a rendu les systèmes RAG si populaires : plutôt que de charger l'intégralité d'une base de connaissances dans le contexte, on sélectionne dynamiquement les fragments pertinents.

Compter ses tokens avant d'envoyer

La bibliothèque Tiktoken d'OpenAI, disponible en open source, permet de compter précisément le nombre de tokens d'un texte avant de l'envoyer à l'API. C'est particulièrement utile pour deux raisons : éviter les erreurs de dépassement de limite (qui font échouer la requête), et anticiper les coûts. Un texte de mille mots en français représente typiquement entre 1 200 et 1 600 tokens selon le contenu. Un document PDF de 50 pages peut atteindre 25 000 à 40 000 tokens. Ces ordres de grandeur permettent de dimensionner ses pipelines et d'estimer des budgets d'utilisation d'API.

Pour les développeurs qui n'utilisent pas OpenAI, HuggingFace propose la bibliothèque tokenizers qui supporte les encodages BPE, WordPiece (utilisé par BERT) et Unigram (utilisé par les modèles SentencePiece de Google). Les tokenizers varient selon les modèles, et un token d'un modèle n'est pas forcément équivalent à un token d'un autre modèle. Comparer des prix entre fournisseurs sur la seule base du coût par token sans tenir compte de la « fertilité » du tokenizer (le nombre moyen de tokens par mot) peut conduire à des surprises.

L'avenir sans tokenizer ?

Meta AI a publié en 2024 une architecture expérimentale appelée Byte Latent Transformer (BLT) qui opère directement sur des octets bruts, sans passer par une étape de tokenisation. L'idée est de laisser le modèle apprendre lui-même à regrouper dynamiquement les octets en unités de traitement pertinentes — des « patches » — selon le contenu. Cette approche montre des résultats prometteurs, notamment sur des langues à faibles ressources, sur la robustesse aux fautes d'orthographe, et sur certaines tâches de manipulation de caractères où les modèles à base de tokens échouent systématiquement. Elle reste pour l'instant expérimentale, mais elle illustre bien à quel point la tokenisation est une pièce centrale et potentiellement fragile de l'architecture LLM actuelle.

Le chunk : découper pour retrouver

Le chunk est un fragment de texte. Mais contrairement au token — unité de traitement interne au modèle —, le chunk est une unité logique définie par l'architecte du système. On parle de chunk principalement dans le contexte du Retrieval-Augmented Generation, ou RAG, une technique qui consiste à connecter un LLM à une base de connaissances externe pour lui permettre de répondre à des questions sur des documents qu'il n'a pas vus pendant son entraînement.

Le RAG a été formalisé en 2020 par Patrick Lewis et ses collègues de Facebook AI Research (aujourd'hui Meta AI) dans un article fondateur publié à NeurIPS. Le principe : plutôt que de charger l'intégralité d'une base documentaire dans la fenêtre de contexte du modèle — ce qui serait coûteux, voire impossible si la base dépasse la limite de contexte —, on indexe les documents sous forme de vecteurs numériques (embeddings), et on ne récupère que les fragments les plus pertinents par rapport à la question posée. Ces fragments, ce sont les chunks.

Comment fonctionne un pipeline RAG ?

Un pipeline RAG comprend deux phases distinctes. La phase d'indexation, d'abord : les documents source sont découpés en chunks, chaque chunk est converti en vecteur numérique par un modèle d'embedding (un modèle spécialisé dans la représentation de texte sous forme mathématique), et ces vecteurs sont stockés dans une base de données vectorielle. La phase de requête, ensuite : quand un utilisateur pose une question, cette question est elle-même convertie en vecteur, et on recherche dans la base les chunks dont les vecteurs sont les plus proches — les plus « similaires » sémantiquement. Ces chunks sont ensuite injectés dans le contexte du LLM qui génère sa réponse à partir de ce contexte enrichi.

La qualité du résultat final dépend énormément de la qualité du découpage. Un chunk trop petit perd son contexte : il peut contenir une réponse partielle qui, isolée de son entourage, induit le modèle en erreur. Un chunk trop grand dilue le signal sémantique et charge inutilement la fenêtre de contexte. Trouver la bonne granularité est un problème d'ingénierie, pas de configuration par défaut.

Les stratégies de chunking et leurs compromis

Il existe plusieurs grandes familles de stratégies de découpage, chacune avec ses avantages et ses limites dans différents contextes d'usage.

Le chunking à taille fixe est la stratégie la plus simple : on découpe le texte en segments de N tokens (ou N caractères), avec un éventuel chevauchement (overlap) entre chunks consécutifs pour éviter de couper une idée en plein milieu. C'est facile à implémenter, prévisible, et suffisant pour des documents homogènes bien structurés. Son défaut principal est évident : il découpe sans lire, et peut donc séparer une phrase de sa conclusion, ou une règle de son exception. LangChain, la bibliothèque Python populaire pour construire des applications LLM, propose un CharacterTextSplitter qui suit exactement ce modèle.

Le chunking par structure logique respecte les frontières naturelles du document : phrases, paragraphes, sections, chapitres. Pour des documents bien formatés — rapports structurés, articles académiques, documentations techniques —, cette approche produit des chunks sémantiquement cohérents. Elle est moins efficace sur des textes mal formatés, des transcriptions de réunions ou des emails.

Le chunking sémantique va plus loin : il utilise lui-même un modèle de langage ou des techniques de segmentation textuelle pour identifier les ruptures thématiques dans le texte, indépendamment de la structure formelle. Des chercheurs ont montré que cette approche améliore la pertinence des chunks récupérés par rapport aux méthodes purement mécaniques. La contrepartie est le coût de calcul et la complexité de mise en œuvre.

Le chunking propositionnel pousse encore plus loin : il décompose le texte en unités atomiques de sens — chaque chunk représente une seule affirmation, un seul fait. Cette granularité fine améliore la précision de la récupération mais multiplie le nombre de chunks et complexifie l'indexation.

Une étude publiée en 2025 dans PubMed Central a comparé ces quatre stratégies sur des données médicales (questions sur la rhinoplastie postopératoire), en les évaluant sur la précision médicale et la pertinence clinique. Le chunking adaptatif — qui ajuste la taille des chunks à la structure du contenu — a obtenu les meilleurs résultats, avec 87 % de précision médicale contre 50 % pour le chunking par taille fixe. L'écart est significatif dans un domaine où une information incomplète peut avoir des conséquences directes.

La taille de chunk : ordres de grandeur utiles

Il n'existe pas de taille universellement optimale. Quelques repères pratiques, issus de l'expérience collective des praticiens du RAG, méritent d'être mentionnés.

Pour des bases de questions-réponses où les réponses sont courtes et précises (FAQ, documentations de référence), des chunks de 100 à 300 tokens donnent généralement de bons résultats. Pour des documents analytiques — rapports, études, contrats — des chunks de 500 à 1 000 tokens préservent mieux le contexte local. Pour des corpus narratifs longs (livres, transcriptions), des chunks hiérarchiques — qui indexent à la fois des segments fins et des agrégats plus larges — offrent le meilleur compromis entre précision et couverture contextuelle.

Le chevauchement entre chunks (overlap) est souvent sous-estimé. Mettre 10 à 20 % de tokens en commun entre deux chunks consécutifs réduit significativement le risque de perdre une information qui se trouve exactement à la frontière entre deux segments. LangChain recommande typiquement un overlap de 100 à 200 tokens pour des chunks de 1 000 tokens.

Les pièges classiques du chunking

Plusieurs erreurs reviennent régulièrement dans les projets RAG. La première est de négliger la phase de prétraitement des documents. Un PDF mal extrait — avec des colonnes mélangées, des en-têtes et pieds de page inclus dans le corps du texte, des tableaux transformés en suites de chiffres sans contexte — produit des chunks de mauvaise qualité quel que soit l'algorithme de découpage utilisé. La qualité des chunks est conditionnée par la qualité de l'extraction du texte en amont.

La deuxième erreur fréquente est d'oublier le contexte des chunks. Un chunk qui contient la phrase « La limite mentionnée à l'article 3.2 ne s'applique pas ici » est inutilisable sans savoir de quelle limite il s'agit. Des techniques comme le ParentDocumentRetriever de LangChain ou le SentenceWindowNodeParser de LlamaIndex adressent ce problème : on indexe de petits chunks pour la précision de la recherche, mais on injecte dans le contexte du LLM un chunk parent plus large pour préserver le contexte. C'est une forme de chunking hiérarchique qui améliore sensiblement les performances sur des documents complexes.

La troisième erreur est de croire qu'on peut définir une stratégie de chunking une fois pour toutes. La granularité optimale dépend du type de document, du type de requête, et du modèle d'embedding utilisé. Un chunk qui se récupère bien avec un certain modèle d'embedding peut être invisible avec un autre. Il faut évaluer, itérer, mesurer — et non pas faire confiance aux valeurs par défaut des frameworks.

Chunking et documents financiers ou juridiques

Une étude de 2024 sur le chunking de rapports financiers SEC (formulaires 10-K et 10-Q) illustre bien la complexité du problème dans des contextes à forts enjeux. Ces documents combinent du texte narratif (analyse de la direction), des tableaux chiffrés, des notes de bas de page et des références croisées. Un chunking naïf par taille fixe produit des chunks qui mélangent des unités hétérogènes ou qui isolent un chiffre de sa note explicative. Les auteurs ont montré que des stratégies de chunking adaptées à la structure sémantique des documents financiers améliorent significativement la qualité des réponses générées par le LLM. Le même raisonnement s'applique aux contrats juridiques, aux cahiers des charges techniques, aux manuels de procédure.

L'approche hiérarchique : segmenter puis regrouper

Des chercheurs de l'Université de technologie de Hanoï ont publié en 2025 (conférence SOICT 2024, publié par Springer) un framework qui combine segmentation textuelle et clustering sémantique. Le document est d'abord segmenté en sections cohérentes par un modèle neuronal entraîné à détecter les frontières thématiques. Ces segments sont ensuite regroupés en clusters basés sur leur similarité sémantique. Au moment de la requête, le système récupère à la fois des segments fins (pour la précision) et des clusters entiers (pour le contexte plus large). Évalué sur les datasets NarrativeQA, QuALITY et QASPER, ce framework surpasse les méthodes de chunking traditionnelles sur la compréhension de textes longs.

Cette direction hiérarchique est représentative d'une tendance plus large : les systèmes RAG matures ne fonctionnent plus avec un seul niveau de découpage, mais avec une pyramide de représentations — du token au chunk atomique, du chunk atomique au segment thématique, du segment au document complet. Chaque niveau sert un type de requête différent.

Ce que ça change dans vos usages quotidiens

Ces deux notions — token et chunk — ne sont pas que des détails d'implémentation réservés aux développeurs. Elles ont des conséquences directes sur la façon dont vous interagissez avec n'importe quel outil IA.

Quand vous rédigez un prompt, vous produisez des tokens. La longueur de votre historique de conversation compte en tokens. Les fichiers que vous joignez comptent en tokens. Les exemples que vous donnez au modèle pour lui montrer ce que vous attendez (few-shot prompting) comptent en tokens. Chaque token a un coût — financier sur les API payantes, computationnel sur les modèles hébergés localement, et cognitif pour le modèle lui-même qui doit les traiter tous.

La bonne pratique n'est pas de compresser à l'extrême — un prompt trop elliptique produit des résultats médiocres. C'est de savoir ce qui est utile et ce qui ne l'est pas. Les reformulations redondantes, les politesses excessives, les rappels de contexte déjà donnés au tour précédent : tout cela consomme des tokens sans améliorer la réponse. À l'inverse, des instructions précises, des exemples courts mais représentatifs, et un contexte pertinent bien ciblé améliorent la qualité de la réponse pour un coût token équivalent ou inférieur.

Si vous utilisez ou envisagez d'utiliser un système RAG — pour interroger une base documentaire interne, un corpus de procédures, une bibliothèque de contrats —, la stratégie de chunking est probablement le paramètre le plus critique de votre pipeline. Avant de choisir un modèle LLM ou un modèle d'embedding, posez-vous la question de la structure de vos documents. Sont-ils homogènes ou hétérogènes ? Courts ou longs ? Bien structurés ou en texte libre ? La réponse conditionne directement le choix de la stratégie de chunking, qui conditionne directement la qualité des réponses que vous obtiendrez.

Un système RAG qui répond mal n'est souvent pas un problème de LLM. C'est un problème de chunking. Les chunks récupérés ne contiennent pas l'information pertinente, ou ils la contiennent mais sans le contexte qui la rend intelligible. Améliorer le chunking améliore le système — parfois de façon spectaculaire — sans changer le modèle ni l'infrastructure.

Il existe un tableau de bord simple pour diagnostiquer un système RAG défaillant. On appelle parfois ces problèmes les « sept points de défaillance » (seven failure points) documentés dans la littérature de recherche : des chunks qui ne contiennent pas la réponse même quand elle est dans les documents, des chunks récupérés mais ignorés par le LLM, des réponses cohérentes mais basées sur des chunks non pertinents, etc. Dans la plupart des cas réels, les deux premiers — chunks mal formés et stratégie de récupération inadaptée — sont responsables de la majorité des erreurs.

Récapitulatif : token vs chunk

Schéma du pipeline RAG : de la tokenisation à la réponse

Conclusion

Le token et le chunk sont deux coutures invisibles de l'infrastructure IA. On ne les voit pas dans les interfaces, mais ils conditionnent tout : ce que le modèle peut traiter, à quel coût, avec quelle fidélité à vos documents. Les ignorer, c'est optimiser à l'aveugle. Les comprendre, c'est gagner la capacité d'agir sur les bons paramètres quand les résultats ne sont pas à la hauteur.

La recherche avance vite sur les deux fronts. Du côté des tokens, l'architecture Byte Latent Transformer de Meta suggère qu'on pourrait un jour se passer du tokenizer classique. Du côté des chunks, les approches hiérarchiques et sémantiques redéfinissent ce qu'on entend par « pertinence » dans la récupération documentaire. Pour l'utilisateur ou l'architecte d'aujourd'hui, l'essentiel reste de comprendre ces mécanismes pour en jouer intelligemment — et ne pas confondre la limite du modèle avec la limite du système qu'on a construit autour.