Agents IA : +98% de pull requests, mais la revue de code prend 91% de retard. Où la file d'attente s'est-elle déplacée

Sergueï Prochtchaev, Tech Lead et responsable du développement Java | Kotlin dans la FinTech et l'e-commerce, a analysé trois grandes études de 2025-2026 et a dégagé un constat unique : l'IA a accéléré l'écriture de code, mais a ralenti la livraison en production.

Le point de départ est simple. Un développeur avec un agent IA assemble en une soirée une fonctionnalité qui aurait auparavant pris une semaine. Il ouvre une PR de mille cinq cents lignes. Ensuite, la MR reste trois jours en revue (quatre autres identiques attendent déjà en file), un seul commentaire arrive, sur le nom d'une variable, la tâche part en QA, où elle se bloque à nouveau. Une semaine plus tard, ce que personne n'a vraiment lu refait surface en production.

L'IA a accéléré la génération plus vite que l'équipe ne peut vérifier, intégrer et livrer. Le goulot d'étranglement ne disparaît pas, il se déplace plus loin dans le pipeline.

Trois études, une seule conclusion : générer est bon marché, vérifier

ne l'est pas

Faros AI : The AI Productivity Paradox (juillet 2025) — données portant sur 10 000 développeurs issus de 1 255 équipes. Le résultat semble favorable : les développeurs utilisant activement des assistants IA ferment 21% de tâches supplémentaires, soumettent 98% de pull requests en plus. Mais un détail change tout : le temps de revue a augmenté de 91%, la taille moyenne des PR de 154%, le nombre de bugs par développeur de 9%. Au niveau de l'entreprise, les chercheurs n'ont trouvé aucune corrélation significative avec le résultat global.

Faros AI : The Speed Trap (18 septembre 2026) — 22 000 développeurs issus de 4 000 équipes sur 12 mois. Le temps passé en QA a augmenté de 300,6% — la détérioration la plus forte parmi les métriques de flux. La taille moyenne des PR est 71,8% plus élevée, le nombre d'incidents par mois a grimpé de 125,4%. Indicateur alarmant : les PR fusionnées sans revue sont passées de 31,3% à 76,3%.

CircleCI : Software Delivery Report 2026 — 28,7 millions d'exécutions de CI analysées en septembre 2025. Le nombre moyen d'exécutions quotidiennes a augmenté de 59% sur un an, mais pour l'équipe médiane, l'activité sur les branches de fonctionnalités a progressé de 15%, tandis qu'elle a reculé de 7% sur main. Le taux de builds réussis sur main est tombé à 70,8% (plus bas niveau en cinq ans), le temps de récupération d'un build vert est de 72 minutes. Moins de 5% des équipes ont réussi à accroître simultanément le développement et le passage des changements par main.

DORA 2025 : en 2024, une hausse de 25% de l'utilisation de l'IA s'accompagnait d'une baisse de 1,5% de la vitesse de livraison et de 7,2% de la stabilité. En 2025, le tableau a changé : le lien entre l'IA et la vitesse de livraison ainsi que les résultats produits est devenu positif, mais il est resté négatif pour la stabilité. Les auteurs qualifient l'IA de « miroir et multiplicateur » — elle accélère le développement, mais sans forte automatisation des tests, l'augmentation du volume de changements se transforme en instabilité.

Où la file d'attente s'est bloquée

Les pull requests avancent en parallèle de la génération et de la revue humaine, puis attendent la QA, l'intégration et le déploiement. L'agent accélère la génération (le bloc vert). La capacité de traitement de tout le reste ne suit pas le rythme.

Si les changements arrivent plus vite que le système ne peut les traiter, la file d'attente s'allonge, le travail inachevé s'accumule et le délai de livraison augmente. La capacité de la revue, de la QA et de l'intégration évolue bien plus lentement que la vitesse de génération de code.

Observation 1 : les MR grossissent plus vite que la capacité de revue. L'agent n'optimise pas la taille du diff comme un objectif technique à part entière. On demande une fonctionnalité, on obtient la fonctionnalité entière, accompagnée d'un refactoring des modules voisins « au passage ». Sur l'un des projets, une simple tâche consistant à ajouter un champ dans la réponse d'un service a fini par atteindre plusieurs centaines de lignes (la tâche en prévoyait 20). SmartBear recommande de ne pas dépasser 200 à 400 lignes par revue, une vitesse maximale de 500 lignes par heure, et des sessions d'environ une heure — dans ces conditions, 70 à 90% des défauts sont détectés.

Observation 2 : l'attente prolongée pour la revue crée une file d'attente, pas des relecteurs lents. Le flux entrant de changements dépasse simplement la capacité de traitement. Google, dans son document sur les pratiques de revue de code, fixe une limite : la première réponse à une demande doit arriver en un jour ouvré maximum.

En attendant la revue de sa MR, l'auteur ne reste pas inactif — il en ouvre une autre, puis encore une autre. Chez Faros, en 2025, les développeurs utilisant massivement l'IA touchaient 47% de PR supplémentaires par jour. Exemple réel : un développeur avec sept MR ouvertes, dont aucune n'avait été fusionnée depuis plus d'une semaine.

Une limite de deux MR ouvertes par personne et par semaine a poussé les équipes à s'entraider pour les revues — et la file d'attente a fondu plus vite.

Observation 3 : la revue dérive vers le tampon automatique ou l'interrogatoire. Sous la pression du volume, on bascule vers l'un des deux extrêmes : l'approbation sans lecture (« c'est l'agent qui l'a écrit, les tests sont verts ») ou l'exigence d'expliquer chaque ligne, par méfiance envers le code généré. Le tampon laisse passer des erreurs, car il n'y a eu aucune vérification. L'interrogatoire laisse passer des erreurs, car l'attention se porte sur des détails plutôt que sur la question « faisons-nous la bonne chose ». La meilleure répartition : l'automatisation vérifie le format, les vulnérabilités connues et les schémas types. L'humain traite la logique et le contexte.

Observation 4 : l'IA ajoute de la capacité à la vérification, mais ne remplace pas la responsabilité. La revue automatisée aide déjà — la première revue arrive plus vite, la proportion de changements défaillants est plus faible. Mais la confiance reste faible : dans l'étude DORA 2025, seuls 24% des répondants ont exprimé une forte confiance, et 30% font peu ou pas confiance du tout.

Si l'agent a écrit le code, l'a vérifié, et que l'humain s'est contenté de cliquer sur un bouton, il n'y a eu aucune vérification indépendante. La solution : des niveaux basés sur le risque — les changements mécaniques entièrement confiés à l'automatisation, les changements critiques (autorisation, paiements, sécurité) soumis à une revue renforcée avec deux relecteurs indépendants.