Vérifier du code généré par IA : du diff au parcours utilisateur

L’agent corrige l’envoi du formulaire, les tests passent, mais une erreur du serveur efface encore la saisie. Cela arrive quand la revue s’arrête au diff et aux commandes au vert. Pour accepter du code, il faut une chaîne de preuves : ce qui a changé, le contrôle capable de détecter le défaut, le comportement observé dans le parcours utilisateur.

Examinez trois niveaux : les fichiers modifiés, les vérifications automatiques et le parcours utilisateur. La méthode ne garantit pas l'absence de bugs. Elle vous montre quelles preuves manquent encore.

Définir les critères avant le travail

Pour un formulaire de contact, « corrige l'envoi » ne suffit pas comme consigne. Décrivez un comportement que l'on peut observer :

Si le serveur renvoie une erreur, les données saisies sont conservées et un message clair apparaît. Pendant l'envoi, aucun doublon de requête n'est créé. Après un envoi réussi, une confirmation s'affiche.

Séparez les obligations des préférences. Sans cela, un beau refactoring peut prendre la place de la correction pour laquelle la tâche a été ouverte.

Pour une tâche complexe, demandez d'abord à l'agent de repérer les zones concernées et les tests existants. Donner à l'agent un moyen explicite de vérifier son travail fait aussi partie des recommandations d'Anthropic.

• recommandations d'Anthropic

L’explication de l’agent décrit son intention, pas un comportement observé. Le diff montre la modification. Un test valide une condition précise. Le parcours exécuté relie l’interface au résultat. Chaque preuve a ses limites, et une capture du message de succès ne prouve pas qu’un e-mail est arrivé.

Niveau 1 : lire le diff

Parcourez la liste des fichiers modifiés et demandez-vous pourquoi chacun a été touché. Une petite correction de formulaire n'a pas à modifier au passage l'authentification, les dépendances ou le déploiement.

Vérifiez que :

• Les règles d'accès et la gestion des erreurs sont conservées.
• Un vrai contrôle n'a pas été remplacé par un succès systématique.
• Les tests qui détectaient le problème n'ont pas disparu.
• Aucun secret, log inutile ou contournement temporaire n'a été ajouté.

Utilisez git diff et git diff --stat. Si l'agent a déjà créé un commit, comparez les commits concernés, car le diff des changements non commités peut alors être vide. Documentation git diff.

• Documentation git diff

Lancez git status --short avant de lire le diff, car les nouveaux fichiers peuvent en être totalement absents. git diff compare les fichiers de travail à l’index, et git diff --cached compare l’index à HEAD. Pour voir d’un coup toutes les modifications suivies non commitées, utilisez git diff HEAD. Les commits déjà créés se comparent avec le point de départ.

Niveau 2 : exécuter les vérifications adaptées

Demandez les commandes exactes et l'issue de chaque contrôle. « Lancé », « terminé » et « réussi » ne veulent pas dire la même chose. Une erreur d'environnement peut arrêter un processus sans rien confirmer ni infirmer au sujet de la correction.

Aucune ligne du tableau ne remplace les autres. Un build réussi, par exemple, ne prouve pas qu'un courriel est arrivé à destination.

Pour un défaut reproductible, assurez-vous que le test échoue sur l'ancien comportement et passe après correction. Sinon, il se contente peut-être de valider une propriété commode de la nouvelle implémentation.

Niveau 3 : parcourir l'application

Pour le formulaire, testez l'entrée vide, la valeur invalide, l'erreur serveur et l'envoi réussi. Travaillez avec des données et un destinataire de test : vous observez ainsi le résultat sans véritables demandes de clients.

Dans les tests automatisés en navigateur, contrôlez le comportement visible en vous appuyant sur des repères stables. Playwright recommande des tests isolés et des locators liés à ce que voit l'utilisateur. Bonnes pratiques Playwright.

• Bonnes pratiques Playwright

Une capture confirme un état visible, pas toute la chaîne. Vérifiez aussi que le gestionnaire a reçu les bons champs, que l'enregistrement figure dans le système de test et qu'un second clic n'a pas créé de doublon.

Un scénario de régression pratique : remplir le formulaire, provoquer une erreur contrôlée du serveur, vérifier que les valeurs sont toujours là, puis réessayer. Un second clic pendant la requête ne doit pas créer un nouvel envoi. Simuler une réponse dans le test ne vérifie que la gestion de l’erreur. La livraison réelle se contrôle à part, avec un destinataire de test.

Faire relire par un second agent

Fournissez-lui la demande initiale, le diff et les résultats dont vous disposez. Demandez-lui de relever les écarts par rapport aux critères et d’expliquer comment reproduire chaque problème. Ne lui annoncez surtout pas que le premier agent a tout corrigé correctement.

Exemple :

Examine ces changements par rapport aux critères de la tâche. Pour chaque remarque, indique le fichier, les conditions du bug et une manière de le vérifier. Évite les recommandations générales sans rapport avec le diff. Signale séparément ce que les données disponibles ne permettent pas de confirmer.

Le second agent vous apporte des questions supplémentaires, rien de plus. La décision repose toujours sur le code et les vérifications. Quand une remarque est contestée, reproduisez le cas. Un vote entre modèles ne prouve rien.

Rédiger le bilan

Conservez un document bref, que l'on pourra relire et vérifier plus tard :

Modification : correction et fichiers concernés.
Vérifié : commandes, conditions et résultats.
Scénario : actions réalisées dans l'application.
Non vérifié : limites de l'environnement et questions ouvertes.
Décision : accepter, reprendre ou demander des preuves.

Acceptez la modification lorsque vous pouvez relier l’exigence, le diff et un résultat observé. Conservez les commandes et les scénarios réellement exécutés, ainsi que les points restant à vérifier. Si un défaut se reproduit, donnez à l’agent l’étape exacte et le comportement attendu. C’est plus utile que « vérifie encore ».

Sources et vérification

Sources techniques et calculs vérifiés le 3 octobre 2026. Les scénarios et schémas sont des exemples pédagogiques de Neaptide. Nous n’avons réalisé aucun benchmark comparatif des produits.

• Claude Code · Best practices
• Git · git-diff
• Playwright · Best practices