Une PR d'IA sur trois arrive en production. Le problème n'est pas le code.

On a beaucoup publié de chiffres d'adoption ces derniers mois. Ils sont tous excellents et ils ne disent rien. Celui-ci est différent, parce qu'il mesure la sortie du tuyau plutôt que l'entrée : LinearB a analysé 8,1 millions de pull requests sur 4 800 équipes et 42 pays, et a regardé lesquelles finissaient par être fusionnées.

88,3 % des développeurs de l'échantillon utilisent l'IA régulièrement, contre un peu moins de 72 % début 2024. L'adoption est donc faite. Et pourtant :

Les pull requests écrites à la main sont fusionnées dans 84,5 % des cas sous trente jours. Celles générées par IA, dans 32,7 %.

Deux PR d'IA sur trois n'atteignent jamais un client. Ce n'est pas une nuance : c'est la moitié de la promesse qui disparaît entre la génération et la production.

Les trois mesures qui expliquent l'écart

Le rapport distingue trois familles de PR - non assistées, assistées par IA, et entièrement agentiques - et les écarts sont mécaniques :

Taux de fusion sous 30 jours
  PR humaines ............... 84,5 %
  PR générées par IA ........ 32,7 %

Taille au 75e centile
  PR humaines ............... 157 lignes
  PR agentiques ............. ~290 lignes
  PR assistées par IA ....... 400+ lignes  (~2,6x l'humain)

Part de refactorisation, 75e centile
  PR humaines ............... ~37 %
  PR assistées par IA ....... proche de 0 %

Délai avant prise en charge de la revue
  PR humaines ............... ~200 minutes
  PR générées par IA ........ plus de 16 heures

LinearB recommande depuis des années de garder une PR sous 300 lignes, parce que c'est à peu près ce qu'un cerveau humain tient en mémoire de travail. Le travail assisté par IA dépasse ce seuil en routine.

La revue craque, et elle craque des deux côtés

Le chiffre le plus parlant n'est pas le taux de fusion, c'est le délai de prise en charge. Une PR d'IA attend plus de seize heures avant qu'un relecteur l'ouvre, contre un peu plus de trois heures pour une PR humaine. Cinq fois plus.

L'explication tient en trois mots : personne ne sait quoi en faire. Le relecteur ignore la charge mentale que ça va lui coûter, doute du contexte que l'auteur avait en tête, et ne ressent pas l'obligation sociale d'aider un collègue à livrer - parce qu'il n'y a pas de collègue.

Et puis vient le retournement. Une fois la revue commencée, les PR d'IA sont traitées plus vite que les autres : environ 194 minutes contre 252. On pourrait y voir une bonne nouvelle. C'en est une mauvaise. Une modification de 400 lignes relue plus rapidement qu'une modification de 157 n'est pas une revue efficace : c'est une inspection de surface. LinearB le dit sans détour, et les réponses qualitatives de son enquête confirment l'inquiétude des équipes - beaucoup de code passe en production sans avoir été réellement examiné.

Le blog de Stack Overflow documente le même phénomène par un autre bout, et l'anecdote qu'il rapporte vaut tous les graphiques. Pratima Arora, CPTO de Smartsheet, décrit une ingénieure produisant sept fois plus de code que le reste de son équipe - et du bon code, précise-t-elle : les livraisons et les revues étaient excellentes. Résultat : les six autres passaient l'essentiel de leur temps à relire le sien plutôt qu'à écrire le leur.

C'est tout le sujet en une histoire. La productivité individuelle n'est pas la productivité de l'équipe. Elle peut même la manger. Et là où une seule personne suffisait à saturer six relecteurs, une flotte d'agents n'a aucune raison d'être plus douce.

Le chiffre dont personne ne parle : la refactorisation à zéro

Il y a dans ce rapport une donnée qui mérite plus d'attention que le taux de fusion. Au 75^e centile, une PR humaine consacre environ 37 % de ses modifications à du code existant. Une PR assistée par IA : presque rien.

Autrement dit, l'IA n'aide pas à rembourser la dette technique. Elle agrandit la surface à entretenir.

L'explication de LinearB est la bonne, et elle est économique plutôt que technique : générer du code neuf ne coûte rien à un modèle. Il n'éprouve pas la fatigue mentale qui pousse un développeur humain à chercher la fonction qui existe déjà. Sans indication explicite sur les bibliothèques internes, les composants partagés et les chemins d'implémentation approuvés, le chemin le plus court est toujours de repartir de zéro - quitte à dupliquer ce que l'équipe avait pris la peine de mutualiser.

C'est le meilleur argument que j'aie lu en faveur d'un contexte explicite. Une base de code n'est pas une source de vérité suffisante : elle montre ce qui existe, jamais ce qui est délibéré. Et un modèle qui ne peut pas distinguer un choix d'architecture d'une dette de huit ans reproduira les deux avec la même conviction.

L'usine à logiciels, une fois mesurée

Le second rapport, publié début août, couvre le premier semestre 2026 : 2,7 millions de PR, 7,5 millions de commits, 83 000 développeurs, 253 organisations. Il permet de mettre un chiffre sur un mot qu'on entend partout - l'usine à logiciels, cette chaîne où des agents trient, spécifient, implémentent, revoient et livrent pendant que les ingénieurs se replient sur les bords.

Dans les organisations classées « élite » :

• 54 % des pull requests sont assistées par IA ;
• 13 % des développeurs utilisent l'IA au moins trois jours travaillés sur quatre ;
• les agents sont auteurs de 4,7 % des PR au maximum.

4,7 %. Même au 90^e centile, la partie réellement autonome de la chaîne ouvre une PR sur vingt. Tout le reste naît encore d'une collaboration avec un humain. Si votre équipe n'est pas passée en mode agentique intégral, vous n'êtes pas en retard : vous êtes dans la majorité, et de très loin.

En regard, l'écart de profondeur est spectaculaire. Comparés à eux-mêmes un an plus tôt, les développeurs de la tranche d'usage la plus intense fusionnent 95,7 % de plus. La tranche haute gagne 65,4 % de rendement, la tranche moyenne 24,4 %, les usagers légers 2,2 %. Ceux qui n'utilisent pas l'IA reculent de 3,6 %.

Deux réserves avant d'utiliser ces chiffres en comité de direction. La première : l'échantillon est composé d'organisations qui mesurent déjà leur livraison avec LinearB - ce sont, par construction, des équipes plus instrumentées que la moyenne. La seconde : LinearB vend la couche d'analyse que ses propres chiffres appellent. Ça n'invalide rien, la méthode est décrite et l'échantillon est énorme ; ça invite simplement à lire la conclusion commerciale avec la même distance que le reste.

Le vrai diagnostic : une PR d'agent n'appartient à personne

Le rapport de mi-année creuse le taux de fusion des PR agentiques par niveau de maturité, et c'est là que l'histoire devient utile :

Taux de fusion des PR ouvertes par un agent
  organisations « élite » ....... 79 %
  organisations « bonnes » ...... 58 %
  organisations « moyennes » .... 37 %

Une organisation moyenne livre à peine un tiers du code que ses agents produisent. Le reste s'accumule, vieillit et finit abandonné - après avoir été payé en jetons.

Le diagnostic de LinearB est le bon, et il n'a rien de technologique : quand un agent ouvre une pull request, aucun humain ne la possède. Elle n'apparaît sur le tableau de personne, ne figure dans les objectifs de personne, et n'a personne à qui poser une question. Elle ne meurt pas : elle s'éteint.

La prescription qui en découle est décevante de banalité, ce qui est généralement bon signe. Avant d'ajouter des agents, donnez à chaque PR ouverte par un agent un propriétaire humain nommé. Mettez ces PR sur le même tableau que les autres. Et comptez ce travail d'accompagnement comme de la livraison au moment des entretiens, sinon personne ne le fera.

Si votre taux de fusion agentique ressemble à celui de la tranche moyenne, acheter plus d'agents est exactement le mauvais achat.

Ce que ça a changé dans notre modèle

C'est la décision de conception que nous avons prise en premier chez Survol, et je la formule ici parce que ces chiffres lui donnent enfin une justification chiffrée plutôt qu'une intuition : l'unité de vérité est la version, pas l'auteur.

Concrètement, une version développée à la main - zéro jeton consommé - et une version produite par un agent ont exactement le même cycle de vie : une branche, une demande de fusion, un propriétaire, une revue, une préview, une promotion. Une version mixte aussi, et c'est le cas le plus fréquent. Ce n'était pas un choix idéologique sur la place de l'humain ; c'était la seule façon d'éviter qu'un changement se retrouve orphelin selon qui l'a écrit. Le rapport de LinearB décrit précisément ce qui arrive quand on ne le fait pas.

Le contrepoint qu'il faut lire aussi

L'article de LinearB cite une expérience qui mérite d'être rapportée telle quelle, parce qu'elle va contre son propre récit. Dex Horthy, de HumanLayer, a fait passer le travail de son entreprise par une usine à logiciels complète, humains sur les bords. Il l'a arrêtée au bout d'environ trois mois, pour cause de pourrissement de la base de code : rien, dans la façon dont les modèles sont entraînés, ne récompense le fait de garder un code maintenable. La qualité s'est érodée d'une manière qu'aucun test ne pouvait attraper.

Rapprochez ça du taux de refactorisation proche de zéro et vous obtenez le même phénomène vu de deux endroits. Ce n'est pas un argument contre l'automatisation - c'en est un contre l'automatisation non mesurée.

Mesurer ce qui est livré, pas ce qui est généré

La partie la plus utile du second rapport est un cadre de mesure en trois grandeurs, toutes calculables avec des données que vous avez déjà :

• Les PR effectives : les PR fusionnées, moins la reprise. Du code généré n'est pas du travail livré. Une PR jamais fusionnée n'a rien livré, et une PR réécrite au sprint suivant a livré moins qu'il n'y paraissait.
• Le coût par PR effective : le coût d'ingénierie total, humains et IA confondus, divisé par les PR effectives. Le coût humain domine largement le numérateur - d'où la précision honnête de LinearB : le niveau dépend de votre comptabilité, seule la tendance entre deux périodes veut dire quelque chose.
• Le taux de reprise, qui sert de garde-fou aux deux autres. Une PR fusionnée puis réécrite dépense deux fois votre budget d'IA : une fois pour la produire, une fois pour la refaire. C'est aussi l'endroit où le pourrissement décrit plus haut cesse d'être une impression pour devenir un nombre.

Ce cadre est juste, et il est meilleur que tout ce qui traîne dans les tableaux de bord d'adoption. Je lui ferais une seule remarque, qui est un prolongement plutôt qu'une critique : la pull request est une unité de plomberie, pas une unité de valeur. Une fonctionnalité peut demander une PR ou onze, selon le découpage de vos dépôts. Le jour où le dénominateur devient la fonctionnalité livrée plutôt que la PR fusionnée, la question « qu'est-ce que ça nous a rapporté » cesse d'être une estimation. C'est la raison pour laquelle nous traçons la consommation par session, par version et par fonctionnalité - même idée, un cran au-dessus.

Ce que ces chiffres ne disent pas

Il faut être honnête sur les limites, sinon on remplace une mauvaise métrique par une autre.

• Un taux de fusion n'est pas un taux de qualité. Une PR abandonnée peut avoir été une bonne expérience, tranchée vite et bien. Explorer trois pistes et en jeter deux est une pratique saine, pas un gaspillage - et l'IA rend précisément ce genre d'exploration abordable. Une partie des 67 % non fusionnés est du travail utile.
• Ces mesures ignorent ce qui n'est jamais devenu une PR. Le prototype qui a servi à trancher une décision en réunion ne laisse aucune trace dans ces statistiques, et il a peut-être fait gagner un mois.
• Le taux de fusion humain à 84,5 % est un point de comparaison, pas un objectif. Une équipe qui ne fusionne jamais rien de ce qu'elle ouvre a un problème ; une équipe qui fusionne tout aussi.

Ce qu'on en retient

1. L'adoption est faite : 88,3 % des développeurs utilisent l'IA régulièrement. Elle n'est plus un indicateur intéressant.
2. Le taux de fusion l'est : 84,5 % pour le code humain, 32,7 % pour le code d'IA. Le goulot d'étranglement s'est déplacé de la production vers la revue et l'appropriation.
3. Les PR d'IA sont 2,6 fois plus grosses, attendent cinq fois plus longtemps, puis sont relues plus vite. Les trois chiffres racontent la même chose.
4. La refactorisation quasi nulle est le signal de fond : l'IA agrandit la surface à maintenir au lieu de la réduire, faute de contexte explicite sur ce qui existe déjà.
5. L'usine entièrement autonome représente 4,7 % des PR, même chez les meilleurs. Le vrai levier n'est pas d'ajouter des agents : c'est de donner un propriétaire humain à chacune de leurs PR.

Il y a une lecture optimiste de tout ça, et je la crois juste. Si le blocage était la qualité des modèles, il faudrait attendre la prochaine génération en espérant qu'elle suffise. Comme il est dans l'organisation du travail - qui possède quoi, qui relit quoi, à quelle maille on compte -, il est adressable dès cette semaine, avec les outils qu'on a déjà.

Sources : « 8 million pull requests reveal where engineering productivity breaks down », LinearB, 4 mai 2026 · « Your software factory needs a context layer », LinearB, 4 août 2026 · « Coding agents are giving everyone decision fatigue », Stack Overflow Blog, 21 mai 2026. Tous les chiffres cités sont ceux publiés par ces sources.