Relire, auditer, sécuriser

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 :

/code-review              # relit le diff courant
/code-review high         # relecture plus poussée, plus longue
/code-review --fix        # applique ensuite les corrections trouvées

codex review --uncommitted        # relit tout ce qui n'est pas commité
codex review --base main          # compare la branche courante à main
codex review --commit <sha>       # relit un commit précis

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.

Dans Claude Code, /simplify fait une partie de ce travail d’origine : il passe les changements en revue sous l’angle de la réutilisation, de la simplification et de l’efficacité, puis applique les corrections. Il ne cherche pas les bugs, c’est le rôle de /code-review. Codex et OpenCode n’ont pas de commande d’audit qualité toute faite : passez la liste ci-dessus en consigne, par exemple codex exec "Audit qualité du dépôt : duplication, code mort, complexité, nommage, tests manquants. Ne modifie rien." (en non interactif, Codex reste par défaut en lecture seule), ou faites-en un skill.

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é :

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. Servez-vous d’abord des commandes fournies (/code-review, /simplify, /security-review dans Claude Code, /review et codex review dans Codex). Pour ce qu’elles ne couvrent pas, vos propres critères, votre pile, vos pièges récurrents, écrivez des skills maison (un /audit à votre façon), et faites-en des étapes systématiques avant chaque mise en ligne.