Token

Qu’est-ce qu’un token et comment fonctionne la tokenisation ?

La tokenisation est la première étape de tout pipeline LLM : avant qu’un modèle puisse traiter une phrase, un document ou une requête, le texte brut doit être converti en une séquence de nombres entiers (les identifiants de tokens) que le réseau de neurones peut manipuler. Un tokeniseur (ou tokenizer) réalise cette conversion en découpant le texte selon un vocabulaire préétabli, construit lors de l’entraînement. En anglais, on estime qu’un token correspond en moyenne à environ 0,75 mot, soit environ 4 caractères. Ces ratios varient selon les langues : le français, l’espagnol ou l’allemand tokenisent généralement moins efficacement que l’anglais en raison de leur morphologie plus riche. (BRICS Econ, 2026)

L’algorithme de tokenisation dominant dans les LLM modernes est le Byte Pair Encoding (BPE). BPE est une technique de compression adaptée au traitement du langage naturel : il commence avec des caractères individuels comme unités de base, puis fusionne itérativement les paires de tokens les plus fréquentes dans le corpus d’entraînement pour former des tokens de niveau supérieur. Le résultat est un vocabulaire de sous-mots qui couvre les mots courants avec un seul token et décompose les mots rares en plusieurs tokens, équilibrant efficacité computationnelle et capacité à traiter n’importe quel texte (y compris des termes techniques, des néologismes ou des mots de langues peu représentées). (Vizuara, 2024)

La taille du vocabulaire de tokens d’un modèle a un impact direct sur ses performances et ses coûts. GPT-2 utilisait un vocabulaire de 50 257 tokens ; GPT-4 dispose d’environ 100 000 tokens ; Gemini 3 atteint 262 000 tokens. Les tailles de vocabulaire ont augmenté d’environ 8 fois en trois ans. Un vocabulaire plus large produit des séquences de tokens plus courtes pour le même texte (ce qui permet au modèle de « voir » davantage de contenu dans sa fenêtre de contexte et réduit les coûts de traitement), mais au prix d’une table d’embeddings plus volumineuse en mémoire. (Let’s Data Science, 2026)

Ressources :

• IA marketing : guide complet pour les équipes marketing

Qu’est-ce que la fenêtre de contexte et pourquoi est-elle déterminante ?

La fenêtre de contexte (context window) d’un LLM est le nombre maximum de tokens que le modèle peut traiter simultanément dans une seule requête (incluant à la fois le texte en entrée et le texte généré en sortie). Tout ce qui dépasse cette limite est simplement invisible pour le modèle : il ne peut ni y faire référence ni en tenir compte pour générer sa réponse. La fenêtre de contexte fonctionne comme la mémoire de travail du modèle (elle délimite ce qu’il « voit » à un instant donné). (IBM, 2025)

Les fenêtres de contexte ont considérablement évolué. Les premiers modèles GPT travaillaient sur quelques milliers de tokens ; les modèles actuels de référence atteignent 128 000 tokens pour GPT-4o, 200 000 tokens pour Claude, et des architectures expérimentales annoncent des fenêtres de plusieurs millions de tokens. En pratique cependant, la taille affichée ne correspond pas toujours aux performances réelles : des recherches montrent que la précision des modèles se dégrade significativement bien avant la limite théorique, notamment pour les informations placées au milieu du contexte (un phénomène appelé « lost in the middle » documenté par Liu et al. en 2024). Les modèles tendent à mieux exploiter les informations placées en début ou en fin de leur contexte. (Atlan, 2026)

Dans un pipeline RAG, la fenêtre de contexte définit le « budget token » disponible pour les passages documentaires récupérés. Lorsqu’un moteur IA comme Perplexity ou ChatGPT Search sélectionne des passages sources pour répondre à une requête, ces passages doivent tenir dans la fenêtre de contexte du modèle aux côtés de la requête elle-même, de l’historique de conversation et des instructions système. Un passage de contenu verbeux, répétitif ou rempli de phrases génériques consomme des tokens sans apporter de valeur informationnelle, réduisant d’autant la place disponible pour des informations factuellement denses. C’est l’un des fondements techniques de la recommandation AEO de produire des contenus denses et directs plutôt que du texte dilué.

Ressources :

• Allier SEO et intelligence artificielle

Comment les tokens sont-ils liés à la génération de texte par un LLM ?

La génération de texte par un LLM est un processus autorégressif fondé sur les tokens : à chaque étape, le modèle calcule une distribution de probabilités sur l’ensemble de son vocabulaire de tokens et sélectionne le token suivant le plus vraisemblable en fonction de la séquence précédente. Ce processus est répété token par token jusqu’à la fin de la réponse. Ce n’est pas le modèle qui « pense » une phrase entière puis la transcrit, c’est une prédiction séquentielle de token en token, à chaque fois conditionnée par tout ce qui précède dans la fenêtre de contexte.

Cette mécanique de génération par token a des implications concrètes sur les comportements des LLM. Elle explique pourquoi les modèles sont naturellement fluides et cohérents sur le plan stylistique (ils optimisent la probabilité locale token par token), mais peuvent dériver sur le plan factuel, notamment lorsque la génération les amène dans des zones peu couvertes par leurs Training Data. Elle explique aussi pourquoi les LLM ont des difficultés avec des tâches qui nécessitent de voir l’intérieur d’un token (comme compter les lettres d’un mot ou inverser une chaîne de caractères) : le modèle ne « voit » pas les caractères qui composent un token, seulement l’identifiant numérique du token lui-même.

La température de génération est un paramètre qui contrôle la distribution de probabilités lors de la sélection du token suivant : une température basse rend la génération plus déterministe et factuelle, une température haute introduit plus de variabilité et de créativité. Les moteurs IA configurés pour répondre à des requêtes factuelles utilisent typiquement des températures basses, ce qui renforce encore l’avantage des contenus sources dont les affirmations sont formulées de façon précise et sans ambiguïté, car elles correspondent mieux aux prédictions de haute probabilité d’un modèle en mode factuel.

Ressources :

• Moteurs de recherche IA : fonctionnement et enjeux pour les équipes marketing

Pourquoi les tokens varient-ils selon les langues et les types de contenu ?

Le nombre de tokens nécessaire pour représenter un texte donné n’est pas uniforme : il varie selon la langue, le type de contenu, et le vocabulaire spécifique du tokeniseur utilisé. Pour l’anglais, le ratio de référence est d’environ 1 token pour 0,75 mot (soit 1 000 tokens pour 750 mots environ). Le français, l’espagnol et les autres langues romanes requièrent généralement davantage de tokens que l’anglais pour exprimer la même information, en raison de leur morphologie plus riche (préfixes, suffixes, conjugaisons complexes). Des langues à système d’écriture non latin (comme l’arabe, le japonais ou le coréen) nécessitent significativement plus de tokens encore, car les tokeniseurs entraînés majoritairement sur des corpus anglophones les représentent moins efficacement. (BRICS Econ, 2026)

Le type de contenu influe également sur la tokenisation. Le code source se tokenise différemment de la prose naturelle (les identifiants camelCase, les symboles de syntaxe et les nombres produisent souvent plus de tokens par mot que le texte ordinaire). Les termes techniques et les néologismes, peu présents dans les corpus d’entraînement des tokeniseurs, sont fréquemment décomposés en plusieurs tokens alors qu’un mot courant du même niveau de longueur ne formerait qu’un seul token. Pour les équipes de contenu qui rédigent en français ou dans d’autres langues non-anglaises, cela signifie que leurs pages consomment davantage de tokens qu’un texte équivalent en anglais dans la fenêtre de contexte d’un modèle (ce qui rend encore plus importante la densité factuelle de chaque passage).

Ressources :

• AEO : définition complète et enjeux pour les équipes marketing

Quel est le lien entre tokens, chunking et Passage Retrieval ?

Dans un pipeline RAG, les tokens sont l’unité de mesure à partir de laquelle est définie la taille des chunks (passages) lors de l’étape de chunking. Un chunk est un fragment de document découpé pour l’indexation dans une base de données vectorielle : sa taille est calibrée en tokens pour correspondre aux capacités de traitement du modèle d’embedding et aux contraintes de la fenêtre de contexte du modèle de génération. Les systèmes RAG définissent typiquement des tailles de chunks entre 200 et 500 tokens (ce qui correspond, en français, à environ 150 à 375 mots) avec des chunks trop petits qui manquent de contexte et des chunks trop grands qui diluent la pertinence thématique.

La tokenisation affecte directement la qualité du Passage Retrieval. Lorsqu’un tokeniseur découpe un texte en tokens, les frontières de tokens ne correspondent pas nécessairement aux frontières sémantiques du contenu : une phrase peut être coupée au milieu d’une expression idiomatique ou d’un concept technique, produisant des chunks dont le sens est incomplet. C’est pourquoi la structuration explicite du contenu en paragraphes autonomes (avec des frontières sémantiques claires matérialisées par des titres H2/H3) aide les pipelines RAG à produire des chunks cohérents, plutôt que de s’appuyer sur un découpage arbitraire par nombre de tokens sans égard pour la structure sémantique.

Le concept de « budget token » dans un contexte RAG illustre bien l’enjeu pour les créateurs de contenu : chaque requête dispose d’un nombre fini de tokens à répartir entre la requête elle-même, les instructions système, les passages récupérés et la réponse générée. Dans ce budget contraint, les passages de contenu verbeux (longs préambules, formules de transition, répétitions) consomment des tokens sans apporter de valeur informationnelle supplémentaire, réduisant la place disponible pour des affirmations factuelles directes. À l’inverse, un contenu dense et précis maximise la valeur informationnelle par token, augmentant la probabilité qu’un passage soit retenu et cité dans la réponse finale. (Steakhouse Blog, 2026)

Ressources :

• Schema.org et AEO : balisage structuré pour les moteurs de réponse
• Chunking — Glossaire AEO

Ce que les tokens impliquent concrètement pour une stratégie AEO

La compréhension des tokens traduit les principes abstraits de l’AEO en contraintes techniques concrètes. Chaque passage d’un article qui sera potentiellement injecté dans la fenêtre de contexte d’un moteur IA dispose d’un budget token limité pour convaincre le modèle de l’utiliser comme source. Un passage qui consacre ses premiers tokens à des formules d’introduction génériques (« Dans cet article, nous allons explorer... »), à des répétitions d’informations déjà développées, ou à des transitions redondantes, gaspille son budget avant d’avoir fourni la moindre information citable. La règle de l’answer-first (répondre directement à la question dès la première phrase) n’est pas seulement une recommandation éditoriale : elle optimise l’utilisation du budget token d’un passage pour maximiser sa densité factuelle.

L’effet « lost in the middle » documenté dans les LLM a une implication directe pour l’architecture de contenu : les informations les plus importantes d’un passage doivent se trouver en début de paragraphe. Dans la fenêtre de contexte d’un modèle, les tokens en début et en fin de contexte sont mieux exploités que ceux du milieu. La structure Sujet → Prédicat → Objet recommandée dans les standards d’écriture AEO correspond exactement à cette contrainte : elle place l’information essentielle dans les premiers tokens du paragraphe.

Ressources :

• Comment mettre en place une stratégie AEO
• Tendances AEO en 2026