Comment relire du code après Cursor, Claude Code et Codex

Un agent de code réduit le temps entre la tâche et le diff, mais il n’assume pas la responsabilité de la release. Le code écrit par IA n’est pas dangereux parce qu’il aurait une catégorie spéciale de bugs propres aux machines. Il produit rapidement des bugs ordinaires, dans plusieurs fichiers, avec des explications convaincantes. La revue doit donc commencer par les limites du changement et des signaux reproductibles, pas par un autre chatbot.

Expliquez pourquoi chaque fichier modifié appartient au diff

Demandez à l’agent un bref résumé, puis comparez-le au diff réel. Supprimez le formatage incident, les mises à jour de lockfile inexpliquées, le code de débogage et les changements dans des modules voisins dont la tâche n’a pas besoin. Scindez un grand diff lorsque c’est possible : schéma de données, serveur, interface et tests sont plus faciles à raisonner comme des unités logiques séparées.

Repérez la nouvelle source de vérité. Où l’état vit-il désormais, qui appelle la fonction et quels anciens chemins restent en place ? Un agent ajoute souvent une nouvelle couche sans supprimer ni mettre à jour la précédente. Chercher le nom, la route et le type peut révéler deux implémentations concurrentes.

Laissez le compilateur et les tests parler avant un relecteur IA

Exécutez le formatage, le linting, la vérification de types, les tests unitaires et les tests d’intégration avec les mêmes commandes que la CI. Si le projet ne dispose pas de ces vérifications, c’est un risque distinct, pas une raison de les remplacer par un modèle. Un outil déterministe répète une règle exactement ; un relecteur IA estime les problèmes probables et peut passer à côté de quelque chose de simple.

Un nouveau test doit échouer avec l’ancien code et réussir après le correctif. Un test qui est vert dans les deux versions peut ne rien prouver. Reproduisez l’échec initial pour une correction de bug ; pour une fonctionnalité, couvrez le chemin principal, les limites et l’échec d’une dépendance.

Playwright valide un parcours utilisateur, pas l’élégance de l’implémentation

Ajoutez ou mettez à jour un test navigateur pour un flux web critique. Les projets Playwright exécutent différents navigateurs et environnements, tandis que le trace viewer conserve les étapes, l’état du DOM, l’activité réseau et les captures d’écran pour le diagnostic en CI. Codegen est une ébauche utile, mais les locators et les attentes doivent être réécrits autour d’un comportement stable et visible par l’utilisateur.

Ne couvrez pas chaque setter avec de l’E2E. Verrouillez le parcours dont l’échec coûte cher : connexion, paiement, création d’objet, publication ou permissions de rôle. Les tests API et unitaires peuvent couvrir les branches moins coûteuses.

Les migrations et le travail en arrière-plan nécessitent une répétition du rollback

Lorsqu’un diff modifie le schéma, inspectez les lignes existantes, les valeurs nulles, les index, les verrous et le temps d’exécution. Exécutez la migration sur une copie avec un volume réaliste. Déterminez si le nouveau code fonctionne avec l’ancien schéma pendant un déploiement progressif et si l’application peut revenir en arrière après la migration.

Pour les files et les webhooks, testez les reprises, l’ordre, les timeouts et l’achèvement partiel. Les agents écrivent volontiers un happy path où un événement arrive une seule fois. La production a tendance à tester l’inverse.

Les permissions et les chemins de données comptent plus que les lignes à l’apparence suspecte

Tracez les entrées non fiables jusqu’à la base de données, au système de fichiers, au shell, au HTML et aux requêtes sortantes. Vérifiez l’autorisation côté serveur au lieu de vous appuyer sur un bouton masqué. Les secrets ne doivent pas entrer dans un bundle client, des logs, une réponse d’erreur ou le contexte d’un modèle.

Inspectez les dépendances et le code généré. Une nouvelle bibliothèque élargit la surface de supply chain et la taille du bundle ; un paquet qui ressemble à un autre peut être une faute de frappe. Pour les données personnelles, vérifiez la minimisation, la conservation et si des enregistrements sont envoyés à un modèle sans autorisation.

Une seconde IA fonctionne mieux comme adversaire étroitement briefé

Après les vérifications conventionnelles, donnez le diff à un agent relecteur séparé. Fixez une mission précise : trouver des violations d’invariants, des tests manquants, une incompatibilité d’API, des conditions de concurrence ou des contournements d’autorisation. Exigez un fichier, une ligne et un scénario d’échec. « Review this code » produit beaucoup de bruit stylistique.

N’acceptez pas une observation sans la reproduire. Un modèle peut inventer un contrat ou manquer une règle du projet. Les produits pertinents sont listés dans la collection de revue de code IA d’AIDive, avec des produits centrés sur l’exécution dans la collection de tests IA.

La revue de release se termine par l’observation après déploiement

Avant le merge, vérifiez la description de la PR, l’issue liée, la documentation, les flags, les métriques et le plan de rollback. Après la release, surveillez plus que les erreurs serveur : conversion des étapes, latence, profondeur de file, taux de rejet et invariants métier. Un rollback rapide vaut mieux qu’un long débat avec un agent pendant un incident.

La séquence courte est la suivante : comprendre le diff, le réduire, exécuter les vérifications déterministes, reproduire le parcours critique, inspecter séparément les données et les accès, utiliser l’IA comme second relecteur, puis publier avec observation. La vitesse de génération n’a d’importance que si l’équipe conserve la capacité de prouver la correction.