🇬🇧 This article is also available in English.

741 % de code en plus, 20 % de logiciels en plus : le goulot de la revue

741 % de code en plus, 20 % de logiciels en plus : le goulot de la revue
🇬🇧 This article is also available in English.
📑 Table of Contents

TL;DR

  • La présentation virale — 741 % de code en plus pour environ 20 % de logiciels livrés en plus, sur « plus de 700 entreprises » — fusionne deux études distinctes de 2026 : le couple 741 %/20 % provient d’un article du NBER sur les développeurs ; les données sur les 700 entreprises et le goulot d’étranglement de la revue de code proviennent d’un article distinct de Harvard.
  • Le chiffre de 741 % repose sur les lignes de code, l’indicateur de productivité le plus faible disponible ; l’étude de Harvard au niveau des entreprises mesurait un gain bien plus modeste de +30 % et ne trouvait toujours aucun gain statistiquement significatif en termes de travail achevé.
  • Les deux articles convergent vers un même mécanisme : les gains sont « absorbés » par la revue de code humaine, ce qui allonge la file de fusion d’environ 49 % dès l’arrivée des agents.
  • L’automatisation de la revue n’a guère aidé : 80 % des entreprises utilisaient des outils de revue par IA en mars 2026, et pourtant les humains étaient à l’origine d’environ 77 % des commentaires de revue.

Les équipes logicielles ont passé deux ans à acheter des outils de codage par IA sur une seule prémisse : plus de code, écrit plus vite, se transforme en plus de logiciels. Deux des plus vastes études observationnelles publiées à ce jour suggèrent que cette prémisse est fausse — et qu’elle a toujours été mal formulée. Écrire du code n’a jamais été la contrainte déterminante.

Le constat est arrivé en deux vagues. Un document de travail de mai 2026 du MIT, de Wharton et de l’université de Boston rapportait que les agents de codage « synchrones » intégrés à l’IDE augmentaient les lignes de code de 741 % alors que les livraisons logicielles réelles n’augmentaient que de 20 % (Source : Quartz — AI is making software developers faster — just not at actually shipping software). Un autre document de travail de Harvard portant sur 300 millions d’« événements de travail » d’ingénierie dans 718 entreprises constatait que les agents d’IA augmentaient les lignes de code par travailleur d’environ 30 % et les pull requests de 23 % — mais sans hausse statistiquement significative des tickets Jira ou des epics résolus (Source : Ars Technica — AI coding agents generate more code, but not more software).

Deux études, un titre confondu

Le titre « 741 % de code en plus, 20 % de logiciels en plus » est généralement raconté aux côtés d’une « étude portant sur plus de 700 entreprises ». Ce sont deux articles différents. Le couple 741 %/20 % est interne à Writing Code vs. Shipping Code, document de travail du NBER n° 35275, de Mert Demirer (MIT), Leon Musolff (Wharton) et Liyuan Yang (BU) — une étude d’événements appariés combinant l’activité publique sur GitHub de plus de 500 000 développeurs avec la télémétrie interne de Microsoft (Source : NBER — Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools). L’échantillon de 700 entreprises et de 300 millions d’événements de travail — ainsi que la thèse de la revue humaine comme contrainte déterminante — provient d’un article distinct de Harvard, Artificial Intelligence in the Firm, de Fiona Chen et James Stratton, fondé sur les données d’analyse d’ingénierie de Jellyfish (Source : Data Phoenix — Harvard study ties coding-agent gains to heavier code review).

La distinction compte : une étude d’événements appariés sur des développeurs individuels et un plan de différence en différences échelonné au niveau des entreprises sur la période 2021–mars 2026 mesurent des populations et des résultats différents. Que les deux aboutissent à la revue humaine est une véritable convergence ; que leurs chiffres soient interchangeables est un artefact médiatique.

Ce que mesure réellement « 741 % de code en plus »

Les 741 % correspondent à une variation des lignes de code — des ajouts, et non de la valeur nette. Les lignes sont gonflées par le code passe-partout généré, l’échafaudage verbeux, la logique dupliquée et les brouillons mis en commentaire, et ne disent rien sur le fait que le code compile, soit testé ou survive à la revue.

La fragilité apparaît au sein même de l’article du NBER. Dans sa révision de septembre 2026, l’effet des agents synchrones sur les lignes de code a été réévalué à 958 %, les pull requests à 86 %, et les effets sur les commits sont rapportés à 30 %, 180 % et 240 % selon les générations d’outils (Source : Mert Demirer — Writing Code vs. Shipping Code (working paper PDF)). Un indicateur qui varie d’environ 200 points entre deux versions n’est pas un fondement sur lequel bâtir un budget.

Pourquoi même 30 % ne se traduit pas en livraisons

Les données de Harvard expliquent la transmission manquante : là où une accélération apparaît en amont, un coût réapparaît en aval. Le temps moyen de revue d’une pull request — de la soumission à la fusion — a augmenté de 3,45 jours, soit 49 %, par rapport à une base de 7,03 jours ; la part des pull requests faisant l’objet d’une demande de modification formelle a presque doublé ; les commentaires par pull request ont augmenté de 35 % ; et la part des travailleurs effectuant des revues a augmenté de 14 % (Source : Data Phoenix — Harvard study ties coding-agent gains to heavier code review).

Point crucial : les mesures du travail achevé n’ont pas évolué de manière significative. L’effet regroupé sur les tickets résolus était une hausse de 0,12 par travailleur-mois avec une erreur type de 0,17, par rapport à une base de 3,67 — un intervalle excluant toute augmentation supérieure à 12 % de la base (Source : Data Phoenix — Harvard study ties coding-agent gains to heavier code review). La file s’est allongée ; la production, non.

L’instabilité ne se limite pas à l’article du NBER. Une version antérieure de janvier 2026 de la même étude de Harvard, sur un échantillon plus restreint de 500 entreprises, rapportait une hausse de 8,5 % de l’activité de codage et aucun effet significatif sur la production (Source : Chen & Stratton — Artificial Intelligence in the Firm (preliminary working paper PDF)). Même l’ampleur au niveau des entreprises a évolué à mesure que le jeu de données s’agrandissait.

La revue peut-elle être automatisée ?

Nominalement oui ; en pratique, pas encore. En mars 2026, 80 % des entreprises étudiées avaient utilisé l’IA pour la revue de code et 95 % avaient adopté des agents de codage d’un type ou d’un autre. Pourtant, l’IA n’a produit que 23,3 % des commentaires de revue et 10,8 % des pull requests comportant un commentaire d’IA (Source : Ars Technica — AI coding agents generate more code, but not more software). Les humains restent le point de passage.

Il existe un enjeu de sécurité que la conversation sur la productivité occulte. La revue est l’étape de détection des défauts et des vulnérabilités, pas seulement une étape de débit. Si elle se dégrade en simple formalité sous la pression de la file, le risque n’est pas une livraison plus lente mais du code silencieusement non vérifié livré à grande vitesse — pire qu’une file de fusion plus longue.

Pour déplacer la contrainte, trois choses doivent changer ensemble : les diffs doivent se réduire vers une taille revuable ; les spécifications et critères d’acceptation doivent précéder la génération, et non être déduits après coup ; et la capacité de revue — humaine ou par agent — doit croître au rythme de la génération. Rien de tout cela n’est une mise à niveau de modèle.

FAQ

Le chiffre de 741 % est-il fiable ? Il est rapporté fidèlement depuis la version de mai 2026 de l’article du NBER, mais il mesure des lignes de code, et la révision de septembre l’a réévalué à 958 %. Considérez-le comme une indication directionnelle d’un écart, et non comme un multiplicateur précis.

Plus de code généré par l’IA signifie-t-il une qualité moindre ? Pas nécessairement. Les deux études s’abstiennent de prouver que les agents causent un code de moins bonne qualité. Les auteurs de Harvard décrivent la revue comme un mécanisme compatible avec une qualité de brouillon plus faible, un volume plus important ou des normes de revue plus strictes — et non comme une cause prouvée (Source : Ars Technica — AI coding agents generate more code, but not more software).

Si l’IA peut relire le code, pourquoi la revue reste-t-elle le goulot d’étranglement ? Parce que l’adoption a dépassé l’effet : quatre entreprises sur cinq disposaient d’une forme de revue par IA en mars 2026, et pourtant l’IA n’a produit qu’un quart des commentaires de revue, laissant les humains responsables de l’essentiel de la vérification (Source : Ars Technica — AI coding agents generate more code, but not more software).

Les agents de codage ne valent-ils donc pas la peine d’être déployés ? Si. Les gains de débit au niveau des tâches sont réels et importants — ils ne se transforment simplement pas d’eux-mêmes en logiciels livrés. Mesurer un déploiement par le volume de code surestime sa valeur ; le levier se situe à l’étape de la revue, pas à celle de la génération.

Pour aller plus loin

— The Agent Report