🌐 Nolife Langage - Ne parlez pas de coût, mais d'investissement.

le 6 septembre 2026

🌐 Nolife Langage - Ne parlez pas de coût. Parlez d'investissement.

Le chiffre ne change pas. C’est le contexte qui change.

Coût donne l’impression d’une perte. Investissement donne l’impression d’une action que vous alliez de toute façon entreprendre, avec un retour sur investissement à la clé. Basique donne l’impression d’une option de second ordre. Indispensable donne l’impression de ce dont vous avez besoin. Standard est générique. Personnalisé a été conçu spécialement pour vous.

J’ai entendu cet argumentaire dans une vidéo de vente :

Ne dites pas « 1 000 $ », dites « 999 $ », ça semble moins cher. Ne dites pas « achetez maintenant », dites « il n’en reste plus que trois ». Ne dites jamais le mot « basique », dites « essentiel ». Ne dites jamais « standard », dites toujours « sur mesure ». Le mot « peu », ne le dites pas, dites toujours « en quantité limitée ». Et n’utilisez jamais le mot « coût », dites toujours « investissement ».

Les mots ont leur importance quand on essaie d’inciter les gens à acheter. Je voulais savoir ce qui se passe lorsque le lecteur n’est pas seulement un être humain, mais aussi un tokeniseur.

La première surprise est venue de l’allemand. Sur ce corpus, avec l’encodage o200k_base, le mot maßgeschneidert, plus percutant sur le plan commercial, a pris cinq tokens. Standard n’en a pris qu’un. Soit +400 %. Unverzichtbar pour Basis est passé de 1 à 4. Le discours commercial s’est amplifié. Le compteur de tokens a évolué dans le sens inverse.

 signification
 |
 |
coût en tokens ----+---- persuasion

Il s’agit là de trois axes différents. Une expression peut gagner sur l’un et perdre sur un autre. Cet article est la petite expérience de Darkwood qui a tenté de les garder séparés.

Les mots ont déjà un prix

Les six substitutions en anglais ne constituent pas un jeu de cartes. Elles forment un laboratoire : suffisamment petit pour être tokenisé, suffisamment intéressant sur le plan sémantique pour faire l’objet d’un débat.

Je n’ai pas effectué de test A/B sur le taux de conversion. Je ne prétends pas que la question psychologique soit tranchée. Je prétends simplement que ces substitutions méritent d’être prises en compte.

En anglais, « coût » → « investissement » est l’exemple le plus clair : même idée, cadre différent. Sur « o200k_base », cela n’a pas non plus d’incidence pour le tokeniseur. Les deux versions ont été mesurées à 1 token. Le nombre n’a pas bougé. Le message a tout de même changé.

« $1 000 » → « $999 » a eu un double effet : un prix plus attractif et moins de tokens (4 → 2). La rareté a pris le sens inverse. « Acheter maintenant » correspond à 2 tokens ; « Plus que trois en stock » en compte 3.

C’est déjà le triangle. Le sens peut rester proche. La persuasion peut s’intensifier. Les tokens peuvent augmenter, diminuer ou rester inchangés.

Ensuite, le modèle attribue un autre prix aux mots

Les API et les fenêtres de contexte ne facturent pas au mot. Elles facturent en tokens : des fragments de texte obtenus après qu’un tokeniseur a découpé la chaîne de caractères. Un tokeniseur n’est pas un dictionnaire. C’est une compression de séquences d’octets qu’il a souvent rencontrées. L’anglais est surreprésenté dans cet historique. D’autres langues, et même d’autres orthographes anglaises de la même notion, peuvent se retrouver en un plus grand nombre de fragments.

C’est l’article de Damian Zygmuntowicz sur le coût caché des tokens selon les langues — avec le mot polonais przedsiębiorstwo comme exemple provocateur — qui m’a poussé à me pencher sur la question. Je n’ai pas reproduit les comptages en polonais. Darkwood est disponible en anglais, en français et en allemand. Ce sont ces langues que j’ai mesurées.

L’unité de mesure a son importance. Les caractères ne sont pas des tokens. Les mots ne sont pas des tokens. Les tokens d’entrée ne sont pas les tokens de sortie. Les accès au cache ne sont pas des factures. Une heuristique « octets / 4 » est une estimation, pas une mesure. J’ai exécuté localement le BPE d’OpenAI avec « yethee/tiktoken » :

• Principal : o200k_base (famille GPT-4o)
• Secondaire : cl100k_base (famille GPT-4 / 3.5-turbo)

Ce ne sont ni des jetons Claude, ni des jetons Gemini, ni des « jetons LLM universels ». L’encodage fait partie du résultat.

Trois langues, une seule idée

J’ai rédigé deux courts passages parallèles — une annonce d’atelier et une ligne de prix — en anglais, en français et en allemand. Même sens, intentionnellement. Petit corpus : version 1.0.2, hachage 7510f01cf7c3…. Il ne s’agit pas d’une étude statistique du « français » ou de l’« allemand ». Un laboratoire déterministe.

Puis j’ai compté.

Sur ce corpus avec o200k_base, la version anglaise utilisait 46 tokens, la version française 58 (+26,09 % par rapport à l’anglais), et la version allemande 63 (+36,96 % par rapport à l’anglais).

Ces pourcentages s’appliquent à ce corpus et à ce tokeniseur. Ils ne constituent pas une pénalisation du français ou de l’allemand.

L’allemand a utilisé le même nombre de mots que l’anglais, mais davantage de caractères. Il a également utilisé plus de tokens par mot. L’heuristique « octets / 4 » a donné des estimations de 60 / 71 / 76 et a surestimé toutes les langues. Elle a toutefois masqué l’ampleur de l’écart dans le classement.

J’ai même essayé de rendre l’allemand plus naturel. Le remplacement du calque aufgezeichnete Führung par gefilmten Rundgang a réduit le nombre de caractères de 301 à 298 et a augmenté le nombre de tokens o200k_base de 62 à 63. Moins de caractères. Un token de plus. La longueur du texte n’est pas le problème.

Cela dépend du tokeniseur

Mêmes textes, deuxième encodage.

L'anglais est resté à 46. Le français a bondi de +26,09 % à +54,35 %. L'allemand est passé de +36,96 % à +58,70 %. L'encodage précédent était plus sévère pour le français et l'allemand. La prime linguistique n'est pas une propriété du français. C'est une propriété de ce corpus × cet encodage.

C’est là tout l’intérêt d’utiliser deux tokeniseurs. Si je n’avais publié que o200k_base, j’aurais sous-estimé à quel point un même texte en français peut paraître « coûteux » sous cl100k_base.

Maintenant, modifions les mots

J’ai pris les six échanges commerciaux, rédigé leurs équivalents idiomatiques en français et en allemand, puis j’ai étiqueté deux intentions :

• persuasion — modifier le cadre de référence de l’acheteur (peut coûter plus de tokens)
• token_opt — exprimer une idée similaire avec moins de tokens (ce qui peut affaiblir le cadre)

Ne choisissez jamais en silence la formulation la moins coûteuse en la qualifiant de meilleure. La « persuasion » est ici identifiée, et non mesurée. Les lignes « token_opt » sont des hypothèses de laboratoire. Les phrases FR/DE sont des ébauches, et non une étude de traduction.

Quelques lignes sur o200k_base :

Les quatre sommets du triangle, pour cette série :

• Ton commercial plus fort, plus de tokens : « standard » → « sur mesure » ; en allemand « maßgeschneidert » (+400 %).
• Mêmes tokens, cadre différent : en anglais « cost » → « investment » (1 → 1).
• Discours commercial moins percutant, moins de tokens : maßgeschneidert → passend (5 → 2).
• Tarification incitative qui réduit également le BPE : $1 000 → $999 (4 → 2).

La rareté coûte souvent des tokens. En français, achetez maintenant → plus que trois en stock est passé de 3 à 5. Puis token_opt l’a condensé en 3 restants (5 → 3). Des tokens moins coûteux. Un ton de vente moins agressif. Ces deux mesures sont réelles. Une seule d’entre elles est « meilleure », et cela dépend de l’axe qui vous intéresse.

Les lignes rouges sont les plus intéressantes

Neuf des vingt-sept paires de lignes utilisaient plus de tokens après la réécriture. Les neuf relèvent de la persuasion. Aucune ne relève de token_opt.

C'est en allemand que cela devient frappant :

Ce n’est pas un benchmark raté. L’optimisation de la persuasion n’est pas l’optimisation des tokens. Un mot plus percutant sur le plan commercial peut être incompatible avec le tokeniseur. Si j’avais écarté les lignes rouges, j’aurais publié un conte de fées sur une formulation qui permet toujours de faire des économies.

Considéré comme un bloc, le niveau de persuasion sur ce corpus est passé de 36 à 45 tokens (−25 % « économisés », c’est-à-dire que cela coûte plus cher). La persuasion en allemand seule : 12 → 20 (−66,67 %). La persuasion en anglais n’a pas eu d’impact (10 → 10). token_opt a ensuite récupéré des tokens, y compris en allemand (+45,45 % globalement). Plusieurs lignes de token_opt rendent moins coûteuse la même idée que la ligne de persuasion venait de rendre plus coûteuse. C’est le groupe témoin : mêmes idées, intention opposée.

62 → 62

Si je regroupe toutes les paires en un seul total, j’obtiens ceci :

Soixante-deux entrés. Soixante-deux sortis. On dirait que la formulation n’a eu aucun effet.

Ce n’est pas le cas. Les substitutions individuelles ont évolué dans les deux sens. L’agrégat « mixte » les a annulées. Le « mixte » en allemand reste à −13,04 % (23 → 26). Le « mixte » en anglais « économise » toujours 2 tokens. Le zéro toutes langues correspond à la persuasion −9 plus token_opt +9.

C’est un avertissement contre les résumés de référence. Un agrégat peut effacer le phénomène que vous essayez de comprendre. J’ai failli publier « 62 → 62 » comme titre. Cela aurait été malhonnête.

Quel est le coût financier ?

J’ai estimé le coût des paires de jetons — et non des passages — pour un million de requêtes, en utilisant un instantané obsolète de gpt-4o-mini (2 août 2026) : 0,15 $ / 0,60 $ par million de jetons d’entrée / de sortie. Il s’agit d’une estimation, pas d’une facture. Ce corpus est minuscule. Une requête ne coûte qu’une fraction de centime. Je ne vais pas prétendre le contraire.

Pour 1 000 000 de requêtes, toutes langues confondues :

La valeur « mixte » de 0,00 $ correspond à la même annulation en dollars. À cette échelle d’un million de requêtes, la saisie de persuasion en allemand passe à elle seule de 1,80 $ à 3,00 $ (économie de −1,20 $). L’échelle peut rendre une habitude tangible. Ce laboratoire particulier n’est pas en soi une simulation de facturation.

La taxe contextuelle invisible

Le modèle dispose toujours de la même fenêtre contextuelle en jetons. Ce qui change, c’est la quantité de ce contenu en langage naturel qui y tient.

J’ai rempli une fenêtre hypothétique de 100 000 tokens avec des copies de l’offre parallèle. Dénominateur : les tokens mesurés dans le passage, et non les totaux par paire. Il ne s’agit pas d’une fenêtre de contexte de produit. Le français ne dispose pas d’une fenêtre plus petite ; le même budget de tokens contient simplement moins de copies de ce texte en français.

Sur o200k_base :

La même fenêtre de tokens couvre une partie moins importante de ce corpus français, et encore moins de ce corpus allemand. En passant à cl100k_base, la comparaison français vs anglais donne −35,21 % de copies. Le codage modifie le nombre de copies couvertes. Vérification : 100 000 / 63 = 1 587,30 ; 2 173,91 − 1 587,30 = 586,61.

Les économies réalisées sur le corpus de la paire étaient minimes. L’impact sur la capacité est déjà visible.

Caveman et le coût de l’optimisation elle-même

Pour cette expérience, je me suis penché sur Caveman — un projet open source visant à compresser l’écriture des agents de codage, et non un deuxième benchmark que j’aurais effectué sur ce corpus. Je ne l’ai pas porté. L’intérêt réside dans la méthodologie.

Caveman rend compte d’une compression réelle et publie également des cas où la surcharge annule ou inverse les économies réalisées. Une sortie plus courte n’implique pas automatiquement un coût total inférieur. La réduction de la sortie n’est pas une facture. Pour obtenir un écart honnête, il faut un groupe témoin : ils comparent par rapport à une consigne concise, et non par rapport au silence.

C’est pourquoi j’ai séparé persuasion de token_opt, et pourquoi les neuf lignes rouges figurent toujours dans l’article. Si la voie « optimisée » coûte plus cher, il faut le montrer. Un benchmark qui n’affiche que les lignes vertes n’est qu’une brochure.

La variable locale o200k_base correspond toujours à OpenAI BPE exécuté sur ma machine. Il ne s’agit pas d’une facture Claude, même si les évaluations hors ligne de Caveman utilisent le même encodage. Produit différent. Même rigueur : étiqueter le compteur, conserver la régression.

Développement avec Symfony et Darkwood Flow

L’expérience consiste en une petite application console Symfony 8.1 sous PHP 8.5.4. Pas de base de données, pas d’API HTTP, pas de front-end. Tokeniseur : yethee/tiktoken 1.1.1. Orchestration : darkwood/flow 8.1.6, effectivement utilisé — la commande ne peut pas afficher de tableaux si Flow n’a pas été exécuté.

Le pipeline comprend sept tâches :

LoadCorpus
    → TokenizeBefore
    → ApplyCandidates
    → TokenizeAfter
    → Compare
    → EstimateCost
    → Report

Chaque étape est explicite. Chargement des deux passages et des 27 paires. Tokenisation de l’offre parallèle. Enregistrement des remplacements étiquetés déjà présents dans le corpus. Tokeniser chaque paire. Comparer, effectuer une auto-vérification, diviser les agrégats par intention. Estimer le coût. Générer un rapport. La trace affichée en est la preuve : COMPARE : auto-vérification RÉUSSIE.

php bin/console app:language:benchmark
php bin/console app:language:benchmark --format=json

Le fichier JSON est enregistré dans var/benchmark/. Je souhaitais disposer d’une mesure que je puisse faire évoluer sans dissimuler les étapes dans un script nommé run.php.

PHP 8.6 : valeurs par défaut en lecture seule

PHP 8.6 permet à une propriété d’instance ordinaire d’avoir une valeur par défaut :

public readonly string $evidence = 'ESTIMATED';

Sur cette machine, cela génère une erreur de compilation : La propriété en lecture seule Demo::$evidence ne peut pas avoir de valeur par défaut. L'environnement d'exécution est PHP 8.5.4. Je n'ai pas activé la fonctionnalité de la version 8.6.

Une valeur par défaut sur un paramètre de constructeur promu fonctionnait déjà à partir de la version 8.1. Le RFC de la version 8.6 indique que ce n’est pas un objectif : il s’agit d’une valeur par défaut de paramètre, et non d’une valeur par défaut de propriété. PricingAssumptions utilise cette ancienne approche. Dans les deux cas, l’instantané de tarification reste un objet de configuration immuable. Cette note en marge n’affecte pas le nombre de tokens.

PHP utilise des références, pas des pointeurs C

Un zval est une balise de type associée à une valeur. Les chaînes de caractères et les tableaux sont copiés à l’écriture. $alias = $state copie un identifiant d’objet (spl_object_id égal à true ; les deux noms ont vu leurs traces passer de 7 à 8). En PHP, l’opérateur & encapsule un zval dans IS_REFERENCE / zend_reference. $ref++ a incrémenté l’entier ($n est devenu 3). Cela n’a pas parcouru la mémoire.

Une référence PHP n’est pas simplement un pointeur C exposé au code PHP. Flow encapsule chaque retour de tâche dans un nouvel Ip avec $data en lecture seule ; le retour de BenchmarkState réutilise le descripteur. Zend utilise des pointeurs C en interne. Le PHP en espace utilisateur ne vous en fournit pas. php bin/console app:language:benchmark --explain-values affiche ce tableau. Pas de FFI. Cette encadré ne modifie pas non plus le nombre de tokens.

Ce que j’ai appris

Les langues naturelles ne sont pas équivalentes en termes de tokenisation. Sur ce corpus avec o200k_base, le français utilisait 58 tokens là où l’anglais en utilisait 46, et l’allemand 63. Modifiez l’encodage et le « premium » évolue en conséquence.

La persuasion et l’efficacité en termes de tokens peuvent entrer en conflit. Maßgeschneidert est un meilleur mot de vente, mais un moins bon citoyen du BPE. Le mot anglais investment est neutre. Une tarification « de charme » peut accidentellement aider les deux axes. Les textes jouant sur la rareté n’y parviennent souvent pas.

Le nombre de caractères est un piètre substitut à un véritable tokeniseur. La phrase allemande, plus naturelle, comptait moins de caractères mais plus de tokens. La formule octets / 4 a surestimé toutes les langues et aplani l’écart.

Les agrégats peuvent masquer des tendances opposées. 62 → 62 est une annulation, et non pas « le choix des mots n’a pas d’importance ». Séparez les intentions, sinon vous optimiserez un zéro.

L’efficacité contextuelle importe même lorsque le corpus de paires est minuscule. La même fenêtre de tokens contient moins d’exemplaires de ce texte en français, et encore moins de celui en allemand.

L’optimisation a son propre surcoût. Publiez la ligne en rouge.

Je n’ai pas mesuré l’utilisation en temps réel du prestataire, le taux de conversion ni une traduction professionnelle. La prochaine expérience honnête, si j’en mène une, portera sur une seule paire EN/FR/DE fournie par un prestataire sur les mêmes passages.

D’ici là : mesurez la charge de travail réelle avant de l’optimiser. Et lorsque le total combiné reste inchangé, examinez les lignes.

Sources

• 3 publications LinkedIn
• tiktoken-php
• Caveman
• Code source : https://github.com/matyo91/nolife-language
• Diapositives : https://github.com/matyo91/slidewire