Workflow de code review avec Claude Code : deux passes, jamais zéro

Un workflow de code review qui tient avec Claude Code repose sur deux passes. Un agent relit d'abord, sur des critères mécaniques : conventions, tests, secrets, surfaces sensibles touchées. Un ingénieur senior relit ensuite, sur ce qui demande du jugement : architecture, conséquences, dette qu'on accepte de prendre. La question n'est pas de choisir entre l'agent et l'humain. C'est de savoir qui attrape quoi.

Le piège classique quand on code avec une IA, c'est de considérer que le code a déjà été relu parce qu'il a été généré par un modèle. Il ne l'a pas été. Il a été produit avec confiance, ce qui n'est pas la même chose. Chaque PR de nos clients passe deux fois. Jamais zéro.

Passe 1 : ce qu'un agent doit relire

L'agent tourne à l'ouverture de la PR, avant tout regard humain. Il ne donne pas d'avis. Il vérifie des choses qui ont une réponse binaire.

Concrètement, quatre catégories :

Les conventions du repo. Nommage, structure des dossiers, forme des composants, gestion des erreurs. Un agent est excellent là-dessus parce que les règles sont écrites. On les met dans le CLAUDE.md du projet, l'agent les applique, et le débat sur le style disparaît de la review humaine. C'est autant de bande passante rendue aux sujets qui comptent.

Les tests. Est-ce que la PR en ajoute quand elle touche une logique qui en mérite ? Est-ce que ceux qui existent passent toujours ? L'agent ne juge pas la qualité du test, il constate l'absence.

Les secrets et l'évident. Clés d'API en dur, tokens laissés dans un fichier de config, endpoints sans vérification d'authentification, dépendances ajoutées sans raison visible. Ce sont des erreurs de fatigue, pas de compétence, et une machine ne fatigue pas.

La détection de surface critique. C'est la partie la plus utile, et celle que la plupart des setups oublient. L'agent regarde quels fichiers la PR touche et les compare au registre du Core : modèle de données, couche d'authentification, contrats d'API, intégrations de paiement, chemins de déploiement. Si la PR touche une de ces zones, elle est taguée arch-review automatiquement. Le tag n'est pas décoratif. Il change qui relit.

L'agent poste ses remarques en commentaires sur la PR. Il ne bloque pas le merge tout seul et ne valide rien tout seul non plus. Il prépare le terrain.

Passe 2 : ce qu'un humain doit relire

L'ingénieur senior arrive après, avec les remarques de l'agent déjà visibles. Il ne relit pas la même chose. Il relit ce qui n'a pas de réponse binaire.

Est-ce que cette PR crée une deuxième façon de faire une chose qui existait déjà ? Est-ce que ce nouveau champ en base va poser un problème de migration dans quatre mois ? Est-ce que ce raccourci est acceptable ici, sur une feature qui sera probablement réécrite, et inacceptable là, sur du code dont tout le reste dépend ?

C'est ce type de question que l'IA ne tranche pas, parce qu'y répondre demande de connaître l'historique du repo et la direction du produit. Un modèle voit la PR. Il ne voit pas la conversation d'il y a six semaines où vous avez décidé de ne pas faire de multi-tenant tout de suite.

Sur les PR taguées arch-review, un architecte s'ajoute au reviewer. Deux paires d'yeux humaines, pas parce que le code est plus compliqué, mais parce que le coût d'une erreur y est plus élevé. Quand une décision structurante en sort, elle est consignée en ADR dans docs/adr/. Six mois plus tard, la question « pourquoi c'est fait comme ça » a une réponse écrite.

Le délai fait partie du workflow

Une review qui arrive quand elle arrive ne fonctionne pas. Le fondateur qui attend trois jours pour merger arrête d'ouvrir des PR et se met à pousser sur main. Le workflow meurt en silence.

Chez nous la review senior arrive sous 24 heures ouvrées, et si on dépasse, ça nous coûte 0,25 jour de crédit sur la facture suivante. Pas de plafond de volume non plus : la seule limite connue à ce qu'un fondateur peut shipper, ce sont ses crédits Claude.

Ce n'est pas un détail commercial. C'est ce qui rend le reste applicable. Une contrainte que personne ne tient devient une contrainte que tout le monde contourne.

Ce que vous pouvez mettre en place vous-même

Trois choses, dans cet ordre, si vous codez seul avec Claude Code :

1. Écrivez vos conventions dans le CLAUDE.md. Tant qu'elles sont dans votre tête, ni l'agent ni un futur collaborateur ne peut les appliquer.
2. Listez vos surfaces critiques. Huit à quinze entrées suffisent : les fichiers dont tout le reste dépend. Toute PR qui les touche mérite une relecture lente, même si vous êtes seul.
3. Séparez les deux passes dans le temps. Relire son propre code juste après l'avoir généré ne marche pas. Ouvrez la PR, laissez l'agent passer, revenez le lendemain matin. La distance fait la moitié du travail.

Le principe tient en une phrase : l'IA attrape l'évident, l'humain attrape le reste. Ce qui compte, c'est que les deux passes existent et qu'aucune ne se fasse passer pour l'autre.

---

Vous voulez savoir ce qu'une review sérieuse trouverait dans votre repo aujourd'hui ? On fait le Bunker Test gratuitement : vous nous donnez accès au code, on vous renvoie un rapport écrit sous cinq jours ouvrés. Aucun engagement.

Demander un Bunker Test

English version: Claude Code review workflow.