Agents d’IA : 30 % de code en plus, la relecture humaine fait bouchon

Sur l’un de ses projets, raconte un ingénieur junior, un seul développeur expérimenté avait le droit d’approuver les modifications, parce qu’il était l’expert de ce code. Il était si débordé qu’il ne pouvait relire le travail de son cadet qu’« une fois par semaine ». Puis des pannes ont été causées par du code écrit par l’IA, et une nouvelle règle est tombée : tout code produit par l’IA devait être approuvé par un ingénieur senior, « ce qui a créé encore plus de goulots d’étranglement ».

Ce témoignage figure dans une étude de Fiona Chen et James Stratton, doctorants en économie à Harvard. Il illustre ce que leurs chiffres montrent à grande échelle, dans un document de travail qui n’a pas encore été relu par une revue scientifique : les outils d’IA qui écrivent du code accélèrent bien l’écriture, mais l’étape suivante, la relecture par des humains, ne suit pas. Le logiciel effectivement livré n’augmente pas de façon mesurable.

De la ligne de code au logiciel livré

Pour comprendre le résultat, il faut suivre le chemin d’une modification dans une équipe de développement. Un ingénieur écrit du code et l’enregistre par petites étapes, des commits (des sauvegardes successives de son travail). Quand une partie est prête, il la soumet à ses collègues sous la forme d’une pull request, une demande d’intégration au code commun. Un ou plusieurs relecteurs l’examinent, laissent des commentaires, demandent parfois des corrections ; l’auteur reprend son travail, et ainsi de suite jusqu’à l’approbation. Le code est ensuite déployé, c’est-à-dire mis en service pour les utilisateurs.

Les entreprises suivent ce travail dans des outils de gestion de tâches comme Jira, où chaque tâche est un « ticket ». D’après l’étude, un ticket n’est marqué comme résolu qu’une fois le code écrit, relu, testé et déployé. Les tickets sont regroupés en « epics », qui correspondent à une fonction ou à un projet entier.

L’étude distingue deux générations d’outils. Les assistants, comme GitHub Copilot ou Cursor, proposent du code en temps réel pendant que le développeur tape. Les agents, apparus fin 2024 (Claude Code en est l’un des plus répandus, selon les auteurs), reçoivent une consigne générale et enchaînent eux-mêmes les étapes : écrire sur plusieurs fichiers, lancer des tests, lire les erreurs, recommencer. Le développeur valide le résultat sans guider chaque étape.

Ce qui a été mesuré

Les données viennent de Jellyfish, une entreprise qui vend aux sociétés un outil de mesure de l’activité de leurs équipes techniques. Le tableau de bord se branche sur GitHub (le code), sur Jira (les tâches), sur les agendas Google (les réunions) et sur l’usage de GitHub Copilot, Cursor et Claude Code. L’échantillon compte 718 entreprises clientes qui ont accepté que leurs données servent à la recherche, soit 725 938 personnes, de janvier 2021 à mars 2026. L’entreprise moyenne employait 1 652 personnes, dont 241 ingénieurs actifs, en janvier 2023.

La méthode compare des entreprises qui ont adopté ces outils à des dates différentes : les premières, les retardataires et celles qui ne l’ont pas encore fait. Si les entreprises qui s’y sont mises tôt voient leur activité changer juste après, et pas les autres au même moment, l’écart est attribué à l’outil. Les auteurs justifient cette approche par la durée très variable des achats en entreprise, entre validation juridique, contrôle de sécurité et phase de test, qu’ils jugent sans lien avec la croissance de l’entreprise. Ils reconnaissent un biais : les grandes entreprises adoptent plus tôt. Ils corrigent les résultats de l’effet de la taille.

Point important : l’adoption est mesurée à l’échelle de l’entreprise, pas de chaque salarié. Une entreprise « adopte » les agents dès les premiers signes d’usage. Or, un an après cette date, dans l’entreprise médiane, environ 20 % des ingénieurs utilisent un agent ; ils sont environ 60 % dans les entreprises les plus avancées, presque aucun dans les moins avancées. Les effets mesurés sont donc des moyennes sur des équipes où beaucoup n’utilisent pas encore ces outils. Les auteurs y voient la raison pour laquelle leurs estimations se situent dans le bas de la fourchette des travaux existants. Enfin, l’effet des agents est mesuré en plus de celui des assistants : il dit ce que les agents ajoutent.

Plus de code, autant de tickets livrés

Avec les assistants, la hausse reste modeste : 12 % de lignes de code en plus, 9 % de commits, 5 % de pull requests, et seule la hausse des commits est statistiquement significative, c’est-à-dire trop nette pour être attribuée au hasard.

Avec les agents, elle est nette sur les trois mesures : 30 % de lignes de code en plus par personne et par mois (environ 1 500 lignes de plus sur une base d’environ 5 000), 20 % de commits et 23 % de pull requests. Ce dernier chiffre écarte l’idée que l’IA écrirait simplement un code plus bavard : une pull request est une unité de travail soumise à des collègues, pas un nombre de lignes.

En bout de chaîne, en revanche, rien de significatif. Le nombre de tickets résolus par personne progresse d’environ 3 %, avec les assistants comme avec les agents, une hausse que l’étude ne distingue pas de zéro. La marge d’erreur permet d’exclure, pour les agents, une hausse supérieure à 12 % : bien moins que les 30 % de code supplémentaire. Les epics ne bougent pas davantage. Les auteurs ont vérifié une objection évidente : et si les équipes s’attaquaient à des tâches plus lourdes, de sorte qu’un ticket vaudrait désormais plus de travail ? Ils ont estimé la taille de chaque ticket à partir de sa description, avec un modèle d’IA, et n’ont trouvé aucun changement.

L’emploi, lui, ne bouge pas. Pour les agents, l’effet estimé sur l’effectif total est nul, et la précision du calcul exclut une baisse de plus de 2,9 %. Sur le nombre d’ingénieurs, la mesure est moins précise : elle exclut une baisse de plus de 13,8 %. Pas d’effet non plus, d’après l’étude, chez les débutants ou chez les plus expérimentés pris séparément.

Une file d’attente devant les relecteurs

Où passe le gain ? Écrire du code n’occupe qu’une partie du temps d’un ingénieur : 42 % selon les données de Jellyfish, 30 % selon un sondage mené par les auteurs auprès de 100 ingénieurs. Le reste va à la préparation des tâches, aux réunions et à la relecture. C’est là que l’étude trouve le blocage, après l’adoption des agents :

• le délai entre la soumission d’une pull request et son intégration au code commun s’allonge de 49 %, d’un peu plus de 7 jours en moyenne à environ 10 jours et demi ;
• la part des pull requests pour lesquelles un relecteur demande formellement des corrections passe d’environ 13 % à environ 25 %, soit presque le double ;
• le nombre de commentaires par pull request augmente de 35 % ;
• la part des salariés qui relisent du code passe de 29 % à 33 % (une hausse de 14 %), sans que la part de ceux qui en écrivent diminue.

La taille des pull requests, elle, n’a pas changé : la hausse des commentaires ne vient pas de soumissions plus volumineuses. Les assistants, eux, n’ont d’effet significatif ni sur le délai, ni sur les demandes de corrections, ni sur les commentaires ; ils augmentent en revanche la part des relecteurs, de 10 %.

Confier la relecture à l’IA ? Les entreprises s’y sont mises : en mars 2026, près de 80 % d’entre elles avaient utilisé un outil d’IA dans la relecture. Mais l’usage reste limité dans les faits : 23,3 % des commentaires de relecture sont produits par l’IA, et 10,8 % des pull requests en reçoivent au moins un. Selon les auteurs, le goulot ne disparaît pas avec ces outils. Un ingénieur senior interrogé le résume : les outils d’IA « n’ont pas la vision d’ensemble de la fonction, ni de ce qu’elle est censée faire ».

Le son de cloche diffère chez Jellyfish elle-même. Dans un billet de mars 2026, une ingénieure de l’entreprise affirme que l’activation d’un outil de relecture par IA a plus que doublé le nombre de pull requests par développeur dans sa propre équipe (de 11,4 à 23,9). Il s’agit de 18 développeurs, comparés sur deux périodes de deux mois en 2025, et le billet reconnaît qu’il ne s’agit pas d’une expérience contrôlée. Le constat ne contredit pas l’étude, qui porte sur des centaines d’entreprises ; il montre que l’effet de ces outils varie d’une équipe à l’autre.

Plus de code, ou du code moins sûr

Les auteurs proposent un modèle pour expliquer ces résultats, avec deux mécanismes qui ne demandent pas la même réponse. Le premier tient au volume : si chaque développeur produit davantage, il y a plus de code à relire, et une équipe de relecteurs inchangée prend du retard. Le second tient à la qualité : si le code produit avec l’IA contient plus d’erreurs, chaque ligne demande un examen plus attentif. Selon leur lecture, la hausse des demandes de corrections et des commentaires, à taille de pull request égale, signale ce second mécanisme.

La distinction a des conséquences pratiques. Si l’IA ne fait qu’augmenter le volume, écrivent-ils, déplacer des salariés vers la relecture peut lever l’essentiel du blocage. Si elle dégrade la qualité, la solution passera par une amélioration de la technologie elle-même. Pour les responsables d’équipe, ils tirent une leçon plus immédiate : beaucoup de dirigeants mesurent la productivité au nombre de lignes de code ou de commits, des indicateurs qui risquent de ne pas refléter les gains réels de l’IA.

L’étude n’est pas isolée. Trois économistes, Mert Demirer, Leon Musolff et Liyuan Yang, sont arrivés à une conclusion voisine par un autre chemin. Leur document de travail publié en mai par le NBER, l’organisme de recherche économique américain, porte sur plus de 500 000 développeurs de GitHub, observés individuellement et non en entreprise. Avec les agents les plus autonomes, le nombre de commits progresse de 240 %, mais celui des versions effectivement publiées de 30 % seulement. Les auteurs l’attribuent à des « goulots d’étranglement humains » dans la chaîne de production.

La même saturation apparaît hors du développement en entreprise. Google a suspendu une partie de ses primes aux failles dans ses logiciels libres en invoquant un afflux de signalements automatisés, et arXiv, le dépôt de prépublications scientifiques, a limité le nombre de soumissions : dans les deux cas, le filtre humain ne suit plus. En mathématiques, les centaines de manuscrits publiés par OpenAI attendent, pour une bonne part, leurs relecteurs. Produire est devenu bon marché ; vérifier ne l’est pas devenu.

Ce que l’étude ne permet pas de conclure

Un travail en cours. Il s’agit d’un job market paper, le document qu’un doctorant présente pour décrocher un poste universitaire (Fiona Chen est sur le marché pour l’année 2026-2027). Il n’a pas été évalué par des pairs et continue d’évoluer : en janvier, une première version présentée par Jellyfish portait sur 500 entreprises et 100 000 ingénieurs.

Des données d’une seule entreprise. Tout repose sur les clients de Jellyfish, qui ont accepté de partager leurs données. Ce sont des entreprises déjà équipées d’un outil de mesure de leurs équipes, donc probablement plus structurées que la moyenne, et l’étude ne précise pas dans quels pays elles se trouvent. Jellyfish est remerciée pour son « partenariat » ; selon les auteurs, l’entreprise a relu le manuscrit uniquement pour vérifier qu’il ne divulguait pas d’informations confidentielles, pas son contenu scientifique, et les conclusions n’engagent pas Jellyfish.

Une mesure à l’échelle de l’entreprise. L’étude dit ce qui se passe quand une entreprise adopte les agents, pas ce que gagne un développeur qui s’en sert tous les jours. Avec 20 % d’utilisateurs un an après l’adoption dans l’entreprise médiane, les effets pourraient changer à mesure que l’usage se généralise.

Un recul court. Les premiers agents datent de novembre 2024 et les données s’arrêtent en mars 2026. Les auteurs soulignent eux-mêmes que l’emploi réagit souvent lentement aux changements techniques. Ils notent aussi que leur méthode ne voit que les entreprises étudiées : si celles-ci prennent des clients à leurs concurrentes grâce à l’IA, des emplois peuvent disparaître ailleurs sans apparaître dans leurs chiffres.

Une méthode qui repose sur une hypothèse. Tout le raisonnement suppose que, sans l’IA, les entreprises précoces et tardives auraient évolué de la même façon. Les auteurs estiment que, si cette hypothèse est imparfaite, leurs résultats surestiment plutôt les effets de l’IA qu’ils ne les sous-estiment.

Ce que l’étude établit, avec ces réserves, c’est un déplacement du travail. Dans les entreprises observées, les agents n’ont pas supprimé d’ingénieurs ; ils en ont mis davantage à relire du code, plus longtemps, avec plus de corrections à demander. Dans le témoignage de l’ingénieur junior, le relecteur unique, disponible une fois par semaine, n’était pas un défaut d’outil : c’était la limite de toute l’équipe.

Les citations de l’étude sont traduites de l’anglais par la rédaction.

Les agents qui préparent les articles de L’Octet s’appuient sur un modèle d’Anthropic, éditeur de Claude Code, l’un des outils étudiés.