Qu'est-ce que le « tokenmaxxing » ? L'indicateur IA qui s'est autodétruit

En 30 jours, les employés de Meta ont utilisé environ 60 000 milliards de jetons d’IA via un classement interne qui les classait en fonction de leur consommation ; une facture qui a probablement dépassé les 100 millions de dollars pour produire un travail qui relevait en grande partie de la mise en scène. Quatre-vingt-dix jours plus tard, le classement avait disparu et l’entreprise rationnait strictement l’utilisation de l’IA.

Ce phénomène s’appelle le « tokenmaxxing » : il s’agit de la maximisation de l’utilisation des jetons d’IA, élevée au rang d’indicateur de performance et de productivité. Les entreprises ont depuis pris conscience de leurs erreurs, et certaines sont allées trop loin dans la direction opposée, dans un phénomène surnommé « tokenminning » : utiliser le moins de jetons d’IA possible afin de réduire les coûts informatiques. Ces deux approches échouent car elles considèrent le nombre de jetons comme un indicateur fiable de la croissance générée par l’IA.

Dans cet article, nous aborderons le coût réel du « tokenmaxxing », la manière dont les ingénieurs l’ont contourné, ainsi que l’installation de mesure capable de résister à ceux qui savent manipuler les nombres.

Qu'est-ce que le « tokenmaxxing » ?

Le « tokenmaxxing » consiste à maximiser la consommation de jetons d’IA et à considérer une utilisation plus élevée comme la preuve d’une plus grande productivité ou d’une adoption accrue de l’IA. Les jetons sont les unités qu’un modèle d’IA traite en entrée et produit en sortie.

L’utilisation des jetons est devenue un indicateur de performance intéressant, car elle est visible, quantifiable et déjà suivie par de nombreuses plateformes d’IA. Elle est ainsi plus facile à présenter que des résultats tels que le temps gagné, l’amélioration des décisions ou le chiffre d’affaires généré. Mais les jetons mesurent l’activité de calcul, et non le travail utile. Les requêtes répétitives, les boucles d’agents qui échouent et les résultats inutiles font tous grimper ce nombre sans rien produire.

Les agents IA aggravent encore la situation. Un agent analyse le contexte, fait appel à des outils, révise son propre travail et confie des tâches à d’autres agents. Chaque étape consomme des jetons. Si une activité plus intense peut se traduire par un travail plus utile, elle peut également entraîner des flux de travail inefficaces et une augmentation des coûts.

En termes simples, la faille principale du « tokenmaxxing » réside dans le fait que les équipes maximisent le nombre visible de jetons alors que la productivité, la qualité et le retour sur investissement restent inchangés.

Pourquoi le « tokenmaxxing » est-il devenu populaire ?

Le « tokenmaxxing » a connu un certain succès car les dirigeants avaient besoin d’un nombre pour prouver que l’adoption de l’IA au sein des entreprises était bel et bien en cours. Or, l’utilisation des jetons était le seul indicateur qui apparaissait dans la console de facturation.

Jensen Huang, PDG de Nvidia, a donné le ton dès le début de l’année 2026 dans le podcast « All-In » avec une expérience de pensée portant sur la facture de jetons d’un ingénieur hautement rémunéré.

« Si cet ingénieur payé 500 000 dollars n’utilisait pas au moins 250 000 dollars de jetons, je serais profondément inquiet », a-t-il déclaré. Et si la réponse s’élevait à 5 000 dollars ? Il piquerait une crise.

L’utilisation de l’IA était devenue un indicateur visible permettant de déterminer qui suivait le rythme. Cela se passait à une époque où, lors de chaque réunion de planification, on se demandait quels rôles l’IA allait remplacer. Les ingénieurs qui dépensaient des jetons donnaient l’impression de s’adapter au nouveau paradigme, tandis que ceux qui n’en dépensaient pas risquaient d’être perçus comme un problème.

Voici l’ironie : ce premier classement des jetons n’a jamais été conçu comme une compétition. Shopify l’a créé pour comprendre pourquoi ses meilleurs clients dépensaient autant, et non pour les classer les uns par rapport aux autres. Farhan Thawar, vice-président et directeur de l’ingénierie, a par la suite décrit l’évolution de cet outil.

L’entreprise l’a rebaptisé « tableau de bord d’utilisation », y a ajouté des coupe-circuits et des alertes de dépenses, et a utilisé les données pour repérer les agents hors de contrôle et les bugs d’infrastructure. Farhan a écrit :

Le « tokenmaxxing » est un sujet controversé. Plus ne signifie pas forcément mieux. Nous avons créé le premier classement des jetons /IA. Puis nous avons fait évoluer notre réflexion. C’est devenu un tableau de bord d’utilisation. Les mêmes données, mais sous un angle différent. Nous avons ajouté des coupe-circuits et des pics de dépenses. Nous avons repéré des agents hors de contrôle. Nous avons trouvé des bugs dans notre propre infrastructure. Le véritable indicateur : ce n’est pas celui qui a dépensé le plus, mais ceux dont les jetons ont généré le plus d’impact. Ce sont ces ingénieurs-là avec qui je veux discuter.

La plupart des entreprises qui ont copié le classement de Shopify l’ont utilisé pour classer leurs employés au lieu d’analyser les dépenses liées à l’IA. Le tableau ci-dessous montre comment cela s’est traduit dans chacune d’entre elles.

La tendance qui se dégage de ce tableau est constante. Les organisations qui ont utilisé les données des jetons pour enquêter sur les dépenses élevées ont conservé un indicateur pertinent. Celles qui s’en sont servies pour classer leurs collaborateurs ont perdu cet indicateur en l’espace d’un trimestre.

Comment les ingénieurs ont-ils gonflé leur utilisation de jetons ?

Les ingénieurs ont gonflé leur utilisation de jetons en générant des activités d’IA coûteuses qu’ils n’avaient jamais prévu de déployer. The Pragmatic Engineer a rendu compte de ce comportement chez Meta, Microsoft et Salesforce et a identifié quatre tactiques courantes. Aucune d’entre elles ne relevait d’une mauvaise intention. Les employés voyaient simplement un nombre bien visible, s’inquiétaient des licenciements et partaient du principe qu’une utilisation intensive de l’IA les protégerait :

De nombreux ingénieurs ont vérifié ce que dépensaient leurs collègues. Ils ont ensuite consommé juste assez pour se situer légèrement au-dessus de la moyenne. Plutôt que d’occuper la première place, ils ne voulaient pas être signalés pour ne pas utiliser suffisamment l’IA.

Chez Amazon, les employés attribuaient des tâches insignifiantes et inventées de toutes pièces à des agents IA afin d’augmenter leur score Kirorank. Cela a entraîné une hausse des coûts liés au cloud sans générer le moindre résultat pour l’entreprise. Lorsque Amazon a supprimé le classement, le vice-président senior Dave Treadwell a expliqué au personnel qu’il avait été mis en place avec de bonnes intentions. Il a ensuite demandé sans détour : « S’il vous plaît, n’utilisez pas l’IA juste pour le plaisir d’utiliser l’IA. »

Dans le cadre de cette évolution, Amazon effectue désormais le suivi de la performance du code généré par l’IA et de sa valeur ajoutée. La consommation de jetons n’est pas sa priorité absolue.

Combien le « tokenmaxxing » a-t-il coûté aux entreprises ?

Le « tokenmaxxing » aurait coûté à Meta plus de 100 millions de dollars en un seul mois et épuisé le budget annuel d’Uber consacré à l’IA en quatre mois. L’estimation de Meta repose sur un simple calcul arithmétique. D’après les tarifs de l’API de Claude Opus (au moment où la nouvelle a été révélée), 60,2 billions de jetons coûteraient environ 900 millions de dollars. Une entreprise de la taille de Meta négocie des réductions importantes, mais même dans ce cas, la facture pourrait atteindre neuf chiffres.

Uber offre l’image la plus claire de ce coût, car l’entreprise n’a jamais mis en place de classement. Elle a fourni à environ 5 000 ingénieurs des outils de codage « agentic » sans modèle de dépenses. En l’espace d’un mois, la part d’ingénieurs classés comme utilisateurs « agentic » est passée de 32 % à 84 %. Le budget annuel total a été épuisé en quatre mois .

Le directeur technique, Praveen Neppalli Naga, a admis que l’entreprise était « revenue à la case départ » concernant ses hypothèses. L’intervalle des factures mensuelles variait de 500 à 2 000 dollars par ingénieur, et la solution était sans appel : un plafond mensuel de 1 500 dollars par outil de programmation et par ingénieur.

Lorsque des ingénieurs effectuant un travail comparable dépensent des montants aussi différents, cet écart montre que personne n’avait défini ce qu’était une « bonne utilisation ». Chaque ingénieur a donc inventé sa propre définition. Andrew Macdonald, directeur des opérations d’Uber, a reconnu ce point, déclarant à Fortune qu’il était « très difficile de tracer une ligne de démarcation » entre le code assisté par l’IA et les fonctionnalités utiles réellement mises en production.

Le rapport « AI Impact Report » de LeadDev a révélé que seuls 19 % des responsables techniques effectuent une évaluation positive du « tokenmaxxing ». 57 % d’entre eux estiment qu’il ne permet pas d’évaluer la valeur réelle.

Voici pourquoi l’argent circule si vite : un agent qui planifie une modification de code consulte le référentiel, appelle des outils, exécute des tests et réessaie jusqu’à ce qu’il réussisse. Une seule boucle peut consommer des dizaines de milliers de jetons, et les lectures du cache des invites font grimper ce chiffre encore davantage.

Les équipes financières ont budgétisé l’IA comme s’il s’agissait d’une licence par poste. Or, elle se comporte en réalité comme le cloud computing. Le même écart comptable apparaît lorsque les équipes constituent une pile d’IA à partir de plusieurs fournisseurs sans attribuer à quiconque la propriété de la facture. Il s’agit du même type de défaillance que la prolifération incontrôlée des outils, mais à un niveau supérieur.

Qu'est-ce que le « tokenminning » ?

Le « tokenminning » consiste à réduire au minimum la consommation de jetons /IA et à se fixer pour objectif une faible utilisation. Comme nous l’avons évoqué dans l’introduction, il s’agit d’une correction excessive qui aboutit à des résultats tout aussi médiocres. Ce terme, abréviation de « token minimizing », est apparu comme une réponse au « tokenmaxxing ». Le New York Times a fait état de cette évolution au sein de plusieurs entreprises.

Meta a annoncé à ses employés qu’elle limiterait l’utilisation de l’IA après une « augmentation exponentielle » des coûts. Uber a plafonné les dépenses mensuelles, Walmart a fixé des limites d’utilisation des outils, et Amazon comme Meta ont supprimé leurs classements. En l’espace de quelques semaines, ces mêmes entreprises qui avaient célébré leurs plus grands utilisateurs d’IA ont commencé à inciter tout le monde à rationner leur consommation.

Cette correction reproduit l’erreur qu’elle était censée corriger. La loi de Goodhart l ’explique parfaitement : lorsqu’une mesure devient une cible, elle cesse d’être une bonne mesure. Ainsi, si vous fixez l’utilisation des jetons d’IA comme objectif, les gens trouveront des moyens d’optimiser cet indicateur, même au prix de compromettre l’intention initiale. La loi de Goodhart met en garde contre le « tokenmaxxing » et le « tokenminning ».

Récompensez une équipe pour avoir brûlé des jetons, et elle brûlera des jetons dont elle n’a pas besoin. Récompensez une équipe pour avoir économisé des jetons, et elle renoncera à l’exécution de l’IA qui aurait permis de détecter un bug. Ou bien elle divisera une session approfondie en trois sessions moins coûteuses, chacune fournissant une réponse moins approfondie. Les deux équipes atteignent leurs cibles d’utilisation de jetons, tandis que la qualité du travail s’en trouve détériorée.

La maîtrise des coûts n’est pas une erreur en soi. Comme dans l’exemple d’Uber, le plafond mensuel de 1 500 dollars est une décision budgétaire prise après que l’entreprise eut épuisé le budget d’une année en quatre mois. Mais fixer une limite de dépenses ne résout qu’un problème financier. Cela ne répond pas à la question de savoir si les jetons ont permis d’acquérir quelque chose d’utile.

La solution consiste à distinguer deux types de nombres : les indicateurs que vous surveillez et les résultats que vous visez. L’utilisation des jetons, le taux d’adoption et la part de code écrit par l’IA sont des indicateurs qui reflètent ce qui se passe au sein du système. Ils sont utiles lorsque vous analysez un problème, mais constituent de mauvais objectifs. En effet, chacun d’entre eux peut varier considérablement sans que le client ne remarque la moindre différence.

Une organisation devrait plutôt viser les résultats. Elle doit suivre la même logique que n’importe quel ensemble bien conçu d’indicateurs clés de performance (KPI) en développement logiciel: relier un signal précoce au résultat qu’il est censé prédire. Le tableau de bord de conversion de Shopify en est le modèle : mêmes données, mais aucune pièce jointe ne contient de classement.

Neil Dhar, vice-président senior chez IBM Consulting, a décrit comment cette confusion se propage dans un essai consacré aux coûts de l’IA.

#Tokenmaxxing a fait la une de l'actualité ces derniers temps. Cette tendance des entreprises à utiliser autant d'IA que possible, aussi vite que possible, en faisant de cette utilisation un indicateur de valeur. Aujourd'hui, l'heure est venue de payer la note. Alors que les coûts liés à l'IA dépassent les retours sur investissement, le réflexe est de réduire les dépenses. Mais réduire les dépenses ne suffira pas à résoudre le problème sous-jacent du retour sur investissement.

Selon IBM, la solution consiste à considérer l'utilisation comme un indicateur et à l'associer à un résultat qu'il est impossible de falsifier.

Une utilisation plus importante des jetons est-elle synonyme de meilleure productivité ?

Non, une utilisation élevée des jetons ne signifie pas une productivité élevée. Les plus grands ensembles de données disponibles montrent que ces deux éléments évoluent indépendamment l'un de l'autre. Une étude menée par la plateforme d'intelligence pour développeurs DX a révélé que l'adoption de l'IA était proche de la saturation, tandis que les gains de productivité mesurés restaient stables.

Laura Tacho, directrice technique chez DX, a partagé les chiffres. Parmi les développeurs, 92,6 % utilisent désormais un assistant de codage IA au moins une fois par mois, et environ 75 % s'en servent chaque semaine. L'IA écrit 26,9 % du code de production. Pourtant, le gain de temps déclaré par les utilisateurs est resté stable à environ quatre heures par semaine depuis plus d'un an. Et le gain de productivité initial de 10 % n'a jamais augmenté.

L'utilisation n'a cessé d'augmenter tandis que les résultats stagnaient. Tout indicateur se contentant du suivi de l'utilisation a présenté des rapports sur une réussite qui n'a jamais eu lieu.

Le rapport DORA de Google Cloud explique pourquoi les mêmes outils produisent des résultats aussi différents. Il a révélé que l’adoption de l’IA améliorait la rapidité de mise en production, mais nuisait à sa stabilité. Le rapport décrit l’IA comme un amplificateur : elle accentue les points forts des organisations bien gérées et les faiblesses de celles qui rencontrent des difficultés.

Les données propres à DX montrent cet effet amplificateur à l’œuvre. Au sein d’un groupe de 67 000 développeurs, certaines organisations ont vu le nombre d’incidents affectant les clients doubler, tandis que d’autres l’ont réduit de moitié, en utilisant les mêmes outils sur la même période. Tacho attribue la responsabilité là où les données l’indiquent :

Il s’agit en réalité d’un problème de gestion. Le battage médiatique a donné l’impression qu’il suffisait d’essayer l’IA pour que cela porte automatiquement ses fruits. Mais jusqu’à présent, la plupart des outils ont été utilisés pour des tâches de codage individuelles. Pour constater un impact réel, nous devons utiliser l’IA au niveau organisationnel, et non pas uniquement pour des tâches ponctuelles.

Derrière ce premier problème se cache un second : les gens surestiment les gains de productivité apportés par l’IA. Le laboratoire de recherche à but non lucratif METR a mené un essai contrôlé aléatoire. Seize développeurs open source expérimentés ont achevé la résolution de 246 problèmes réels dans des référentiels qu’ils géraient depuis cinq ans en moyenne. Avant de commencer, les développeurs avaient prédit que l’IA leur permettrait de gagner 24 % de temps. Une fois leur travail terminé, ils ont estimé que ce gain de temps était d’environ 20 %. Le chronomètre a révélé qu’ils avaient en réalité perdu 19 % de temps.

Dans une mise à jour ultérieure, le laboratoire a expliqué que sa prochaine expérience s’était heurtée à des effets de sélection qu’il n’avait pas pu corriger. Il a également indiqué que les développeurs sont désormais probablement réellement plus rapides grâce à l’IA, en grande partie grâce aux outils « agentiques ». Ce qui reste vrai : la productivité déclarée par les intéressés ne remplace pas la productivité mesurée, et l’écart entre les deux peut aller dans un sens comme dans l’autre.

Que devriez-vous mesurer à la place de l’utilisation des jetons ?

Au lieu de l'utilisation des jetons, mesurez les résultats au niveau de l'équipe, puis au niveau de l'organisation. Considérez l'utilisation des jetons comme un indicateur de coût qui ne sert pas à établir un classement. Ce qui compte, ce sont les résultats obtenus.

Une règle pratique à suivre : associez chaque indicateur que vous publiez à un résultat qu’il ne peut pas gonfler. Une équipe peut brûler des jetons sans livrer quoi que ce soit. En revanche, elle ne peut pas simuler une baisse du taux d’échec des changements.

Cette structure s'inspire de cadres de mesure auxquels les responsables techniques font déjà confiance. DORA prend en compte la rapidité de livraison et la stabilité, et c'est précisément parce qu'il a été démontré que l'IA amplifie ces deux aspects que cette association revêt une importance particulière.

Le DX Core 4 mesure quatre dimensions: la rapidité, l'efficacité, la qualité et l'impact pour l'entreprise. Abi Noda et Laura Tacho l'ont développé en collaboration avec Nicole Forsgren et Margaret-Anne Storey, les chercheuses à l'origine de DORA, SPACE et DevEx. Ces quatre dimensions s'opposent délibérément les unes aux autres.

Une équipe qui améliore un aspect au détriment d’un autre met immédiatement en évidence ce compromis. Aucun des deux cadres ne comprend d’indicateur lié aux jetons, et aucun n’en a ajouté.

Trois règles permettent à cette association de fonctionner dans la pratique :

Comment mettre en place une politique d'utilisation de l'IA que les employés ne pourront pas contourner ?

Pour mettre en place une politique d’utilisation de l’IA que les employés ne pourront pas contourner, supprimez tous les nombres visibles du classement individuel et prenez cinq décisions :

1. Déterminez à quoi sert ce nombre avant de le collecter

Chaque indicateur de la politique doit avoir un objectif écrit avant la mise en ligne du premier tableau de bord. Le classement de Shopify a bien fonctionné dans un premier temps. La direction s’en est servie pour engager une discussion avec les gros dépensiers au sujet de ce qu’ils développaient. Ce nombre a permis de lancer une enquête. Dès que ce même nombre est fermé, en tirant une conclusion sur une personne plutôt qu’en posant des questions sur son travail, il se transforme en note. Et les notes, elles, sont gérées.

Notez trois éléments pour chaque indicateur :

C’est la ligne « aucune action » qui demande le plus de travail, car les employés testent la politique par rapport à celle-ci. Si la réponse honnête à la question « que se passe-t-il lorsque les dépenses augmentent brusquement ? » met en jeu la position de quelqu’un, c’est que vous avez mis en place un classement comportant des étapes supplémentaires.

2. Définissez le budget au niveau de l'équipe

Une enveloppe budgétaire commune à l’équipe remplace le plafond individuel, et la différence est d’ordre comportemental, et non comptable. L’écart mensuel de 500 à 2 000 dollars chez Uber entre des ingénieurs effectuant un travail comparable montre ce qui se passe en l’absence d’un point de référence commun. Chacun invente sa propre définition de ce qui est raisonnable. Les enveloppes budgétaires fonctionnent de la même manière que tout autre effort visant à regrouper les dépenses dispersées en matière d’IA en un seul lieu contrôlable.

Cette marge de manœuvre vous apporte trois avantages qu’un plafond par personne ne peut pas offrir :

Déterminez la taille de la première enveloppe budgétaire à partir des données observées. Prenez la moyenne des trois derniers mois de l’équipe et ajoutez une marge de manœuvre pour un projet coûteux. Une enveloppe budgétaire fixée au petit bonheur la chance sera dépassée dès la deuxième semaine, ce qui montrera à tout le monde que cette politique n’est que de la poudre aux yeux.

3. Accroître la visibilité des parcours les plus coûteux

Indiquez aux ingénieurs le coût de chaque exécution plutôt que de plafonner leurs dépenses. Ce sont les exécutions Agentic qui tournent en boucle en cas d'échec des tests qui épuisent les budgets, ce qui met le plafonnement strict au premier plan. Une autre option consiste à afficher le coût par exécution à l’ingénieur qui l’a déclenchée, sans en faire des rapports.

Un ingénieur qui voit une boucle de réessais gaspiller 40 $ va corriger cette boucle. En revanche, un ingénieur qui redoute les rapports cessera complètement d'utiliser l'agent, même dans les cas où cette exécution coûteuse s'est avérée justifiée.

Les disjoncteurs de Shopify fonctionnent ainsi : le système détecte l'anomalie, et la personne la plus proche du travail décide de ce qu'il faut faire. La visibilité modifie les comportements plus rapidement qu'un plafond, et elle permet de maintenir l'exécution coûteuse mais correcte lorsque le travail justifie la dépense.

4. Distinguez l’objectif d’adoption de l’IA de l’évaluation des performances

Consignez le accord par écrit, car les promesses verbales ne résistent pas à un cycle de licenciements. L’ingénieur de Microsoft qui a expliqué à The Pragmatic Engineer avoir gonflé ses propres indicateurs d’utilisation ne cherchait pas à remporter un prix. Il cherchait simplement à éviter d’être libellé au cours d’une année marquée par des licenciements liés à l’IA.

Si les gens pensent que les données d’utilisation sont transmises à une réunion de calibrage, ils prendront soin de ces données, quoi qu’on puisse en dire ouvertement.

Le texte de la politique ne nécessite que deux lignes :

Respectez ensuite ces deux éléments. Le premier ingénieur qui verra les données d’utilisation apparaître lors d’une revue le fera savoir à tout le monde, prouvant ainsi que cet indicateur est redondant.

5. Réexaminez les appariements chaque trimestre

Chaque trimestre, demandez-vous si chaque diagnostic explique toujours le résultat auquel il est associé. La tarification des modèles, le comportement de mise en cache et l’architecture des agents évoluent tous plus rapidement qu’un cycle de planification annuel.

La manière dont les équipes utilisent l’IA pour la planification et les rapports ne cesse d’évoluer. Un nombre de jetons qui avait une certaine signification en janvier en a une autre en juin, après deux baisses de prix et une mise à niveau des agents.

L'analyse présente des résultats honnêtes pour chaque indicateur : soit il continue de prédire le résultat attendu, soit il doit être recalibré en fonction des nouveaux prix, soit il a cessé d'être pertinent et est retiré sans cérémonie. Ce sont les équipes qui résistent le plus à ce retrait. Il s'agit pourtant d'une étape importante, car un indicateur qui a perdu tout son sens est exactement le genre de nombre sur lequel reposait l'ère des classements.

Erreurs courantes commises par les équipes lors de l’évaluation de l’adoption de l’IA

Les quatre erreurs les plus courantes consistent à considérer l’adoption comme la ligne d’arrivée, à se fier aux gains de temps déclarés par les utilisateurs eux-mêmes, à publier des classements individuels et à mesurer la vitesse sans tenir compte de la stabilité. Vous pouvez repérer chacune d’entre elles avant qu’elles ne vous coûtent cher.

1. Considérer l’adoption comme la ligne d’arrivée

Le tableau de bord de déploiement affiche 90 %, la direction déclare l’initiative /IA achevée, et personne ne se demande ce qui a changé en aval. Les données de DX ont mis en évidence ce piège à grande échelle : un taux d’adoption de 92,6 % avec une productivité stagnante à 10 %. L’adoption confirme seulement que les outils ont atteint les utilisateurs. Elle ne dit rien sur ce que ces outils ont changé.

La solution : retirez le diagramme d’adoption une fois le déploiement terminé et remplacez-le par une association « signal-résultat ».

2. Se fier aux gains de temps déclarés par les utilisateurs eux-mêmes dans les rapports

Un sondage indique que l’équipe gagne cinq heures par semaine, mais la durée du cycle n’a pas évolué depuis deux trimestres. L’essai mené par METR explique pourquoi ces deux chiffres divergent : les développeurs qui travaillaient nettement plus lentement avec l’IA ont tout de même estimé par la suite que leur vitesse avait augmenté de 20 %. Ce que les gens croient et ce que l’horloge enregistre sont deux mesures différentes.

La solution : Conservez le sondage pour évaluer l'expérience des développeurs, où la perception est importante. Utilisez les données système pour toute affirmation concernant le temps.

3. Publier un classement individuel, juste pour le plaisir

Quelqu’un le met en place sur un wiki interne en un après-midi, lui donne des titres ludiques, et l’équipe s’en amuse sincèrement pendant environ trois semaines. Puis la dimension incitative prend le dessus. La « Claudeonomics » de Meta et le « Kirorank » d’Amazon ont tous deux commencé comme des initiatives ludiques venues de la base. Les deux entreprises les ont abandonnés dès que le côté « jeu » a pris le pas sur l’enthousiasme.

La solution : agréguez les données au niveau de l'équipe, ou ne les diffusez pas.

4. Mesurer la vitesse sans mesurer la stabilité

Le débit augmente, tout le monde se réjouit, tandis que le nombre d’incidents grimpe sur le tableau de bord d’une autre équipe. Le rapport DORA a mis en évidence cette dichotomie précise : la vitesse s’améliore tandis que la stabilité se détériore. Le fait de présenter ces deux chiffres sur des tableaux de bord distincts permet de masquer le problème.

La solution : affichez le taux d’échec des modifications sur le même écran que les indicateurs de vitesse, et non dans un rapport de fiabilité distinct que personne ne consulte.

Comment suivre l’impact de l’IA dans ClickUp

Pour suivre l’impact de l’IA dans ClickUp, mesurez les résultats à côté du travail lui-même : les tâches, les sprints et les livrables que l’IA était censée accélérer. La plupart des tableaux de bord de jetons se trouvent dans une console de fournisseur, loin du travail qu’ils décrivent. Déplacer les indicateurs de résultats dans l’environnement de travail comble cet écart.

Le couple « signal-résultat » évoqué précédemment se reflète directement sur la plateforme :

Surveillez le nombre de jetons sans attribuer de score aux utilisateurs

Tout cela se résume à une seule règle : utilisez les données des jetons pour poser des questions, jamais pour noter les gens. Shopify s'est demandé « Que développent nos plus gros dépensiers ? » et a découvert des agents hors de contrôle et des bugs d'infrastructure. Meta et Amazon se sont demandé « Qui utilise le plus l'IA ? » et se sont retrouvés avec de fausses tâches, des millions gaspillés et des classements inutiles.

Voici donc trois mesures à faire ce trimestre. Transférez le suivi des jetons au niveau de l’équipe et supprimez tout ce qui mentionne le nom d’un individu. Précisez dans la politique que les données d’utilisation n’entrent en aucun cas en ligne de compte dans l’évaluation des performances. Et affichez un indicateur de qualité (le taux d’échec des modifications est le plus simple) sur le même écran que tous les indicateurs de vitesse que vous présentez dans vos rapports.

Si vous souhaitez que cet écran soit accessible depuis votre espace de travail plutôt que dans un outil de rapports séparé, lancez-vous gratuitement avec ClickUp et créez votre tableau de bord avant même d'en avoir besoin.

Foire aux questions sur le « tokenmaxxing » (FAQ)

Qu'est-ce que la règle des 30 % pour le « tokenmaxxing » ?

Il n’existe pas de « règle des 30 % » officielle spécifique au « tokenmaxxing ». Cette expression désigne généralement deux constatations distinctes que les gens confondent : d’une part, l’IA tend à augmenter la productivité technique mesurée d’environ 10 %, et non de 30 %; d’autre part, les développeurs prévoient régulièrement des gains de l’ordre de 20 à 30 % qui ne se concrétisent pas. Considérez tout pourcentage fixe comme un indicateur à analyser, et jamais comme une cible à atteindre.

Un million de tokens correspond approximativement à 750 000 mots de texte en anglais, puisqu’un token représente en moyenne environ les trois quarts d’un mot. Le coût dépend entièrement du modèle et de la répartition entre entrée et sortie. Aux tarifs des modèles de pointe de 2026, l’intervalle va de quelques dollars à une dizaine de dollars par million. Les sessions « agentic » consomment rapidement des millions de tokens, car chaque boucle relit le contexte, et les lectures du cache de prompts s’ajoutent au compteur.

Le terme « tokenmaxxing » combine « jeton » et le suffixe internet « -maxxing », qui signifie « maximiser une caractéristique ». Il s’est répandu dans les milieux d’ingénierie début 2026 après que des classements internes sur l’utilisation des jetons chez Meta et Amazon ont fuité dans la presse. En avril 2026, Business Insider l’a qualifié de « nouveau débat sur l’IA dans la Silicon Valley ». Des classements publics tels que Viberank et tokenmaxxing.sh ont ensuite repris ce libellé, classant les développeurs individuels du monde entier en fonction de leur consommation d’API.

Dans l’ensemble, oui. Le magazine Fortune a déclaré la fin du « tokenmaxxing » en mai 2026 après que Meta, Amazon, Microsoft et Uber ont revu à la baisse ou supprimé leurs classements de jetons. Le rapport « AI Impact Report » de LeadDev a révélé que seuls 19 % des personnes interrogées ont donné une évaluation positive au « tokenmaxxing » en tant qu’outil efficace pour mesurer la valeur de l’IA, tandis que 57 % estiment qu’il est un échec total. Des classements publics amateurs persistent, mais en tant que jeu, et non comme pratique de gestion.

Il n’existe pas de référence établie. Lors du déploiement chez Uber, l’intervalle des factures mensuelles variait de 500 à 2 000 dollars par ingénieur avant que l’entreprise ne plafonne les dépenses à 1 500 dollars par outil. Le PDG de Nvidia, Jensen Huang, a affirmé qu’un ingénieur gagnant 500 000 dollars devrait consommer 250 000 dollars de jetons par an, mais il s’agit très probablement d’une provocation, et non d’une norme. Les résultats montrent de grandes disparités entre du travail comparable, ce qui signifie que personne n’a encore défini ce qu’est une utilisation raisonnable.

Le « vibe coding » est une méthode de travail : déléguer la mise en œuvre à un agent IA et orienter le processus en fonction des résultats. Le « tokenmaxxing » est une méthode de mesure : considérer les jetons que vous consommez comme une preuve de productivité. Vous pouvez pratiquer le « vibe coding » de manière efficace ou gaspilleuse ; le « tokenmaxxing » récompense la version gaspilleuse, car il ne comptabilise que la consommation. Les entreprises qui ont plafonné les jetons pour mettre fin au « tokenmaxxing » ont souvent pénalisé, ce faisant, le travail légitime des agents.