Les tokens : l'unité de mesure de l'IA

Derrière chaque requête à un grand modèle de langage (LLM), il y a une unité de comptage que vous ne voyez pas : le token. Coût des API, limites de mémoire, différence entre l’anglais et le français — tout passe par là. Voici les trois idées essentielles.

1. Qu’est-ce qu’un token ?

Un LLM ne lit pas du texte comme un humain. Il découpe chaque phrase en petits morceaux appelés tokens. Un token peut être un mot entier, une partie de mot, une ponctuation, voire un espace.

Par exemple, la phrase :

« Bonjour tout le monde »

peut être découpée en :

• Bonjour
• tout
• le
• monde

Soit 4 tokens, car l’espace placé avant chaque mot est souvent intégré au token.

En anglais, on utilise souvent l’ordre de grandeur :

100 tokens ≈ 75 mots (soit 1 000 tokens ≈ 750 mots).

Tokenisation et vecteurs

Avant tout calcul, le modèle applique la tokenisation : votre texte est découpé, puis chaque token est converti en représentation numérique — des vecteurs — que le réseau neuronal peut traiter. « Incroyable » peut tenir en un seul token ; un mot rare ou inventé sera souvent éclaté en plusieurs morceaux, ce qui augmente la facture pour la même phrase affichée.

Comment le modèle « écrit »

Tous les modèles génératifs reposent sur les tokens :

• ils reçoivent des tokens en entrée (votre prompt, l’historique, les documents) ;
• ils prédisent le premier token de la réponse ;
• puis ils enchaînent, token après token, des milliers de fois jusqu’à produire une phrase complète.

C’est pour cela que les API (OpenAI, Anthropic, etc.) facturent au nombre de tokens en entrée et en sortie : chaque étape de génération consomme du calcul.

2. Pourquoi parler français consomme plus de tokens ?

Toutes les langues ne sont pas traitées de la même manière par les modèles.

Les LLM modernes ont été massivement entraînés sur de l’anglais — beaucoup ont été conçus par des équipes dont les corpus dominants sont anglophones. Résultat : leur tokenizer est souvent optimisé pour cette langue. Des mots fréquents en anglais existent déjà comme tokens uniques.

Par exemple :

• « understanding » → souvent 1 token

Alors qu’en français, des mots du quotidien ou techniques sont en général composés de plusieurs tokens :

• « compréhension »
• « industrialisation »
• « réglementation »

… peuvent chacun représenter 3 tokens ou plus, selon le modèle.

En pratique, un texte français demande souvent plus de tokens qu’un texte anglais de même sens ; l’écart dépend du tokenizer de chaque modèle. Conséquences directes : plus de mémoire occupée dans la fenêtre de contexte, plus de calcul, et plus de coût à volume égal.

Ce phénomène varie selon les modèles : certains tokenizers sont plus efficaces en français, d’autres restent ultra-optimisés pour l’anglais et le code. Avant de comparer deux offres API, il est utile de regarder non seulement le prix au million de tokens, mais aussi la langue dominante de vos usages.

3. La « context window » : la mémoire court terme du modèle

Les modèles ont une limite de mémoire appelée context window (fenêtre de contexte). C’est le nombre maximum de tokens qu’ils peuvent voir et traiter en même temps — pas une mémoire longue durée qui se souviendrait de vous des semaines plus tard.

Cette fenêtre inclut tout ce qui est envoyé au modèle dans un même appel ou une même conversation :

• votre prompt ;
• les messages précédents de la discussion ;
• les documents joints (PDF, extraits collés, etc.) ;
• et la réponse générée — qui consomme aussi des tokens au fur et à mesure qu’elle est produite.

Selon les fournisseurs, les fenêtres de contexte vont aujourd’hui de quelques dizaines de milliers à plus d’un million de tokens, soit jusqu’à plusieurs milliers de pages de texte. Même avec ces plafonds élevés, une conversation très longue ou un dossier entier peut saturer la fenêtre : le modèle ne « voit » plus le début.

C’est aujourd’hui l’un des grands enjeux techniques des LLM : comment gérer des contextes gigantesques sans faire exploser le calcul (temps de réponse, coût, consommation énergétique). D’où l’émergence de pistes complémentaires :

• RAG (retrieval-augmented generation) — récupérer seulement les passages utiles au lieu de tout charger ;
• mémoire externe — stocker l’historique ou les faits en dehors du prompt ;
• cache KV — réutiliser des calculs déjà faits sur une partie du contexte ;
• compression de contexte — résumer ou condenser avant d’envoyer au modèle ;
• architectures hybrides agent + recherche — déléguer la collecte d’information à des outils spécialisés.

Nous pourrons détailler ces sujets dans un prochain article de la série.

En résumé

Les tokens ne sont pas un détail de facturation : ils structurent la lecture, l'écriture et les limites des LLM. Savoir découper une phrase, mesurer l'écart français/anglais et comprendre la context window, c'est déjà lire correctement les contraintes techniques de l'IA générative.