Avant même de « penser », un modèle de langage doit découper le monde. Ce découpage — la tokenisation — décide de ce qu'il peut lire, de ce qu'il vous facture, de ce qu'il comprend… et de par où on peut l'attaquer.
Tous les tokeniseurs de cette présentation sont réellement entraînés dans votre navigateur, sur un corpus embarqué. Rien n'est simulé.
« Combien de fois la lettre r apparaît-elle dans strawberry ? »
Pendant des années, les meilleurs modèles du monde ont répondu « deux ». Avec aplomb. La bonne réponse est trois.
Ce n'est pas un défaut d'intelligence. C'est un défaut de vision.
Trois blocs opaques. Aucun n'est une lettre. Demander à ce modèle de compter les « r » revient à demander à quelqu'un qui lit les idéogrammes chinois de compter les traits d'un mot français.
Le modèle ne lit pas des lettres. Il lit des tokens — et il n'a jamais vu ce qu'il y a dedans.
La thèse de cette présentation : la tokenisation est la couche la plus sous-estimée de l'IA générative. Elle est simultanément une décision d'ingénierie, une décision économique, une décision politique (quelles langues coûtent cher ?) et une décision de sécurité. Tout ce qui suit découle d'un seul arbitrage.
Du problème fondamental aux attaques concrètes, en passant par huit familles d'algorithmes.
Un réseau de neurones ne manipule que des nombres. Il faut donc transformer « Bonjour le monde » en une liste d'entiers. Le tokeniseur est ce traducteur : il découpe le texte en morceaux, et chaque morceau a un numéro dans un dictionnaire figé — le vocabulaire.
Un ? signale un symbole absent du vocabulaire appris sur ce petit corpus — chiffres, ponctuation rare, alphabets étrangers. C’est exactement le problème du hors-vocabulaire, et la raison d’être du repli sur les octets.
La liste fermée de tous les morceaux connus. Typiquement 30 000 à 260 000 entrées. Ce qui n'y est pas doit être reconstruit par morceaux.
Elle se compte en tokens, pas en mots. Un tokeniseur inefficace vous vole littéralement de la mémoire.
Les API facturent au token. Le même texte, deux tokeniseurs, deux factures différentes.
Tous les algorithmes qui suivent ne font qu'une chose : négocier un compromis entre deux forces opposées. Il n'existe pas de solution parfaite, seulement des points d'équilibre.
<UNK> — information perdueUn BPE est entraîné sur le corpus embarqué, puis appliqué avec un nombre croissant de fusions. Observez la courbe : chaque token gagné coûte de plus en plus cher en vocabulaire.
Le point d'équilibre trouvé par l'industrie : le sous-mot. Assez gros pour que « bonjour » soit un seul token, assez petit pour que « antidéconstitutionnellement » reste représentable.
L'approche naïve — et instructive par ses échecs.
<UNK>.Analogie : un dictionnaire papier. Si le mot n'y est pas, vous n'avez aucun moyen de le lire — même pas lettre à lettre.
L'extrême opposé — élégant, mais coûteux.
Analogie : lire une phrase en épelant. Vous ne serez jamais bloqué par un mot inconnu, mais vous lirez dix fois plus lentement.
L'algorithme roi. Détourné en 2015 d'une technique de compression de 1994.
Analogie : un sténographe. À force d'écrire « ment » mille fois par jour, il invente un signe unique pour « ment ». Puis un pour « tion ». Le vocabulaire émerge de la répétition, pas d'une théorie linguistique.
manger → mang|er, mais mangeoire → man|geo|ireLe corpus embarqué est réel (texte français, ~6 000 caractères). Lancez l'apprentissage et regardez le vocabulaire naître.
Remarquez la décroissance des gains : les premières fusions rognent énormément (elles capturent « es », « en », « ti »…), les suivantes de moins en moins. C'est exactement la loi de Zipf qui se manifeste — et la raison pour laquelle les vocabulaires plafonnent autour de 100 000–200 000 entrées.
La ruse qui a définitivement tué le token <UNK>.
Analogie : au lieu d'un dictionnaire de mots, un alphabet universel de 256 briques. Un émoji, un idéogramme, un caractère runique, un fichier binaire : tout se reconstruit. Rien n'est jamais « inconnu ».
Le cousin statistique de BPE — celui de BERT.
f(ab) / (f(a)·f(b)).##.La différence en une phrase : BPE demande « quelle paire vois-je le plus souvent ? ». WordPiece demande « quelle paire apparaît le plus souvent par rapport à ce que le hasard prédirait ? ». Le second favorise les associations réellement significatives plutôt que les lettres omniprésentes.
## rend la frontière de mot explicite et lisible[UNK] — pas de repli sur les octetsL'approche probabiliste : on part d'un excès et on élague.
Analogie : BPE est un maçon qui empile des briques du bas vers le haut. Unigram est un sculpteur : il part d'un bloc trop gros et retire tout ce qui ne sert pas. Surtout, il connaît plusieurs découpes valides du même mot et sait laquelle est la plus vraisemblable.
▁) → indépendant de la langueTous ces tokeniseurs sont entraînés sur le même corpus embarqué, avec la même cible de vocabulaire. Les différences que vous voyez sont donc purement algorithmiques.
ByT5, CANINE, MambaByte — supprimer le problème plutôt que l'optimiser.
L'argument de fond : le tokeniseur est le dernier morceau non appris du pipeline. C'est un artefact figé, entraîné sur un corpus différent du modèle, jamais mis à jour. L'histoire de l'apprentissage profond suggère que les composants faits main finissent toujours par être absorbés.
Meta, 2024-2025 : découper selon la difficulté, pas selon la fréquence.
L'idée est belle : un tokeniseur classique dépense autant d'effort pour la fin prévisible d'un mot courant que pour un nom propre inattendu. BLT alloue son budget de calcul dynamiquement, en fonction de l'incertitude réelle. Les travaux de Meta rapportent des lois d'échelle au moins comparables à celles de Llama 3 à calcul égal, avec une robustesse au bruit nettement supérieure.
Plutôt que descendre sous le mot, monter au-dessus. SuperBPE (COLM 2025) lève la contrainte qui interdisait à un token de franchir un espace, et apprend des « supermots » comme « by accident » ou « depend on ». Résultat rapporté : environ 33 % de tokens en moins à vocabulaire égal, un gain moyen de +4 % sur trente tâches et une inférence ~27 % plus rapide — avec quelques reculs, notamment sur le code. Deux écoles opposées, un même constat : le mot n'a rien de sacré.
| Algorithme | Principe | Vocabulaire | Force principale | Faiblesse principale | Modèles |
|---|---|---|---|---|---|
| Mots | Découpe sur les espaces | 10⁵–10⁶ | Sens immédiat | Mur du hors-vocabulaire | Word2Vec |
| Caractères | Un token = un caractère | ~10² | Zéro inconnu | Séquences 4-5× plus longues | petits modèles |
| BPE | Fusion gloutonne par fréquence | 30k–100k | Meilleur compromis global | Frontières non morphologiques | GPT-2, RoBERTa |
| Byte-level BPE | BPE appliqué aux octets | 50k–260k | Couverture universelle | Taxe sur les langues non latines | GPT-4o, Llama 3 |
| WordPiece | Fusion par vraisemblance | 30k | Segments plus significatifs | Glouton exploitable | BERT |
| Unigram | Élagage probabiliste + Viterbi | 32k–256k | Régularisation, multilingue | Entraînement coûteux | T5, Gemma |
| Octets purs | Aucun apprentissage | 256 | Équité et robustesse | Coût de calcul | ByT5, MambaByte |
| Patches (BLT) | Découpe par entropie | 256 | Calcul adaptatif | Complexité, immaturité | BLT (Meta) |
La tendance de fond est nette : les vocabulaires grossissent. Plus de vocabulaire, c'est moins de tokens par phrase — donc plus de contexte utile et moins de calcul par mot — au prix d'une couche d'embedding et d'une couche de sortie plus lourdes.
Un tokeniseur entraîné majoritairement sur de l'anglais compresse très bien l'anglais. Les autres langues paient — en argent, en latence et en contexte disponible.
Le tokeniseur BPE est ici entraîné sur le corpus français embarqué. Observez comment il se comporte face à des langues qu'il n'a jamais vues — c'est exactement la situation de la plupart des langues du monde face aux tokeniseurs des grands modèles.
Conséquence économique. À contenu équivalent, certaines langues consomment plusieurs fois plus de tokens que l'anglais. Facturation à l'usage, plafond de contexte, latence : la note est multipliée d'autant, pour des locuteurs souvent situés dans des pays à faible revenu.
Conséquence qualitative. Une segmentation plus fragmentée, c'est un signal plus dilué et un raisonnement plus fragile. L'écart de performance entre langues n'est donc pas seulement un problème de données d'entraînement : il est en partie inscrit dans le tokeniseur.
Presque toute l'attention en sécurité des LLM se porte sur le prompt et sur les poids. Or il existe une couche entre les deux — figée, rarement auditée, souvent partagée entre le modèle et ses garde-fous.
Le tokeniseur et le modèle ne sont pas entraînés sur les mêmes données. Un pseudonyme de forum très actif au moment de la construction du vocabulaire obtient son propre token. Puis ces données sont filtrées avant l'entraînement du modèle.
Résultat : le token existe, mais son vecteur d'embedding n'a jamais été appris. Il reste proche de son initialisation aléatoire.
Donner ce token en entrée revient à injecter du bruit pur au cœur du réseau. Les modèles y répondent par des insultes, du charabia, des refus inexpliqués, des changements de langue — ou en ignorant totalement l'instruction.
SolidGoldMagikarp — pseudonyme d'un utilisateur de Reddit, découvert en 2023. Demander à GPT-3 de le répéter produisait « distribute », des insultes, ou un refus.
Le travail « Fishing for Magikarp » (2024) a automatisé la détection de ces tokens et en a trouvé dans la quasi-totalité des grandes familles de modèles : fragments de code, mots issus de spam, artefacts de nettoyage, chaînes de configuration. Des tokens anormaux ont encore été documentés dans des modèles récents.
Un état interne hors distribution peut faire sauter des comportements appris — dont l'alignement.
Réponses incohérentes ou boucles infinies déclenchées par une chaîne courte.
La réaction à ces tokens identifie précisément le modèle et sa version derrière une API opaque.
Unicode contient plusieurs caractères visuellement indiscernables du a latin. Pour un humain, c'est le même mot. Pour un tokeniseur travaillant sur les octets, c'est un objet totalement différent.
Publiée en 2025, cette attaque exploite une asymétrie déroutante : ajouter une seule lettre à un mot suffit à faire dérailler la segmentation d'un classifieur BPE ou WordPiece — alors que le LLM cible, lui, comprend toujours parfaitement.
La découpe gloutonne ne peut plus s'ancrer sur le début du mot. Le classifieur reçoit des fragments qu'il n'a jamais associés à un contenu problématique. Le LLM, entraîné sur des milliards de fautes de frappe humaines, lit sans difficulté.
L'attaque vise la stratégie de tokenisation du garde-fou, pas le modèle. Les classifieurs BPE et WordPiece se sont montrés vulnérables ; ceux fondés sur Unigram nettement moins, car la découpe par Viterbi est globale et non gloutonne.
C'est le premier critère de sécurité concret pour choisir un tokeniseur : votre filtre et votre modèle doivent voir le même texte.
Faire passer une instruction que l'humain ne voit pas mais que le modèle lit parfaitement.
Défense : supprimer par défaut les catégories Unicode non imprimables (Cf, Co, tag characters) à l'entrée, journaliser leur présence comme un signal d'alerte fort, et faire porter la décision de sécurité au texte après normalisation.
L'asymétrie caractères / tokens est un levier de déni de service.
Défense : plafonner en tokens, jamais en octets ou en caractères. Compter les tokens avant l'appel au modèle. Surveiller la fertilité (tokens ÷ caractères) : au-delà d'un seuil, rejeter ou dégrader.
Le fil rouge des cinq attaques : elles exploitent toutes le même écart — celui entre ce que l'humain voit, ce que le filtre voit et ce que le modèle voit. Réduire cet écart est un objectif d'architecture, pas un correctif ponctuel.
Neuf mesures concrètes, ordonnées du plus rentable au plus exigeant.
Principe directeur : traiter le tokeniseur comme un composant de sécurité de première classe — versionné, testé, journalisé, audité — et non comme un détail d'implémentation hérité du dépôt Hugging Face d'origine.
Nous sommes partis d'une plaisanterie — un modèle incapable de compter les r de strawberry. Nous arrivons à une couche d'infrastructure qui détermine ce qu'un modèle peut percevoir, ce que son utilisateur paie, quelles langues sont favorisées, et par où un attaquant peut passer.
1. Tout tokeniseur est un compromis entre taille de vocabulaire et longueur de séquence. Il n'existe pas d'optimum universel.
2. Le tokeniseur est le dernier composant non appris du pipeline — donc le prochain candidat à disparaître (BLT, MambaByte).
3. C'est une surface d'attaque réelle, exploitée, et presque jamais auditée. Le durcissement commence là.
Prochaine étape naturelle pour le projet LLM SECURITY : construire un banc de test de tokenisation — détection de glitch tokens, mesure de fertilité, fuzzing Unicode, vérification de l'alignement entre garde-fou et modèle.
Sources principales : Sennrich et al. (BPE, 2015) · Kudo (Unigram, 2018) · Kudo & Richardson (SentencePiece, 2018) · Radford et al. (byte-level BPE, GPT-2, 2019) · Xue et al. (ByT5, 2022) · Land & Bartolo (« Fishing for Magikarp », 2024) · Pagnoni et al. (Byte Latent Transformer, Meta, 2024) · Liu et al. (SuperBPE, COLM 2025) · HiddenLayer (TokenBreak, 2025).