🔎Relire, auditer, sécuriser
L'agent écrit vite, votre métier devient de vérifier. Les bonnes pratiques pour relire un diff, auditer la qualité et passer la sécurité au crible, avec Claude Code ou n'importe quel agent.
Un agent produit du code à une vitesse folle. C’est sa force, et c’est précisément ce qui déplace votre rôle. Vous n’êtes plus celui qui tape chaque ligne ; vous êtes celui qui vérifie. Et un code généré vite, abondamment, avec assurance, mérite exactement le même soin de relecture qu’un code écrit à la main. Peut-être plus, parce que l’agent ne doute jamais de lui.
Bonne nouvelle : l’agent est aussi un excellent outil de vérification. On le retourne contre son propre travail. Voici les trois passes à prendre comme réflexe.
1. La relecture systématique du diff
La règle d’or, déjà croisée partout sur ce site : vous lisez le diff avant d’accepter. git diff vous montre exactement ce qui a changé. Vous ne validez que ce que vous comprenez ; pour le reste, vous demandez « pourquoi ce choix ? ».
Mais vous pouvez aussi confier la première passe à un agent dédié, un relecteur qui traque ce que l’œil fatigué laisse passer :
Claude Code propose une revue de diff intégrée, et vous pouvez en faire une commande à vous (un skill /review, voir Les skills) :
/review
Ou demandez-le en langage naturel : « relis le diff courant contre la branche de base, liste les bugs et les régressions par fichier:ligne, ne corrige rien sans mon accord ».
2. L’audit qualité
Au-delà des bugs, il y a la santé du code : est-il lisible, maintenable, testé ? Demandez un audit qualité régulier, l’agent est très bon pour repérer ce qui pourrit doucement :
- Duplication et code mort : du copier-collé à factoriser, des fonctions qui ne servent plus.
- Complexité : les fonctions à rallonge, les imbrications illisibles, ce qui gagnerait à être découpé.
- Nommage et cohérence : des noms trompeurs, des conventions qui partent dans tous les sens.
- Couverture de tests : ce qui n’est pas testé et devrait l’être.
3. L’audit sécurité
C’est la passe qu’on saute trop souvent, et celle qui fait le plus mal quand on la néglige, surtout sur une machine joignable de l’extérieur. Avant de mettre quoi que ce soit en ligne, demandez explicitement une revue de sécurité :
Lancez un audit ciblé
« Fais une revue de sécurité de ce code. Cherche : injections (SQL, commandes), secrets en clair, dépendances vulnérables, entrées non validées, permissions trop larges, et tout ce qui s’expose sans authentification. Classe par gravité. »
Vérifiez les points sensibles à la main
L’audit de l’agent dégrossit, mais recoupez vous-même ce qui compte : aucun secret dans le code (voir Sécuriser les accès), les entrées utilisateur échappées, et rien d’exposé publiquement qui ne devrait pas l’être.
Surveillez les dépendances
La moitié des failles vient des librairies tierces. Demandez à l’agent de vérifier les versions et de signaler les vulnérabilités connues, et gardez vos dépendances à jour.
En faire une routine, pas une corvée
Le secret, c’est que ces trois passes ne vous coûtent presque rien si vous les automatisez. Transformez-les en skills que vous déclenchez d’une commande (/review, /audit, /security), ou en étapes systématiques avant chaque mise en ligne. Beaucoup d’agents proposent déjà des commandes de revue toutes faites, servez-vous-en.