Le byte-pair encoding (BPE) est l'algorithme sous-mot que la plupart des tokenizers modernes utilisent pour découper le texte en tokens qu'un modèle de langage lit réellement. Il part des octets bruts et, pendant l'entraînement, repère de façon répétée la paire de symboles adjacents la plus fréquente et la fusionne en un nouveau symbole. Faites cela quelques dizaines de milliers de fois et vous obtenez un vocabulaire où les mots courants (« the », « import », « return ») survivent en tant que tokens uniques tandis que les chaînes rares se brisent en morceaux plus petits.Le mécanisme est presque gênant de simplicité — il a commencé sa vie comme une astuce de compression de données en 1994 avant que le NLP ne l'emprunte — et c'est précisément pourquoi il l'a emporté. Il n'a besoin d'aucune règle propre à une langue, il ne tombe jamais sur un mot inconnu (au pire, il se replie sur les octets individuels), et la table de fusion est minuscule. Quand on dit qu'un modèle « pense en tokens », le BPE est généralement la chose qui a décidé où tombent les frontières des tokens.
Pourquoi c'est important en 2026
C'est important parce que le BPE est la raison pour laquelle votre code coûte plus de tokens que votre prose, et les tokens sont ce que vous payez. C'est du texte anglais qui a entraîné les tables de fusion, donc une phrase ordinaire tient en ≈4 caractères par token. Le code source n'a pas droit à cette affaire : les identifiants en snake_case, l'indentation profonde, les séries de ponctuation });, et les symboles en CamelCase qui ne sont jamais apparus assez souvent pour mériter leur propre fusion se brisent tous en plusieurs tokens chacun. J'ai mesuré la même logique coûtant 30 à 50 % de tokens en plus en tant que code que sa description en anglais ne l'aurait fait — et aux tarifs de Claude Opus 4.8 de 5 $ / 25 $ par MTok, ou de GPT-5.5 à 5 $ / 30 $, ce surcoût atterrit directement sur la facture chaque fois qu'un agent relit un fichier.C'est toute la raison pour laquelle j'ai construit Tokenade. Une fois que vous acceptez que le BPE va être coûteux sur le code, le levier est d'arrêter de faire passer autant de tokens de code à travers : Tokenade utilise la semantic code search et la skeleton compression pour alimenter l'agent avec les quelques fonctions qui comptent au lieu de fichiers entiers, filtre la sortie des outils avant qu'elle ne ré-entre dans le context window, et charge les outils MCP de façon paresseuse — avec un dashboard pour que vous puissiez voir les tokens économisés plutôt que de me croire sur parole. Il s'intègre à Claude Code, Cursor, Codex, Copilot et Windsurf, le tier gratuit couvre ~20M tokens/mois, et le code source est sous licence MIT pour que vous puissiez lire exactement ce qu'il envoie.
Quand NE PAS l'utiliser (ou s'en soucier)
Pour des estimations de coût approximatives — si vous avez seulement besoin d'un ordre de grandeur, la règle des ≈4 caractères par token est suffisamment proche ; vous n'avez pas besoin de penser aux tables de fusion.
Comparer les comptes de tokens entre fournisseurs — les vocabulaires BPE diffèrent d'un modèle à l'autre, donc « 1 000 tokens » sur un tokenizer n'est pas le même texte que 1 000 sur un autre. Comptez avec le bon tokenizer ou ne comparez pas.
Comme quelque chose que vous pouvez régler — vous ne pouvez généralement pas modifier le vocabulaire BPE d'un modèle, donc optimiser l'encodeur lui-même est une impasse. Dépensez cette énergie à envoyer des tokens moins nombreux et plus denses à la place.