Garage Eight a supprimé les approbations externes sur 69 MR d'un service interne grâce à la revue par IA

L'équipe a accéléré l'écriture du code grâce à l'IA, puis s'est heurtée à la revue : le nombre de relecteurs n'a pas augmenté. Chez Garage Eight, une fonctionnalité Android de 35 merge requests pouvait attendre une semaine deux approbations sur chacune. La question pratique est simple : quels changements peut-on laisser passer après vérification par un bot, afin que les humains aient le temps d'examiner les erreurs vraiment coûteuses ?

D'après Anna Sabotovitch, qui pilote le déploiement du relecteur IA, 69 MR ont été mergés en octobre sans approbation d'une autre personne dans le service interne d'analytique du développement. Dans le dépôt du relecteur lui-même, seuls 6 des 35 MR avaient une approbation externe. Le cas est utile aux équipes dont la file de changements s'allonge, mais il ne donne pas un feu vert universel pour supprimer les relecteurs.

Le nombre de relecteurs dépend du coût de l'erreur

Garage Eight répartit les services en quatre niveaux de risque. Pour la revue, ce qui compte, c'est ce qui se passe si le service produit un résultat erroné. L'évaluation est faite par les architectes de domaine selon le pire scénario ; un service sans évaluation est considéré comme le plus risqué.

Par exemple, une erreur dans une expérience interne peut ne toucher que ses auteurs. Une erreur dans le calcul d'un paiement concerne déjà l'argent du client. Exiger le même nombre d'approbations pour ces changements est commode sur le plan administratif, mais l'attention de l'équipe est dépensée sans tenir compte des conséquences.

L'entreprise a commencé par les dépôts internes, où les conséquences d'une erreur sont plus faciles à détecter et à annuler. Dans le schéma cible, pour les deux niveaux de risque inférieurs, l'auteur pourra merger lui-même après la revue par IA et la réussite des contrôles automatiques. Pour les fonctions clients secondaires, on prévoit de conserver un humain sur les MR simples et ordinaires, et deux sur les MR complexes. La complexité est déterminée par une étape distincte du relecteur : on ne confie pas cette évaluation à l'auteur.

Au niveau le plus élevé, où l'argent et les exigences du régulateur sont en jeu, deux personnes restent requises. Tant que le retour automatique de l'approbation humaine obligatoire n'existe pas, l'entreprise maintient des humains sur les deux niveaux de risque supérieurs.

Un commentaire clos ne signifie pas un bug corrigé

La première métrique semblait convaincante : 92 % des remarques du bot étaient closes. Mais dans les dépôts mobiles, GitLab interdit le merge tant qu'une discussion reste ouverte. Parmi les remarques analysées sur les MR mergés, les 647 sur 647 étaient closes. La métrique reflétait en fait le respect de la condition de merge.

L'équipe a donc commencé à regarder si le code situé près de la ligne commentée changeait avant le merge. Elle a ensuite comparé le résultat au bruit de fond : à quelle fréquence un endroit aléatoire du même fichier est modifié.

Au troisième trimestre, dans 12 dépôts, le bot a laissé 585 remarques sérieuses. Après 219 d'entre elles, le code voisin a été modifié — soit 37 % contre 7 % de bruit de fond. Sur 27 cas vérifiés manuellement, la correction se rapportait bien à la remarque dans 25. Selon l'estimation de l'auteur de l'article, environ 200 problèmes sérieux ont été corrigés avant le merge au cours du trimestre, dont 98 bugs.

Il ne faut pas ici tirer de conclusion hâtive. La modification du code voisin est un indice indirect de l'acceptation de la remarque. Ces chiffres ne mesurent pas la part de toutes les erreurs trouvées et ne prouvent pas que le bot relit mieux qu'un humain. En revanche, ils sont bien plus utiles qu'un compteur de fils clos pour décider si le relecteur est rentable dans un dépôt donné.

Le bot a aussi besoin d'une file, de contrôles et de garde-fous

L'infrastructure est vite devenue une part de la qualité de la revue. Une vérification sur un modèle interne a duré environ 50 minutes et retardé les autres MR. En septembre, le relecteur est resté muet sept jours, en octobre encore 30 heures : les deux fois, le budget API était épuisé. Depuis, des alertes ont été mises en place pour le silence, les vérifications bloquées et le solde.

Pour tester les changements de modèles, l'équipe a constitué 42 MR historiques ; dans 32, un humain a confirmé de vrais problèmes. Un tel jeu aide à comparer les versions du relecteur, mais ne suffit pas à tirer des conclusions générales sur la fiabilité.

Il y a aussi le problème des discussions sans fin : sur un MR, le bot a vérifié 27 commits et laissé 45 constats, dont 44 ont reçu une réponse de l'agent de l'auteur. L'équipe juge nécessaires une limite du nombre de cycles et la vérification du seul nouveau diff.

Conclusion pratique : mieux vaut commencer par un dépôt au coût d'erreur clair et à la file d'attente humaine mesurable. Puis vérifier quelles remarques mènent à des corrections utiles, combien de bruit le bot génère et ce qui se passe quand il tombe en panne. Le retour automatique de l'humain en cas de hausse des rollbacks reste pour l'instant à l'état de projet chez Garage Eight. C'est précisément ce point non résolu qui limite la suppression d'autres approbations.