Une responsable de l’ingénierie plateforme ouvre un lundi matin la facture mensuelle de son fournisseur d’IA. La ligne des agents de programmation a encore augmenté, et elle doit l’expliquer pour mercredi. Elle construit le graphique évident : dépenses par ingénieur sur un axe, travail fusionné sur l’autre. Elle s’attend à une courbe ascendante. Elle obtient une dispersion de confettis. Deux ingénieurs ayant la même production dépensent dans des proportions qu’elle ne sait expliquer, et le plus gros utilisateur n’est pas celui dont elle distinguerait le travail. Cette scène est inventée, une façon de voir le problème avant les chiffres.

Les chiffres existent désormais. Le 10 novembre, une équipe de JetBrains, de Carnegie Mellon University et de la University of California, Irvine a publié une prépublication intitulée The AI Era’s Lines of Code?, qui demande ce que mesurent réellement les dépenses en tokens d’un ingénieur. Les auteurs sont Shyam Agarwal, Olga Lvova, Agnia Sergeyuk, Anastasiia Serova, Timofey Bryksin, Thomas Zimmermann et Bogdan Vasilescu. Leur réponse, obtenue à partir des données d’une seule entreprise, est qu’elles mesurent la quantité de travail qu’une personne effectue via des agents et disent peu de ce qu’elle produit. L’article n’a pas été évalué par les pairs.

Une métrique adoptée avant d’être testée

Les entreprises ont commencé à utiliser les dépenses en tokens comme indicateur de gestion avant que quiconque les étudie, soulignent les auteurs. Ils citent un classement créé par un salarié de Meta pour que ses collègues rivalisent afin de devenir le plus gros utilisateur de tokens de l’entreprise ; Fortune a rapporté en avril son retrait deux jours après les articles de presse. Ils citent des dirigeants de Nvidia et Meta affirmant qu’un bon ingénieur devrait consommer des tokens représentant une large part de son salaire, Salesforce fixant des objectifs minimaux de dépenses mensuelles, et des fournisseurs d’analyse divisant le coût des tokens par les pull requests fusionnées et appelant ce ratio retour sur investissement.

Les doutes se sont accumulés depuis. L’article rapporte qu’Uber a dépensé en quatre mois son budget 2026 d’outils de programmation par IA, et que son directeur des opérations a déclaré que le lien entre dépenses en tokens et fonctionnalités livrées « n’est pas encore là ». Un critique cité dans l’article a qualifié les dépenses en tokens de « métrique des lignes de code de l’ère de l’IA : facile à mesurer, facile à manipuler et déconnectée de la productivité réelle ». Meta a depuis indiqué à ses ingénieurs que les nombres de tokens ne serviraient pas à évaluer leur impact, et Amazon a supprimé un classement d’utilisation en qualifiant cette mesure de « profondément défaillante », selon le compte rendu des articles de presse par les auteurs. Restait à savoir si ces critiques résistaient au rapprochement des journaux d’utilisation et de la production réelle.

Ce que montre la télémétrie

JetBrains, qui construit des outils de développement logiciel et comptait alors environ 2 600 employés, exploite une passerelle interne enregistrant chaque appel d’agent de programmation. Les chercheurs ont retenu les cinq semaines complètes du 29 juin au 2 août 2026 et rapproché les tokens hebdomadaires de chaque ingénieur de ses commits. Le panel couvre 404 ingénieurs ; les journaux contiennent 3,1 millions d’appels d’agents. Une enquête anonyme distincte dans l’entreprise a recueilli les réponses de 412 employés.

Dans chaque tranche de nombre de commits hebdomadaires, l’observation ingénieur-semaine au 90e percentile des dépenses utilisait entre 39 et 240 fois les tokens de celle au 10e percentile. Suivre une même personne d’une semaine à l’autre donnait une relation plus plate qu’attendu. Une semaine comptant deux fois les commits habituels d’un ingénieur coûtait environ 20 % de tokens supplémentaires. Dans l’autre sens, une semaine consommant deux fois les tokens habituels ne s’accompagnait que d’environ 10 % de commits supplémentaires. Si la production augmentait proportionnellement aux dépenses, les deux chiffres approcheraient 100 %, et les auteurs rejettent la proportionnalité pour toutes les unités de temps testées.

Une grande partie de la variation tient à la personne. L’identité de l’ingénieur expliquait 79 % de la variation des tokens hebdomadaires, et le tiers des utilisateurs les plus intensifs consommait 79 % de tous les tokens. Les personnes dépensant le plus restaient les mêmes pendant les cinq semaines. Les commits, les lignes modifiées et deux autres mesures d’activité expliquaient ensemble 38 % des écarts entre ingénieurs et 13 % des écarts hebdomadaires chez une même personne. Pris seuls, le rôle et l’équipe prédisaient moins bien les dépenses que la simple moyenne.

L’article demande ensuite où va le surplus. Les semaines sans aucun commit ne représentent que 4 % des tokens, mais les auteurs estiment, à partir des courbes les mieux ajustées, que jusqu’à environ deux cinquièmes des dépenses ne varient pas avec les commits de la semaine. Ils parlent d’une borne supérieure, car elle inclut le coût fixe du simple usage d’un agent et les dépenses associées aux commits écrits à la main. Ils relèvent aussi que la plupart des tokens correspondent à du contexte renvoyé à chaque tour, et qu’un nouveau modèle de pointe est arrivé en troisième semaine, captant 45 % de toutes les dépenses en deux semaines.

Le travail qui ne devient jamais un commit

L’enquête explique une partie de l’écart. Parmi les 197 évaluations des deux agents de programmation par les répondants techniques, 167 répondaient aux questions sur la semaine précédente. Dans 91 % d’entre elles, les répondants disaient que l’outil leur avait fait gagner du temps, avec une médiane de 10 heures. Ils utilisaient les agents pour programmer dans 63 % des évaluations et pour au moins une autre activité dans 89 % : analyse de données, recherche d’idées, recherche sur un sujet, planification, apprentissage, rédaction. Ceux qui utilisaient l’agent uniquement pour programmer rapportaient un gain médian de 3 heures ; ceux déclarant au moins deux usages hors programmation rapportaient 10 heures.

Une partie de la valeur est du travail qui n’aurait pas existé autrement. À la question du principal bénéfice de l’agent, 31 % des 74 réponses substantielles citaient la rapidité sur les tâches habituelles et 30 % le travail dans du code, des domaines ou des technologies inconnus ; une personne écrivait : « Je peux essayer des choses que j’avais peur d’essayer. » Parmi 44 descriptions de travail réalisé uniquement grâce à l’existence de l’agent, 36 % concernaient une base de code, un langage ou une pile inconnus. L’enquête relève aussi des coûts. Le plus fréquent était une sortie erronée ou de faible qualité, mentionnée dans 49 % des réponses, et 31 % des utilisateurs techniques d’agents rapportaient une charge cognitive accrue. Les auteurs ajoutent que les déclarations personnelles peuvent surestimer les gains, et citent un essai randomisé de 2025 où des développeurs open source expérimentés prenaient 19 % plus de temps avec les outils d’IA tout en croyant être plus rapides.

Ce que cela signifie pour les objectifs, budgets et plafonds

Les auteurs ne concluent pas que les agents sont un mauvais investissement. Leur conclusion porte sur la mesure. Si l’association chez un même ingénieur était causale, doubler ses dépenses par un objectif augmenterait ses commits d’environ 10 %, dans une fourchette de 2 à 25 %. Ils déconseillent d’évaluer les ingénieurs selon leurs dépenses et d’attendre des objectifs une forte hausse de production. Diviser les dépenses par la production induit aussi en erreur : les tokens par commit diminuent mécaniquement quand les commits augmentent, donnant à l’ingénieur l’air plus efficace lors d’une semaine chargée.

Le traitement des plafonds est le moins rassurant. Un plafond touche surtout les plus gros utilisateurs, dont la part des dépenses non liée à la production est la plus faible des trois groupes, à 36 %, contre 51 et 52 % pour les autres. Comme ils consomment l’essentiel des tokens, ils concentrent aussi l’essentiel des dépenses non liées ; un plafond retire donc à la fois des dépenses utiles à la production et d’autres qui ne le sont pas, sans que le nombre de tokens permette de les distinguer. Avant de plafonner, les auteurs suggèrent de compresser ou gérer le contexte, de mettre en cache le contexte répété et d’orienter les appels courants vers des modèles moins chers. Ils recommandent de mesurer le coût facturé plutôt que les tokens, car réduire le contexte peut augmenter la facture lorsque l’agent relit ce qui a été supprimé.

Deux limites comptent. JetBrains construit des outils de programmation par IA ; certains usages mesurés peuvent donc être des tests de ses propres agents, et ses ingénieurs travaillent sur des bases de code établies. L’utilisation était volontaire, sans objectif, si bien que les écarts de dépenses reflètent en partie des choix personnels. Les commits omettent aussi les revues et la conception. Les auteurs soulignent qu’il s’agit d’associations observées dans une seule entreprise sur cinq semaines.

Une seconde étude, dont les auteurs se recoupent partiellement, montre ce qui se passe lorsqu’un objectif est imposé. À partir de 802 développeurs et 196 212 pull requests, elle examine une entreprise de taille moyenne dont le directeur technique a fixé en juin 2025 l’objectif de doubler les pull requests fusionnées par ingénieur grâce à l’IA. L’entreprise n’a atteint cet objectif qu’au dixième mois, et le coût s’est reporté sur la revue de code, où la charge par relecteur a doublé.

Compter ce qui compte

Les auteurs de JetBrains proposent deux corrections. Les passerelles devraient enregistrer le ticket ou la tâche servi par chaque session d’agent, afin de relier les dépenses aux résultats plutôt qu’aux seuls commits. Et le domaine a besoin de mesures validées de la valeur du travail assisté par agent ; les auteurs n’en connaissent aucune. D’ici là, disent-ils, les dépenses conviennent à la comptabilité des ressources et guère davantage. Pour l’adoption, ils suggèrent de publier le nombre hebdomadaire d’utilisateurs à côté d’un indicateur qui ne grandit pas avec le contexte, comme la part des ingénieurs utilisant des agents la plupart des jours travaillés.

De retour dans le bureau inventé, la responsable de l’ingénierie plateforme ne réduit aucun budget le mercredi. Elle demande à l’équipe de la passerelle d’ajouter un champ, le ticket auquel chaque session appartient, et explique à son interlocuteur financier que le graphique en confettis est le résultat. La facture continuera d’arriver le premier du mois. Elle compte la fréquence à laquelle ses ingénieurs recourent à l’agent. Savoir si cela valait la dépense est une autre question, sans ligne correspondante sur la facture.

Références

  • Agarwal, S., Lvova, O., Sergeyuk, A., Serova, A., Bryksin, T., Zimmermann, T., & Vasilescu, B. (2026). The AI Era’s Lines of Code? A Case Study on What an Engineer’s Token Spend Measures. arxiv.org
  • Arar, A. B. (2026). Tokenmaxxing and the search for AI metrics that matter. LeadDev. leaddev.com
  • Becker, J., Rush, N., Barnes, E., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. arxiv.org
  • Bharade, A. (2026). Uber’s COO says it’s getting harder to justify the money spent on AI tokenmaxxing. Business Insider, via Yahoo Finance. finance.yahoo.com
  • Cooter, M. (2026). Meta minimizes role of token maxing in employee evaluations. CIO. cio.com
  • He, H., Agarwal, S., Denisov-Blanch, Y., Azaletskiy, P., Koyejo, S., & Vasilescu, B. (2026). AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise 2x Mandate. arxiv.org
  • Munis, J. (2026). A Meta employee created a dashboard so coworkers can compete to be the company’s No. 1 AI token user. Fortune. fortune.com
  • Palmer, A. (2026). Amazon’s anti-tokenmaxxing memo says engineers should be pickier about using AI. CNBC. cnbc.com