Les coûts cachés des merge requests générées par l’IA

Brian Wald, Head of Global Field CTO org chez GitLab analyse le sujet.

À mesure que les équipes se développent, la génération de code augmente, mais l’expertise nécessaire en matière de revue de code n’évolue pas de la même façon. Mesurer l’adoption de l’IA en fonction du volume de merge requests, du nombre de lignes de code ou de l’utilisation d’un siège, revient à suivre uniquement les données d’entrée, et non le véritable goulot d’étranglement.

Les données du rapport DORA 2025 montrent que les indicateurs clés de livraison, tels que le délai d’exécution, la fréquence de déploiement, le taux d’échec des modifications et le temps moyen de réparation ne se sont pas améliorés avec l’utilisation accrue des outils d’IA. Les équipes avec les taux d’échec de modifications les plus bas sont aussi celles qui utilisent le moins les outils de développement assistés par l’IA. Cela ne remet pas en cause ces outils, mais souligne qu’un volume accru de merge requests n’entraîne pas nécessairement une amélioration de la productivité.

La file d’attente des revues est devenue le plan de sprint

Une analyse menée avec l’équipe d’ingénierie chargée de l’adoption de l’IA chez un client, qui portait sur les indicateurs de livraison et le déploiement d’un outil de développement assisté par l’IA, a révélé un taux d’adoption élevé. Toutefois, la durée de cycle par relecteur a révélé une toute autre réalité. Les ingénieurs possédant une connaissance approfondie du système avaient un nombre de revues en attente si important que la relecture était devenue leur tâche principale et limitait leur capacité à mener des travaux de conception et d’architecture.

Cette tendance se retrouve dans toutes les équipes. Le volume de merge requests augmente, les délais de revue s’allongent et les ingénieurs expérimentés ont de moins en moins de temps à consacrer à la conception. La charge de travail se concentre sur un petit groupe, car ce sont eux qui maîtrisent le contexte système, les zones sensibles en matière de sécurité et les niveaux de responsabilité.

Le coût principal réside dans la fragmentation de l’attention. Les ingénieurs expérimentés font face à des interruptions fréquentes, qui entraînent une baisse prévisible de la qualité : validations superficielles dues à des files d’attente trop longues ou retards lorsque des merge requests complexes attendent qu’un relecteur soit disponible pour effectuer une revue.

Passer la CI ne rend pas la revue moins coûteuse

Les contrôles automatisés permettent de traiter un volume de travail plus important, mais l’évaluation humaine n’arrive pas à suivre le même rythme. Même si un pipeline réussit, les relecteurs travaillant dans des environnements réglementés doivent encore comprendre l’intention, évaluer l’impact, vérifier les niveaux d’autorisation, examiner le comportement en cas d’échec et confirmer la conformité aux exigences d’audit.

Le code généré par l’IA accroît la charge de travail liée à la vérification de l’exactitude apparente. Le code peut compiler, passer les tests et respecter les règles de linting, mais les relecteurs doivent toujours confirmer qu’il remplit l’objectif visé, gère correctement la classification des données et ne va à l’encontre d’aucune politique. Cette vérification prend souvent plus de temps lorsque le code est généré pour une correction de syntaxe plutôt que pour une correction au niveau du système. À mesure que les files d’attente s’allongent, les relecteurs consacrent moins de temps à chaque merge request, ce qui génère une tension entre rapidité et qualité.

Brian Wald, Head of Global Field CTO org chez GitLab

La génération de code évolue, mais pas l’évaluation

Il convient de reconnaître que les outils de développement assistés par l’IA contribuent à la productivité. Ils peuvent produire du code rapidement, accélérer la refactorisation et permettre aux équipes de traiter davantage de fonctionnalités par sprint.

Cependant, la capacité de revue est limitée par un contexte restreint et une responsabilité individuelle. Lorsqu’un ingénieur expérimenté approuve une modification apportée à un service d’identité dans un environnement réglementé, il endosse un risque organisationnel. Cette responsabilité ne change pas, quelle que soit la rapidité avec laquelle le code a été généré.

La revue de code assistée par l’IA semble la solution évidente à ce problème. Mais il n’est pas encore avéré qu’elle puisse remplacer de manière fiable l’évaluation en contexte, un atout précieux des revues effectuées par les développeurs expérimentés dans les chemins de code à haut risque. En pratique, accélérer la génération de code sans repenser la revue ne résoudra pas le problème.

Quand la revue assistée par l’IA change la donne

Dans un cas observé, la revue assistée par l’IA a effectivement réduit la charge de travail des ingénieurs expérimentés. L’équipe disposait déjà d’une intégration continue (CI) solide, d’une propriété du code clairement définie, de templates de services cohérents et de normes de revue sous forme de listes de contrôle. L’utilisation de l’IA a surtout permis d’améliorer les tâches à effectuer avant le classement : synthèse de l’intention, signalement des modifications de fichiers liés aux politiques et mise en correspondance des diffs avec des modèles connus. Les relecteurs expérimentés se sont concentrés sur les changements à haut risque et ont accéléré les durées de cycle sans augmenter le nombre de défauts.

Lorsque le développement assisté par l’IA est déployé à grande échelle sans ajuster les workflows, les échecs sont inévitables. Par exemple, dans une entreprise soumise à des réglementations strictes, la charge de travail liée aux revues des développeurs expérimentés avait fortement augmenté. Limiter la génération de code et exiger des merge requests moins nombreuses mais plus volumineuses n’avait fait que créer des lots plus importants et des revues plus difficiles à traiter. La refonte des workflows a constitué une solution efficace : application de règles strictes de portée pour les diffs restreints, obligation de résumés d’auteur et de déclarations de risque, automatisation des vérifications des politiques et rotation de personnes formées en tant que « responsables du risque » pour gérer le classement des changements à haut risque. La plupart des modifications sont devenues à faible risque par nature, et les experts ont pu se concentrer sur les exceptions.

Le facteur déterminant n’était pas l’outil, mais l’existence de normes et de workflows de revue clairement définis, pilotés avec responsabilisation, itération et retour. L’IA a renforcé les workflows existants. Là où les normes sont floues, le classement assisté par l’IA génère du bruit que les relecteurs finissent par ignorer.

Là où les coûts s’accumulent : interfaces, exceptions et responsabilité des risques

Les revues les plus complexes portent sur les politiques et le périmètre du système : classification des données, journalisation, autorisation et gestion des erreurs. Dans une banque internationale comptant plus de 4 000 ingénieurs répartis entre les équipes sécurité, plateforme et livraison, chaque groupe suivait ses propres indicateurs. L’équipe sécurité réduisait les vulnérabilités, l’équipe plateforme améliorait la disponibilité, l’équipe ingénierie accélérait les déploiements, mais les transferts entre équipes généraient des retards significatifs. Personne n’était responsable de l’ensemble du cycle.

Le volume généré par l’IA peut aggraver cette dynamique en augmentant les changements, à moins que les workflows ne soient conçus pour les contenir.

Mesurer les contraintes plutôt que la production

Sans mesure de la capacité des relecteurs, le véritable impact de l’IA sur la performance de livraison risque d’être mal interprété. Les indicateurs suivants permettent de distinguer le débit réel des points de blocage :

• Durée de cycle des merge requests par relecteur, et non une moyenne à l’échelle de l’organisation
• Charge par relecteur expérimenté : nombre de revues par jour, taille de la file d’attente active, heures consacrées aux revues
• Taux de défauts non détectés, pondéré par sévérité, distinguant les merge requests assistées par l’IA des merge requests classiques

Un petit nombre d’experts débordés peut retarder des systèmes critiques même lorsque les indicateurs globaux semblent satisfaisants. L’augmentation du temps consacré à la conception et au maintien de la qualité par les ingénieurs expérimentés est ici l’indicateur clé, et non le nombre de merge requests ouvertes.

Structurer les workflows

La solution n’est ni d’interdire l’IA ni d’approuver des modifications sans vérification. Elle consiste à instaurer une structure pour que l’augmentation du volume de code généré par l’IA ne se traduise pas automatiquement par une charge cognitive accrue pour les ingénieurs expérimentés. Voici un exemple de framework  :

• Mettre en place un classement préalable comme étape centrale du workflow. L’IA peut résumer l’intention, cartographier les fichiers affectés par zones de risque et signaler les tests manquants, afin que les relecteurs puissent commencer leur travail avec une évaluation claire du risque.
• Établir des parcours de revue hiérarchisés par niveau de risque afin que les changements courants fassent l’objet d’une revue par les pairs, tandis que les modifications liées aux autorisations, au traitement des données ou aux frontières inter-services soient dirigées vers les relecteurs expérimentés.
• Joindre les preuves directement à la merge request : notes de modèles de menaces, annotations sur le traitement des données, résultats de tests et résultats des contrôles de conformité.
• Appliquer des limites de travail en cours pour les relecteurs désignés via les règles CODEOWNERS et l’automatisation des workflows.

Le critère de décision pour étendre l’utilisation de l’IA

Voici un test utile pour les décideurs : après l’adoption de l’IA, le temps de revue des changements à haut risque a-t-il diminué, ou la charge de travail s’est-elle concentrée sur un nombre restreint de relecteurs expérimentés ? Dans le second cas, la génération de code augmente alors que la capacité de revue reste fixe. Le géant français de la grande distribution Carrefour, par exemple, a introduit la revue de merge requests assistée par l’IA et a constaté que le temps de revue était passé de 20 à 40 minutes à moins de 5 minutes : un signe que la capacité de génération et de revue avaient évolué de concert, et non l’une au détriment de l’autre.

Traitez l’attention des relecteurs expérimentés comme une ressource gouvernée, avec des limites explicites, des règles de routage et des procédures d’escalade. N’étendez l’utilisation de la génération de code assistée par l’IA à de nouveaux dépôts ou équipes que lorsque la charge des relecteurs et les taux de défauts non détectés sont acceptables.

Au début de chaque semaine, posez-vous la question suivante : qui sont les deux personnes qui limitent actuellement le merge des changements à haut risque, et combien de revues en attente ont-elles ? Si cette question n’a pas de réponse, le système manque de visibilité. Si ce nombre augmente chaque semaine, les coûts cachés ont été identifiés, et ils sont en train de s’accumuler.