Brancher une relecture automatique sur chaque changement

1Ne relire que le diff

Le premier réglage est le périmètre. Une revue qui a accès à tout le dépôt commente l'architecture, les choix historiques et les fichiers que personne n'a touchés. Le diff seul contraint la sortie à ce qui vient de changer.

git diff --stat main...HEAD
git diff main...HEAD

La forme à trois points compare avec l'ancêtre commun plutôt qu'avec l'état courant de main, ce qui évite de faire relire les commits des autres.

Relis uniquement ce diff. Tu n'as pas le contexte du reste du projet, et
c'est voulu.
Si une remarque necessite de voir un autre fichier, demande ce fichier
precis au lieu de supposer.

2Écrire la liste, dans les deux sens

C'est l'étape que tout le monde saute, et c'est la seule qui décide du résultat. Une consigne du type « relis ce code et signale les problèmes » produit une revue générique. La liste explicite produit une revue lisible.

Ce qu'elle doit signaler, parce que c'est constatable et coûteux :

Signale uniquement :
- une erreur qui casse le comportement : cas limite non gere, valeur
  nulle possible, condition inversee, boucle sur une collection modifiee ;
- un secret, une cle ou une URL interne en dur ;
- une donnee venant de l'exterieur qui atteint une requete, un shell,
  un chemin de fichier ou du HTML sans validation ;
- une erreur avalee : un catch vide, une exception loguee puis ignoree,
  une valeur de repli qui masque une panne ;
- une regression de comportement sur un chemin existant ;
- une ressource non liberee : connexion, fichier, verrou, abonnement.

Ce qu'elle doit ignorer, parce que c'est de la préférence ou du ressenti :

N'ecris rien sur :
- le style, le nommage, la mise en forme (le formateur s'en occupe) ;
- les suggestions d'extraction, de factorisation ou de renommage ;
- les choix d'architecture deja en place dans le projet ;
- les tests manquants sur du code trivial ;
- les commentaires manquants ;
- tout ce qui commence par "on pourrait aussi".

3Choisir le moment du déclenchement

Trois emplacements possibles, avec des propriétés différentes.

À la fin d'un tour d'agent. Claude Code déclenche des scripts sur des événements nommés, décrits dans .claude/settings.json. PostToolUse se déclenche après un outil, Stop à la fin d'un tour.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/revue.sh" }
        ]
      }
    ]
  }
}

Le script reçoit un objet JSON sur son entrée standard. Un code de sortie 2 bloque l'action et renvoie la sortie d'erreur à Claude, qui peut alors corriger sans que tu interviennes. Tout autre code non nul est signalé sans bloquer.

Avant le commit. Un point d'ancrage git local, posé à la main dans .git/hooks/pre-commit ou via un gestionnaire de hooks, attrape la bêtise avant qu'elle parte. Garde-le rapide : au-delà de quelques secondes, il sera contourné avec --no-verify.

Sur la demande de fusion. C'est là que la revue est visible par l'équipe.

gh pr diff 42 | claude -p "$(cat .claude/revue.md)" --output-format json

-p exécute une requête sans mode interactif, --output-format json rend la sortie exploitable par un script, et --allowedTools limite ce que la revue a le droit de faire.

4Contraindre le format et autoriser le silence

Un format fixe permet de comparer deux revues, et un plafond force le tri.

Rends un tableau, au plus 5 lignes : fichier:ligne, probleme en une
phrase, gravite (bloquant / important), ce qui casse concretement.
Classe par gravite. Ne propose pas de correction.
Si tu ne trouves rien qui entre dans la liste, ecris exactement :
"Rien a signaler sur ce diff." et n'ajoute rien.

La dernière phrase est celle qui sauve le dispositif. Un relecteur qui n'a pas le droit de ne rien trouver trouvera toujours quelque chose, et ce quelque chose sera une remarque de confort. Le plafond de cinq lignes joue le même rôle : il oblige à choisir, au lieu de tout déverser.

5Mesurer, puis couper

Une revue automatique se règle avec un seul chiffre : la part des remarques qui entraînent une modification. Compte-la à la main sur dix demandes de fusion.

• Au-dessus de deux tiers, le réglage est bon, tu peux élargir la liste.
• Entre un tiers et deux tiers, retire les catégories les moins rentables.
• En dessous d'un tiers, la revue est déjà en train d'être ignorée. Réduis à deux ou trois catégories, celles qui correspondent à des incidents que vous avez réellement vécus.

Une revue qui part de trois règles issues de vos propres pannes vaut mieux qu'une revue exhaustive copiée d'ailleurs. Et une catégorie qui n'a rien trouvé en deux mois se retire : elle ne coûte pas rien, elle coûte de l'attention.