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

« Les tests passent » ne répond qu'à une partie des questions. Quels tests ont été exécutés ? Couvrent-ils le problème initial ? Des changements sortent-ils du périmètre ? La validation commence par des critères comparables au code et au comportement de l'application.

Examinez trois niveaux : les fichiers modifiés, les vérifications automatiques et le parcours utilisateur. Cette méthode proposée ne garantit pas l'absence de bugs ; elle aide à identifier les preuves manquantes.

Définir les critères avant le travail

« Corrige l'envoi » est insuffisant pour un formulaire de contact. Décrivez un comportement observable :

Si le serveur renvoie une erreur, les valeurs restent et un message clair apparaît. Pendant l'envoi, aucun doublon de requête n'est créé. Après un succès, une confirmation s'affiche.

Séparez obligations et préférences. Un beau refactoring ne doit pas remplacer la correction attendue.

Pour une tâche complexe, demandez d'abord de repérer les zones concernées et les tests existants. La vérification explicite figure aussi dans les recommandations d'Anthropic.

• recommandations d'Anthropic

Niveau 1 : lire le diff

Parcourez les fichiers modifiés et justifiez le rôle de chacun. Une petite correction de formulaire ne devrait pas modifier discrètement l'authentification, les dépendances et 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 créé un commit, comparez les commits appropriés : le diff des changements non commités peut être vide. Documentation git diff.

• Documentation git diff

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

Demandez les commandes et l'issue de chaque contrôle. Distinguez « lancé », « terminé » et « réussi ». Une erreur d'environnement peut arrêter un processus sans confirmer ni invalider la correction.

Aucune ligne ne remplace toutes les autres. Un build réussi ne prouve pas qu'un courriel est arrivé à destination.

Pour un défaut reproductible, vérifiez que le test détecte l'ancien comportement et passe après correction. Sinon, il pourrait seulement valider une propriété commode de la nouvelle implémentation.

Niveau 3 : parcourir l'application

Pour le formulaire, testez entrée vide, valeur invalide, erreur serveur et envoi réussi. Utilisez des données et un destinataire de test pour observer les résultats sans véritables demandes clients.

En automatisation navigateur, contrôlez le comportement visible avec des repères stables. Playwright recommande des tests isolés et des locators proches de la perception utilisateur. Bonnes pratiques Playwright.

• Bonnes pratiques Playwright

Une capture confirme un état visible, pas toute la chaîne. Vérifiez aussi les champs reçus par le gestionnaire, l'enregistrement dans le système de test et l'absence de doublon après un second clic.

Faire relire par un second agent

Fournissez la demande initiale, le diff et les résultats disponibles. Demandez les violations des critères et leur reproduction, sans annoncer 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 apporte des questions supplémentaires. La décision doit toujours reposer sur le code et les vérifications. Reproduisez un cas contesté plutôt que de départager les modèles par vote.

Rédiger le bilan

Conservez un document bref et vérifiable :

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.

Ne masquez pas l'incertitude par « ça fonctionne globalement ». Si le service de test est indisponible, indiquez que la livraison finale n'est pas confirmée.