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 :
Bonjourtoutlemonde
Soit 4 tokens pour une courte salutation — pas 4 mots « visibles » au sens strict, car l’espace avant un mot compte souvent.
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 nécessite souvent 15 à 30 % de tokens supplémentaires par rapport à un texte anglais de sens équivalent. Conséquences directes : plus de mémoire occupée dans la fenêtre de contexte, plus de calcul GPU, et plus de coût à volume égal.
Exemple concret
- Un e-mail d’environ 300 mots en anglais peut faire ~400 tokens.
- Le même contenu en français peut monter à ~500–550 tokens.
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 « 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.
Aujourd’hui, les modèles les plus larges atteignent des fenêtres de l’ordre de 272 000 tokens — soit l’équivalent de plusieurs centaines de pages de texte selon la densité du contenu. 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 compute (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.