Produire plus de code ne signifie pas nécessairement livrer plus vite
Quand l’IA accélère la production de code, le goulot d’étranglement ne disparaît pas : il se déplace vers l’étape suivante, la revue de code.
Une prépublication parue le 2 juillet 2026 sur arXiv documente le cas d’une entreprise de taille intermédiaire, fortement engagée dans l’IA, dont la direction technique a publiquement fixé mi-2025 un objectif de doublement du nombre de pull requests mergées par ingénieur. Les auteurs y ont suivi 802 développeurs et 196 212 pull requestsde janvier 2024 à avril 2026. Ils soulignent eux-mêmes la rareté de ce type de matériau : les entreprises annoncent volontiers des gains de productivité liés à l’IA, mais les données longitudinales décrivant comment un tel objectif se déroule réellement dans le temps sont peu nombreuses.
Le résultat brut est spectaculaire. En avril 2026, le nombre de pull requests mergées par développeur atteignait 2,09 fois le niveau de référence mesuré avant l’annonce de l’objectif, ce qui en fait, à la connaissance des auteurs, l’un des écarts les plus élevés jamais rapportés pour un déploiement d’outils d’IA en conditions réelles. Mais un second mouvement accompagne le premier : la charge de revue par relecteur a elle aussi approximativement doublé. Le mécanisme est arithmétique. Le volume de pull requests a été multiplié par 3,1 par rapport au niveau de référence du début 2025, tandis que le nombre de développeurs occupant effectivement le rôle de relecteur n’augmentait que de 1,5 fois. Le rapport entre ces deux courbes donne le facteur 2,0 supporté par chaque relecteur.
Ce que cette étude établit, et ce qu’elle n’établit pas
C’est ici que l’interprétation demande le plus de prudence, et les auteurs sont les premiers à le rappeler. L’adoption des outils n’a pas été tirée au sort : chaque développeur a choisi quand commencer à les utiliser et à quelle intensité. Le chiffre de 2,09 fois décrit donc une évolution observée, pas un effet mesuré de l’IA.
Pour isoler ce qui revient à l’adoption, les auteurs recourent à une méthode de doubles différences échelonnées (staggered difference-in-differences), qui compare chaque développeur à sa propre production antérieure plutôt que les développeurs entre eux. La part du gain ainsi rattachée à l’adoption, puis à l’usage accumulé, se situe entre 1,46 et 1,72 fois selon la sévérité du contrôle exercé sur les effets de calendrier, et les auteurs retiennent la borne basse, 1,46 fois, comme estimation de référence. L’écart avec le 2,09 brut correspond à tout ce que l’étude ne peut pas attribuer à l’IA : la dynamique propre de l’entreprise, l’effet d’entraînement de l’objectif affiché, l’évolution du périmètre de travail ou celle de la taille moyenne des changements.
Les auteurs résument leur propre position en écrivant qu’ils lisent ces résultats comme désignant fortement un canal d’adoption et d’usage, plutôt que comme une attribution causale exacte. Ils précisent également que l’objectif de doublement a joué un rôle de catalyseur et non de cause directe. Deux réserves supplémentaires s’imposent. Il s’agit d’une seule entreprise, atypique par son engagement dans l’IA : rien n’autorise à transposer ces multiples à une autre organisation. Et le texte est une prépublication, qui n’a pas encore été évaluée par les pairs.
Cela n’enlève rien à l’intérêt de l’observation, mais déplace ce qu’on peut en tirer. Le résultat solide n’est pas « l’IA double la productivité ». C’est qu’une organisation ayant réellement accéléré sa production de code a vu, dans le même mouvement, la charge de revue se concentrer sur un vivier de relecteurs qui ne grandissait pas au même rythme. Ce constat est structurel, et il ne dépend pas de la valeur exacte du multiplicateur.
Le goulot d’étranglement ne disparaît pas, il se déplace
Une chaîne de livraison logicielle se comporte comme n’importe quelle chaîne de production : son débit est fixé par son étape la plus lente, pas par la plus rapide. Le cycle classique enchaîne quatre étapes après l’expression du besoin.
besoin → développement → review → test → production
Les coding agents n’ajoutent pas d’étape à ce cycle. Ils changent le débit d’une seule d’entre elles.
besoin → génération accélérée → beaucoup plus de changements → review → test → production
Accélérer une étape qui n’était pas la contrainte ne fait pas gagner de temps : cela produit un stock. Ici, le stock prend la forme de pull requests en attente de lecture. Tant que la capacité de revue et de test ne progresse pas dans les mêmes proportions, le délai entre le besoin exprimé et la mise en production reste largement déterminé par ces étapes aval.
L’entreprise étudiée a absorbé ce choc par l’automatisation, et la manière dont elle l’a fait est instructive. La proportion de pull requests recevant une revue automatisée par IA est passée d’environ 19 % à 84 %. Dans le même temps, la part des pull requests bénéficiant d’une revue humaine substantielle, c’est-à-dire comportant au moins un commentaire écrit par une personne, est tombée d’environ 39 % à 21 %. La revue n’a pas disparu sous la pression du volume : elle a changé de nature.
Il faut être exact sur ce que cette bascule a produit dans cette entreprise. Les taux de merge et de retour arrière (revert) sont restés stables sur la période. L’étude ne documente donc pas une dégradation de la qualité, et il serait abusif de le lui faire dire. Elle documente un transfert du contrôle, de la lecture humaine vers l’outillage automatique, dont les effets de long terme sur la connaissance qu’une équipe a de son propre code ne sont pas mesurés.
La code review, nouveau point de contrôle du flux
Une seconde prépublication, publiée en juillet 2026 par une équipe dont deux auteurs signaient déjà la première, aborde la question par l’autre bout : non plus les traces d’activité, mais le discours des praticiens. Ses auteurs ont collecté 38 709 documents de littérature grise, billets d’ingénierie et fils Reddit, filtré ceux qui traitent réellement de revue de code, puis codé un échantillon aléatoire stratifié de 3 100 d’entre eux à l’aide d’une chaîne assistée par LLM, pour en tirer un modèle causal de 26 concepts et 67 relations.
Sa thèse centrale est directement exploitable par une équipe : la revue est le point de contrôle par lequel se décide l’effet d’un coding agent sur le logiciel, et l’IA ne fixe pas le signe de cet effet. C’est l’équipe qui le fixe, par l’expertise des personnes qu’elle mobilise et par la façon dont elle organise cette étape. Le même outil peut donc produire un gain net ou une dette, selon ce qui se passe au moment de la relecture.
La nature de ce travail doit être comprise pour ne pas lui faire dire plus qu’il ne dit : il construit une théorie explicative à partir d’opinions, il ne mesure pas des effets. Les auteurs l’illustrent eux-mêmes en analysant l’activité publique de GitHub. Les pull requests écrites par des agents y apparaissent moins souvent relues, plus vite mergées et moins discutées que celles écrites par des humains, mais le sens de ces tendances s’inverse selon des choix d’analyse également défendables. Les traces établissent ce qui change, pas pourquoi. C’est précisément ce qui rend l’exercice utile : il rend explicites les positions qui s’opposent, au lieu de trancher avec un chiffre fragile.
L’implication pratique, elle, ne dépend pas de cette incertitude. Si le coût de production d’une ligne de code baisse et que celui de sa vérification ne baisse pas, le rôle du développeur se déplace mécaniquement de part et d’autre de la frappe : spécifier, arbitrer, vérifier, comprendre.
Mesurer le flux, pas la génération
Le nombre de lignes générées et le nombre de pull requests ouvertes mesurent l’activité d’une seule étape, celle qui vient précisément d’être accélérée. Ces indicateurs progresseront quoi qu’il arrive, y compris si plus rien n’arrive plus vite en production. Quatre mesures suffisent à décrire le flux réel.
| KPI | Ce qu’il révèle |
|---|---|
| Lead time | Délai entre le besoin exprimé et la mise en production : la seule mesure de vitesse qui intègre toutes les étapes. |
| Temps de review | Durée pendant laquelle un changement attend une décision : le candidat le plus probable au nouveau goulot d’étranglement. |
| Reverts et incidents | Ce qui revient en arrière après le merge : la qualité vue du système en production, pas de la relecture. |
| Throughput mergé | Volume réellement intégré, par opposition au volume produit ou simplement soumis. |
Quatre indicateurs complémentaires permettent ensuite de qualifier ce que ce flux transporte. Le taux de modifications demandées en revue indique si le volume supplémentaire arrive dans un état exploitable ou s’il reporte simplement le travail sur les relecteurs. Les défauts constatés après mise en production disent si la vitesse gagnée en amont se paie plus loin. Le temps humain consacré à la validation, à distinguer du délai calendaire de revue, révèle la charge réellement supportée par les équipes, celle-là même que l’étude voit doubler. Enfin, la proportion de code généré puis supprimé mesure ce qu’une organisation produit sans jamais l’utiliser, poste de coût que les compteurs de volume rendent invisible par construction.
L’enjeu Produit pèse autant que l’enjeu Tech
Si produire coûte moins cher, tout ce qui décide de ce qu’il faut produire prend mécaniquement plus de poids relatif. Ce n’est pas une formule d’organisation, c’est une conséquence arithmétique : le coût d’une fonctionnalité inutile ne baisse pas parce qu’on l’a écrite plus vite, et il occupe donc une part croissante du coût total.
Trois blocs de compétences changent alors de statut. En amont, la définition du besoin et les critères d’acceptation cessent d’être une formalité de cadrage : ce sont désormais les instructions à partir desquelles une machine produit, et leur imprécision se convertit immédiatement en volume de code à relire. L’architecture joue le même rôle à l’échelle du système, en fixant les limites à l’intérieur desquelles la génération reste sûre ; un cadre flou multiplie les arbitrages à trancher en revue, un par pull request.
Au point de contrôle, la revue et les tests portent la charge que l’étude documente. Ils constituent le dernier endroit où une décision de qualité est prise avant la mise en production, et leur capacité ne s’étend pas au rythme de la génération.
En aval enfin, l’observabilité et la mesure de la valeur ferment la boucle. Elles répondent à la seule question qui compte une fois le code livré : ce qui a été produit sert-il à quelque chose ? Sans elles, une organisation peut accélérer longtemps sans savoir si elle accélère dans la bonne direction. L’IA réduit le coût de génération d’un code ; elle ne réduit pas celui d’une mauvaise décision produit.
Le risque : confondre accélération locale et performance
Une équipe peut annoncer en toute bonne foi qu’elle produit deux fois plus de code, et n’avoir rien accéléré du tout. Le volume supplémentaire alimente alors une file d’attente au lieu d’alimenter la production : les relecteurs absorbent une charge doublée, le stock de changements en attente de validation grandit, une part de ce qui a été écrit n’aurait pas dû l’être, et le délai de mise en production reste identique. Chaque indicateur local s’améliore pendant que l’indicateur global ne bouge pas.
Ce scénario est un risque à surveiller, pas un constat d’étude : dans l’entreprise observée, les taux de merge et de retour arrière sont restés stables. Il n’en reste pas moins que la seule façon de savoir de quel côté on se trouve est de mesurer la chaîne entière. La bonne unité de mesure n’est pas la vitesse de génération, c’est la performance du flux de delivery de bout en bout.
Conclusion
Les coding agents ne rendent pas mécaniquement une organisation deux fois plus productive. Ils modifient la répartition du travail entre les étapes, et c’est cette redistribution qu’il faut piloter. La question utile n’est donc pas de savoir de combien la génération de code a accéléré, mais où se situe le goulot d’étranglement suivant une fois cette accélération acquise, et si l’organisation a prévu la capacité de l’absorber.
Cette capacité se construit avant de se mesurer. Elle relève des mêmes exigences que le passage d’un prototype à un service exploité, décrites dans notre décryptage sur l’industrialisation des projets IA, et elle suppose une adoption réellement accompagnée plutôt qu’un simple accès aux outils, sujet que nous traitons dans notre décryptage sur l’adoption de l’IA en entreprise.
