Le français vous coûte plus cher que l'anglais : la taxe cachée des tokenizers

Prenez un texte en anglais. Traduisez-le en français, fidèlement, sans rien ajouter. Envoyez les deux versions au même modèle d'intelligence artificielle.

La version française vous coûtera plus cher. Pas parce qu'elle est plus longue à lire — parce que la machine la découpe en davantage de morceaux.

Ce surcoût n'est ni une rumeur ni une impression : il est mesuré, publié, et il porte un nom dans la littérature scientifique — la taxe du tokenizer. Il pèse sur chaque requête que vous envoyez en français, et il ne figure sur aucune grille tarifaire.

Plus troublant encore : ce n'est pas seulement une question d'argent. Les langues les plus coûteuses à découper sont aussi celles sur lesquelles les modèles obtiennent les moins bons résultats. Vous payez plus, et vous recevez moins.

Voici ce que dit la recherche, ce que cela vous coûte réellement, et ce que vous pouvez y faire.

Un rappel de trente secondes : le token

Un modèle de langage ne lit pas des lettres ni des mots. Il lit des tokens — des fragments de texte issus d'un découpage appris pendant l'entraînement.

Le mot « bonjour » peut constituer un seul token, ou se découper en « bon » et « jour », selon le vocabulaire du modèle. Un mot fréquent dans les données d'entraînement obtient généralement son propre token. Un mot rare est fragmenté.

Et c'est là que tout se joue : le vocabulaire est appris majoritairement sur de l'anglais.

Ce n'est pas une décision hostile, c'est une conséquence mécanique. Les corpus d'entraînement sont massivement anglophones. L'algorithme qui construit le vocabulaire — le plus souvent une variante du byte-pair encoding — attribue ses places aux séquences les plus fréquentes. L'anglais rafle la mise, les autres langues se partagent le reste.

Ce que mesure la recherche

Plusieurs travaux récents ont quantifié le phénomène sur un large échantillon de langues. Les résultats convergent.

Une étude portant sur les langues européennes établit une hiérarchie nette de la fertilité — le nombre de tokens nécessaires par mot :

Famille de langues	Tokens par mot
Anglais	~1,2
Langues romanes (français, espagnol, italien…)	~1,5 à 1,7
Langues germaniques	~1,7 à 1,9
Langues slaves	~2,2 à 2,5
Langues ouraliennes et baltes	~2,7 à 3,0

Le français se situe donc dans la première tranche au-dessus de l'anglais — la moins pénalisée, mais pénalisée tout de même.

D'autres mesures, sur des modèles différents, confirment l'ordre de grandeur. Sur un grand modèle de la famille Llama, le français demande environ 2,03 tokens par mot contre 1,39 pour l'anglais. Sur une autre génération, le nombre de caractères couverts par un token tombe d'environ 4,9 en anglais à 3,6-3,8 en français, en espagnol et en portugais.

En synthèse : comptez entre 25 % et 45 % de tokens supplémentaires en français, pour un contenu équivalent. Le chiffre exact dépend du modèle, et c'est précisément pourquoi il faut le mesurer plutôt que le supposer — nous expliquons comment plus bas.

Et le français s'en sort bien. Les langues à écriture non latine encaissent des multiplicateurs sans commune mesure : certaines langues indiennes atteignent un facteur huit, et jusqu'à treize pour le malayalam, ce qui réduit leur fenêtre de contexte utile à une fraction de celle dont dispose un anglophone.

Pourquoi les accents coûtent cher

Le français cumule plusieurs handicaps face à un découpage conçu pour l'anglais. Ils sont identifiables, et le premier est purement mécanique.

Les caractères accentués pèsent deux octets. Les modèles travaillent sur du texte encodé en UTF-8, où les caractères de l'alphabet anglais tiennent sur un octet — mais où é, è, à, ç, ô en occupent deux.

Tant que le vocabulaire du modèle contient une entrée pour la séquence accentuée, aucune conséquence. Mais quand il n'en contient pas — parce que le mot est rare dans les données d'entraînement —, le découpage retombe au niveau de l'octet. Et un seul caractère accentué produit alors deux tokens à lui tout seul.

C'est le mécanisme que la recherche décrit comme des fusions de séquences qui échouent, laissant le texte éclaté en fragments d'un octet. Un mot français peu fréquent et fortement accentué peut ainsi coûter plusieurs fois ce que coûterait son équivalent anglais.

Les élisions et la ponctuation interne fragmentent. l'entreprise, aujourd'hui, qu'il : l'apostrophe est un point de découpe naturel. Là où l'anglais écrit the company en deux tokens propres, le français produit facilement trois morceaux pour l'entreprise.

Le français est plus long, à contenu égal. C'est un fait de traduction connu bien avant l'intelligence artificielle : une traduction française d'un texte anglais est typiquement plus longue de 15 à 20 %. Ce foisonnement s'ajoute à la taxe de tokenisation au lieu de s'y substituer — les deux effets se cumulent.

Les accords grammaticaux multiplient les formes. grand, grande, grands, grandes sont quatre chaînes distinctes là où l'anglais n'a que big. Un vocabulaire de taille fixe ne peut pas offrir une entrée dédiée à chaque variante, et les formes les moins fréquentes se retrouvent fragmentées.

Aucun de ces quatre facteurs n'est corrigeable de votre côté. Ils expliquent en revanche pourquoi le surcoût est structurel, et pourquoi il ne disparaîtra qu'avec des vocabulaires conçus autrement.

Trois conséquences, dont deux que personne ne mentionne

Le coût, la partie visible

C'est la conséquence évidente, et la seule habituellement citée. Vous payez au token. Vous consommez plus de tokens. Votre facture augmente d'autant.

Reprenons un cas que nous avons chiffré dans un précédent article : une équipe de développement dont l'usage agentique revient à environ 700 dollars par développeur et par mois avec un modèle haut de gamme, sur la base des tarifs officiels relevés le 7 août 2026.

Si le contenu traité est en français plutôt qu'en anglais — documentation, commentaires, tickets, échanges —, appliquez une majoration de l'ordre de 30 %. Vous passez à environ 900 dollars. Sur une équipe de dix personnes, l'écart annuel dépasse vingt mille dollars.

Personne ne l'a décidé. C'est une propriété du découpage.

La fenêtre de contexte rétrécit

Voici la première conséquence dont on ne parle jamais, et elle est plus gênante que la première.

Les éditeurs annoncent des fenêtres de contexte en tokens : un million chez plusieurs d'entre eux. Mais un million de tokens, ce n'est pas une quantité de texte — c'est une quantité de fragments.

Si le français consomme 30 % de tokens en plus, alors votre fenêtre d'un million de tokens contient environ 30 % de texte français en moins que la même fenêtre remplie d'anglais.

Autrement dit, la capacité annoncée n'est pas la capacité que vous obtenez. Deux utilisateurs du même modèle, l'un travaillant en anglais et l'autre en français, ne disposent pas de la même mémoire de travail — alors qu'ils paient le même tarif affiché et lisent la même fiche technique.

Pour les langues à écriture non latine, l'effet devient sévère : la recherche évoque des fenêtres utiles réduites à une petite fraction de celle des anglophones.

La qualité baisse

C'est la conséquence la plus contre-intuitive, et elle est documentée.

On pourrait croire que le découpage n'affecte que le compteur. Les travaux disponibles suggèrent autre chose : les langues moins coûteuses à tokeniser obtiennent aussi de meilleurs résultats. Le surcoût et la sous-performance vont de pair.

Le mécanisme est plausible et cohérent avec ce que l'on sait du fonctionnement de ces modèles. Un mot fragmenté en cinq morceaux arbitraires est plus difficile à traiter qu'un mot représenté par un token unique : la structure sémantique est diluée dans la découpe. La recherche pointe en particulier les fusions de séquences qui échouent et laissent le texte éclaté en fragments d'un seul octet.

Il faut rester prudent sur l'interprétation. La tokenisation n'est pas seule en cause : les langues moins présentes dans les corpus d'entraînement souffrent aussi d'un déficit de données, et les deux facteurs sont difficiles à démêler. Mais la corrélation est mesurée, et elle va dans le mauvais sens pour nous.

Ce qui change d'un modèle à l'autre

La taxe n'est pas une constante universelle. Elle dépend du vocabulaire de chaque modèle, et les écarts entre familles sont importants.

Les vocabulaires récents et conçus pour le multilingue réduisent sensiblement la pénalité. La recherche mesure par exemple une réduction substantielle de la taxe sur les langues indiennes avec les vocabulaires plus récents, comparés à ceux de la génération précédente.

Conséquence pratique directe : deux modèles au même tarif affiché peuvent avoir des coûts réels différents en français, selon la qualité de leur découpage. Un modèle légèrement plus cher au token mais nettement plus efficace en français revient moins cher à l'usage.

Aucun comparatif ne mesure cela. Vous pouvez le faire vous-même en une demi-heure.

Un autre effet, moins connu, mérite attention : les éditeurs changent parfois de vocabulaire entre deux générations de modèles. Anthropic documente ainsi qu'un de ses passages de génération produit sensiblement plus de tokens pour un même texte — le tarif par token n'ayant pas changé, le coût d'une requête identique augmente malgré tout. Une facture qui grimpe après une migration de modèle n'est donc pas nécessairement une anomalie.

Mesurez-le sur vos propres textes

Rien de ce qui précède ne remplace une mesure. Les fournisseurs exposent tous un moyen de compter les tokens d'un texte donné, sans consommer de génération.

Le protocole tient en quatre étapes et une demi-heure.

Prenez un texte représentatif de votre usage réel — un vrai document, pas un paragraphe de test. Comptez ses mots.

Faites-le compter par l'API de comptage de chaque modèle candidat. Vous obtenez un nombre de tokens.

Divisez les tokens par les mots : vous obtenez la fertilité, directement comparable aux chiffres de recherche cités plus haut.

Recommencez avec la traduction anglaise du même texte. Le rapport entre les deux fertilités, c'est votre taxe personnelle — pas celle d'une étude, la vôtre, sur vos contenus.

Cette mesure a une vertu supplémentaire : elle vous donne une base fiable pour estimer vos coûts avant de vous engager, au lieu de projeter des ordres de grandeur relevés sur des textes anglais.

Cinq façons de réduire la note

La taxe est structurelle, mais son effet sur votre facture ne l'est pas entièrement.

Choisissez le modèle sur sa fertilité en français, pas seulement sur son tarif. C'est le levier le plus puissant, et le seul que personne n'active parce que personne ne mesure. Un écart de 15 % de fertilité entre deux modèles annule un écart de 15 % de tarif.

Mettez en cache vos préambules. Vos instructions système, vos conventions, votre documentation de référence sont refacturées à chaque appel tant qu'elles ne sont pas mises en cache — et elles sont en français, donc surtaxées. C'est là que le cache rapporte le plus.

Ne traduisez pas inutilement vers l'anglais. L'idée circule : rédiger les prompts en anglais pour économiser. Elle se défend arithmétiquement pour les instructions système, longues et stables. Elle se défend beaucoup moins pour le contenu utilisateur, qu'il faudrait traduire — au prix d'un appel supplémentaire, d'une perte de nuance, et d'une réponse à retraduire. Mesurez avant de vous convaincre.

Soyez concis dans vos instructions. Une consigne de trois cents mots en français coûte davantage que la même en anglais, et davantage encore que la même en cent cinquante mots. La concision rapporte double.

Surveillez la sortie autant que l'entrée. Les tokens produits coûtent cinq à six fois ceux que vous envoyez, et une réponse en français est elle aussi surtaxée. Demandez explicitement des réponses courtes : c'est la ligne d'instruction la plus rentable de votre prompt.

Le cas des langues africaines

Un mot sur une question que la recherche traite peu et que les comparatifs ignorent totalement.

Si le français paie une taxe modérée, les langues africaines — wolof, lingala, bambara, peul, et des centaines d'autres — se situent bien plus loin sur l'échelle. Elles sont faiblement représentées dans les corpus d'entraînement, donc mal servies par les vocabulaires, donc fragmentées à l'excès.

Les mesures disponibles sur d'autres familles de langues peu dotées donnent l'ordre de grandeur du problème : des multiplicateurs de cinq, huit, parfois davantage. À ce niveau, ce n'est plus une taxe, c'est une barrière — le coût par requête et le rétrécissement de la fenêtre rendent certains usages économiquement irréalistes.

Nous n'avancerons pas de chiffres précis pour ces langues, faute de mesures publiées que nous puissions vérifier. Nous signalons le problème, parce qu'il concerne directement une partie de nos lecteurs et qu'il ne se réglera pas tout seul.

C'est aussi l'un des arguments les plus solides en faveur des modèles à poids ouverts : un vocabulaire peut être réentraîné, un modèle peut être ajusté sur une langue donnée. Cela demande des compétences et des données, mais c'est possible — ce qui n'est pas le cas avec une API fermée.

Questions fréquentes

Dois-je écrire mes prompts en anglais pour économiser ?

Pour les instructions système — longues, stables, réutilisées à chaque appel — l'arithmétique le justifie parfois, et la plupart des modèles récents suivent aussi bien une consigne en anglais qu'en français. Pour le contenu utilisateur, presque jamais : traduire suppose un appel supplémentaire, une perte de nuance, et une réponse à retraduire. Vous déplacez le coût au lieu de le supprimer. Mesurez les deux configurations sur vingt requêtes réelles avant de trancher.

Le modèle répond-il moins bien si je l'interroge en français ?

La recherche établit une corrélation entre coût de tokenisation et qualité des réponses, mais elle ne permet pas d'isoler la part imputable au découpage de celle imputable au volume de données d'entraînement. En pratique, les grands modèles récents sont solides en français. Le seul verdict qui compte reste une comparaison à l'aveugle sur vos propres tâches.

Est-ce que cela concerne aussi les images et l'audio ?

Non, pas de la même façon. La taxe décrite ici est propre au texte. Les images et l'audio sont convertis en tokens selon d'autres mécanismes, indépendants de la langue. En revanche, le texte contenu dans une image — une capture d'écran de document, par exemple — sera bien soumis à la tokenisation une fois transcrit.

Pourquoi les éditeurs n'en parlent-ils pas ?

Il n'y a probablement rien à cacher : les tarifs sont annoncés au token, et le nombre de tokens dépend du texte envoyé. La grille est exacte. Ce qui manque, c'est la traduction de cette exactitude en langage utilisateur — personne n'écrit « votre fenêtre d'un million de tokens contient environ 30 % de texte français en moins ». C'est vrai, ce n'est écrit nulle part, et c'est précisément le genre de chose qu'un média spécialisé devrait dire.

Est-ce que ça s'améliore ?

Oui, mesurablement. Les vocabulaires récents réduisent sensiblement la pénalité par rapport à ceux d'il y a deux ans, et des travaux portent spécifiquement sur des découpages plus équitables entre langues. Le sens de l'évolution est bon ; le rythme dépend de la priorité que les éditeurs accordent au multilingue.

Comment savoir si mon fournisseur actuel est bon en français ?

Comptez. Prenez un de vos documents réels, faites-en compter les tokens par chaque modèle candidat, divisez par le nombre de mots. Une demi-heure de travail, et vous saurez lequel vous coûte le moins cher sur vos textes — une information qu'aucun comparatif ne vous donnera.

Ce que cela dit de l'écosystème

Un dernier point, qui dépasse la question du budget.

L'infrastructure de l'intelligence artificielle générative n'est pas neutre linguistiquement. Elle a été construite en anglais, sur de l'anglais, et cette origine se paie — littéralement — par tous ceux qui travaillent dans une autre langue.

Ce n'est pas une conspiration, c'est une conséquence de l'histoire technique du domaine. Mais c'est une asymétrie réelle, mesurable, et rarement nommée : les francophones subventionnent, requête après requête, un système optimisé pour d'autres.

La bonne nouvelle est que le problème est identifié et traité. Des travaux portent spécifiquement sur des découpages plus équitables entre langues, et les vocabulaires récents font mesurablement mieux que ceux d'il y a deux ans. La direction est la bonne.

En attendant, la seule réponse à votre portée consiste à mesurer, à choisir en connaissance de cause, et à cesser de croire que le tarif affiché est le prix que vous payez.

---

Note de méthode

Les mesures de fertilité citées dans cet article proviennent de travaux de recherche publiés sur arXiv, référencés ci-dessous. Nous rapportons les ordres de grandeur qu'ils établissent, sans les recalculer nous-mêmes.

La fourchette de 25 à 45 % de surcoût pour le français est une synthèse des sources citées, qui portent sur des modèles et des méthodologies différentes. Elle constitue un ordre de grandeur, pas une constante : la valeur exacte dépend du modèle, du domaine et du type de texte. Nous indiquons comment la mesurer sur vos propres contenus plutôt que de la présenter comme établie.

Nous n'avançons aucun chiffre pour les langues africaines, faute de mesures publiées vérifiables. L'ordre de grandeur évoqué est extrapolé de familles de langues comparables et présenté comme tel.

La corrélation entre coût de tokenisation et qualité des réponses est rapportée par la recherche mais reste difficile à isoler : le déficit de données d'entraînement pour les langues peu dotées est un facteur confondant que les travaux cités ne permettent pas de démêler entièrement.

Les tarifs d'API utilisés dans nos calculs de coût proviennent des pages officielles des éditeurs, relevées le 7 août 2026.

Sources

• The Tokenizer Tax Across European Languages — arXiv 2605.24718
• The Tokenizer Tax: Cross-Lingual Cost of Subword Tokenization for Indian Languages — arXiv 2607.24276
• Language Model Tokenizers Introduce Unfairness Between Languages — arXiv 2305.15425
• Equity with Efficiency: An Empirical Study of Tokenizers for Multilingual LLMs — arXiv 2606.15044
• Parity-Aware Byte-Pair Encoding: Improving Cross-lingual Fairness in Tokenization — arXiv 2508.04796