L'IA comme contrôleur¶

Les chapitres précédents traitent l'IA comme un producteur dont il faut contrôler la sortie. Mais les orchestrateurs l'utilisent aussi comme contrôleur : relecteur de PR, générateur de tests, juge de la correction d'un patch. Ce chapitre rassemble ce que la recherche dit de l'IA dans ce second rôle — et constate que, sur ce sujet, presque toutes les données viennent des entreprises qui déploient leurs propres outils.

Les déploiements industriels de revue par IA¶

Google : résoudre les commentaires de revue¶

Google a déployé un modèle qui propose une modification de code en réponse à un commentaire de relecteur (Frömmgen et al., ICSE-SEIP 2024, présentation ; étude de l'éditeur). En production, les auteurs traitent 7,5 % de l'ensemble des commentaires de revue en appliquant une modification suggérée par le modèle. Le billet de 2023 (source) indique que, hors ligne, le modèle traite 52 % des commentaires à une précision cible de 50 %, et que 40 à 50 % des modifications prévisualisées sont appliquées. Le chiffre d'« heures d'ingénieurs économisées » est une projection.

Note : la page du programme d'ICSE donne « presque 5 % » au lieu de 7,5 % ; probablement une version antérieure du résumé.

Beko (Qodo) : une étude de cas indépendante¶

Cihan et al. (ICSE-SEIP 2025, arXiv 2412.18531) ont étudié le déploiement d'un relecteur automatique (Qodo PR-Agent) chez l'industriel Beko : environ 238 praticiens, 4 335 PR dont 1 568 relues par l'outil.

73,8 % des commentaires automatiques ont été « résolus », 21,3 % classés « ne sera pas corrigé » ; selon le projet, de 55 % à 90 % ;
le temps moyen de fermeture des PR a augmenté, de 5 h 52 à 8 h 20 ;
plaintes qualitatives : faux rapports de bug, suggestions hors sujet.

Atlassian (RovoDev) : une étude de l'éditeur¶

Tantithamthavorn et al. (ICSE-SEIP 2026, arXiv 2601.01129 ; étude de l'éditeur) rapportent que 38,7 % des commentaires générés entraînent une modification de code, avec une baisse de 30,8 % du temps de cycle des PR et de 35,6 % des commentaires écrits par des humains. Selon un billet d'Atlassian (source secondaire), 60 à 70 % des commentaires du modèle ne sont pas résolus, et le taux de résolution varie selon le type de commentaire (lisibilité 43,3 %, bugs 41,9 %, conception 28,6 %).

Limite importante : « résolu » n'est pas « juste »

Aucune de ces études ne mesure la précision du relecteur IA (la part de ses signalements qui désignent un vrai problème) ni son rappel (la part des vrais problèmes qu'il signale). Elles mesurent un taux de commentaires résolus, qui mélange les signalements justes, les suggestions de style acceptées par politesse et les modifications faites pour faire taire l'outil. Ce rapport n'a trouvé aucune étude industrielle publiant précision et rappel d'un relecteur LLM.

Ce que montrent les bancs d'essai de revue¶

Côté recherche, SWR-Bench (Zeng et al., arXiv 2509.01494), construit sur 1 000 PR vérifiées à la main, identifie la faible précision comme le principal facteur limitant des relecteurs LLM ; l'agrégation de plusieurs revues améliore le score F1 jusqu'à 43,7 %. Le détail des taux de faux positifs n'a été lu qu'à travers un résumé.

Le juge LLM de code¶

Quand un orchestrateur fait juger la correction d'un patch par un modèle, quelle est la fiabilité du juge ?

CodeJudge (Tong et Zhang, EMNLP 2024, arXiv 2410.02184) : comparé à la vérité de l'exécution, le juge (GPT-3.5) a raison dans 80,6 % des cas sur HumanEval-X, 74,6 % sur BigCodeBench, 68,3 % sur APPS. Il se trompe donc une fois sur quatre ou cinq, plus souvent sur les problèmes difficiles. Les erreurs : mauvaise analyse de la logique (53 %), mauvaise compréhension de la demande (26 %), exigence excessive sur la gestion d'erreurs (21 %). Les techniques de prompting habituelles (raisonnement pas à pas, exemples) n'aident pas.
CodeJudgeBench (Jiang et al., ACL 2026, arXiv 2507.10535) : 26 modèles juges testés ; tous « présentent encore une part importante d'aléatoire », et inverser l'ordre de présentation de deux réponses peut changer fortement la précision. Les comparaisons par paires sont plus fiables que les notes absolues.
Wang et al. (ISSTA 2025, arXiv 2502.06193) concluent qu'un juge LLM ne peut remplacer l'évaluation humaine que « pour certaines tâches » de génie logiciel : sa corrélation avec les notes humaines est bonne en traduction de code (0,81), plus faible en génération (0,69).

Lecture SPC : le juge est un instrument à étalonner

Un juge qui se trompe une fois sur quatre a une erreur de mesure du même ordre que les dégradations qu'on veut détecter. Sur une carte p du taux de réussite jugé par un LLM, une baisse de 10 points peut venir de l'agent ou du juge. D'où les trois règles déjà posées : étalonner le juge sur des étiquettes humaines (taux de vrais positifs et de vrais négatifs séparés), le garder fixe (version, prompt) pendant qu'on surveille l'agent, et préférer l'exécution (tests, analyse statique) au jugement chaque fois que c'est possible.

Les migrations de code chez Google¶

Un dernier cas montre l'IA dans un rôle mixte, producteur et contrôlé. Google a publié un retour d'expérience sur des migrations de code à grande échelle (Nikolov et al., ICSE-SEIP 2025, arXiv 2501.06972 ; étude de l'éditeur, explicitement non contrôlée) :

migration d'entiers 32 vers 64 bits : 80 % des modifications dans les changements fusionnés entièrement écrites par l'IA ; temps total « réduit d'environ 50 % » selon l'estimation des ingénieurs ;
migration JUnit 3 vers JUnit 4 : 5 359 fichiers et plus de 149 000 lignes en trois mois ; environ 87 % du code généré fusionné sans modification.

Pourquoi ce cas marche

La migration est le cas idéal pour un orchestrateur : tâches homogènes (la même transformation répétée des milliers de fois), vérifiables mécaniquement (compilation et tests existants, écrits avant la migration et non par l'IA), et découpables en petits lots. C'est exactement le profil de processus pour lequel le SPC a été inventé — et le profil opposé à celui des tickets de fonctionnalité.

À retenir

Les relecteurs IA déployés voient de 39 % à 74 % de leurs commentaires « résolus » selon l'entreprise, mais aucune étude ne publie leur précision et leur rappel ; dans le seul cas indépendant, les PR ont mis plus longtemps à se fermer.
Un juge LLM de code se trompe environ une fois sur quatre face à l'exécution, et reste sensible à l'ordre de présentation.
Les succès les mieux documentés (migrations Google, tests Meta) ont en commun des tâches homogènes et un contrôle mécanique indépendant de l'IA.