Utiliser un agent IA sur une application existante : quelles preuves demander ?
Adapter la revue au risque du changement, reproduire le défaut puis vérifier qu’un test échoue avant la correction et réussit après.
Demander ce que la modification permet de vérifier
Un agent propose de corriger un export et annonce que les tests passent. La question de revue reste ouverte : les tests couvrent-ils le défaut signalé ? Je propose de demander une preuve proportionnée au risque, reliée au comportement attendu. Cette méthode est une proposition de travail, pas un résultat comparatif sur les agents.
Dans un scénario fictif, l’export oublie les commandes annulées qu’un gestionnaire souhaite consulter. Il faut d’abord décider si leur présence appartient au besoin. L’agent ne devrait pas fixer seul cette règle à partir du code existant.
Un dossier de preuve court
- Contexte : règle métier validée, état initial et environnement où le défaut apparaît.
- Diff : fichiers modifiés, rôle de chaque changement et justification des déplacements éventuels.
- Reproduction : données fictives et résultat observable avant correction.
- Validation : commande ou parcours qui échoue avant, puis réussit après ; autres usages susceptibles d’être affectés.
- Limites : contrôles non exécutés, accès absents et incertitudes de livraison.
Conserver la sortie des commandes avec la version testée. Une liste de commandes dans une réponse ne prouve pas leur exécution. Un test ajouté qui ne fait que recopier la nouvelle implémentation peut passer sur le défaut ; rejouer ce test sur l’état défectueux permet de vérifier son pouvoir de détection.
Éviter un dossier plus coûteux que le changement
Une correction d’orthographe dans une légende mérite une relecture et un contrôle du rendu. Elle n’exige pas un laboratoire de charge. À l’inverse, une nouvelle règle d’autorisation demande de vérifier les accès refusés et les propriétaires des données. La taille du diff seule ne mesure pas ce risque.
Les recommandations de GitHub pour son agent insistent sur des tâches cadrées et une revue humaine. Elles ne garantissent pas qu’une sortie est correcte. La personne qui relit doit comprendre le comportement critique et pouvoir remettre en cause la proposition, y compris lorsque les contrôles automatiques sont verts.
Une petite expérimentation possible
Choisir un défaut déjà reproductible et figer le critère de validation avant la demande. Confier une correction limitée à l’agent, conserver ses itérations, puis faire relire le diff et rejouer le scénario. Noter ce que la preuve permet de conclure et ce qu’elle laisse inconnu.
Cette expérimentation n’a pas été menée avec un groupe de reviewers ici. Aucun gain de temps ni taux d’erreur n’en est déduit. Son intérêt serait de comparer les questions encore ouvertes à la revue : si le dossier permet de retrouver le défaut et de vérifier la correction, il rend l’acceptation plus explicite.
