La facture annuelle des jetons d'IA commence à rivaliser avec la masse salariale des ingénieurs dans certaines entreprises, et la direction ne sait pas si elle doit se réjouir ou paniquer. Les entreprises ont passé ces dernières années à injecter massivement des capitaux dans les grands modèles de langage, espérant qu'une inférence moins coûteuse se traduirait automatiquement par une réduction des effectifs et des cycles de déploiement plus rapides. Au lieu de cela, de nombreuses organisations d'ingénierie se retrouvent à payer deux fois : une fois pour les talents qu'elles espéraient augmenter, et une seconde fois pour la puissance de calcul qui était censée les remplacer. La question n'est plus de savoir si l'IA peut écrire du code. C'est de savoir si le code qu'elle écrit justifie la fortune engloutie pour le produire.
Le seuil du demi-salaire
Jensen Huang a exposé les chiffres sans détour à la clôture de la GTC 2026, lors de son intervention dans le podcast All-In. Le PDG de Nvidia a proposé de mesurer l'efficacité d'un ingénieur en comparant directement son salaire à sa consommation de jetons d'IA. Son seuil était sans appel. Prenons l'exemple d'un ingénieur logiciel gagnant 500 000 $ par an. Si cet ingénieur utilise moins de 250 000 $ de jetons par an, soit environ la moitié de son salaire, Huang considère cela comme un signal d'alarme. La direction devrait être « profondément alarmée », selon ses termes, non pas parce que l'entreprise dépense trop pour son personnel, mais parce qu'elle est probablement en train de le sous-utiliser.
Cette logique inverse la mentalité traditionnelle de contrôle des coûts. Pendant des années, les équipes financières ont traité la puissance de calcul comme une dépense variable à minimiser. Huang soutient le contraire. Un ingénieur coûteux qui utilise à peine un modèle est un ingénieur coûteux opérant sans multiplicateur de force. L'attente est que les talents à haut coût agissent comme un entonnoir, faisant passer d'énormes volumes de travail à travers des systèmes d'IA, en révisant les résultats et en orchestrant l'ensemble. Une faible consommation de jetons n'est pas un signe d'économie. C'est le signe que l'humain effectue encore le travail mécanique qu'un modèle aurait pu gérer.
À quoi ressemble cette dépense en pratique
Pour comprendre l'importance de ce seuil, considérons ce que représentent réellement 250 000 $ de jetons. Aux tarifs actuels des modèles de pointe, il ne s'agit pas de quelques suggestions d'autocomplétion. Cela représente des millions de jetons traités chaque jour ouvré pour une vaste gamme de tâches. Cela suggère un ingénieur qui ne se contente pas d'accepter des complétions d'éditeur, mais qui réalise un raisonnement architectural approfondi, de la refactorisation massive via des agents intelligents, des pipelines de tests automatisés, de la génération de données synthétiques et de l'exploration de conception itérative.
Un ingénieur senior travaillant de cette manière pourrait enchaîner plusieurs appels de modèles pour une seule fonctionnalité : générer l'ossature, analyser les dépendances pour détecter des changements de rupture, simuler des comportements de cas limites et produire de la documentation en parallèle. Le débit est massif car l'humain ne tape plus chaque ligne. Il pilote. Pour Huang, le salaire ne se justifie que lorsque l'humain opère à cette échelle, multipliant sa production grâce à une interaction incessante avec les modèles.
Là où les rendements se perdent
Malgré cette vision, l'industrie est confrontée à un écart croissant entre les dépenses d'infrastructure et les résultats livrés. Les entreprises se sont précipitées vers des stratégies gourmandes en jetons, souscrivant des contrats d'entreprise auprès de fournisseurs d'IA et adaptant leurs pipelines de développement autour d'outils génératifs. Les dépenses d'investissement ont été colossales. Les retours sur productivité, pour beaucoup, ont été décevants.
Les développeurs sont en effet plus rapides pour les tâches ingrates. Le code répétitif, les squelettes de tests unitaires et les opérations CRUD répétitives s'enchaînent rapidement lorsqu'un modèle génère le premier jet. Mais l'ingénierie logicielle n'a jamais vraiment été une question de vitesse de frappe. Le travail difficile et coûteux réside dans la maintenance de systèmes tentaculaires, le raisonnement face à des modes de défaillance distribués, la garantie de la sécurité à travers des dépendances multicouches et la gestion de la dette technique que chaque raccourci accumule. Ces