Tokenization (LLM)

Qu'est-ce que la tokenization d'un LLM ?

La tokenization (ou segmentation en jetons) désigne l'opération qui transforme une chaîne de caractères en une séquence d'unités discrètes appelées tokens, seules entités qu'un grand modèle de langage (LLM) sait réellement manipuler. Un modèle de type Transformer ne « lit » jamais du texte : il consomme des identifiants entiers issus d'un vocabulaire fixe, généralement compris entre 32 000 et 200 000 entrées, que la couche d'embedding convertit ensuite en vecteurs numériques. La tokenization est donc la frontière exacte entre le monde du langage naturel et celui du calcul matriciel.

Cette étape n'a rien d'anodin en cybersécurité : elle conditionne la longueur du contexte disponible, le coût facturé par appel d'API, la latence de traitement, et surtout elle constitue une surface d'attaque à part entière, exploitée par plusieurs techniques de contournement de garde-fous.

Fonctionnement technique

Les LLM modernes n'utilisent ni la segmentation par mots (vocabulaire trop volumineux, incapacité à traiter un mot inconnu) ni la segmentation par caractères (séquences trop longues). Ils s'appuient sur des algorithmes de sous-mots (subword tokenization) :

• BPE (Byte Pair Encoding) : on part des octets ou caractères isolés, puis on fusionne itérativement la paire de symboles la plus fréquente du corpus d'entraînement. Après quelques dizaines de milliers de fusions, on obtient un vocabulaire mixte de mots complets, de radicaux et de fragments. La variante byte-level BPE opère sur les octets UTF-8 bruts, ce qui garantit qu'aucune entrée n'est hors vocabulaire, y compris des données binaires ou des émojis.
• SentencePiece : bibliothèque qui traite le texte comme un flux continu sans pré-segmentation par espaces (l'espace est encodé par le méta-caractère ▁). Elle implémente BPE ainsi que le modèle Unigram, qui part d'un vocabulaire large et élague les tokens dont la suppression dégrade le moins la vraisemblance du corpus. Son intérêt majeur : la réversibilité totale et l'indépendance vis-à-vis de la langue, précieuse pour le japonais ou le thaï, dépourvus de séparateurs.
• WordPiece : variante historique de BERT, proche de BPE mais fusionnant selon un critère de vraisemblance plutôt que de fréquence brute.

Le vocabulaire est figé à l'entraînement : un modèle ne peut jamais produire un token absent de sa table. Des tokens spéciaux (<|endoftext|>, <s>, [MASK], marqueurs de rôle système/utilisateur) délimitent les segments d'une conversation — et leur injection non filtrée dans une entrée utilisateur est précisément un vecteur d'attaque.

Exemples concrets

La règle empirique en anglais est d'environ 4 caractères par token, soit ~750 mots pour 1 000 tokens. Le français, plus riche en accents et en flexions, coûte typiquement 15 à 30 % de tokens supplémentaires pour un contenu équivalent.

• cybersecurity → souvent 2 tokens (cyber + security), alors que cybersécurité peut en consommer 4 à 6 à cause du caractère accentué encodé sur deux octets UTF-8.
• Un identifiant technique comme CVE-2024-3094 se fragmente en 5 à 7 tokens : chiffres et tirets sont découpés agressivement.
• Une clé d'API ou un hash SHA-256 explose littéralement en dizaines de tokens, ce qui explique le coût élevé de l'analyse de logs bruts par LLM.
• Le fameux échec du comptage des « r » dans « strawberry » vient de là : le modèle voit trois tokens opaques, pas dix lettres.

Implications pour la sécurité

Plusieurs classes de vulnérabilités s'ancrent directement dans la couche de tokenization :

• Contournement de filtres : un mot interdit par une liste noire textuelle peut être re-segmenté par insertion de caractères invisibles (espaces de largeur nulle, homoglyphes Unicode, marques de direction). Le filtre en amont ne reconnaît plus le motif, le modèle comprend toujours l'intention — un scénario classique de prompt injection.
• Glitch tokens : tokens présents dans le vocabulaire mais quasi absents des données d'entraînement (le cas historique SolidGoldMagikarp). Leur embedding non entraîné provoque des comportements erratiques, parfois une évasion des alignements de sécurité.
• Token smuggling : encodage d'une charge utile en Base64, ROT13 ou fragments concaténés, que le modèle recompose après avoir franchi les contrôles.
• Déni de service économique : un attaquant soumettant des entrées pathologiques (texte adversarial maximisant le ratio tokens/caractères) fait exploser la facture d'API et sature la fenêtre de contexte.
• Fuite de données : le comptage de tokens en sortie constitue un canal auxiliaire exploitable pour inférer la longueur de réponses chiffrées en streaming.

Bonnes pratiques

• Normaliser avant de filtrer : appliquer une normalisation Unicode NFKC, supprimer les caractères de contrôle et les espaces de largeur nulle avant tout contrôle de contenu, afin d'éliminer les variantes homoglyphes.
• Compter côté serveur : mesurer la taille réelle des entrées avec le tokenizer exact du modèle cible (bibliothèques tiktoken, tokenizers ou sentencepiece) plutôt que d'estimer en caractères, et imposer un plafond strict par requête et par utilisateur.
• Neutraliser les tokens spéciaux : échapper systématiquement les marqueurs de rôle et de fin de séquence présents dans les données non fiables, pour empêcher un utilisateur de simuler une instruction système.
• Budgétiser et journaliser : instrumenter la consommation de tokens par appel, poser des quotas et des alertes de dérive — un pic anormal est souvent le premier signal d'un abus ou d'une boucle d'agent incontrôlée.
• Optimiser les coûts : privilégier des prompts concis, exploiter la mise en cache de préfixes lorsque le fournisseur la propose, et éviter d'injecter des artefacts binaires ou des logs bruts non prétraités.

Comprendre la tokenization n'est donc pas une curiosité académique : c'est un prérequis pour dimensionner correctement une architecture RAG, maîtriser le budget d'une plateforme d'IA générative, et défendre une application contre les attaques référencées par l'OWASP Top 10 for LLM Applications.