Les tokens ne sont pas une monnaie. Ce sont des lignes de code avec une facture jointe.

Nisha Talagala vient de publier dans Forbes un primer sur les tokens où elle défend que les tokens — l'unité de coût et de mesure de la consommation des LLM — deviennent une monnaie d'entreprise fondamentale. Elle introduit le terme tokenmaxxing, signale que des entreprises évaluent déjà publiquement leurs employés à l'usage de tokens, et pose un cadre sage de budgets, suivi et arbitrages. Comme primer, c'est correct. Comme feuille de route pour une organisation d'ingénierie qui doit livrer sous contrainte budgétaire, c'est la version la plus polie d'une idée très dangereuse.

L'idée dangereuse : que l'usage de tokens mesure le travail. Non. Il mesure la facture. Du siège de quelqu'un qui a dû défendre une ligne de coût IA devant un CFO et une rotation SRE la même semaine, le cadrage compte plus que les chiffres — et Forbes n'a raison qu'à moitié.

Ce que Forbes a bon

Trois choses dans l'article sont justes et devraient déjà être sur la feuille de route de tout CTO :

1. La dépense en tokens est réelle et croît. L'article cite qu'une simple révision d'email consomme ~100 tokens, à un coût d'environ 0,25 centimes US par tâche. Multiplie ça par chaque employé, chaque workflow, chaque retry, chaque agent chaîné — et la ligne passe de "arrondi comptable" à "négociation avec le CFO" en un trimestre. Les entreprises qui ont démarré en offrant des tokens illimités aux employés rationnent désormais, sans surprise.
2. Tous les tokens ne se valent pas. Forbes a raison : un token n'est pas comparable entre vendeurs, modèles, tâches et époques. Un token d'un modèle de raisonnement frontière n'est pas commercialement équivalent à un token d'un petit modèle open-weights, même si la compta veut les additionner.
3. Il faut de l'outillage. Le suivi de tokens va générer la même vague de vendeurs que le coût cloud il y a dix ans : un marché FinOps pour tokens. Ce marché est déjà en train de se former.

Ces trois observations suffiraient à justifier l'article. Le problème, c'est la quatrième idée qu'on lui colle dessus.

Là où Forbes se trompe : le token comme proxy de productivité

L'article décrit — avec trop peu d'esprit critique — une tendance où les entreprises traitent tokens par employé par unité de temps comme métrique de productivité. Il file même l'analogie avec le budget voyage d'un commercial : l'employé qui sous-consomme son budget de tokens équivaut, dans ce cadre, au commercial qui ne prend pas de rendez-vous clients. Dépenser moins devient un signal négatif.

C'est la loi de Goodhart en costume neuf. Quand une mesure devient une cible, elle cesse d'être une bonne mesure. Le jour où tu dis aux ingénieurs que leur usage de tokens est évalué — formellement, par le management, avec impact sur les performance reviews — tu n'as rien mesuré sur la productivité. Tu as créé un nouveau marché du bruit.

Forbes reconnaît le vecteur d'abus ("les tokens sont triviaux à abuser") mais le traite comme un sujet d'hygiène gérable. Il ne l'est pas. L'histoire des métriques d'ingénierie, c'est exactement l'histoire de ce mode d'échec :

• Lignes de code par développeur. Mesurées pendant deux décennies. Optimisées en écrivant plus de lignes. Récompense : des bases Fortran 77 qu'aucun humain ne pouvait maintenir. La chose mesurée — la valeur créée — s'est décorrélée puis anti-corrélée à la métrique. J'ai défendu ce point sur les métriques de productivité et la mécanique est identique.
• Tickets fermés par sprint. Optimisé en découpant les tickets. Ou en fermant les triviaux en premier. Ou en gonflant le sprint. Les équipes qui gamaient le mieux la métrique livraient le pire.
• Couverture de tests. Optimisée en écrivant des tests qui exécutent des lignes sans assertion. La couverture monte, les défauts montent, les ingénieurs sont promus.

"Tokens consommés par employé par mois" rentre dans cette lignée. Et c'est pire, parce que chaque token gamé coûte de l'argent réel à un vrai fournisseur. Les métriques de vanité classiques se gamaient gratuitement. Le tokenmaxxing, c'est du gaming payant, avec la facture qui passe par la finance.

La mesure honnête est plus dure, et ce ne sont pas les tokens

Ce que tu veux vraiment savoir d'un ingénieur qui utilise des outils IA, c'est en gros :

• Le changement a-t-il été livré ?
• A-t-il été livré correctement ?
• A-t-il été livré plus vite qu'il ne l'aurait été sans l'outil ?
• L'ingénieur a-t-il appris quelque chose de réutilisable, ou a-t-il sous-traité la pensée ?
• Le code résultant est-il revuable, maintenable et owned ?

Aucune des cinq ne se mesure en tokens. Les quatre premières se mesurent par des métriques DORA honnêtes — fréquence de déploiement, lead time, change failure rate, MTTR. La cinquième se mesure uniquement par revue de code et temps. Il n'y a pas de raccourci, et les tokens ne sont pas le raccourci déguisé.

Forbes acquiesce avec la phrase "infuse the AI force multiplier" — l'idée que c'est l'expertise humaine qui donne sa valeur au token. D'accord. Mais cette concession sape tout le cadre token-budget-as-productivité qui est juste à côté. Si le multiplicateur, c'est l'humain, l'unité pertinente est résultat par ingénieur, pas tokens par ingénieur. La dépense en tokens est un coût d'entrée, comme le cloud, l'électricité ou le bureau — et on ne promeut personne pour avoir dépensé plus en électricité.

Ce que les tokens sont vraiment : une ligne de coût cloud, avec des défauts pires

Si tu enlèves l'erreur métrique-de-productivité, ce qui reste est correct et vaut la peine d'être bien géré. Les tokens entrent sur la même courbe de maturité que la dépense cloud, et le playbook de la décennie FinOps s'applique presque sans changement :

1. Affecte la dépense aux résultats, pas aux personnes. Un token consommé par un agent CI qui attrape une régression en production n'est pas commensurable avec un token consommé par un ingénieur demandant à un LLM de reformuler un Slack. Étiquette les tokens par workflow, pas par employé — comme tu étiquetais les EC2 par service, pas par la personne qui les avait lancées.
2. Mets des quotas par route, pas par personne. Le dérapage intéressant dans une organisation IA, c'est rarement un employé bavard. C'est un agent runaway dans un pipeline appelant un modèle frontière en boucle avec retry-with-backoff. Les budgets par employé ne l'attrapent pas. Les budgets par outil et par flux, si, comme les budgets par service ont attrapé la lambda qui faisait 3 000 lectures Aurora à 3h du matin.
3. Arbitre les prix entre modèles. Forbes a raison : les vendeurs et les prix fluctuent ; la bonne réponse, c'est une couche de routing qui envoie chaque tâche au modèle le moins cher qui satisfait le seuil qualité pour cette tâche — pas un contrat fixe avec un seul vendeur frontière au prix catalogue. L'économie des modèles fondation récompense les décisions build-vs-buy par charge, pas la standardisation sur le plus cher.
4. Observabilité avant incitations. La plupart des organisations s'apprêtent à prendre des décisions de politique sur les tokens avant d'avoir une attribution fiable par tâche. L'ordre est faux. Règle d'abord l'attribution — par service, par flux, par retry, par résultat utilisateur final — ensuite parle de budgets. Sinon, tu poses des quotas sur du bruit.

C'est du FinOps avec une autre unité. Ce n'est pas, et ça ne devrait pas être, du performance management.

Ce que le « tokenmaxxing » dit vraiment d'une organisation

Si une organisation d'ingénierie se retrouve à récompenser la consommation de tokens — ou pire, à voir ses ingénieurs gamer la consommation pour avoir l'air productifs — le problème n'est pas chez les ingénieurs. Il est chez le leadership qui a choisi la métrique. Le tokenmaxxing est un symptôme, et la maladie de fond est la même que je vois chez tous les clients qui n'ont pas construit une vraie culture de mesure : le management veut un chiffre unique, la finance veut un chiffre unique, et la facture LLM donne commodément un chiffre unique qui monte.

Une vraie organisation d'ingénierie résiste à cette compression. Elle fait tourner au moins deux flux en parallèle :

• Flux coût. Qu'a-t-on dépensé en outils IA, ventilé par workflow, par équipe, par modèle, par mode de retry ? Où est le gaspillage ? Le routeur fait-il son boulot ? Y a-t-il des agents en boucle ?
• Flux résultat. Qu'est-ce qui a été livré ? Qu'est-ce qui ne l'a pas été ? Quel est le change failure rate ? Les PR assistées par IA ont-elles un profil de défauts différent des non-assistées ? L'IA attrape-t-elle plus d'incidents qu'elle n'en provoque ?

Si tu ne fais tourner que le flux coût, tu vas optimiser la consommation de tokens — et Forbes décrit correctement le type d'entreprise que tu deviendras. Si tu ne fais tourner que le flux résultat, tu n'attraperas pas l'agent runaway qui a mis le feu à ta facture AWS. Il faut les deux, sur des dashboards distincts revus par des personnes distinctes.

Ce que je mettrais devant un CTO ce trimestre

1. Attribution par flux avant budgets par employé. Tant que tu ne peux pas nommer les cinq workflows qui consomment le plus de tokens dans ta stack, tu n'as pas de problème de tokens que tu peux résoudre.
2. Un kill-switch par agent, le même que je défends comme non négociable pour tout système agentique en production. Une boucle infinie dans un agent est désormais un incident finance autant qu'un incident SRE.
3. Une couche de routing de modèles, même rudimentaire. Si toutes les équipes appellent directement le même modèle frontière sans fallback sur des paliers moins chers pour les tâches triviales, ta facture paie la paresse de la plateforme, pas la productivité des ingénieurs.
4. Une politique de mesure qui exclut explicitement les tokens de la performance individuelle. Par écrit. Et fort. Le jour où un manager félicite un ingénieur pour avoir "consommé plus de tokens ce trimestre", la métrique est morte et ta culture suit.
5. Une ligne budgétaire pour le gaspillage. Une part de la dépense en tokens sera exploratoire, sans débouché et irréductiblement expérimentale. Très bien. Nomme cette ligne, budgétise-la, et arrête d'essayer de l'optimiser à zéro. C'est aussi là que se passe la majeure partie de l'apprentissage.

La ligne que je trace

Forbes a raison : les tokens sont désormais une vraie ligne que les entreprises doivent planifier, suivre et gouverner. Forbes se trompe — ou est dangereusement casual — quand il étend cette ligne pour en faire une métrique de productivité individuelle. La première chose, c'est du FinOps. La seconde, c'est l'erreur lignes-de-code rééditée avec une facture fournisseur collée dessus.

Les entreprises qui navigueront bien les deux prochaines années seront celles qui traiteront les tokens avec la même discipline ennuyeuse qu'elles ont (finalement) appris à appliquer au cloud : affecter la dépense aux résultats, router le travail vers le modèle le moins cher qui suffit, observer avant d'inciter, et jamais — jamais — promouvoir un ingénieur pour avoir consommé plus de l'input.

Les tokens sont un coût. L'ingénieur est le multiplicateur. Si tes métriques confondent les deux, tu n'as pas de stratégie IA. Tu as une facture IA.

---

Sources :

• Nisha Talagala, Are Tokens The New Currency? A Primer For Business, Forbes, mai 2026. forbes.com
• The Pragmatic Engineer, The Pulse: Tokenmaxxing as a weird new trend. blog.pragmaticengineer.com
• Wall Street Journal, Why Some Companies Say AI Tokenmaxxing Is Key To Survival. wsj.com

Tu mets une équipe d'ingénierie augmentée par IA sous vrai budget et tu ne sais pas comment la mesurer sans casser l'équipe ? Parle à un CTO — on t'aide à séparer la facture du travail.