Le périmètre
Avant même le contenu : quels fichiers ont été touchés ? Y en a-t-il que tu n’avais pas demandés ? Un diff qui déborde du périmètre est un signal à lui seul, même si chaque ligne prise isolément semble correcte.
1 · La méthode
Lire un diff d’agent en quatre passes
Relire linéairement un gros diff ne marche pas : l’attention s’épuise et on valide la fin sans la lire. Quatre passes ciblées sont bien plus efficaces.
L’intention
Le changement résout-il le problème posé, ou un problème voisin plus facile ? C’est le piège classique : l’agent traite le symptôme visible plutôt que la cause. Un test qui passe ne prouve pas que la bonne chose a été corrigée.
Les bords
Là où le code IA est le plus faible : valeur nulle ou vide, erreur réseau, échec d’écriture, entrée hostile, concurrence. Le chemin nominal est presque toujours correct ; les bords sont souvent traités à la va-vite ou pas du tout.
L’intégration
Ce code ressemble-t-il au reste du projet ? Réutilise-t-il les helpers existants ou réinvente-t-il une fonction déjà présente ? Un agent qui n’a pas lu tout le repo duplique volontiers ce qu’il ne connaît pas.
2 · Signaux d’alerte
Les pièges typiques du code généré
Ces défauts reviennent si souvent qu’ils méritent une checklist mentale. Ils sont rarement visibles au premier coup d’œil, parce que le code « a l’air » propre.
La dépendance inventée
Un import vers un paquet qui n’existe pas, ou qui existe mais ne fait pas ça. Au-delà du bug, c’est un risque de sécurité réel : des attaquants publient des paquets aux noms fréquemment hallucinés.
L’erreur avalée
Un try / catch qui capture tout et ne fait rien, ou qui log et
continue comme si de rien n’était. Ça transforme une panne visible en corruption
silencieuse — le pire scénario en production.
Le test qui teste le mock
Le test le plus facile à écrire est celui qui vérifie que le mock renvoie ce qu’on lui a dit de renvoyer. Il passe toujours, il ne prouve rien. Vérifie qu’un test échouerait si tu cassais volontairement la logique.
La validation absente
Entrées non vérifiées, requêtes construites par concaténation, données de formulaire utilisées directement. Le chemin heureux fonctionne, l’entrée hostile passe aussi.
La sur-abstraction
Trois couches, une interface et une factory pour un besoin qui tenait en quinze lignes. Le code paraît « professionnel » mais devient coûteux à maintenir. Demande toujours la version la plus simple qui marche.
La duplication silencieuse
Une fonction utilitaire recréée alors qu’elle existait déjà ailleurs, avec un nom légèrement différent. Deux implémentations divergentes du même besoin, c’est un bug futur garanti.
Le code que tu merges est ton code. « C'est l'IA qui l'a écrit » n'a jamais réparé une production cassée ni convaincu un reviewer.
Le principe non négociable de ce chapitre
Le test le plus utile : casse volontairement quelque chose et vérifie
que la suite de tests échoue. Une suite verte qui reste verte quand tu supprimes une
ligne de logique ne protège rien du tout.
3 · Le filet
Git comme discipline, pas comme option
Les points de restauration d’un agent ne couvrent que ses propres éditions de fichiers. Une commande lancée, une migration appliquée, un fichier supprimé au terminal : rien de tout ça ne s’annule. Git est le seul vrai filet.
Une branche par tâche, un commit avant de lâcher l’agent, des commits atomiques
pendant, et un diff relu avant merge. Cette routine coûte deux minutes et évite
les soirées de récupération.
1
Branche dédiée
Jamais d’agent qui travaille directement sur la branche principale. Le retour arrière doit rester trivial.
2
Point de sauvegarde avant
Un état propre et commité avant de lancer une grosse tâche : c’est ce qui rend le diff lisible ensuite.
3
Commits atomiques
Un sujet par commit. Un commit géant mélangeant fix, refacto et formatage est impossible à relire et à annuler proprement.
4
Relecture avant merge
Le diff complet, pas seulement le résumé de l’agent. C’est le dernier moment où une erreur coûte encore peu.
4 · Déléguer la relecture
Faire relire l’IA par l’IA, sans se mentir
Une seconde passe automatique attrape beaucoup de choses, à condition de savoir ce qu’elle ne remplace pas.
Demande à ton agent
Relis le diff que tu viens de produire, en tant que
reviewer critique et sans complaisance.
Pour chaque point trouvé, donne le fichier, la ligne
et la gravité (critique / important / cosmétique).
Cherche en priorité :
- dépendances ou API inventées
- erreurs avalées silencieusement
- entrées non validées
- tests qui ne testeraient rien si je cassais la logique
- code dupliqué avec l'existant du projet
Ne corrige rien : je veux d'abord le rapport.
Ce que ça attrape bien : les incohérences mécaniques, les cas
limites oubliés, les écarts de convention, les duplications visibles.
Ce que ça n’attrape pas : une mauvaise compréhension du besoin
métier. Si l’agent a mal compris le problème, il relira son travail avec la même
mauvaise compréhension et le trouvera excellent. C’est structurel — et c’est
exactement pour ça que ta relecture reste indispensable.
Vérifie que c’est acquis
L’agent te livre une fonctionnalité avec des tests, et tous les tests passent du premier coup. Quel est le bon réflexe ?
Des tests qui passent immédiatement peuvent simplement ne rien vérifier — typiquement
en testant un mock. La seule façon de savoir si un test protège quelque chose, c’est
de vérifier qu’il sait échouer.
À retenir
Tu restes l’auteur
Relis par passes plutôt que linéairement, connais les défauts typiques du code généré, exige des tests qui savent échouer, et garde git comme filet réel. L’IA accélère la production ; c’est ta relecture qui décide de ce qui entre en production.