Le burn rate d'un ingénieur pourrait bientôt égaler son salaire

In plain terms

Le patron d'Instagram estime que, d'ici un à deux ans, ce qu'un bon ingénieur dépense en tokens d'IA pourrait coûter à peu près aussi cher que son salaire. Conséquence logique : les entreprises commenceront à plafonner ce budget, ingénieur par ingénieur. Ce n'est pas une anecdote RH - c'est la fin d'une hypothèse implicite de notre métier.

Une variable de coût réapparaît là où on l'avait oubliée

Nous suivons depuis plusieurs semaines le retour du CFO dans la boucle de l'IA. L'annonce d'Adam Mosseri, sur le podcast de Lenny, en marque l'étape suivante : le rationnement descend jusqu'à l'individu. Sa formulation est mesurée : « I think that you can imagine, at least in a year or two … that the burn rate of a strong engineer might be the same as their salary ». Il ne parle pas d'un plafond punitif, mais d'une allocation de ressource, au même titre que la masse salariale ou les GPU - proportionnée à la capacité démontrée de chacun à produire du ROI.

Les faits autour sont plus éloquents que la prédiction. Meta a fermé son classement interne d'usage de tokens quand les coûts se sont emballés - Mosseri qualifie lui-même la pratique de « silly ». Uber a épuisé la totalité de son budget de codage IA 2026 dès le mois d'avril. Microsoft a coupé des licences Claude Code face à la dépense. Meta, elle, n'a pas encore instauré de plafond par tête.

Under the hood

Pendant vingt ans, l'architecture logicielle a raisonné sur un coût marginal de production de code quasi nul : le temps de l'ingénieur était la seule ressource rare, et on optimisait ça. Une boucle agentique qui tourne la nuit sur une migration change l'équation - elle consomme une ressource facturée au token, dont la consommation croît avec la taille du contexte, donc avec la dette technique du dépôt. Un monorepo mal découpé ne coûte plus seulement du temps de compréhension humaine : il coûte du contexte à chaque itération d'agent, sur chaque tâche.

So what

Le plafonnement par tête est la mauvaise réponse à une bonne question. Il rationne l'accès sans traiter la cause, et il crée une métrique que les ingénieurs apprendront à jouer - on l'a vu avec les lignes de code, on le reverra avec les tokens.

La bonne réponse est architecturale, et elle est réjouissante : dans un monde où le contexte se paie, la modularité, les frontières nettes et la documentation à jour redeviennent des postes d'économies mesurables, pas des vertus abstraites qu'on plaide en rétrospective. Le refactoring vient de trouver son business case.

Mosseri table par ailleurs sur une baisse des prix des tokens sous l'effet de la concurrence. Probable. Mais la demande d'un agent est élastique : si le token vaut dix fois moins, on en consommera cent fois plus.