Le français consomme généralement 15 à 25 % de tokens en plus que l'anglais pour un même contenu, avec des écarts qui peuvent dépasser 30 % sur des textes techniques ou peu ponctués. Concrètement, un texte de 1 000 mots coûte donc plus cher à traiter en français qu'en anglais, à modèle et tarif identiques. Voici pourquoi, avec un exemple chiffré et des ordres de grandeur pour estimer votre facture.
Pourquoi le français consomme plus de tokens que l'anglais
Un token est l'unité de découpage qu'un modèle de langage manipule : ce n'est ni un mot ni un caractère, mais un fragment de texte produit par un tokenizer (l'outil qui convertit le texte brut en tokens). La plupart des modèles récents utilisent un algorithme de type BPE (Byte Pair Encoding, ou encodage par paires d'octets) : il apprend statistiquement les séquences de caractères les plus fréquentes dans un corpus d'entraînement et les fusionne en tokens. Or ces corpus sont massivement anglophones, et le vocabulaire appris est calé sur les mots anglais fréquents, souvent courts.
Résultat : un mot anglais courant comme « the », « and » ou « information » correspond à un seul token, alors qu'un mot français comme « anticonstitutionnellement » ou même « développement » est découpé en plusieurs fragments. Les accents (é, è, à, ç) et les apostrophes typographiques aggravent le phénomène : selon la façon dont le tokenizer gère les octets UTF-8, un caractère accentué peut occuper un ou plusieurs tokens à lui seul. Les langues dont l'orthographe est proche de l'anglais (l'espagnol, l'allemand) s'en sortent un peu mieux que le français sur certains points, mais toutes les langues non anglaises paient un « surcoût de tokenisation ».
Ce surcoût a deux conséquences pratiques. D'abord, il gonfle le nombre de tokens en entrée (le prompt) comme en sortie (la réponse générée), et les tarifs des API sont presque toujours exprimés par million de tokens, avec un prix distinct pour l'entrée et la sortie. Ensuite, il réduit la quantité de texte utile que l'on peut faire tenir dans la fenêtre de contexte (context window, la limite maximale de tokens qu'un modèle peut traiter en une fois). À budget de tokens égal, on traite donc moins de contenu en français.
Exemple chiffré : un même texte dans les deux langues
Prenons un paragraphe de 200 mots rédigé en anglais, puis sa traduction fidèle en français. L'anglais compte environ 1,3 token par mot en moyenne avec les tokenizers usuels, soit environ 260 tokens. Le français, lui, tourne plutôt autour de 1,5 à 1,7 token par mot selon la densité d'accents, de mots composés et de ponctuation : comptez environ 300 à 340 tokens pour les mêmes 200 mots. L'écart est donc d'environ 15 à 30 %.
Passons au coût. Imaginons un tarif d'API de 3 $ par million de tokens en entrée et de 15 $ par million de tokens en sortie (ordre de grandeur courant pour un modèle de milieu de gamme ; vérifiez les grilles tarifaires à jour, elles changent souvent). Pour traiter 10 000 paragraphes de ce type, soit environ 2 millions de mots :
- en anglais : 2 000 000 × 1,3 ≈ 2,6 millions de tokens en entrée, soit environ 7,80 $ en entrée ;
- en français : 2 000 000 × 1,6 ≈ 3,2 millions de tokens en entrée, soit environ 9,60 $ en entrée.
Si l'on ajoute une sortie générée de 300 tokens par paragraphe (3 millions de tokens en sortie), le coût de sortie est identique dans les deux langues si la réponse est de même longueur, mais il augmente mécaniquement si la réponse française est elle aussi plus « tokenisée ». L'écart total reste de l'ordre de 15 à 25 % : sur une facture de 100 $, comptez 15 à 25 $ de surcoût lié à la seule langue. Ces chiffres sont des estimations raisonnées, pas des mesures issues d'un benchmark précis : faites toujours votre propre calcul avec votre tokenizer et votre tarif réels.
Calculer le coût réel avec le token-counter et le calculateur d'API
Un token est l'unité de base traitée par un LLM (grand modèle de langage) : environ un mot court ou un morceau de mot. La tokenisation BPE (Byte Pair Encoding) découpe le texte selon des fréquences apprises, souvent sur des corpus majoritairement anglophones.
Pour estimer un coût, partez toujours de vos propres mesures :
- Comptez les tokens d'entrée avec le token-counter officiel du modèle visé (les tokenizers diffèrent d'une famille de modèles à l'autre : un texte peut donner un nombre différent selon le modèle).
- Estimez les tokens de sortie : la réponse du modèle est facturée séparément, souvent plus cher que l'entrée.
- Appliquez la grille tarifaire du modèle (prix pour 1 million de tokens en entrée / en sortie), puis multipliez par le volume d'appels.
Formule générique (les prix sont à remplacer par ceux de votre fournisseur) :
cout_appel = (tokens_entree / 1_000_000) * prix_entree
+ (tokens_sortie / 1_000_000) * prix_sortie
cout_mensuel = cout_appel * nb_appels_par_mois
Exemple chiffré (hypothèses explicites). Supposons un prompt de 1 000 tokens en anglais qui devient 1 250 tokens en français (écart de +25 %, ordre de grandeur plausible pour du français face à l'anglais avec un tokenizer courant — à vérifier avec votre tokenizer). Sortie identique : 400 tokens dans les deux cas. Prix fictifs pour l'illustration : 2 € / million de tokens en entrée, 8 € / million en sortie.
Anglais : (1000/1e6)*2 + (400/1e6)*8 = 0,002 + 0,0032 = 0,0052 €
Français : (1250/1e6)*2 + (400/1e6)*8 = 0,0025 + 0,0032 = 0,0057 €
Écart par appel : 0,0005 € (+9,6 %)
Sur 100 000 appels/mois : 520 € vs 570 €, soit +50 €/mois
Le surcoût vient surtout de l'entrée ; si votre sortie est longue et en français, l'effet peut être plus marqué. Refaites le calcul avec vos vrais chiffres : c'est le seul moyen d'être précis.
Conseils pour réduire la facture de vos prompts en français
Checklist actionnable :
- Mesurer avant d'optimiser : passer chaque prompt type dans le token-counter et noter entrée/sortie.
- Raccourcir les instructions : supprimer les formules de politesse, les répétitions et les consignes redondantes (elles coûtent à chaque appel).
- Mutualiser le contexte : si un même texte de référence revient, envisagez la mise en cache de prompts quand le fournisseur la propose (facturation réduite sur la partie répétée).
- Limiter la sortie : demander des réponses courtes, plafonner
max_tokens, formater en listes plutôt qu'en paragraphes. - Choisir le bon modèle : un petit modèle suffit souvent pour des tâches simples ; réservez le grand modèle aux cas difficiles.
- Tester l'anglais en interne : pour des instructions système ou des exemples, l'anglais peut être plus compact ; gardez le français pour le contenu visible par l'utilisateur.
- Pré-traiter le texte : retirer le balisage inutile, normaliser les espaces, découper les longs documents en passages pertinents plutôt que tout envoyer.
- Suivre le coût par fonctionnalité : journaliser tokens et coût par appel pour repérer les prompts qui dérapent.
L'objectif n'est pas de « traduire en anglais » à tout prix, mais de réduire les tokens sans perdre en qualité : chaque token économisé sur l'entrée est facturé en moins à chaque appel.
Questions fréquentes
Combien de tokens compte un texte français par rapport à l'anglais ?
À contenu équivalent, comptez en moyenne 1,3 à 1,6 fois plus de tokens pour le français que pour l'anglais avec les tokeniseurs BPE (Byte Pair Encoding, l'algorithme qui découpe le texte en sous-mots) de la plupart des modèles. Autrement dit, là où un texte anglais consomme environ 1 token par mot court et courant, le français tourne souvent autour de 1,3 à 1,8 token par mot selon le vocabulaire, les accents et la longueur des mots. Cette fourchette est une estimation : elle varie selon le modèle et le texte, donc mesurez toujours sur votre propre contenu plutôt que de généraliser.
Pourquoi la tokenisation BPE défavorise-t-elle le français ?
Les tokeniseurs BPE sont entraînés sur de grands corpus où l'anglais domine largement, si bien que les sous-mots anglais fréquents (« the », « ing », « tion ») ont leur propre token, tandis que beaucoup de mots français sont découpés en fragments plus petits. Les accents (é, è, à, ç) et les lettres isolées aggravent le phénomène : un mot comme « dévelopement » mal orthographié ou peu fréquent peut éclater en plusieurs tokens. Résultat : à sens égal, le français produit plus de tokens, donc plus de calcul et un coût plus élevé à tarif identique par token.
Comment estimer le coût d'un appel API pour un texte français ?
La formule de base reste la même dans les deux langues :
coût = (tokens d'entrée × prix entrée) + (tokens de sortie × prix sortie)
La différence vient du nombre de tokens, pas de la tarification. Concrètement : comptez vos tokens avec un token-counter (outil qui applique le tokeniseur du modèle visé), ajoutez la longueur de la réponse attendue en sortie, puis multipliez par les prix au million de tokens affichés par le fournisseur. Comme le français gonfle le compte d'entrée d'environ 30 à 60 %, appliquez ce facteur à vos estimations anglaises pour obtenir un ordre de grandeur, puis vérifiez avec le compteur réel.
Quelles stratégies réduisent le nombre de tokens sans perdre en qualité ?
D'abord, raccourcissez les instructions : supprimez les formules de politesse, les répétitions et le contexte inutile. Ensuite, préférez des consignes directes et un format de sortie contraint (liste, JSON) pour limiter les tokens générés. Mutualisez le contexte stable (règles, glossaire) dans un prompt système réutilisé plutôt que de le recopier à chaque appel. Enfin, choisissez le modèle le plus petit qui suffit à la tâche et, pour les gros volumes, testez une reformulation en anglais des seules instructions techniques : le contenu français reste en français, mais les consignes coûtent moins cher.
Le français coûte-t-il plus cher avec tous les modèles LLM ?
Le surcoût existe avec la quasi-totalité des modèles, mais son ampleur varie : les tokeniseurs les plus récents et les mieux couverts multilingues réduisent l'écart, sans l'annuler. En pratique, le français reste plus cher à contenu égal, mais la différence dépend du modèle, du type de texte (le français courant et bien orthographié s'en sort mieux que le jargon) et du ratio entrée/sortie de votre usage. Le réflexe utile n'est donc pas de fuir le français, mais de mesurer sur votre cas réel et d'optimiser les prompts.