Checklist de review Claude Code: repérer les risques avant publication

Les trois premières lignes fixent la profondeur de la review

Quand une review Claude Code paraît superficielle, le problème ne vient pas seulement du modèle. La demande ne précise souvent ni le périmètre, ni ce qui ne doit pas casser, ni les vérifications déjà faites, ni la décision attendue.

Dans cet article, un workflow de review désigne une suite répétable: réduire le diff, nommer le risque, joindre des preuves, demander les findings en premier, puis laisser l’humain décider. Pour débuter, le diff est ce qui a changé dans le PR, le review gate est le contrôle avant merge ou publication, et le verification receipt est la trace courte des commandes, résultats, captures, logs et risques restants.

Les références officielles utiles sont Claude Code overview, common workflows, GitHub pull request reviews et npm scripts. Pour compléter, utilisez aussi la checklist de code review Claude Code et le verification receipt workflow.

Préparer le contexte avant Claude Code

Claude Code trouve mieux les défauts quand l’entrée contient Scope, Risk, Evidence et Handoff. Sans ces quatre éléments, il peut produire un résumé correct mais manquer le point qui bloque vraiment la mise en ligne.

Entrée	But	Version faible	Version forte
Scope	Limiter le changement	J’ai corrigé plusieurs choses	Seulement liens CTA, texte et espacement mobile
Risk	Nommer l’impact	Ça devrait aller	Produits, consultation et liens internes touchent le revenu
Evidence	Montrer la vérification	Vu en local	npm run build passe, CTA vérifié à 360px
Handoff	Définir la sortie	Peux-tu relire	Findings P1/P2/P3, risque résiduel et checks suivants

flowchart LR
  A["Diff"] --> B["Scope and risk"]
  B --> C["Claude Code review"]
  C --> D["Human decision"]
  D --> E["Fix, verify, or ship"]
  E --> F["Review receipt"]

La limite est importante: Claude Code n’est pas l’approbateur. Il réduit les oublis, propose des tests et signale les hypothèses fragiles. La décision de corriger, revérifier ou publier reste au propriétaire du PR.

Checklist avant review

Commencez par collecter l’état du dépôt et les commandes de vérification. L’exemple ci-dessous vise un projet Node; remplacez les dernières lignes par pytest, go test ./..., bundle exec rspec ou votre commande CI habituelle.

git status --short
git diff --stat
git diff --name-only
npm run build
npm run test -- --runInBand

Placez ensuite cette checklist dans la description du PR, .github/review-checklist.md ou la documentation d’équipe.

# Claude Code Review Checklist

## Scope
- [ ] This PR has one clear purpose.
- [ ] Changed files match the stated purpose.
- [ ] No unrelated formatting, dependency, or generated files are mixed in.

## Risk
- [ ] Risk level is marked as low, medium, or high.
- [ ] User-facing routes, forms, auth, billing, analytics, and CTA paths are named.
- [ ] Rollback or recovery steps are written for high-risk changes.

## Evidence
- [ ] Build, test, lint, or typecheck commands are listed with results.
- [ ] Manual checks include browser width, account state, and actual URL when relevant.
- [ ] Screenshots, logs, or console output are attached for UI and integration changes.

## Review output
- [ ] Findings come first, ordered by severity.
- [ ] Each finding has file reference, reproduction condition, and expected fix.
- [ ] Residual risk is written even when no blocker is found.

Cette checklist force la review à chercher un risque de publication plutôt qu’une impression générale.

Prompt prêt à l’emploi

Le prompt peut rester court si le format de sortie est strict. Gardez bug-finding mindset, findings first et do not rewrite code yet.

Review this diff with a bug-finding mindset.

Scope:
- Only review the files changed in this PR.
- Do not rewrite code yet.

Prioritize:
1. behavioral regressions
2. security, privacy, or permission mistakes
3. missing tests or weak verification
4. broken mobile layout, internal links, product CTA, or training CTA

Return:
- Findings first, ordered by P1/P2/P3 severity
- File and line references when possible
- Why each issue matters to users or revenue
- Checks I should run next
- Residual risk if no blocker is found

La première passe doit rester en lecture seule. Si Claude Code corrige pendant qu’il relit, l’équipe perd la liste claire des problèmes et la priorité de chacun.

Quatre cas d’usage concrets

Premier cas: CTA et parcours de revenu. Si le footer d’article, une carte produit, un prix ou un lien de consultation change, vérifiez l’URL cible, le produit associé, l’ordre des boutons, le mobile et l’événement analytics. Un échec courant est un bouton “templates” qui pointe encore vers un ancien produit. Le parcours doit mener clairement vers /fr/products/ et /fr/training/.

Deuxième cas: authentification, permissions et données privées. Masquer un bouton côté UI n’est pas une autorisation serveur. Claude Code doit vérifier qui peut agir, qui doit être refusé, si les logs exposent email ou payment ID, et si les tests couvrent le refus.

Troisième cas: publication multilingue. Une langue peut être naturelle tandis qu’une autre garde une vieille updatedDate, un code fence ouvert, un lien produit manquant ou du mojibake. Indiquez les fichiers locale autorisés et les metadata à préserver.

Quatrième cas: triage de build ou de tests. Ne collez pas un log énorme. Donnez la commande en échec, les dernières lignes utiles, le diff récent et ce qui a déjà été essayé. Le piège est de transformer un petit correctif de build en mise à jour de dépendances sans rapport.

Erreurs fréquentes

“Relis tout” est une mauvaise demande. Un périmètre trop large pousse Claude Code vers des généralités. Une meilleure demande liste les fichiers, les risques et ce qui est hors scope.

Autre erreur: ne pas fournir de preuve. Si personne ne sait si npm run build, le typecheck, le parcours navigateur ou la vue mobile ont été vérifiés, la review devine. Si une commande n’a pas été lancée, écrivez la raison.

Les parcours business ont leurs pièges: vérifier seulement desktop, ne pas cliquer les vrais liens, et oublier l’ordre de /products/ et /training/. Un CTA cassé peut ne pas être évident dans le diff.

Côté sécurité, ne collez pas d’API key, token, email client, payment ID ou contenu privé. Réduisez les logs au minimum reproductible avant de demander l’aide de Claude Code.

Vérifier le receipt avec un script

Ce petit script Node vérifie que le review receipt contient les sections nécessaires et au moins une commande cochée. Ce n’est pas une garantie complète, mais cela évite de publier sans preuve minimale.

{
  "requiredSections": ["Scope", "Risk", "Checks run", "Findings", "Residual risk"]
}

#!/usr/bin/env node
const fs = require("node:fs");

const receiptPath = process.argv[2] || "review-receipt.md";
const policyPath = process.argv[3] || "review-policy.json";
const receipt = fs.readFileSync(receiptPath, "utf8");
const policy = fs.existsSync(policyPath)
  ? JSON.parse(fs.readFileSync(policyPath, "utf8"))
  : { requiredSections: ["Scope", "Risk", "Checks run", "Findings", "Residual risk"] };

const escapeRegExp = (value) => value.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
const missingSections = policy.requiredSections.filter((name) => {
  const heading = new RegExp(`^## ${escapeRegExp(name)}\\b`, "m");
  return !heading.test(receipt);
});

const hasCheckedCommand = /^- \[(x|X)\] `(npm|pnpm|yarn|node|pytest|go test|cargo test)/m.test(receipt);

if (missingSections.length || !hasCheckedCommand) {
  for (const section of missingSections) console.error(`Missing section: ${section}`);
  if (!hasCheckedCommand) console.error("Missing checked command evidence such as - [x] `npm run build`");
  process.exit(1);
}

console.log("Review receipt passed.");

# Review receipt

## Scope
Article CTA links and mobile layout only.

## Risk
Medium: product and training links affect revenue.

## Checks run
- [x] `npm run build` passed
- [x] mobile CTA path checked at 360px

## Findings
- P2: Product CTA text and destination mismatch on one locale.

## Residual risk
Analytics event names were not checked in production.

La même idée peut devenir une section de PR template, une consigne Claude Code ou un contrôle CI léger.

Prochaine étape

En solo, commencez avec la cheatsheet Claude Code gratuite pour stabiliser les commandes et les demandes sûres. Si vous réécrivez toujours les prompts de review, debugging et triage, utilisez Prompt Templates et /fr/products/.

En équipe, le vrai sujet n’est pas un prompt malin. Il faut cadrer CLAUDE.md, permissions, review gates, verification receipts et responsabilité d’approbation. Pour l’adapter à un dépôt réel, utilisez /fr/training/.