L’IA rend chaque individu 10x plus productif. Aucune entreprise n’est devenue 10x plus performante.

Où est passée la productivité ? C’est la question que pose a16z cette semaine — et la réponse ressemble étrangement à ce qui s’est passé avec l’électricité dans les usines textiles des années 1890. Les moulins ont installé des moteurs électriques à la place de la vapeur. Pendant trente ans, la productivité n’a pas bougé. Pas parce que la technologie ne marchait pas — parce que l’organisation n’avait pas changé.

Le paradoxe de la productivité IA

L’analogie historique que développe a16z est frappante : dans les années 1890, les usines textiles ont simplement remplacé les moteurs à vapeur par des moteurs électriques, sans repenser l’organisation du travail [1]. Il a fallu attendre les années 1920 — les chaînes de montage, les moteurs individuels par machine, des métiers complètement redéfinis — pour que l’électricité produise enfin des gains réels. Trente ans de latence.

On vit exactement le même décalage avec l’IA. Les individus qui maîtrisent les outils agents sont déjà au niveau 5 ou 6 sur l’échelle de maturité que propose Bassim Eledath [2]. Ils lancent des agents en parallèle, dorment pendant que leurs PRs se construisent. Mais quand leur collègue est au niveau 2 et doit approuver manuellement chaque PR, tout le pipeline s’arrête. Le goulot d’étranglement n’est plus le modèle — c’est l’écart de maturité entre les membres d’une même équipe.

Amazon : quand l’IA ralentit le travail

Le cas Amazon est un concentré de tout ce qui peut mal tourner. Selon une enquête du Guardian, une demi-douzaine d’employés témoignent que l’outil interne Kiro hallucine régulièrement, génère du code bancal, et les force à passer plus de temps à corriger l’IA qu’à coder eux-mêmes [3]. Une développeuse résume : “On essaie de résoudre avec l’IA un problème que l’IA a créé.” Quelques jours après son témoignage, elle a été licenciée.

Le problème n’est pas l’outil. C’est la logique de déploiement : Amazon impose l’IA à tous les postes, traque l’utilisation, et pousse la vitesse comme métrique principale. Pendant ce temps, 30 000 employés ont été licenciés en quatre mois.

“You don’t look at the problem and go, ‘How do I use this hammer?’ You look at it and go, ‘Is this a problem for a hammer or something else?’” — ingénieur supply chain chez Amazon

Meta aussi trébuche

De l’autre côté, Meta repousse son modèle “Avocado” d’au moins deux mois [4]. En interne, le modèle n’atteint pas le niveau de Gemini 3.0 de Google. Plus révélateur encore : la direction discute de licencier temporairement Gemini pour faire tourner ses propres produits IA. Quand le lab IA d’une des plus grandes entreprises tech du monde envisage de sous-traiter son inférence au concurrent, c’est que la course aux modèles ne suffit plus.

La boucle du milieu

Annie Vella a mené une étude longitudinale sur six mois avec 158 ingénieurs logiciels dans 28 pays [5]. Résultat contre-intuitif : les développeurs passent moins de temps sur presque toutes les tâches — écriture, design, refactoring, tests, debug. Le temps gagné ne remonte pas vers l’architecture ou la conception. Il disparaît dans ce qu’elle appelle “the middle loop” : orchestrer, vérifier, itérer avec l’IA.

82 % des participants déclarent passer moins de temps à écrire du code. Mais la seule tâche en hausse, c’est la revue de code. Le métier de développeur se redéfinit en temps réel : moins d’écriture, plus de vérification. Et cette nouvelle boucle de travail — prompt, évaluation, ajustement — n’a même pas encore de nom dans la plupart des organisations.

Quand le benchmark ment

Et les progrès des modèles, dans tout ça ? Un article d’Entropic Thoughts pose une question dérangeante : les LLMs progressent-ils vraiment encore pour le code ? [6] En regardant les données SWE-bench sous l’angle du taux de merge (et non du simple passage de tests), la courbe est plate depuis début 2025. Le modèle qui explique le mieux les données ? Une fonction constante. Pas de pente, pas de progrès. Les scores SWE-bench montent, mais le code qui en sort n’est pas plus souvent mergeable.

Simon Willison propose un recadrage salutaire : produire du code moins bon avec des agents est un choix [7]. Les agents sont idéaux pour le refactoring, la dette technique, les renommages massifs — tout ce qu’on repousse éternellement parce que c’est simple mais chronophage. Le vrai gain n’est pas d’aller plus vite, c’est d’aller mieux.

Prouver, pas vibrer

Et si la solution venait d’un changement plus fondamental ? Un article propose de remplacer le “vibe coding” par du “prove coding” en utilisant des types dépendants et la vérification formelle [8]. Avec un langage comme Lean 4, le compilateur ne vérifie pas juste que le code compile — il vérifie que la preuve est valide. Si les humains ne lisent plus la majorité du code généré, optimiser un langage pour la lisibilité humaine n’est plus la priorité. Ce qui compte, c’est la capacité à exprimer précisément ce que le code doit faire.

C’est un virage philosophique : passer d’un monde où on écrit du code à un monde où on écrit des spécifications, et où la machine prouve que l’implémentation est correcte.

L’organisation est le nouveau goulot d’étranglement

Les modèles progressent moins vite que ce qu’on croit. Les outils individuels sont déjà puissants. Le vrai retard, c’est l’organisation. Comme les usines de 1890 qui avaient de l’électricité mais pas de chaîne de montage, la plupart des entreprises ont accès à GPT-4, Claude, Gemini — et n’en tirent rien de transformationnel.

La question pour un engineering leader aujourd’hui n’est plus “quel modèle choisir”. C’est : à quel niveau de maturité agentique se trouve chaque membre de mon équipe ? Et qu’est-ce que je change dans l’organisation pour que les gains individuels deviennent collectifs ?

Sources

1. Institutional AI vs Individual AI
2. The 8 Levels of Agentic Engineering
3. Amazon is determined to use AI for everything – even when it slows down work
4. Meta Delays Rollout of New A.I. Model After Performance Concerns
5. The Middle Loop
6. Are LLMs not getting better?
7. AI should help us produce better code
8. Don’t Vibe — Prove

Pour aller plus loin

• The Shape of the Thing — Ethan Mollick sur le passage de l’ère du co-pilotage à l’ère du management d’agents, et pourquoi l’exponentielle continue
• Claude now creates interactive charts, diagrams and visualizations — Anthropic lance les visualisations interactives dans Claude, un pas vers l’IA comme outil de pensée visuelle
• How Vimeo Implemented AI-Powered Subtitles — Un cas concret de déploiement IA réussi : architecture, compromis, leçons d’ingénierie
• Anthropic invests $100 million into the Claude Partner Network — 100 M$ pour structurer un écosystème de partenaires autour de Claude

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.