Les agents de codage IA produisent plus de code, mais pas plus de logiciels
Les chercheurs de Harvard Fiona Chen et James Stratton ont analysé les données de Jellyfish : 300 millions d'événements, plus de 700 entreprises. Le gain en codage est absorbé par la revue de code ; production et emploi restent quasi inchangés.
Depuis plusieurs années, l'industrie raisonne à partir d'une hypothèse simple : si les assistants et les agents de codage IA écrivent du code plus vite, la production de logiciels devrait augmenter dans la même proportion, et les entreprises pourraient même réduire leurs équipes d'ingénieurs. Une nouvelle étude, rapportée par Ars Technica, remet en cause cette hypothèse. Les chercheurs de l'université Harvard Fiona Chen et James Stratton ont examiné des données d'ingénierie réelles issues de centaines d'entreprises. Ils concluent qu'il existe peu d'indices montrant que l'adoption de ces outils accroît la production de logiciels ou réduit l'emploi. Le code coûte moins cher à produire. Le logiciel livré, lui, n'en profite pas.
La base empirique de l'étude est solide. Les auteurs ont utilisé les données agrégées de Jellyfish, une société qui mesure finement l'activité des équipes d'ingénierie. Elles couvrent environ 300 millions d'événements de travail, comme les commits et les demandes de fusion (pull requests), ainsi que les données d'outils de gestion des tickets. L'échantillon compte plus de 700 000 salariés dans plus de 700 entreprises de développement logiciel, de 2021 à mars 2026. Pour déterminer quand chaque entreprise a adopté l'IA, les chercheurs ont combiné l'usage mesuré directement et l'analyse de l'activité sur GitHub. Ils distinguent aussi deux types d'outils : les assistants, qui complètent un code surtout rédigé par des humains, et les agents, qui écrivent et soumettent du code de façon largement autonome à partir d'instructions. Ils appliquent ensuite une régression en différences de différences sur des variables clés avant et après l'adoption. Ce choix de méthode compte : il sépare les tendances générales et les écarts fixes entre entreprises de l'effet propre des outils, et se rapproche donc d'une lecture causale mieux qu'une simple comparaison entre utilisateurs et non-utilisateurs.
L'explication proposée est la partie la plus utile de l'article. Selon les auteurs, tout gain d'efficacité obtenu pendant la phase de codage est absorbé par les contraintes situées en aval dans le processus de production, la principale étant la revue de code par des humains. Après l'adoption, la revue devient nettement plus longue, les demandes de fusion nécessitent plus souvent des corrections, et les relecteurs laissent davantage de commentaires. Tout développeur reconnaîtra ce schéma. Le code généré par l'IA paraît souvent plausible et s'exécute souvent, mais personne ne peut s'y fier sans vérification. Le coût d'établir la justesse du code se déplace donc de l'auteur vers le relecteur. Lorsqu'une étape d'une chaîne s'accélère et que sa voisine ne change pas, le débit total dépend de l'étape la plus lente. C'est la vieille logique de la théorie des contraintes, avec une différence : le goulot d'étranglement est désormais la lecture, et non l'écriture.
Pour le secteur, ce constat appelle plusieurs leçons. D'abord, des indicateurs comme le nombre de lignes générées, de commits ou le taux d'adoption des outils peuvent tromper : ils se situent du côté du processus que les outils amplifient, et paraîtront brillants même si la livraison ne change pas. Ensuite, les entreprises qui veulent un retour réel sur productivité ne peuvent pas se limiter à acheter un générateur plus puissant. Elles doivent investir dans l'étape de revue : tests automatisés, analyse statique, conventions applicables, et agents qui aident à vérifier le travail au lieu de seulement le produire. Enfin, le récit selon lequel l'IA permettrait de réduire les équipes n'est pas étayé par ces données : sur la période étudiée, aucune baisse nette de l'emploi n'apparaît. Il faut toutefois préciser la portée de ce constat. L'étude ne dit pas que l'IA n'apporte aucune valeur. Elle dit que les indicateurs d'entreprise sur la production et les effectifs changent peu, ce qui est différent d'affirmer que les tâches individuelles ne sont pas plus rapides.
Le travail a aussi des limites. Les données s'arrêtent en mars 2026, alors que les capacités des modèles, la conception des agents et les méthodes de travail évoluent vite. Le goulot de la revue n'est peut-être pas permanent. Si les agents futurs produisent des changements plus petits et plus faciles à vérifier, ou joignent des tests et des preuves que les relecteurs peuvent contrôler rapidement, le coût de la revue pourrait baisser. La production logicielle est en outre difficile à mesurer, et les commits ou demandes de fusion ne sont que des indicateurs indirects de la valeur livrée aux utilisateurs. Le message reste clair. À l'ère des agents, la compétence rare n'est plus d'écrire du code, mais de confirmer, à un coût acceptable, que ce code est correct. Les équipes et les outils qui rendent la vérification plus rapide et plus fiable sont les mieux placés pour transformer plus de code en plus de logiciels.
Sources
FAQ
Quelle est la principale conclusion de l'étude ?
Fiona Chen et James Stratton, de Harvard, trouvent peu d'indices que les entreprises utilisant des assistants ou agents de codage IA aient augmenté leur production de logiciels ou réduit leurs effectifs. Les gains du codage sont absorbés en aval, surtout par la revue de code humaine.
Pourquoi la revue de code devient-elle le goulot d'étranglement ?
Après l'adoption de l'IA, la revue dure nettement plus longtemps, les demandes de fusion nécessitent plus souvent des corrections et les relecteurs commentent davantage. Le code généré ne peut pas être cru sans vérification : le coût de contrôle passe de l'auteur au relecteur.
Les données et la méthode sont-elles fiables ?
Les données Jellyfish couvrent environ 300 millions d'événements, plus de 700 entreprises et 700 000 salariés, de 2021 à mars 2026. La méthode est une régression en différences de différences. Limites : les données s'arrêtent en mars 2026 et les commits ne sont qu'un indicateur indirect de la production.