L’IA brûle des milliards en haut — et change votre métier en bas

Anthropic vient de signer un contrat de calcul à près de 45 milliards de dollars avec SpaceX [1]. Pendant ce temps, sur votre laptop, un agent vient peut-être de réécrire correctement un module en trois minutes. Deux échelles, deux mondes — et pourtant un seul fil. Parce que la question n’est pas « combien ça coûte là-haut », mais « qu’est-ce que ça change ici, dans le travail ».

Quarante-cinq milliards pour calculer

Commençons par le vertige des chiffres. Le deal Anthropic–SpaceX à 45 milliards [1] n’est pas un cas isolé : c’est la signature d’une industrie qui dépense comme jamais. OpenAI fonce vers une IPO qui pourrait arriver dès septembre [2], avec une valorisation projetée au nord de 800 milliards de dollars — comme Anthropic [3].

Le problème, c’est l’hypothèse cachée derrière ces valorisations : que ces labos garderont leur part de marché et leur pricing premium, parce qu’il n’y aurait pas d’alternative. Or les données pointent dans l’autre sens. Sur un même panier de 10 évaluations, le modèle le plus capable de chaque labo coûte 4 811 $ chez Anthropic, 3 357 $ chez OpenAI… mais 544 $ chez Zhipu (GLM) [3]. Claude est près de neuf fois plus cher que l’alternative chinoise la moins chère pour le même travail.

La subvention qui ne tient pas

Et le prix ne baisse plus — il remonte. Tomasz Tunguz l’a chiffré : l’IA de Google triple de prix chaque année, le modèle phare d’OpenAI a d’abord été subventionné avant de remonter [4]. Sa lecture est limpide :

Les baisses quand le cash abonde et que la part de marché compte. Les hausses quand le cash se resserre et que ce sont les marges qui comptent.

Nous sommes clairement dans le second cas — le capex bat des records et les marges deviennent la priorité. La conséquence se voit déjà dans les résultats trimestriels : Meta, Shopify, Spotify et Pinterest ont tous signalé la hausse des coûts d’inférence comme un poids sur leurs marges [3]. La facture de l’IA arrive. Mais alors, qu’est-ce qu’on fait, nous, concrètement, avec cette techno ?

Construire des agents, pas invoquer des frameworks

C’est là que le sujet redescend sur Terre. Anshuman Mishra propose un changement de regard salutaire : arrêter de commencer par le framework [5]. Les tutos sur les agents démarrent trop haut dans la pile — « installe cette lib, définis cette reward, lance ce trainer ». Utile une fois qu’on a compris. Inutile pour se construire un modèle mental.

Sa proposition : descendre d’un cran. Avant le trainer, il y a un environnement. Avant le reinforcement learning, il y a un espace d’actions. La boucle de fond est toujours la même — prompt → action du modèle → environnement → reward → mise à jour du gradient — qu’on parle d’un agent navigateur, d’un agent de code ou d’un agent qui dessine des diagrammes. Les libs (TRL, verl, OpenRLHF…) ne sont pas magiques : ce sont des infrastructures autour de cette boucle. Le cœur conceptuel, lui, est petit. Et la vraie bascule, c’est que l’agent ne génère plus du texte plausible : il génère des instructions qu’un autre système va exécuter — et qui peuvent échouer.

Le vrai sujet, c’est le feedback

Marc Brooker tire le fil au même endroit, et c’est l’idée la plus marquante du jour : les agents ne sont rien d’autre que des boucles de feedback [6]. Un composant utile mais imparfait (le LLM), rendu capable par la boucle qui l’entoure. Le passage de l’autocomplétion « open loop » aux agents, c’est exactement ça : déplacer le feedback du développeur (build, test, retour à l’IDE) vers l’agent lui-même.

D’où son hypothèse, profondément contre-intuitive : à long terme, les agents trouveront faciles les tâches dotées d’un feedback efficace, et difficiles celles qui en sont privées. Conséquence qui dérange : un site web ergonomique et « délicieux » a besoin d’un humain — lent, mou, inconsistant — dans sa boucle. Un moteur de stockage de base de données correct et performant a une spécification claire, des propriétés de sûreté testables sans humain.

En fait, on va découvrir que le SaaS est « difficile » et que le logiciel système est « facile ».

Ce qui monte en valeur, ce n’est donc pas le prompt magique : c’est la spécification — écrire ce que « bien » veut dire — et les outils qui l’appliquent au code (Rust, TLA+, property-based testing). Le futur du dev, c’est construire ces boucles de feedback.

Tester moins au hasard

Spotify donne une déclinaison très concrète de cette idée côté produit. Chez eux, seulement 12 % des A/B tests aboutissent à un résultat positif livré [7]. Leur usage des LLM evals tient en une formule : un entonnoir, pas une fourche. Les evals vérifient (la sortie respecte-t-elle les standards de qualité ?), les expériences valident (les vrais utilisateurs réagissent-ils comme prévu ?). Les evals viennent avant l’expérience, pas à sa place — elles écartent les candidats non prometteurs avant qu’ils ne consomment de la bande passante d’expérimentation. On ne teste plus pour savoir si le changement fait ce qu’on voulait : ça, l’eval l’a déjà dit. On teste pour valider qu’il produit le résultat business attendu. Encore une boucle de feedback, mieux outillée.

Et le management dans tout ça ?

Reste l’humain qui pilote tout ça, sous pression. John Cutler ramène le leadership à trois mouvements fondamentaux : Exception, Présence, Délégation [8]. L’exception : des systèmes qui signalent les écarts pour n’intervenir qu’alors — et qui sont le mécanisme d’apprentissage. La présence : aller voir par soi-même (genchi genbutsu), parce que le tacite ne se transfère qu’en travaillant ensemble sur de vrais problèmes. La délégation : pousser l’autorité vers les gens au plus près du travail. Ou, comme le formulait David Marquet après avoir redressé un sous-marin nucléaire :

Push authority to information, as opposed to information to authority.

Quand l’un manque, les anti-patterns ressurgissent : des dashboards que personne ne sait lire, un VP épuisé sans qui rien ne bouge, des équipes « autonomes » qui n’ont aucune idée de ce à quoi ressemble « bien ». Confondre lisibilité et compréhension, implication et création de valeur, autonomie décrétée et autonomie construite.

Le fil de la journée tient peut-être là. En haut, on dépense des milliards en pariant qu’il n’y aura pas d’alternative. En bas, le vrai levier n’a pas changé : des boucles de feedback bien conçues, des spécifications claires, de la présence et de la confiance. La question que je vous laisse : et si l’avantage durable n’était pas dans le modèle le plus cher, mais dans la qualité des boucles qu’on construit autour ?

---

Sources

1. Anthropic to Pay SpaceX Nearly $45 Billion for Computing Deal
2. OpenAI barrels toward IPO that may happen in September
3. Cheap AI could derail OpenAI and Anthropic’s IPOs
4. The Unsustainable Subsidy
5. anshuman on X: “On Building Agents From First Principles”
6. What’s Easy Now? What’s Hard Now?
7. Better Experiments with LLM Evals — A funnel, not a fork
8. TBM 422: Exception, Presence, Delegation

Pour aller plus loin

• What data agent benchmarks do and don’t tell us — pour creuser la différence entre ce qu’un benchmark d’agent data mesure vraiment et ce qu’il laisse dans l’ombre.
• Prompt Engineering from Zero to Hero — un panorama pratique pour muscler la partie prompt, même si le vrai levier reste la boucle de feedback.
• Horizontal vs. vertical context switching for engineering managers — un complément concret au triptyque Exception/Présence/Délégation, côté charge mentale du manager.
• mondayDB 3 - Solving HTAP for a Trillion-Table System — un cas système où la spécification claire fait tout : exactement le « facile » au sens de Brooker.

Cet article a été rédigé en m’appuyant sur une IA pour m’aider à synthétiser et structurer ma veille. Les idées, le choix des sources et la relecture restent les miens.