# BPE (Byte-Pair Encoding)

> Le byte-pair encoding (BPE) est l'algorithme sous-mot que la plupart des tokenizers utilisent pour découper le texte en tokens en fusionnant de façon répétée les paires d'octets adjacentes les plus fréquentes.

Source: https://tokenade.net/fr/glossary/bpe · Updated: 2026-10-16

## Qu'est-ce que le BPE (byte-pair encoding) ?

Le byte-pair encoding (BPE) est l'algorithme sous-mot que la plupart des [tokenizers](https://tokenade.net/fr/glossary/tokenizer) modernes utilisent pour découper le texte en [tokens](https://tokenade.net/fr/glossary/token) 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 5.5 de 4 $ / 20 $ par MTok, ou de GPT-5.5 à 5 $ / 30 $ (prix catalogue d'octobre 2026), ce surcoût atterrit directement sur la facture chaque fois qu'un agent relit un fichier.

La table de fusion n'est pas figée d'une génération de modèles à l'autre non plus. La documentation tarifaire d'Anthropic indique que Claude 4.7 et les modèles suivants utilisent un nouveau tokenizer qui produit environ 30 % de tokens en plus pour le même texte que celui de Sonnet 4.6 et des modèles antérieurs. Même fichier, nouveau vocabulaire, compteur plus élevé — c'est pourquoi un budget de tokens mesuré sur le modèle de l'an dernier ne se transpose pas tel quel.

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](https://tokenade.net/fr/glossary/semantic-code-search) et la skeleton compression pour alimenter l'agent avec les quelques fonctions qui comptent au lieu de fichiers entiers. Il [filtre la sortie des outils](https://tokenade.net/fr/glossary/output-filtering) avant qu'elle ne ré-entre dans le [context window](https://tokenade.net/fr/glossary/context-window), et compacte de la même façon les résultats MCP. `tokenade dashboard` ouvre un rapport local et graphique des tokens économisés, pour que vous n'ayez pas à me croire sur parole. Il s'intègre à Claude Code, Cursor, Codex, Copilot et Windsurf, il est gratuit et open source (MIT/Apache-2.0), et la compaction tourne entièrement sur votre machine : rien de votre code n'est envoyé nulle part. {/* measured CTA */}

## 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.

## Voir aussi

- [Glossaire : Tokenizer](https://tokenade.net/fr/glossary/tokenizer)
- [Glossaire : Token](https://tokenade.net/fr/glossary/token)
- [Glossaire : Context window](https://tokenade.net/fr/glossary/context-window)
- [Article : Comment réduire la consommation de tokens d'un agent de codage IA](https://tokenade.net/fr/articles/reduce-ai-coding-agent-token-usage)