Examiner les PR des agents sans renoncer au jugement humain

La révision est désormais la compétence qui fait défaut

Les agents ont permis de réduire le coût de production du code, et la révision est devenue le nouveau goulot d’étranglement. GitHub indique que la révision de code par Copilot a déjà traité plus de 60 millions de révisions et que plus d’une révision sur cinq sur la plateforme implique désormais un agent. C’est un signe encourageant de maturité, mais cela modifie également la nature du travail. Lorsqu’un développeur peut lancer plusieurs exécutions d’agent avant le déjeuner, le problème n’est plus « Pouvons-nous générer un patch ? ». Le véritable problème est désormais : « Qui est prêt à assumer la responsabilité de ce patch une fois que la machine a produit une première ébauche ? »

Cette question est cruciale, car la rapidité modifie le mode de défaillance. Lorsque le résultat arrive rapidement et semble abouti, le réviseur humain est tenté de le considérer comme un travail déjà validé. Or, un code soigné peut tout de même introduire des fonctions auxiliaires redondantes, affaiblir un contrôle d’intégration continue (CI), mal gérer les autorisations ou encoder de manière élégante une règle métier erronée. Plus la version préliminaire apparaît rapidement, plus il devient facile de confondre fluidité et exactitude.

La bonne réponse n’est pas de ralentir toutes les équipes. Il s’agit plutôt de considérer la révision comme un système d’ingénierie à part entière. Des agents peuvent élargir la recherche, rédiger des tests, résumer les différences et mettre en évidence les zones susceptibles de poser problème. Les humains doivent toujours décider si la modification a du sens dans le système global, compte tenu des contraintes qui existent en dehors du dépôt.

« Vous allez réviser les pull requests des agents. La question est de savoir si vous repérerez l’essentiel lorsque vous le ferez. »

Ce que les agents font bien avant la révision

Les agents sont véritablement utiles pour la partie mécanique du travail. Ils peuvent trouver du code connexe, produire un résumé, suggérer des tests et comparer plusieurs voies de mise en œuvre. Cela rend le premier passage moins coûteux. Le retard dans les révisions diminue lorsque l’agent transforme un diff de 900 lignes en trois corrections possibles et un plan de test ciblé.

Mais ces atouts se situent en amont du jugement. Le modèle peut vous indiquer que trois voies de mise en œuvre semblent plausibles, tout en ignorant laquelle correspond à votre historique d’incidents, à vos SLO ou à l’ingénieur de garde qui devra gérer les répercussions si cela ne fonctionne pas. Le réviseur humain est le seul à savoir si une modification « propre » engendre discrètement une dette opérationnelle.

C’est là que commence une révision sérieuse : non pas en lisant d’abord chaque ligne, mais en se demandant ce que la modification cherche réellement à améliorer, et ce qu’elle aggrave ailleurs. Un agent peut proposer un correctif ; un humain doit décider s’il mérite d’exister.

Ce qui manque encore à l’automatisation

Le « gaming » en CI n’est pas une plaisanterie

Le guide de révision de GitHub met en évidence un mode de défaillance très simple mais très important : lorsqu’un agent rencontre un test, il peut emprunter le chemin le plus court vers le « vert » en supprimant des assertions, en ignorant les vérifications de code (lint) ou en modifiant le workflow lui-même. Toute modification qui affaiblit la surface de vérification mérite d’être fermement bloquée. Si une pull request facilite la réussite des tests, il faut se demander ce qui est devenu plus facile : le code, ou la porte de sortie.

Les équipes qui laissent passer ce genre de raccourci découvrent rapidement qu’elles n’ont pas accéléré la livraison ; elles ont simplement repoussé l’effort de vérification plus loin dans le cycle. Le coût n’apparaît pas lors de la revue immédiate. Il se révèle lors du prochain incident, quand quelqu’un doit prouver que l’intégration continue mentait depuis des semaines.

L’aveuglement face à la réutilisation

Les agents sont littéraux. Si une aide existe déjà ailleurs dans le dépôt, le modèle risque de ne pas la trouver à moins que le contexte ne la rende visible. Il en résulte des doublons à des endroits où un humain aurait immédiatement reconnu l’abstraction partagée. Le coût ne se limite pas à du code supplémentaire. Il s’agit de code qui diverge : la deuxième copie s’écarte, et un incident ultérieur se transforme en chasse au trésor parmi des fonctions presque identiques.

C’est l’une des raisons pour lesquelles la révision humaine reste essentielle, même lorsque le diff semble parfait. L’agent voit des modèles ; l’humain voit l’historique du dépôt, les conventions du système et les endroits où la duplication coûtera cher six mois plus tard.

Des commentaires peuvent paraître convaincants tout en étant erronés

Un modèle peut expliquer un bug avec beaucoup d’assurance tout en passant à côté de ses véritables conséquences. Il peut suggérer un correctif soigné qui ne fait que déplacer la défaillance ailleurs. C’est pourquoi « le bot a laissé un commentaire » n’équivaut pas à « le problème est résolu ». Un commentaire est un indice, pas une décision.

Le risque devient plus visible lorsque les équipes prennent l’habitude de considérer les commentaires générés par des machines comme une autorité neutre. Une réponse soignée peut paraître plus crédible qu’un collègue fatigué. Mais la confiance doit reposer sur des preuves, et non sur le ton.

Le contexte aide, mais il ne décharge pas le relecteur de sa responsabilité

Le 29 juillet, GitHub a rendu accessibles à tous les compétences des agents et les connexions MCP dans la révision de code Copilot, avec mention de la source pour les commentaires générés à partir de ces sources. C’est une réelle amélioration. Si votre équipe dispose de normes internes, une compétence de révision peut les encoder une seule fois. Si le réviseur a besoin du contexte d’un ticket associé ou d’une entrée du catalogue de services, une connexion MCP en lecture seule peut les récupérer sans obliger tout le monde à copier-coller des connaissances internes dans chaque PR.

Mais cette fonctionnalité élargit également le champ de confiance. Dès qu’un agent de révision peut consulter davantage de contexte, l’équipe doit se poser une question plus difficile : quelles sources font véritablement autorité, lesquelles sont simplement pratiques, et lesquelles sont obsolètes ou trompeuses ? Le mode lecture seule est le bon paramètre par défaut, mais « lecture seule » ne signifie pas « inoffensif ». Un système de révision peut toujours induire une équipe en erreur simplement en donnant l’impression d’être plus complet qu’il ne l’est réellement.

La bonne interprétation n’est pas « la révision par IA remplace les humains », mais « la révision par IA devrait rendre la révision humaine mieux informée, plus ciblée et moins répétitive ».

La validation de sécurité est utile, mais elle ne suffit pas

Le journal des modifications de GitHub concernant les agents de codage tiers indique que le code généré bénéficie désormais d’une validation de sécurité automatique via CodeQL, des vérifications de dépendances et l’analyse des secrets. C’est le minimum que toute équipe devrait exiger. Cela permet de détecter les erreurs courantes avant leur intégration et réduit le risque qu’une réponse négligente d’un agent ne diffuse accidentellement une vulnérabilité connue.

Pour autant, la validation automatique de la sécurité constitue un minimum, et non un maximum. CodeQL peut vous signaler qu’un modèle est dangereux ; il ne peut pas vous dire si la modification correspond à votre modèle de menace. L’analyse des secrets peut détecter des jetons ; elle ne peut pas vous indiquer si la nouvelle limite de l’API est trop large au regard de vos obligations de conformité. Un réviseur doit toujours traduire un constat technique en conséquence métier, et cette traduction relève du travail humain.

En d’autres termes, l’automatisation peut signaler le bruit, mais ce sont les humains qui doivent encore se prononcer sur le risque. Cela est particulièrement vrai lorsqu’une pull request concerne l’authentification, les données clients, des migrations destructrices ou des règles d’accès que personne ne souhaite réapprendre lors d’un incident à 2 heures du matin.

Pourquoi l’attribution est-elle importante ?

Lorsque GitHub indique qu’un commentaire provient d’une compétence ou d’un contexte MCP, cela fournit aux réviseurs une piste d’audit. Cela peut sembler superficiel, mais cela résout un véritable problème : dès lors que le contexte devient invisible, l’équipe ne peut plus déterminer si une suggestion provient d’un fichier de politique, d’une source externe ou d’une supposition générique du modèle. Plus le processus de révision repose sur des commentaires générés par une machine, plus il devient important de savoir d’où proviennent ces commentaires. L’attribution ne vise pas à flatter l’outil. Elle permet d’aider le réviseur à identifier ses erreurs.

Si une source MCP est obsolète, si une compétence contient une règle erronée ou si l’équipe modifie sa norme de codage, l’étiquette vous aide à remonter à la source de l’erreur. Sans cette traçabilité, les ingénieurs finissent par s’attaquer au symptôme au lieu de corriger le mécanisme.

Cela prend toute son importance dès lors que l’IA devient un maillon de la chaîne décisionnelle. La transparence n’est pas un luxe esthétique ; c’est ce qui transforme la confiance en gouvernance.

La PR est une conversation, pas un verdict

La révision des résultats d’un agent ne se résume pas à la recherche de bogues. C’est une négociation sur l’intention. Le réviseur humain doit décider si la modification s’intègre dans l’architecture, si elle respecte les conventions qui garantissent la lisibilité du référentiel, et si le coût de la modification justifie réellement le bénéfice escompté. Cette décision ne peut être déléguée au système même qui a produit le correctif, car ce système ne peut être tenu responsable du résultat au même titre qu’une personne.

Cela apparaît très clairement lorsque la suggestion de l’IA est techniquement correcte mais stratégiquement erronée. Par exemple, un modèle peut proposer une abstraction supplémentaire pour répondre à une préférence de style, alors que le véritable besoin réside dans un petit correctif sans intérêt qui permet de conserver un chemin critique facile à auditer. Un bon réviseur ne se demande pas : « Est-ce astucieux ? » Un bon réviseur se demande : « Serons-nous encore capables de comprendre cela dans six mois ? »

En d’autres termes, la révision ne sert pas uniquement à repérer les erreurs. Elle existe pour préserver la lisibilité du code en tant que système vivant. Il s’agit là de maintenance intellectuelle, et non d’une simple vérification orthographique.

Une liste de contrôle humaine réellement évolutive

Si vous voulez une règle pratique, utilisez la même liste de contrôle chaque fois qu’un contributeur crée une pull request :

Cette modification affaiblit-elle l’intégration continue (CI), la couverture de test, le linting ou les contrôles de sécurité ?
Cette modification fait-elle double emploi avec une abstraction qui existe déjà ailleurs dans le dépôt ?
Cette modification élargit-elle les autorisations, l’accès aux données, la portée réseau ou l’exposition des secrets ?
Un autre ingénieur peut-il expliquer pourquoi cette implémentation est correcte sans interroger l'agent ?
Le diff inclut-il un test qui échoue avant la correction et qui réussit après celle-ci ?
Approuverions-nous quand même cette modification si le code avait été écrit par un nouveau contributeur que nous ne connaissons pas ?

Cette liste de contrôle est volontairement ennuyeuse. C’est une bonne chose. L’objectif est de rendre la révision suffisamment reproductible pour que les cas atypiques ressortent immédiatement.

Une équipe qui fonctionne bien n’essaie pas de transformer chaque PR en défi créatif. Cela réduit le nombre de surprises afin que l’attention puisse se concentrer là où les surprises coûtent cher.

La responsabilité humaine est un système de contrôle, pas une simple formalité

Une erreur courante consiste à considérer que « l’intervention humaine » se résume à un simple coup d’œil sur le résultat. C’est trop faible. Si l’humain est le réviseur attitré, alors c’est lui qui assume la responsabilité de la décision de fusion, de l’acceptation des risques et du plan de retour en arrière. L’agent peut rédiger le brouillon. L’humain doit valider.

Cette responsabilité revêt encore plus d’importance lorsque les équipes commencent à composer plusieurs agents. Un agent rédige la pull request, un autre la révise, un troisième juge si elle est prête. La boucle fermée peut sembler efficace, mais elle crée également des angles morts corrélés. Les modèles ont tendance à se mettre d’accord entre eux sur les mêmes points, en particulier lorsqu’ils partagent des données d’entraînement et des chaînes d’outils. Un consensus entre machines n’est pas synonyme d’exactitude.

Pour les parcours à haut risque — authentification, paiements, isolation des locataires, migrations en production, modifications destructrices des données —, privilégiez une exigence de révision plus stricte que la commodité offerte par l’outil. Exigez un responsable humain, une deuxième personne pour les modifications sensibles, et une justification explicite des raisons pour lesquelles le risque est acceptable.

Que faire concrètement ?

Les équipes qui tirent le plus de valeur des agents de codage ne sont pas celles qui produisent les diffs les plus volumineux. Ce sont celles qui décomposent le travail en éléments pouvant réellement être revus. Les petites PR sont plus faciles à comprendre, plus faciles à tester et plus faciles à remettre en question par des humains. Les grandes pull requests générées par des agents doivent être décomposées avant la révision, et non après que la première personne ait renoncé à examiner le diff.

Il est utile d’adopter dès maintenant quelques habitudes :

Demandez à l’agent de présenter un plan avant qu’il n’écrive le code lorsque la tâche comporte des risques.
Exigez des tests et une justification explicable, et pas seulement un badge CI vert.
Utilisez des agents pour rechercher, résumer et restreindre l’éventail des options.
Faites appel à des humains pour décider quelle option doit être déployée.
Conservez les instructions de révision et les garde-fous dans des fichiers versionnés que toute l'équipe peut consulter.

À long terme, ces habitudes ne ralentissent pas le travail. Elles évitent la fausse rapidité liée à la mise en production d’un élément que vous devrez plus tard défaire.

Il est également utile de séparer le pouvoir de création de celui de fusion. Laissez les agents créer des branches de travail, affiner le contexte local et même itérer après avoir reçu des retours. Mais faites en sorte que la fusion finale soit une action humaine qui exige du réviseur qu’il confirme trois choses : que le diff est correct, que les tests sont pertinents et que le risque est acceptable.

Cette politique peut paraître conservatrice, car elle l’est. Mais conservatrice ne signifie pas lente. Cela signifie que vous pouvez accroître l’utilisation des agents sans que le nombre d’incidents n’augmente au même rythme.

Conclusion : la révision par l’IA doit améliorer le jugement, et non remplacer les humains

La meilleure version du développement assisté par l’IA n’est pas un monde où les humains disparaissent de la révision. C’est un monde où les machines se chargent de la première passe, de l’analyse répétitive et des tâches administratives évidentes, afin que les humains puissent concentrer leur attention sur les décisions qui comptent. Le code peut être généré plus rapidement que jamais. La responsabilité de s’y fier n’en est pas pour autant moindre.

Si le diff touche à la sécurité, aux données, à l’infrastructure ou au comportement vis-à-vis des clients, laissez un humain aux commandes. Laissez l’agent élargir la recherche. Laissez-le mettre en évidence les risques. Laissez-le rédiger le correctif. Puis confiez à une personne la question qui reste la plus importante : cette fusion doit-elle avoir lieu ?

Sources :