Mon fil LinkedIn en est rempli depuis des semaines. Ma timeline X aussi. Des gens qui postent des captures d'écran de dépenses en jetons comme s'il s'agissait de rapports d'avancement. Des fondateurs de startups qui se vantent d'avoir dépensé 16 000 $ pour Claude Code le mois dernier et qui visent 60 000 $ le mois prochain. Les classements. Des classements. Des titres comme "Légende des jetons" et "Dieu de l'IA".
Et puis, la semaine dernière, la masse critique a été atteinte. Forbes [a parlé du mouvement "tokenmaxxing"] (https://www.forbes.com/sites/richardnieva/2026/03/31/the-ai-gods-spending-as-much-as-they-can-on-ai-tokens/) qui balaie la Silicon Valley, où les entreprises rivalisent pour savoir qui brûlera le plus de jetons d'IA. Jensen Huang a déclaré sur le podcast All-In : Cet ingénieur à 500 000 dollars, à la fin de l'année, je lui demanderai : "Combien avez-vous dépensé en jetons ?". S'il me répond "5 000 dollars", je deviendrai fou. Si cet ingénieur de 500 000 dollars n'a pas consommé au moins 250 000 dollars de jetons, je serai très inquiet.
Puis [Fortune a rapporté] (https://fortune.com/2026/04/09/meta-killed-employee-ai-token-dashboard/) qu'un employé de Meta avait créé un tableau de classement interne appelé "Claudeonomics" pour suivre la consommation de jetons par les plus de 85 000 employés de la société. Les meilleurs utilisateurs recevaient des titres. Sur une période de 30 jours, l'utilisation totale a atteint 60 000 milliards de jetons. Le meilleur utilisateur individuel a consommé en moyenne 281 milliards. Mark Zuckerberg n'est même pas entré dans le top 250. Andrew Bosworth, directeur technique de Meta, a déclaré publiquement que son meilleur ingénieur dépensait l'équivalent de son salaire en jetons, mais qu'il était "5 à 10 fois plus productif". "C'est comme si c'était de l'argent facile", a déclaré Bosworth. "Aucune limite".
Je travaille dans le secteur des logiciels depuis suffisamment longtemps pour comprendre ce qui se passe ici. Il s'agit de "lignes de code" avec un prix beaucoup plus élevé.
We've been here before
En 2003, Martin Fowler a écrit [un court article sur les raisons pour lesquelles la productivité des logiciels ne peut être mesurée] (https://martinfowler.com/bliki/CannotMeasureProductivity.html) qui devrait probablement être une lecture obligatoire pour tous les cadres techniques. Son argument sur les lignes de code était précis :
"L'une de mes plus grandes irritations concerne les études de productivité basées sur les lignes de code. Tout bon développeur sait qu'il peut coder la même chose avec d'énormes variations dans les lignes de code."
Le problème est évident une fois qu'on le dit à haute voix. La LOC mesure l'activité, pas la production. Deux développeurs peuvent créer la même fonctionnalité : l'un écrit 1 200 lignes, l'autre 80. Le plus concis a probablement construit un meilleur système. Dans le cadre d'un régime LOC, le développeur verbeux semble plus productif.
Les équipes évaluées sur la base de la LOC ont réagi de manière rationnelle. Elles ont écrit plus de lignes. Elles ont copié-collé au lieu d'abstraire. Elles ont évité le remaniement parce que la suppression de code aurait nui à leurs résultats. La mesure a influencé le comportement, mais pas dans le sens d'un meilleur logiciel. Plus de code. Des systèmes moins bons.
En 2023, McKinsey a publié un article affirmant avoir trouvé une mesure objective de la productivité des développeurs. [La réponse détaillée de Gergely Orosz et Kent Beck (https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity) a mis en évidence le même défaut : presque tous les indicateurs de McKinsey mesuraient l'effort et la production, et non les résultats. Kent Beck a raconté avoir vu les enquêtes internes de Facebook sur le sentiment des développeurs se transformer d'un retour d'information utile en une négociation entre les managers et les ingénieurs pour obtenir des scores plus élevés. C'est ce qui se passe lorsque l'on encourage une mesure indirecte. Le chiffre s'améliore. La chose dont vous vous souciez réellement ne s'améliore pas.
On aurait pu penser que nous aurions appris. Ce n'est pas le cas.
Même erreur, unité différente
La logique séduisante du tokenmaxxing est la suivante. Consommation de jetons = utilisation de l'IA. Plus d'utilisation de l'IA = les équipes utilisent l'IA. Par conséquent, une forte consommation de jetons = une forte adoption de l'IA = une bonne chose.
Cette logique est précisément aussi erronée que celle qui consiste à mesurer les lignes de code, mais avec un tableau de bord de facturation au lieu d'un graphique de validation. Et pour être juste à l'égard de l'article de Forbes, le PDG de Sendbird, John Kim, a dit exactement cela : "Nous avons déjà vu ce film". Il faisait référence à la culture LOC des années 1990 et 2000. Le véritable indicateur, a-t-il fait remarquer, est la quantité de code généré par l'IA qui entre effectivement en production. Les dépenses en jetons "servent davantage à engager la conversation". Je suis d'accord avec cela. Cela devient un problème lorsque l'amorce de conversation est promue au rang d'indicateur clé de performance.
[L'enquête 2024 de GitHub auprès des développeurs (https://github.blog/news-insights/research/survey-ai-wave-grows/) a révélé que 97 % des développeurs d'entreprise avaient déjà utilisé des outils de codage de l'IA dans le cadre de leur travail. Cependant, une adoption organisationnelle significative nécessite des politiques claires, des flux de travail et des résultats mesurables liés à des résultats commerciaux réels. Il ne s'agit pas d'une simple utilisation. Pas seulement la consommation.
Boris Cherny, l'ingénieur à l'origine de Claude Code, a [partagé publiquement] (https://x.com/bcherny/status/2004626064187031831) qu'il n'a pas ouvert d'IDE du tout pendant un mois de travail, avec Opus 4.5 rédigeant environ 200 PR. C'est impressionnant. Mais ce qui est impressionnant, ce ne sont pas les tokens que ces 200 PR ont consommés. C'est qu'il s'agissait de 200 contributions fusionnées avec un logiciel fonctionnel à l'autre bout.
La valeur est dans le résultat. Les jetons sont l'énergie qui vous a permis d'y arriver, rien de plus.
Quand la métrique devient la cible
Il existe un principe appelé la loi de Goodhart : lorsqu'une mesure devient une cible, elle cesse d'être une bonne mesure. L'histoire du développement de logiciels est essentiellement un musée de la loi de Goodhart en action.
Le suivi des jetons en tant qu'indicateur clé de performance pour l'adoption de l'IA crée exactement la même dynamique. Les équipes d'ingénieurs évaluées sur la base de la consommation de jetons consommeront plus de jetons. C'est ainsi que fonctionnent les incitations. Vous voulez paraître plus productif ? Exécutez quelques boucles agentiques supplémentaires. Laissez le modèle raisonner longuement avant de générer des résultats. Enveloppez chaque tâche dans une couche d'orchestration qui appelle quatre outils là où un seul suffirait. Les dépenses en jetons augmentent. La valeur fournie n'augmente pas.
En fait, l'histoire de Claudeonomics l'a prouvé presque immédiatement. Fortune a noté que "certains employés ont fait travailler des agents d'intelligence artificielle pendant des heures pour maximiser l'utilisation de leurs jetons". Et voilà. La loi de Goodhart exécutée en temps réel, au sein d'une entreprise censée être à la pointe de la productivité induite par l'IA. Le tableau de classement était en place depuis quelques semaines avant d'être fermé, et les employés le jouaient déjà en faisant tourner des agents en boucle. La mesure datait de trois semaines et ne mesurait déjà plus ce qu'elle était censée mesurer.
Tout développeur lisant ceci peut probablement penser à cinq façons de gonfler les mesures d'utilisation des jetons sans que cela ne profite à personne. Je ne les énumérerai pas. Mais si je peux penser à cinq d'entre elles, les ingénieurs qui sont mesurés ici le peuvent aussi.
Andrej Karpathy a décrit [le moment actuel du génie logiciel] (https://x.com/karpathy/status/2004607146781278521) comme un "tremblement de terre de magnitude 9" pour la profession. Il a raison. Mais les tremblements de terre ne se mesurent pas à l'électricité consommée. Ils sont mesurés en fonction de ce qui a été déplacé.
La version de la documentation de ce problème
Ce n'est pas seulement un problème pour les équipes d'ingénieurs. Je constate la même dynamique dans la gestion des connaissances, qui est beaucoup plus proche de nous chez Rasepi.
"Nous avons publié 400 documents ce trimestre" est un chiffre qui sonne bien dans une présentation de diapositives. Il ne dit en rien si ces documents sont exacts, si quelqu'un les a lus ou si les informations qu'ils contiennent sont toujours d'actualité six mois plus tard. Il est possible d'atteindre ce chiffre grâce à l'IA et sans aucune réflexion. Le bruit assisté par des jetons est publié à grande échelle.
La mesure honnête est plus difficile à collecter mais beaucoup plus utile : quel pourcentage de votre base de connaissances reflète réellement la manière dont vos systèmes fonctionnent aujourd'hui ? Combien de personnes sont parvenues à une réponse correcte en utilisant votre documentation ? Combien ont essayé, ont échoué et ont fini par demander à quelqu'un sur Slack à la place ?
Ces questions n'ont pas encore de jolis tableaux de bord. Elles nécessitent une véritable réflexion sur ce que vous voulez que la documentation fasse pour votre organisation. (Ce n'est pas une coïncidence si c'est exactement le problème autour duquel Rasepi est construit. Les dates d'expiration forcées existent précisément pour que les équipes aient à se demander si le contenu est toujours valide, plutôt que de le laisser se décomposer silencieusement derrière un nombre de pages élevé).
Ce qu'il faut suivre à la place
La réponse honnête à la question "Notre investissement dans l'IA est-il rentable ?" ne peut pas être lue à partir d'un tableau de bord de facturation.
Vous pouvez l'approcher en posant de meilleures questions : les temps de cycle s'améliorent-ils ? Le rapport entre les fonctionnalités livrées et les bogues signalés évolue-t-il dans la bonne direction ? Les ingénieurs déclarent-ils qu'ils consacrent plus de temps au travail de jugement et moins à la dactylographie ? Votre documentation reste-t-elle à jour au lieu de s'accumuler comme des sédiments ?
Il est plus difficile de tirer ces informations d'une API. Elles nécessitent une réflexion sur les résultats que vous attendez réellement de vos équipes, ce qui, il faut le reconnaître, est le travail le plus difficile. Mais ce sont les questions qui comptent, parce qu'elles concernent les résultats plutôt que les intrants.
Les dépenses en jetons vous indiquent la quantité de calcul que vous avez achetée. La question de savoir si ce calcul est devenu quelque chose d'utile est tout à fait distincte. Les entreprises qui ne font pas cette distinction vont construire des tableaux de bord très coûteux qui ne leur montreront presque rien.
Nous avons passé des années à optimiser la mauvaise mesure de la productivité des développeurs. Il nous reste peut-être un trimestre avant que la même erreur ne soit intégrée dans tous les rapports sur l'adoption de l'IA dans les entreprises. La fenêtre pour éviter cela est ouverte, mais elle ne le restera pas.