La question a changé
En 2026, la question « est-ce que l’IA écrit du code ? » n’intéresse plus personne. La réponse est oui, à grande échelle : d’après le rapport DORA 2025 de Google, 90 % des professionnels de la tech utilisent l’IA au travail, et plus de 80 % estiment qu’elle a augmenté leur productivité.
La question intéressante est ailleurs. Si l’écriture de code était réellement le goulot d’étranglement du développement logiciel, nous devrions observer une explosion proportionnelle de valeur livrée. Ce n’est pas ce que montrent les données.
Le paradoxe de la productivité perçue
Le résultat le plus dérangeant vient d’une étude contrôlée randomisée publiée par METR en juillet 2025. Seize développeurs open source expérimentés, 246 tâches réelles sur leurs propres dépôts, tirage au sort entre « avec IA » et « sans IA ».
Résultat : les développeurs ont mis 19 % de temps en plus avec les outils d’IA. Ils anticipaient un gain de 24 %. Après l’expérience, donc après avoir été plus lents, ils estimaient encore avoir gagné 20 %.
Cette étude a ses limites, et les auteurs sont les premiers à les poser : petit échantillon, développeurs très expérimentés travaillant sur des bases de code qu’ils connaissent par cœur, contexte peu représentatif d’un projet greenfield. Il ne s’agit pas de conclure que l’IA ralentit tout le monde. Il s’agit de constater qu’il existe un écart mesurable entre la productivité ressentie et la productivité réelle, et que cet écart va systématiquement dans le même sens.
C’est un problème de pilotage avant d’être un problème technique. Un dirigeant qui arbitre sur du ressenti collectif arbitre sur une donnée biaisée.
Plus vite, mais plus instable
Le rapport DORA 2025 pose le second constat, plus structurant : une adoption élevée de l’IA est corrélée à une hausse du débit de livraison ET à une hausse de l’instabilité.
Les deux avancent ensemble. On livre plus, on casse plus.
DORA formule cela sous le nom d’effet amplificateur : l’IA ne transforme pas une organisation, elle amplifie ce qu’elle est déjà. Une équipe avec une plateforme solide, des tests automatisés sérieux et une culture de revue exigeante en tire un effet de levier considérable. Une équipe avec un outillage fragmenté, une couverture de tests approximative et une revue de complaisance accélère simplement sa propre dégradation.
Autrement dit : l’IA ne rattrape pas une dette d’ingénierie. Elle la facture plus vite.
Le nouveau goulot : la revue
Si l’écriture coûte moins cher, la lecture, elle, coûte exactement le même prix. Et il y a soudainement beaucoup plus à lire.
Les chiffres de l’enquête Stack Overflow 2025 cadrent bien le phénomène : 84 % des développeurs utilisent ou prévoient d’utiliser des outils d’IA, dont 47 % quotidiennement, mais seuls 3 % déclarent leur faire hautement confiance, contre 46 % qui s’en méfient. Leur frustration numéro un, citée par 66 % d’entre eux : des solutions « presque justes, mais pas tout à fait ». Et 45 % estiment que déboguer du code généré par IA prend plus de temps que déboguer du code écrit par un humain.
Fait notable : l’usage monte pendant que la confiance descend. L’opinion favorable envers l’IA de développement est passée de plus de 70 % à 60 % en deux ans.
« Presque juste » est la pire catégorie possible. Un code faux est rejeté en trente secondes. Un code presque juste passe la revue, passe les tests superficiels, et se révèle en production trois semaines plus tard.
Addy Osmani, ingénieur chez Google, résume ce déplacement par ce qu’il appelle le problème des 70 % : l’IA produit très vite environ 70 % d’une fonctionnalité, la structure, les patterns évidents, le plomberie. Les 30 % restants, cas limites, sécurité, intégration au système existant, comportement sous charge, demandent le même effort qu’avant. Sauf qu’ils sont désormais mélangés à du code qu’on n’a pas écrit soi-même.
Conséquence directe : la revue de code devient le poste de charge critique, et elle repose sur un nombre fini de seniors. C’est un goulot d’étranglement humain, non élastique, qu’aucun abonnement supplémentaire ne desserre.
Ce que l’IA ne fait toujours pas
Trois activités résistent, et ce sont précisément celles qui déterminent si un logiciel a de la valeur.
Décider quoi construire. Un modèle répond à une demande ; il ne détermine pas si la demande est la bonne. Arbitrer entre deux fonctionnalités, trancher un compromis produit, dire non à un client, aucune de ces décisions ne se délègue.
Choisir une architecture qui tiendra. Un assistant optimise localement : il résout le ticket qu’on lui donne. Il n’a pas de préférence pour la cohérence globale du système à trois ans. Le rapport GitClear 2026, qui analyse 623 millions de changements de code entre 2023 et 2026, le mesure crûment : les appels de fonctions inter-fichiers, signal de réutilisation et de structure, ont chuté de 35 % depuis 2023, tandis que la duplication de blocs de code augmentait de 81 %.
Assumer la responsabilité. Quand un bug coûte de l’argent, quelqu’un doit répondre. Cette personne est encore, et restera, humaine.
La spécification redevient le livrable
C’est la conséquence la plus intéressante, et la moins commentée. Si le coût marginal de l’implémentation baisse, alors la qualité de l’intention en amont devient le facteur limitant de la qualité finale.
Une spécification floue produisait autrefois du code lent et discutable, mais un développeur humain comblait les trous avec du bon sens, posait des questions, refusait une incohérence. Un agent ne pose pas de questions. Il comble les trous avec une hypothèse plausible, et il le fait très vite, sur des milliers de lignes.
Le mouvement du spec-driven development traduit cette prise de conscience. Thoughtworks en donne une lecture lucide : la démarche restaure un cycle de retour plus court que la génération « à l’aveugle », mais elle n’est pas résolue. La génération reste non déterministe, la même spécification ne produit pas le même code deux fois. La dérive entre la spec et le code reste difficile à éviter. Et la question de fond n’est pas tranchée : qui est la source de vérité, la spécification ou le code ?
Il y a là un risque réel de réinventer le cycle en V avec un vocabulaire plus récent. Une spécification trop formalisée redevient un document qu’on ne met plus à jour.
Ce que ça change pour une équipe, concrètement
Quatre déplacements opérationnels, sans théorie :
Mesurer la sortie, pas l’entrée. Le nombre de lignes produites ou de pull requests ouvertes n’a jamais été un bon indicateur ; il est devenu franchement trompeur. Les métriques qui comptent restent le délai de mise en production, le taux d’échec des changements et le temps de rétablissement.
Traiter la capacité de revue comme une ressource rare. Si la génération triple et que la revue reste constante, la file s’allonge jusqu’à ce que quelqu’un commence à approuver sans lire. C’est le point de rupture réel, et il est silencieux.
Investir dans les tests avant d’investir dans les agents. C’est l’application directe de l’effet amplificateur. Sans harnais de vérification automatisé, accélérer la génération revient à retirer les freins avant d’appuyer sur l’accélérateur.
Payer le prix de la clarté en amont. Le temps passé à écrire une spécification exploitable n’est plus un coût administratif. C’est devenu la partie du travail qui détermine le résultat.
L’angle mort
Il reste une question que peu d’équipes se posent. Si l’IA absorbe les 70 % faciles, par où passent désormais les gens qui apprenaient précisément sur ces 70 % ?
Le travail d’entrée de gamme, le CRUD, le formulaire, le test unitaire évident, n’était pas seulement de la production. C’était le terrain d’apprentissage qui fabriquait, en trois ou quatre ans, les seniors capables de faire la revue dont on a désormais un besoin critique.
On a optimisé la production immédiate en consommant le stock de compétences qui la rend possible. C’est le vrai arbitrage de la période, et il ne se voit pas dans les métriques trimestrielles.
Questions fréquentes
**Les développeurs font-ils confiance au code généré par IA ? ** Non, et de moins en moins. D’après l’enquête Stack Overflow 2025, 84 % des développeurs utilisent ou prévoient d’utiliser des outils d’IA, mais seuls 3 % leur font hautement confiance et 46 % s’en méfient. L’opinion favorable est passée de plus de 70 % à 60 % en deux ans.
**L’IA rend-elle vraiment les développeurs plus productifs ? ** Sur la génération de code, oui, nettement. Sur la livraison de logiciel fiable, c’est plus nuancé. Le rapport DORA 2025 associe une forte adoption de l’IA à une hausse du débit de livraison mais aussi de l’instabilité. Et l’étude contrôlée de METR (2025) a mesuré un ralentissement de 19 % chez des développeurs expérimentés sur des bases de code qu’ils maîtrisaient.
**Quel est le nouveau goulot d’étranglement du développement logiciel ? ** La revue et la vérification. L’écriture de code est devenue peu coûteuse, mais la lecture, la validation et la responsabilité du résultat reposent toujours sur un nombre limité d’ingénieurs expérimentés.
**Faut-il abandonner les assistants de code ? ** Non. L’enjeu est de les adosser à un dispositif de vérification, tests automatisés, revue exigeante, observabilité, sans lequel le gain de vitesse se convertit en instabilité.
**Qu’est-ce que le spec-driven development ? ** Une approche où une spécification structurée sert de source principale au travail des agents d’IA, avec séparation explicite entre phase de conception et phase d’implémentation. Elle réduit l’improvisation, mais ne résout ni le non-déterminisme de la génération, ni la dérive entre spec et code.
Sources
DORA, Balancing AI tensions: moving from AI adoption to effective SDLC use (2025)
METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
Stack Overflow Developer Survey 2025
GitClear, The Maintainability Gap: 2026 AI Code Quality Research
Addy Osmani, The 70% Problem
Thoughtworks, Spec-driven development