La génération de code par l'IA crée des goulets d'étranglement dans les revues de code alors que les ingénieurs peinent

Auteur : The Pragmatic Engineer

Traduction : Deep潮 TechFlow

Lecture approfondie de Shenchao : L'IA écrit de plus en plus vite du code, mais la revue reste humaine. Ce paradoxe évolue en une crise : les ingénieurs sont submergés par les demandes d'intégration générées par l'IA, soit ils se précipitent pour les examiner sans soin, soit ils approuvent simplement les modifications car l'IA n'a pas signalé d'erreurs. Les grandes entreprises développent toutes leurs propres outils pour y faire face, mais personne n'a encore trouvé de solution standard.

Bonjour, je suis Gergely, et voici un supplément gratuit de la Pragmatic Engineer Newsletter. Chaque numéro couvre les grandes entreprises technologiques et les startups du point de vue d’ingénieurs chevronnés et de dirigeants techniques. Aujourd’hui, nous abordons l’un des quatre sujets traités dans l’édition précédente de The Pulse. Les abonnés complets ont reçu cet article il y a une semaine. Si cet e-mail vous a été transféré, vous pouvez vous abonner ici.

J'entends souvent que la préoccupation principale des chefs de projet est de faire face à la charge croissante des revues de code. Ce sujet existe depuis un moment, et ces discussions semblent de plus en plus fréquentes aujourd'hui.

Pour moi, tout a commencé en janvier de cette année, lorsque Opus 4.5 et GPT 5.4 ont commencé à écrire plus de code et de meilleur code dans la plupart des entreprises. À peu près à partir de ce moment-là, les directeurs ont commencé à discuter du fait que le goulot d'étranglement dans le développement logiciel passait de la phase de codage à la phase de revue.

Depuis février, les outils d'analyse de code par IA ont connu une croissance exponentielle pour faire face à l'augmentation de la charge, avec une adoption et des expérimentations massives d'outils spécialisés tels que CodeRabbit, Greptile, Qodo, SonarQube (qui intègre désormais Gitar). Des outils intégrés directement dans les environnements de développement, comme Claude Code Review, Cursor Review et GitHub Copilot Review, sont également en plein essor. Par ailleurs, des outils qui n'étaient pas initialement dédiés à l'analyse de code mais qui possèdent un contexte sur les bases de code rejoignent ce domaine, comme les revues d'IA Seer de Sentry et les revues de code de Linear.

Les grandes entreprises développent des outils internes pour améliorer l'expérience de revue de code. Uber Code Inbox en est un exemple :

L'attribution intelligente est une fonctionnalité de Code Inbox conçue pour accélérer le processus de revue :

Figure : Paramètres d'affectation intelligente (Smart assignment) de Code Inbox pour accélérer le processus de revue. Source : The Pragmatic Engineer

Il existe également une fonction de profil de risque pour évaluer l'impact des modifications et encourager les développeurs à prêter une attention particulière aux modifications à haut risque :

Illustration : Fonction Profils de risque de Code Inbox, qui évalue les risques liés aux modifications de code et signale les points à surveiller. Source : The Pragmatic Engineer

Nous avons déjà rapporté comment Uber utilise l'IA pour le développement logiciel, et ce n'est pas seulement Uber : Cloudflare (AI Code Reviewer), Faire (Fairey), HubSpot (Sidekick) et de nombreuses autres entreprises ont développé des outils pour rendre leurs processus de revue de code plus fluides, car elles ont constaté que les solutions internes étaient plus efficaces que l'intégration de fournisseurs externes.

Une autre approche consiste à réfléchir à la manière de vérifier le code plutôt que de l'examiner. Facile à dire, difficile à faire ; théoriquement, des tests approfondis devraient permettre de vérifier que le code fonctionne comme prévu. Mais combien de tests constituent un « approfondissement » complet ? De quels types de tests parle-t-on ? Les tests d'intégration et les tests end-to-end sont-ils inclus ? Et les tests de fuzzing ? Et les méthodes formelles ? Comment vérifier que les nouveaux tests couvrent effectivement les fonctionnalités comme prévu ? Comment relier tout cela à l'observabilité ?

Les revues de code trop approfondies épuisent les ingénieurs et entraînent une baisse de la qualité des revues. J’ai entendu dire que de nombreux développeurs, en voyant que les autres ne prenaient plus le temps de reviser soigneusement le code, passaient directement les demandes d’intégration si l’analyse par IA ne fournissait pas d’avis substantiels. Dans le même temps, les développeurs qui continuent de consacrer le même niveau d’effort et de temps aux revues de code se sentent submergés par les demandes d’intégration remplies de contenus générés par l’IA.

Le problème existe, mais la solution semble plus comme une expérience.