- Uber a consommé en quatre mois l’intégralité de son budget IA 2026 en élargissant l’usage de Claude Code et de Cursor, et une expérimentation de productivité a immédiatement débouché sur une remise à plat du budget
- Le CTO d’Uber a indiqué que le coût mensuel des API par ingénieur se situait entre 500 et 2 000 dollars, et que 95 % des ingénieurs utilisent des outils d’IA chaque mois
- 70 % du code validé chez Uber proviendrait de l’IA, ce qui montre que les outils de codage IA sont désormais au cœur du flux de travail d’ingénierie
- Claude Code, déployé auprès des équipes d’ingénierie en décembre 2025, a vu son usage doubler d’ici février 2026 après avoir démontré ses capacités sur des tâches à plusieurs étapes, puis a épuisé le budget annuel dès avril
- Alors que l’usage de Cursor a cessé de progresser, Claude Code est devenu l’outil dominant, plaçant Uber dans l’obligation de recalculer le coût des outils de codage IA à l’intérieur de ses 3,4 milliards de dollars de dépenses annuelles en R&D
Généralisation du déploiement et révision du budget
- Chez Uber, l’usage de Claude Code et de Cursor a augmenté rapidement, au point que malgré l’explosion des coûts, les ingénieurs ont accordé à ces deux outils une valeur telle qu’il leur est devenu difficile de s’en passer
- En décembre 2025, l’accès à Claude Code a été déployé auprès des équipes d’ingénierie, et après validation de ses capacités sur des tâches en plusieurs étapes, son usage a doublé d’ici février 2026
- En avril 2026, les coûts ont absorbé l’intégralité du budget IA annuel, plaçant la direction face à une décision qu’elle n’avait pas anticipée
- Le CTO d’Uber a déclaré que l’entreprise était revenue “back to the drawing board” pour l’établissement de son budget IA
Évolution de l’usage selon les outils
- Cursor était un autre outil majeur en lice dans la bataille de l’adoption, mais sa croissance d’usage a stagné
- Claude Code est devenu l’outil dominant dans les workflows d’ingénierie
- Ce qui avait commencé comme une expérimentation de productivité s’est rapidement étendu, institutionnalisant l’usage des outils d’IA dans les activités d’ingénierie internes de l’entreprise
Ce que signifie la pression sur les coûts
- L’épuisement budgétaire inattendu chez Uber montre à quel point les outils d’IA sont perçus comme précieux pour la productivité en ingénierie
- Le rôle des outils d’IA a pris une telle importance que restreindre leur accès semblerait désormais contre-productif
- À mesure que davantage de développeurs adoptent Claude Code, il est probable que d’autres entreprises subissent des effets similaires
- Les éditeurs de logiciels vont devoir gérer une pression croissante pour maîtriser les coûts tout en maintenant leur vitesse de développement
- Si des outils de productivité pour développeurs ont une valeur telle que les ingénieurs ont consommé l’intégralité du budget en quatre mois, la conclusion est que le problème ne vient pas de l’outil lui-même, mais d’un budget établi trop tôt pour prévoir correctement la courbe d’adoption
2 commentaires
Le plaisir de tout cramer
Avis Hacker News
Quand on regarde les dépenses de l’entreprise environ une fois par mois, on voit de plus en plus de personnes dépenser 1 k$ par mois en tokens, et c’est franchement déroutant de comprendre comment c’est possible
Même en utilisant un LLM tous les jours, avec les modèles les plus chers et un mode de réflexion poussé, on plafonne en général à 200 à 400 $. Je ne suis pas un luddite opposé à l’usage en soi, je veux juste dire qu’il est difficile de comprendre comment brûler ce montant de manière responsable chaque mois. J’aimerais que quelqu’un qui dépense 5 k$ à 10 k$ par mois montre comment cela se transforme en 50 k$ à 100 k$ de valeur. Du point de vue de l’entreprise, plutôt que de justifier 100 k$ par an de dépenses en tokens, il vaudrait mieux embaucher un ingénieur junior qui produit en dépensant 100 à 200 $/mois
Les intermédiaires découvrent ensuite des schémas du type « lance 5 sous-agents, fais-leur analyser la solution sous des angles différents, puis résume », et ils peuvent vite devenir accros. Ce n’est pas une mauvaise habitude en soi, mais si on ne fait pas attention, on dépasse largement ses crédits. Les utilisateurs avancés, eux, font tourner en parallèle 10 arbres de tâches en permanence et passent d’une réponse d’agent à l’autre dans un multitâche extrême, ce qui peut faire exploser les coûts de manière exponentielle
Les gros codebases ou les problèmes complexes pèsent aussi lourd. Quand on rejoint une équipe et qu’on ne connaît pas encore de larges pans du système, on reçoit une tâche, on demande à Claude de trouver le code pertinent et de comprendre les flux existants avant même d’essayer de modifier quoi que ce soit. On accumule moins d’expertise, mais avec Claude on peut finir en 1 jour ce qui prenait 5 jours, et si tout le monde fait pareil on ne peut pas se permettre de rester à la traîne. Du coup, j’ai choisi une voie intermédiaire : finir en 2 ou 3 jours au lieu d’1 et essayer quand même de lire un peu le code. Surtout avec l’IA, le rythme de modification du code a tellement augmenté qu’on a même construit des outils pour faire expliquer en profondeur les pull requests au LLM. Ce n’est pas pour remplacer les reviewers, mais pour suivre le travail de l’équipe. Je n’ai même pas encore vraiment réfléchi à mieux utiliser les LLM, et si j’avais été plus familier du codebase, j’en aurais sans doute utilisé bien davantage. Le goulot d’étranglement reste les tests et la revue appropriés. Pour le code interne moins critique ou les projets personnels, j’ai l’impression de quasiment tout confier à l’IA, et si on utilise des compétences « superpowers », on brûle aussi beaucoup de tokens sur des fonctions de base. On commence souvent à 20–40K tokens et on finit à 80–90K, ce qui veut dire qu’à l’approche de la fin, plusieurs requêtes envoient presque 80K tokens. C’est du gaspillage, mais quand c’est quelqu’un d’autre qui paie, voilà ce qui arrive
Au début ça allait, puis un agent a écrit des centaines de milliers de lignes dans la sortie d’une cellule, créant un fichier
ipynbde 500 Mo, et Claude a essayé de le relire plusieurs fois jusqu’à épuiser toute la limite de contexte. La solution était de définir une meilleure structure de travail avec des scripts d’analyse CLI et un dossier pour stocker les résultats de recherche, mais en tant qu’opérateur, c’est moi qui ai dû faire la planification et la conception. Pour les gens qui dépensent 10 k$ de tokens par mois, il est difficile d’y voir autre chose qu’une manière paresseuse de laisser Claude Code, ce marteau hors de prix, traiter tous les problèmes. Par exemple, faire lire tous les emails chaque jour à Claude, alors qu’une solution plus intelligente consisterait d’abord à nettoyer le bruit du HTML dans le corps des emailsÀ l’inverse, si le dépôt est petit ou s’appuie sur un framework courant déjà bien connu du modèle, on peut accomplir beaucoup avec une fenêtre de contexte plus petite, et la consommation de tokens est nettement plus faible
Depuis que j’utilise des agents de codage, le seul moment où je me suis vraiment approché de la limite, c’est quand je faisais du développement cross-platform sur 3 ordinateurs en même temps dans les mêmes conditions, et même là je n’ai fait qu’approcher la limite hebdomadaire. En général, je descends à environ 20 % du quota, mais presque jamais plus bas. Pourtant je m’amuse à lancer beaucoup de prompts et de requêtes, et je ne vois pas comment dépenser davantage
Je sais que je réponds à l’IA en ce moment, mais la phrase « déterminer si l’entreprise peut absorber ce niveau de productivité à grande échelle » me paraît étrange. Si c’est réellement productif, cela augmentera le chiffre d’affaires, et la question de savoir si c’est soutenable ne devrait pas se poser
Le fait que « 95 % des ingénieurs d’Uber utilisent désormais des outils d’IA chaque mois, et que 70 % du code commité vient de l’IA » est totalement prévisible. C’est ce qui arrive quand l’usage des outils d’IA entre dans l’évaluation de performance
Je ne comprends pas le passage « déterminer si l’entreprise peut absorber ce niveau de productivité à grande échelle ». Le budget a été dépensé et il y a 4 mois de données ; la vraie question est de savoir quels résultats il y a à montrer
Je ne suis ni anti-IA ni luddite, et j’utilise l’abonnement Max à 200 $. Donc Uber a ouvert l’accès à cet outil, encouragé tout le monde à l’utiliser, cela a bien fonctionné, et maintenant ils sont confus de voir ce qui s’est passé ? C’est une autre question de juger si l’IA offre ou non un rapport productivité/coût suffisant. On se demande presque s’ils n’ont plus rien à construire ensuite
Chez Salesforce aussi, j’ai vu des changements où des choses qui prenaient plusieurs semaines semblaient soudain se faire en quelques jours. Cela ne se transforme pas immédiatement en argent, mais cela augmente le potentiel d’en gagner
Il faudrait leur demander pourquoi ils ont besoin d’autant de tokens et ce qu’ils obtiennent en échange. Si c’était AWS, tout le monde dirait : « vous ne regardez pas vos dépenses mensuelles ? »
Il est intéressant de voir qu’à chaque fois qu’un article comme celui-ci sort, beaucoup de gens se mettent soudain à penser que mesurer la productivité des développeurs est simple. Il est vrai que la productivité peut se traduire en chiffre d’affaires ou en réduction des coûts, et que le chiffre d’affaires se mesure, mais ce n’est pas si simple
On dépense de l’argent aujourd’hui pour construire des fonctionnalités qui généreront des revenus demain ; on peut donc avoir une explosion des coûts aujourd’hui sans encore avoir de revenus à mesurer. Le simple fait qu’une fonctionnalité ait été terminée aujourd’hui grâce à l’IA ne permet pas de dire immédiatement que l’IA est productive ou non ; il faudrait estimer ce qui aurait été fait sans IA, dans quels délais, et quels revenus cela aurait produits. Dans les entreprises, on est souvent dans une course de la Reine Rouge : si on n’améliore pas, on se fait dépasser par les concurrents et on perd du chiffre d’affaires. L’usage de l’IA a probablement mêlé du travail important et des choses du type « maintenant que c’est facile, on lance plein d’essais ». Pour mesurer une vraie amélioration de productivité, il faut savoir conserver le premier et éviter le second. Ce n’est pas une position pour ou contre l’IA ; c’est simplement refuser l’idée paresseuse selon laquelle « si c’était productif, on pourrait forcément le mesurer »
Je ne sais pas d’où vient cette idée qu’il serait facile de mesurer la productivité de gens qui ne sont pas des ouvriers d’usine
Je suis d’accord sur le fait que c’est très difficile à mesurer. Mais vu ce coût, il faut absolument pouvoir répondre à la question, et le multiplicateur doit aussi justifier la dépense
Selon [1], l’organisation d’ingénierie d’Uber compte environ 5 500 personnes. En prenant la valeur médiane de la fourchette de dépenses, soit 1 250 $, la dépense IA de l’ingénierie serait d’environ 6,8 M$, avec une fourchette de 2,75 M$ à 12 M$. L’article indique des dépenses R&D de 3,4 Md$
Les dépenses IA ne représentent donc pas une part énorme des dépenses de R&D. Sur 4 mois, cela fait environ 0,3 %, et annualisé environ 1 %. Si ce n’était pas prévu, ce n’est pas de l’argent de poche dans un budget, mais dans le contexte ce n’est pas gigantesque. La vraie question est : qu’ont-ils obtenu pour cette somme ? L’article affirme que 70 % des commits de code sont générés par l’IA, donc ils ont probablement passé la revue et les tests. Ce qui importe, c’est de savoir si le nombre de fonctionnalités a augmenté, si les problèmes de qualité ont diminué, ou s’il y a eu d’autres bénéfices. Malheureusement, l’article ne parle d’aucun résultat autre que la hausse des dépenses. Il est peut-être trop tôt pour évaluer les bénéfices après 4 mois. Dans un monde agile, on pourrait toutefois en attendre autre chose. [1] https://www.unifygtm.com/insights-headcount/uber
Elle ajoute aussi que « l’entreprise n’a pas divulgué les chiffres exacts de son budget logiciel ni de ses dépenses en outils de codage IA »
En tant que personne qui bootstrappe son activité, j’envie souvent les ingénieurs des grandes entreprises, mais cela m’inquiète aussi de voir à quel point les incitations sont cassées
Si j’étais ingénieur chez Uber, je n’aurais aucune raison de ne pas mettre
gpt 5.5 pro @ very high thinking + fast modedans mes prompts, même pour de petits changements. Il n’y a aucune incitation à ne pas utiliser le modèle le plus puissant, donc le plus cher. J’ai essayé un prompt de ce genre sur un test de conversion image→HTML, et un seul prompt m’a coûté 40 $. Si c’était moi qui payais directement, je n’utiliserais presque jamais ce réglage, mais dans une grande entreprise, si quelqu’un d’autre paie, j’en lancerais souvent. Le résultat était effectivement meilleur. Les ingénieurs sont évalués sur ce qu’ils livrent, pas sur le coût du processus. Il existe des façons moins chères de faire, mais les ingénieurs n’ont pas vraiment d’incitation à les choisirJe ne suis pas encore convaincu que ce soit vraiment le cas en pratique, mais la théorie est là. Chercher à réduire le coût des LLM est aussi une arme à double tranchant. Il faut que les économies de LLM réalisées par un développeur dépassent ce que l’entreprise lui coûte. Si on passe une journée à économiser 1 $ par appel, il faut presque 2 ans pour amortir ce coût salarial. Et les LLM évoluent tellement vite qu’il est difficile d’être sûr que cette optimisation ne sera pas obsolète avant 2 ans. Dans 2 ans, personne ne sait même si on fera encore des appels d’outils, si le mode de raisonnement existera encore, ni même si les fournisseurs de pointe seront les mêmes
Plus il devient courant que la direction pense pouvoir remplacer l’ingénierie logicielle par des agents, plus je me demande si les décisions ne reposent pas sur une vision irréaliste de ce qu’est un ingénieur logiciel moyen
D’un côté, il y a un effet « garbage in, garbage out ». Un CTO brillant peut être très enthousiaste sur ce qu’on peut faire avec des agents, puis s’imaginer que tous les ingénieurs peuvent en faire autant. En réalité, l’ingénieur moyen de l’organisation n’a peut-être même pas la créativité nécessaire pour voir où il pourrait économiser du travail. Dans ce cas, rendre l’usage des agents obligatoire peut ne pas augmenter la productivité, tout en faisant grimper la facture IA. D’un autre côté, l’usage de l’IA rend plus visibles deux écarts : qui va dire aux agents quoi faire, et qui va absorber le cycle de QA/revue ? Dans beaucoup d’organisations, les responsables produit ne sont pas assez techniques pour rédiger les spécifications détaillées ou les plans dont un LLM a besoin, tandis que les développeurs rouages n’ont pas vocation à produire des spécifications et veulent seulement implémenter. Si on attend des développeurs utilisant des agents qu’ils implémentent tout, on risque au contraire d’augmenter le nombre de personnes qui restent passives en attendant que le travail leur arrive. Je suis favorable à une adoption sélective des LLM pour améliorer la vitesse et la qualité des développeurs existants, mais l’idée de « réorganiser toute l’entreprise autour de ça » me paraît assez dangereuse, surtout dans les entreprises petites ou moyennes
Je suis sans doute biaisé parce que j’ai moi-même plus de fibre produit que d’autres développeurs, mais je pense que ce sont précisément ces profils qui sont les mieux placés pour être plus productifs avec des agents. Ils comprennent suffisamment la technique pour implémenter avec des agents, et suffisamment le produit pour savoir quoi implémenter. Je m’attends à ce que d’autres entreprises suivent cette voie
Je ne vois pas bien ce qu’Uber développe encore. Ils ont l’app, le backend d’affectation des véhicules, et les deux fonctionnent correctement. Je ne comprends pas pourquoi ils dépensent autant
Ils ont abandonné la conduite autonome, donc ce n’est probablement pas ça
Avec les tokens API, surtout en utilisant un contexte de 1M sans purger soigneusement l’ancien contexte, il est très facile de brûler plusieurs centaines de dollars sur une seule session
En parallèle, les abonnements autorisent le même type d’usage pour quelques centaines de dollars par mois. On dirait qu’Anthropic facture extrêmement cher les utilisateurs API, subventionne lourdement les abonnements, ou fait les deux
« Cursor estimait l’an dernier qu’un abonnement Claude Code à 200 $ par mois permettait d’utiliser jusqu’à 2 000 $ de calcul, ce qui suggérait une subvention significative de la part d’Anthropic. Aujourd’hui, cette subvention semble encore plus agressive : l’offre à 200 $ permettrait de consommer environ 5 000 $ de calcul »
C’est une manière de rendre les gens dépendants de tokens bon marché, puis de récupérer la mise quand ils montent en échelle. Uber obtiendra sûrement une remise sur le prix catalogue, mais certainement pas un tarif proche des abonnements pour entreprises de moins de 150 personnes
On peut définir des plafonds par utilisateur, mais sans plafond mensuel glissant, on se retrouve à devoir dire à un collègue : « plus d’IA pour toi jusqu’à la fin du mois ». Dans sa forme actuelle, cela me semble être une offre assez risquée