L’IA écrit le code. Le vrai travail commence après.

Et si la bonne question n’était plus « est-ce que l’IA va écrire notre code ? » mais « qu’est-ce qui se passe une fois le code écrit ? ». Cette semaine, cinq études indépendantes convergent vers la même conclusion : on génère du code plus vite qu’on ne construit les systèmes pour le comprendre, le vérifier et le livrer [1]. Le goulot d’étranglement s’est déplacé.

L’IA compresse le milieu du sandwich

La meilleure image pour comprendre ce qui se passe nous vient d’une équipe de Princeton. Le travail de connaissance — dont le développement logiciel — fonctionne comme un « sandwich décider-exécuter-livrer » [2]. L’IA compresse la couche du milieu — l’exécution, c’est-à-dire écrire le code. Mais les deux autres couches, décider quoi faire et livrer réellement de la valeur, résistent à l’automatisation d’une manière que de simples gains de capacité ne suffiront pas à surmonter.

C’est ce qui explique un paradoxe. On nous a vendu des vagues de licenciements dus à l’IA. Quand Block a annoncé 4 000 suppressions de postes en invoquant une « nouvelle façon de travailler » permise par l’IA, l’enquête qui a suivi a révélé une tout autre histoire : une entreprise sous pression financière après avoir triplé ses effectifs pendant la pandémie [2]. Le fameux « AI-washing ». La conclusion des chercheurs est nette : il y a assez de preuves pour rejeter le récit du remplacement massif, y compris dans le secteur où l’IA est la plus avancée.

Générer plus vite ne veut pas dire livrer plus

Alors si le code sort plus vite, où part le temps gagné ? Nulle part, ou presque. Les études convergent : le vrai coût, ce n’est pas de produire le code, c’est de le comprendre, de le vérifier et de le mettre en production [1]. « Ton code IA marche » n’a jamais été synonyme de « ton code est livré ». La compréhension doit suivre le rythme de la génération, sinon on accumule une dette d’un genre nouveau : du code que personne ne comprend vraiment.

C’est exactement l’angoisse que le chercheur Arvind Narayanan a adressée de front dans sa keynote à ICML : comment se préparer à un futur où l’IA fera de plus en plus de notre travail ? Sa réponse tient dans le cadre « AI as Normal Technology » [3]. Aucun jalon franchi en laboratoire ne nous mettra tous au chômage du jour au lendemain. En revanche, les métiers de demain seront radicalement différents, et l’adaptation nécessaire sera énorme.

Le code n’est plus le livrable

Si la valeur se déplace, notre attention doit se déplacer avec elle. Et c’est là que le message devient inconfortable pour beaucoup de développeurs. Salvatore Sanfilippo — antirez, le créateur de Redis — le formule sans détour : beaucoup de programmeurs ont aujourd’hui moins d’impact qu’ils ne pourraient, parce qu’ils regardent le code [4].

Si vous contrôlez les idées de votre logiciel, regarder le code lui-même est sous-optimal et souvent inutile.

Attention, ce n’est pas un appel au « vibe coding » où l’on demande juste le produit final. C’est un déplacement de curseur : comment relire 5 000 lignes de code par jour ? Les LLM écrivent un code localement optimal mais peinent encore sur les grandes idées. Le temps passé à scruter ligne par ligne, c’est du temps volé à la vraie question : qu’est-ce que je construis, et dans quelle direction [4] ?

Ce constat n’est pas isolé. Lors du retreat « Future of Software Engineering » organisé par Martin Fowler chez Thoughtworks, une soixantaine de leaders sont arrivés à une conclusion voisine : la qualité du code bas niveau est probablement encore importante, mais automatisable ; le design de haut niveau reste du territoire humain [5]. Leur pari le plus radical : la spécification pourrait remplacer le code comme unique source de vérité. On ne versionnerait plus le code, mais l’intention qui le génère.

Et l’économie, dans tout ça ?

Reste une question que personne n’aime poser : est-ce que ça vaut le coût ? Les chiffres donnent le vertige. Anthropic dépense 2,3 fois sa masse salariale en compute — environ 515 000 $ de calcul par ingénieur et par an, contre un salaire chargé de 224 000 $ [6]. Le reste du marché suit de loin : le top 1 % des entreprises dépense 89 000 $ par ingénieur, la médiane 137 $. Autant dire quasi rien.

Mais ceux qui investissent ne dépensent pas au hasard. Les données de la passerelle IA de Vercel montrent une discipline de routage désormais visible à l’échelle : le travail à fort volume part vers des modèles bon marché, le travail à fort enjeu reste sur les modèles frontière [7]. Les modèles open-weight sont passés d’un neuvième à près d’un tiers du volume de tokens en trois mois, pour environ un dixième du prix moyen. Le prix par token, lui, s’est stabilisé. On ne dépense pas plus par unité — on dépense plus, parce qu’on en fait plus.

C’est peut-être ça, la vraie histoire de l’année : l’IA ne remplace pas l’ingénieur, elle change la nature de ce pour quoi on le paie. Écrire le code devient la partie facile. Décider quoi construire, garantir que ça marche vraiment, et le livrer — c’est là que se trouve désormais l’essentiel de votre valeur.

Alors la question n’est plus « l’IA va-t-elle prendre mon job ? », mais « suis-je en train de monter dans le sandwich, ou je reste coincé au milieu ? »

---

Sources

1. Five studies that are changing how I think about AI in software engineering
2. Why AI hasn’t replaced software engineers, and won’t
3. What will be left for us to work on?
4. Control the ideas, not the code
5. Software Design in the Agentic Age: Place Your Bets
6. “When AI Costs More Than the Engineer”
7. Open-weight models surge to 29% of volume, price per token flattens

Pour aller plus loin

• The Conversation Isn’t Real – Lon Riesberg — pour comprendre pourquoi un chat avec un LLM n’est pas une conversation mais un document, et comment en tirer parti.
• A software architecture reading list — pour muscler le design haut niveau, justement la couche que l’IA n’automatise pas.
• Introducing TabFM: A zero-shot foundation model for tabular data — un modèle de fondation zero-shot pour les données tabulaires, la même logique de compression appliquée à la data.
• On Data Quality - The Fundamentals — parce que la qualité en entrée reste le premier facteur de confiance, IA ou pas.

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.