Une revue GitHub sur cinq est faite par l'IA. Qui vérifie la prémisse ?

Le bouton Approuver porte une lourde charge

GitHub affirme que la revue de code par Copilot représente désormais plus d'une revue de code sur cinq sur GitHub. L'entreprise indique également que son système de revue peut explorer le contexte du dépôt, inspecter de volumineuses pull requests, relire des pull requests ouvertes par des bots, et revérifier ses propres constats après modification.

Relisez lentement cette dernière capacité. Un modèle peut désormais relire le travail produit par un autre modèle, puis vérifier sa propre vérification. Un article de développeur publié sur DEV.to décrit où cela mène : l'IA écrit la fonctionnalité, l'IA écrit les tests, l'IA ouvre la pull request, l'IA relit la pull request, l'IA corrige les commentaires de revue, et un humain clique sur Approuver. La question de l'auteur est celle à laquelle personne dans ce pipeline n'a besoin de répondre à voix haute : que vérifie exactement l'humain ?

Des relecteurs corrélés ne sont pas des relecteurs indépendants

La revue de code a toujours reposé sur une hypothèse qui se fissure aujourd'hui sans bruit : celle selon laquelle le relecteur pense autrement que l'auteur. Deux personnes qui lisent la même exigence arrivent avec des parcours différents, et l'une remarque donc ce que l'autre a manqué. Cette indépendance fait toute la valeur d'une seconde paire d'yeux.

Lorsque l'auteur et le relecteur sont tous deux des modèles qui travaillent à partir du même prompt et du même contexte de dépôt, cette indépendance s'amenuise. L'auteur donne un exemple concret : une exigence stipule qu'un utilisateur ne doit recevoir un remboursement que si le paiement a bien été encaissé. Le modèle la lit comme « un remboursement est autorisé s'il existe un enregistrement de paiement ». Il l'implémente. Il écrit les tests à partir de la même compréhension, de sorte que les tests passent. Un relecteur IA inspecte le résultat et trouve une structure propre, une gestion des erreurs sensée, des types corrects et des tests qui passent, ce qui est exact. L'exigence, elle, reste mal comprise.

L'article appelle cela une boucle d'accord de l'IA : plusieurs étapes qui semblent se vérifier mutuellement, mais qui héritent de la même erreur de lecture. La cohérence est contrôlée. L'exactitude ne l'est pas. Et plus il y a d'étapes qui s'accordent, plus le pipeline paraît fiable.

Le problème des tests en est la version la plus aiguë. Des tests écrits à partir du même prompt que l'implémentation ne constituent pas une vérification indépendante : ils en sont une reformulation. Si le modèle a oublié une règle métier en construisant la fonctionnalité, il oubliera la même règle en écrivant le test de cette fonctionnalité. La correction proposée par l'auteur consiste à changer la fiche de poste du générateur de tests : lui demander d'agir comme un ingénieur QA sceptique, d'ignorer l'implémentation et de concevoir les tests directement à partir de l'exigence d'origine, en traquant les cas d'échec, les conditions de concurrence, les cas d'abus et les états invalides. Cela reste de l'IA qui relit de l'IA, mais l'objectif n'est plus l'accord.

Qui est réellement exposé

Le gain est réel et tient surtout à la vitesse : de gros diffs relus rapidement, le pinaillage répétitif absorbé, l'attention humaine libérée pour ce qui compte. L'exposition, elle, se répartit moins uniformément.

L'ingénieur qui clique sur Approuver est responsable de la modification, quel que soit celui qui l'a saisie. Le test de préparation sans détour de l'auteur : si quelqu'un demande pourquoi une modification a été implémentée de cette façon, « l'agent l'a générée et Copilot l'a approuvée » n'est pas une réponse. Les développeurs juniors sont exposés autrement : le travail qui servait à forger leur jugement est précisément celui qui est désormais automatisé. Et l'organisation est exposée par ce que l'article appelle le rayon d'impact : une modification qui touche aux paiements, à l'authentification ou à l'intégrité des données mérite plus d'attention humaine qu'un ajustement d'interface, mais une coche verte rend les deux identiques à l'écran.

L'exposition la plus profonde tient au contexte. L'intention produit vit généralement en dehors de la base de code : dans une conversation avec un client, un ticket de support, une obligation légale, un cas limite non documenté, une décision prise il y a six mois. Le modèle peut ne jamais y avoir accès, et peut mal l'interpréter même lorsqu'on la lui fournit. Un pipeline au vert vous dit que le système a passé les contrôles que vous avez choisi d'exécuter. Il ne vous dit pas que vous avez choisi les bons contrôles.

Les questions à vous poser

• Si l'exigence à l'origine de cette pull request était erronée, un seul des contrôles de notre pipeline la détecterait-il, ou héritent-ils tous de la même hypothèse ?
• Parmi les modifications fusionnées le mois dernier, lesquelles une personne nommément identifiée peut-elle encore expliquer, en termes d'intention métier, sans ouvrir le diff ?
• Lorsque notre relecteur IA signale un problème et que nous cliquons sur Appliquer la suggestion, qui a vérifié quel nouveau risque cette correction introduit ?
• Traitons-nous différemment une modification touchant aux paiements, à l'authentification ou à l'intégrité des données et une modification d'interface, ou la même coche verte valide-t-elle les deux ?
• Les tests de nos chemins critiques sont-ils dérivés de l'exigence, ou de l'implémentation écrite pour la satisfaire ?

Ce qu'il faut surveiller ensuite

Surveillez le chiffre de la part de l'IA. GitHub avance aujourd'hui plus d'une revue sur cinq par l'IA ; ce qui compte, c'est ce que ce chiffre donne spécifiquement pour les modifications des paiements, de l'authentification et des magasins de données, et si les équipes se mettent à publier cette ventilation plutôt que l'agrégat. Un pourcentage global en hausse indique l'adoption. Un pourcentage en hausse sur les chemins critiques, sans changement correspondant dans la façon dont les humains relisent les exigences, indique qu'une boucle d'accord est en train d'être installée là où elle coûtera le plus cher.