Le code IA sort plus vite, sa revue prend cinq fois plus de temps

Depuis deux ans, une bonne partie de l'attention se porte sur la vitesse d'écriture du code. Les assistants génèrent des fonctions entières, les agents ouvrent des pull requests seuls, et les tableaux de bord affichent des débits en hausse. Un ensemble d'études publiées en 2026 montre que le point de tension s'est déplacé ailleurs : la relecture. Le code arrive plus vite, mais quelqu'un doit toujours le comprendre, le valider et en assumer la maintenance. C'est là que la file d'attente se forme désormais.

Le débit monte, la revue s'allonge

Le rapport annuel de Faros AI, intitulé « The AI Acceleration Whiplash », s'appuie sur deux ans de télémétrie couvrant environ 22 000 développeurs ¹. Il rapporte une hausse du débit de tâches de 33,7 %, ce qui confirme l'accélération côté production. Le même jeu de données indique une hausse du temps médian passé en revue de 441,5 %. Autrement dit, chaque unité de code livrée progresse d'un tiers, mais le temps consacré à la relire est multiplié par plus de cinq.

Ce décalage a une explication simple de terrain. L'écriture a été automatisée, la relecture non. Un relecteur humain reste au bout de la chaîne, avec le même nombre d'heures dans sa journée, face à un volume de code qui a augmenté. Le rapport note aussi que les bugs et les incidents progressent plus vite que le débit, ce qui pèse encore sur le travail de vérification.

Des pull requests plus grosses, une attente plus longue

Les chiffres de LinearB pour 2026 vont dans le même sens, sur un échantillon différent. Leur analyse porte sur 8,1 millions de pull requests, réparties sur 4 800 équipes dans 42 pays, avec 88,3 % de développeurs déclarant un usage régulier de l'IA ². Deux effets se combinent.

D'abord la taille. Au 75e centile, les pull requests assistées par IA atteignent 408 lignes contre 157 pour les autres, soit environ 2,6 fois plus de code à examiner d'un coup. Ensuite l'attente. Les pull requests produites par des agents patientent en moyenne 1 055 minutes avant qu'un relecteur les prenne en charge, contre 201 minutes pour le travail non assisté, soit un facteur d'environ 5,3. Une contribution plus volumineuse, qui attend plus longtemps avant même que la lecture commence : le goulet se situe à l'entrée de la revue, pas à l'exécution des tests.

Pourquoi ce code est plus lent à relire

La difficulté ne tient pas seulement au volume. Une étude empirique de grande ampleur, « Debt Behind the AI Boom », a analysé 304 362 commits attribués à l'IA sur 6 275 dépôts GitHub, pour cinq assistants courants dont Copilot, Claude, Cursor, Gemini et Devin ³. Elle mesure 1,7 fois plus de problèmes par pull request que dans le code écrit par des humains. Sur 484 366 problèmes distincts recensés, les « code smells » représentent 89,3 % du total.

Ces défauts sont précisément ceux qui passent le mieux la revue. Le code produit paraît idiomatique, bien nommé, cohérent avec ce qui l'entoure, et il compile. Un relecteur pressé l'approuve sans voir la faille de structure ou de logique dessous. L'étude relève d'ailleurs un versant sécurité : l'IA introduit 1,5 fois plus de problèmes qu'elle n'en corrige, pour un solde net de 7 342 vulnérabilités sur les dépôts étudiés, et 22,7 % des problèmes introduits survivent encore dans la dernière version du dépôt. Nous avions déjà abordé ce vieillissement du code généré dans un précédent article.

Ce que cela change pour une PME ou une ETI

Dans une petite structure, ce goulet frappe plus fort qu'ailleurs. Le débit d'écriture, lui, ne dépend plus vraiment de la taille de l'équipe : un développeur outillé produit beaucoup. La capacité de revue, elle, reste liée au nombre de personnes capables de relire sérieusement, et elles sont souvent une ou deux. Le plafond de livraison réel devient donc le temps de relecture disponible, pas la vitesse de génération.

Quelques pratiques limitent la casse. Découper les contributions en petites unités, car une pull request de 150 lignes se relit vraiment, une de 400 se survole. Traiter la revue comme un travail à part entière, avec du temps réservé, plutôt que comme une tâche intercalée entre deux urgences. Placer des contrôles automatiques en amont de la lecture humaine, pour que l'analyse statique et les tests écartent les défauts évidents avant qu'un collègue n'y consacre son attention. Enfin, mesurer le temps d'attente en revue autant que le débit, sinon le tableau de bord ne montre que la moitié de l'histoire.

Notre lecture

Chez NXL Forge, nous voyons ces chiffres se vérifier sur des projets Odoo comme sur du code applicatif. L'IA nous fait gagner du temps réel sur la première rédaction, à condition de ne pas confondre ce gain avec une livraison plus rapide. Tant que la relecture reste humaine, et elle doit le rester pour du code qui touche à la comptabilité, aux stocks ou à la paie, elle fixe le rythme. Notre règle de travail est devenue simple : nous n'accélérons l'écriture que si nous avons prévu, en face, la capacité de relire ce qui en sort. Un agent qui produit trois fois plus de code sans relecteur en face ne fait pas gagner du temps, il déplace la dette vers plus tard.

Sources

• Faros AI, The AI Acceleration Whiplash (2026 AI Engineering Report) : https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways
• LinearB, 8 million pull requests reveal where engineering productivity breaks down : https://linearb.io/blog/8-million-prs-engineering-productivity
• Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild : https://arxiv.org/abs/2603.28592