Assistants de code : pourquoi plus de code ne signifie pas plus de travail livré

Dans l’étude de 718 entreprises rapportée par InfoQ le 22 octobre 2026, les agents de code sont associés à davantage de lignes de code, de commits et de pull requests. Mais cette hausse ne se retrouve pas à la même échelle dans le travail achevé : les agents sont associés à 12 % de tickets supplémentaires résolus, contre 30 % de lignes de code en plus. La différence déplace la question : que mesure-t-on quand on évalue la productivité d’une équipe de développement ?

Le résultat ne signifie pas que l’IA ne sert à rien, ni que chaque ligne générée crée nécessairement du travail supplémentaire. Il montre plutôt pourquoi le volume produit ne suffit pas à décrire le flux allant de la demande à la fonctionnalité livrée. L’étude, menée à partir de données de Jellyfish et rapportée par InfoQ, donne un cas concret de ce décalage.

Du code produit aux tâches terminées

Les auteurs examinent trois indicateurs de production de code : les lignes ajoutées, les commits et les pull requests. Pour les assistants de codage, les hausses estimées sont respectivement de 12 %, 9 % et 5 % ; seul l’effet sur les commits est statistiquement significatif. Pour les agents, les hausses rapportées sont de 30 % pour les lignes, 20 % pour les commits et 23 % pour les pull requests, et elles sont toutes statistiquement significatives.

La distinction entre assistant et agent compte donc dans les résultats rapportés : les chiffres ne décrivent pas un effet uniforme de toute forme d’IA de code. Ils indiquent aussi que les métriques de production ne racontent pas, à elles seules, ce qui a été achevé pour les utilisateurs ou l’équipe.

Pour approcher le travail terminé, les chercheurs comptent les tickets Jira et les epics résolus par personne et par mois. Les tickets représentent des unités de travail d’ingénierie ; les epics, des projets ou fonctionnalités plus larges. Selon l’étude, les assistants n’augmentent pas le nombre de tickets résolus. Les agents sont associés à une hausse de 12 %, plus faible que leur hausse estimée de 30 % des lignes de code.

Ces chiffres ne sont pas interchangeables : une ligne de code, une pull request et un ticket résolu ne mesurent pas la même étape. La comparaison suggère un écart entre la production de code et les unités de travail achevées ; elle ne permet pas, à elle seule, d’attribuer chaque partie de cet écart à une cause unique.

La revue devient un point de passage mesurable

Pour expliquer cet écart, l’étude considère plusieurs étapes au-delà de l’écriture : planification des fonctionnalités et du périmètre, revue de code, tests et déploiement. Les auteurs estiment, à partir des données Jellyfish, que les ingénieurs consacrent 30 à 40 % de leur temps à écrire du code. Ils indiquent avoir confronté cette estimation à une enquête menée auprès de 100 ingénieurs recrutés via Prolific. Cette répartition invite à regarder aussi les tâches complémentaires, sans supposer qu’elles se répartissent de la même façon dans chaque équipe.

La revue des pull requests fournit un signal particulièrement concret. Selon les résultats rapportés, le temps moyen de revue par pull request augmente de 49 %, le nombre de commentaires par pull request de 53 %, et la part des pull requests nécessitant des changements double. La proportion de travailleurs qui effectuent des revues augmente de 14 %. L’étude ne rapporte pas d’amélioration de la revue liée à l’adoption d’une IA d’assistance à cette étape.

Les auteurs précisent que l’augmentation de l’effort lié aux pull requests ne s’explique pas par une hausse de la taille individuelle des pull requests. Ce point rend l’interprétation plus précise : dans les données rapportées, le surcroît de revue ne se réduit pas simplement à des changements plus volumineux. Il reste toutefois prudent de ne pas transformer ces associations en règle valable pour tous les dépôts, toutes les équipes ou tous les outils.

Ce que l’étude aide à décider — et ce qu’elle ne tranche pas

Pour une équipe qui évalue un assistant ou un agent, l’enseignement pratique est de ne pas isoler la vitesse de génération. Il est utile de suivre ensemble, sur un périmètre défini, le code proposé, le travail fusionné, les demandes de changements et les tâches effectivement résolues. Ce sont des indicateurs à confronter, pas une formule universelle ni un protocole testé ici.

• Si le nombre de lignes ou de pull requests progresse, vérifier si les tickets ou fonctionnalités terminés évoluent aussi.
• Si la charge de revue augmente, distinguer le temps consacré à comprendre le changement, les commentaires et les demandes de correction.
• Comparer des unités de travail et des périodes cohérentes : les métriques de code et celles de livraison ne répondent pas à la même question.
• Interpréter les résultats selon le type d’outil : l’étude rapporte des effets différents pour les assistants et les agents.

Cette lecture complète les questions générales sur la mesure de l’effet de l’IA sur la productivité des développeurs : ici, l’intérêt tient à la comparaison, dans une même étude, entre indicateurs de code, tickets résolus et effort de revue. Pour approfondir le contrôle de cette étape, voir aussi les méthodes de revue de code avec l’IA.

Enfin, les données proviennent de plusieurs systèmes reliés à la plateforme Jellyfish, notamment la gestion des ressources humaines, le contrôle de version, les outils de suivi des tâches, les calendriers et des outils d’IA. L’analyse porte sur des événements recueillis de janvier 2021 à mars 2026, selon le compte rendu d’InfoQ. Ce périmètre donne de l’ampleur à l’observation rapportée, mais ne remplace pas une mesure locale : les outils, tâches, pratiques de revue et définitions du travail achevé peuvent varier d’une organisation à l’autre.

Le signal à retenir est donc plus précis qu’un verdict pour ou contre l’IA : produire davantage de code ne garantit pas une hausse équivalente du travail livré, et la revue fait partie des étapes où l’écart peut se manifester. Pour décider d’un déploiement, une équipe a intérêt à vérifier simultanément ce qui est généré, ce qui passe la revue et ce qui est réellement terminé.