Checklist de Revue de Code Claude Code pour Équipes

Commencer par le risque, pas par “review this”

Si vous donnez un diff à Claude Code avec seulement “review this PR”, vous obtiendrez souvent des remarques utiles mais trop générales.

En équipe, une revue doit d’abord répondre à des questions concrètes: qu’est-ce qui peut casser, quelles données sont touchées, quelle preuve de test existe, et quels points doivent bloquer le merge.

Cet article fournit une checklist copiable, un prompt de revue Claude Code, un modèle de pull request GitHub et un garde CI avec GitHub Actions.

Claude Code ne remplace pas la responsabilité humaine. Il réduit les oublis et rend le niveau de revue plus constant. Pour les sources officielles, gardez sous la main le guide Claude Code deconfiguration de code review, la documentationClaude Code GitHub Actions, les docs GitHub sur lesmodèles de PR, lesprotected branches et lesActions workflows. Pour la sécurité, utilisez laOWASP Secure Code Review Cheat Sheet.

La revue basée sur le risque

Une revue basée sur le risque ne traite pas tous les PR de la même façon. Une correction de texte, un ajustement CSS, un webhook de paiement et une migration destructive n’ont pas le même impact. Si tout est lourd, les petits changements ralentissent. Si tout est léger, les changements dangereux passent trop facilement.

Trois niveaux suffisent au départ:

Risque	Exemples	Revue requise
Low	Texte, CSS simple, docs, libellé de log	Un reviewer, résumé clair, capture ou explication du diff
Medium	Formulaire, état UI, recherche, forme de réponse API, accès lecture seule	Un reviewer, preuve de test, revue Claude Code
High	Auth, autorisation, billing, données personnelles, migration, suppression, webhook	Deux reviewers, plan de rollback, CI obligatoire, revue sécurité/vie privée

Une migration est un changement de structure ou de forme de données. Le code se revert souvent. Une colonne supprimée, des enregistrements réécrits ou un backfill raté se récupèrent beaucoup moins facilement. Pour une migration, la première question est donc “comment revenir en arrière ?”.

Quand vous sollicitez Claude Code, indiquez le niveau de risque. Une demande vague produit souvent des remarques de style. Une demande comme “High risk: billing webhook and customer email changed” oriente la revue vers validation de signature, idempotence, retries, confidentialité, logs et preuve de tests.

Dans les notes de Masa, l’erreur récurrente était d’utiliser seulement des mots abstraits comme qualité, sécurité ou maintenabilité. Ils sont utiles comme titres, pas comme questions. Un bon modèle de PR demande fichiers touchés, types de données, raisons du risque, preuves de test et étapes de rollback.

Checklist de revue copiable

Placez cette checklist dans .github/review-checklist.md, dans le wiki d’équipe ou dans CLAUDE.md. Les questions sont volontairement observables pour que Claude Code et les reviewers humains jugent des faits.

# Code Review Checklist

## 0. PR scope
- [ ] This PR has one clear purpose.
- [ ] Changed files match the stated purpose.
- [ ] Generated or AI-written files are marked in the PR description.
- [ ] No unrelated formatting, dependency, or config changes are mixed in.

## 1. Risk level
- [ ] Risk level is marked as low, medium, or high.
- [ ] High-risk PRs have two human reviewers.
- [ ] High-risk PRs include rollback or recovery steps.

## 2. Security and privacy
- [ ] User input is validated on the server side.
- [ ] Authorization is checked near the data access point.
- [ ] Secrets are not printed, committed, or sent to Claude prompts.
- [ ] Logs do not include email, tokens, addresses, payment IDs, or private content.
- [ ] OWASP-relevant risks such as injection, XSS, broken access control, and SSRF were considered.

## 3. Tests
- [ ] Unit or integration tests cover the changed behavior.
- [ ] Regression tests cover the bug that motivated the PR.
- [ ] Manual verification steps are written with actual result, not "works locally".
- [ ] Snapshot changes are explained.

## 4. Performance
- [ ] New loops, queries, and network calls are bounded.
- [ ] N+1 queries were checked.
- [ ] Large lists, images, and bundles have a budget.
- [ ] Metrics or before/after evidence are attached for performance-sensitive changes.

## 5. Accessibility
- [ ] Keyboard operation works for interactive UI.
- [ ] Focus order and visible focus state are preserved.
- [ ] Form fields have labels and errors that screen readers can understand.
- [ ] Color contrast and reduced-motion behavior are checked where relevant.

## 6. Migration and data risk
- [ ] Migration is backward compatible during rollout.
- [ ] Destructive changes have backup or recovery steps.
- [ ] Old and new app versions can run during deployment.
- [ ] Data cleanup jobs are idempotent.

## 7. AI-generated diff hygiene
- [ ] AI-generated code was read by a human before approval.
- [ ] The diff does not remove tests, monitoring, analytics, or CTA links by accident.
- [ ] New dependencies are justified.
- [ ] Comments do not claim verification that was not actually done.

Le détail important est que chaque point doit pouvoir être vérifié. “La sécurité a été prise en compte” est faible. “Les logs ne contiennent pas d’email, token, adresse, payment ID ou contenu privé” est vérifiable. “L’accessibilité est correcte” est faible; “le clavier fonctionne, le focus est visible, les erreurs sont lisibles” est exploitable.

Prompt de revue Claude Code

Le prompt doit fournir le rôle, le contexte, le niveau de risque et une règle: produire les findings avant de modifier. Si Claude Code commence à corriger trop tôt, la revue et l’implémentation se mélangent, et le PR grossit sans décision claire.

You are reviewing a pull request for a production team.

Goal:
- Find concrete risks before merge.
- Prioritize correctness, security/privacy, tests, performance, accessibility, migration/data risk, and AI-generated diff hygiene.
- Do not rewrite code yet. Produce review findings first.

Context:
- Risk level: <low | medium | high>
- Business area: <auth | billing | content | search | admin | analytics | other>
- Sensitive data touched: <none | email | payment | address | health | private content | other>
- Rollout plan: <flag | migration | immediate deploy | other>

Review method:
1. Read the PR summary and changed files.
2. List the top risks by severity.
3. For each finding, include file, line or function, why it matters, and a minimal fix.
4. Separate "must fix before merge" from "follow-up".
5. Check whether tests prove the changed behavior.
6. Check whether any AI-generated code, dependency, config, or formatting change is unrelated to the PR goal.

Output format:
- Findings first, ordered by severity.
- Then missing evidence.
- Then questions for the author.
- Then a short merge recommendation: block, approve with fixes, or approve.

Ce prompt fonctionne bien avec lanavigation de codebase et lastratégie de tests. Avant la revue, demandez à Claude Code de résumer le domaine touché par le PR. Cela évite une revue limitée aux noms de variables et au formatage.

Modèle GitHub Pull Request

Avec .github/pull_request_template.md, GitHub préremplit le corps du PR. Le but n’est pas la paperasse, mais la preuve de revue: contexte, risque, tests, sécurité, rollback.

## Summary
- TODO

## Risk
Risk level: low | medium | high

Risk reasons:
- Data touched:
- Users affected:
- Rollout:

## Review focus
- [ ] Correctness
- [ ] Security/privacy
- [ ] Tests
- [ ] Performance
- [ ] Accessibility
- [ ] Migration/data risk
- [ ] AI-generated diff hygiene

## Test evidence
- Automated:
- Manual:
- Not tested because:

## Security and privacy notes
- Secrets changed: no | yes
- Personal data in logs: no | yes
- Authorization boundary changed: no | yes

## Migration / rollback
- Migration included: no | yes
- Backward compatible: no | yes | not applicable
- Rollback plan:

## Claude Code review prompt
Paste this into Claude Code after the PR is ready:

Review this PR as risk level "<low|medium|high>".
Focus on correctness, security/privacy, tests, performance, accessibility, migration/data risk, and AI-generated diff hygiene.
Return findings first with file/function references and minimal fixes.

Évitez le modèle composé uniquement de cases à cocher. Les équipes finissent par les cocher mécaniquement. Les champs Risk reasons, Test evidence et Rollback plan forcent une preuve et peuvent être contrôlés automatiquement.

Garde CI avec GitHub Actions

Ce workflow et ce script Node contrôlent le corps du PR et les fichiers modifiés. Ils ne prouvent pas que le code est correct, mais bloquent les PR sans niveau de risque, sans preuve de test ou sans rollback quand il en faut un.

name: PR review guard

on:
  pull_request:
    types: [opened, edited, synchronize, reopened, ready_for_review]

permissions:
  contents: read
  pull-requests: read

jobs:
  review-guard:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: Check PR review evidence
        run: node scripts/pr-review-guard.mjs
        env:
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}

import { execSync } from "node:child_process";
import { readFileSync } from "node:fs";

const eventPath = process.env.GITHUB_EVENT_PATH;
if (!eventPath) throw new Error("GITHUB_EVENT_PATH is missing.");

const event = JSON.parse(readFileSync(eventPath, "utf8"));
const pr = event.pull_request;
const body = pr?.body ?? "";
const base = process.env.BASE_SHA ?? pr?.base?.sha;
const head = process.env.HEAD_SHA ?? pr?.head?.sha;

function safeRef(value, name) {
  if (!value || !/^[a-f0-9]{40}$/i.test(value)) throw new Error(`${name} must be a full git SHA.`);
  return value;
}

const changedFiles = execSync(`git diff --name-only ${safeRef(base, "BASE_SHA")} ${safeRef(head, "HEAD_SHA")}`, {
  encoding: "utf8",
}).split(/\r?\n/).filter(Boolean);

const hasRisk = /Risk level:\s*(low|medium|high)/i.test(body);
const hasTests = /## Test evidence[\s\S]*(Automated|Manual):\s*\S/i.test(body);
const hasRollback = /Rollback plan:\s*\S/i.test(body);
const highRisk = /Risk level:\s*high/i.test(body);
const migrationChanged = changedFiles.some((file) => /migrations?|schema|prisma|drizzle/i.test(file));
const sensitiveChanged = changedFiles.some((file) => /auth|session|permission|billing|payment|webhook/i.test(file));
const failures = [];

if (!hasRisk) failures.push("Add Risk level.");
if (!hasTests) failures.push("Add automated or manual test evidence.");
if ((highRisk || migrationChanged) && !hasRollback) failures.push("Add rollback plan.");
if (sensitiveChanged && !/Security and privacy notes/i.test(body)) failures.push("Add security/privacy notes.");

if (failures.length) {
  console.error("PR review guard failed:");
  for (const failure of failures) console.error(`- ${failure}`);
  process.exit(1);
}

console.log("PR review guard passed.");

Commencez en mode indicatif. Ensuite, rendez ce check obligatoire sur les branches protégées pour les changements high-risk. Gardez les PR low-risk rapides, sinon les personnes rempliront le modèle pour passer la barrière.

Sécurité, vie privée, tests, performance et accessibilité

Pour la sécurité, découpez la revue en entrée, autorisation, sortie, logs et appels externes. La validation existe-t-elle côté serveur ? L’autorisation est-elle proche de l’accès aux données ? La sortie peut-elle produire du XSS ? Les logs contiennent-ils des données privées ? Un webhook ou une URL externe peut-il devenir un risque SSRF ou bypass de signature ?

La vie privée dépasse les secrets. Emails, payment IDs, adresses, messages de contact, identifiants analytics et contenu privé doivent être protégés. Ne collez pas de vraies clés API, emails clients, contrats ou IDs de paiement dans les prompts. Masquez les valeurs et donnez seulement la structure à Claude Code.

Pour les tests, demandez une preuve. “Works locally” ne suffit pas. Un bon PR indique le test automatique exécuté, le flux manuel vérifié et le résultat observé. S’il n’y a pas de test, la raison doit être écrite.

Pour la performance, cherchez les boucles non bornées, les N+1 queries, les appels réseau répétés, la croissance du bundle, les images lourdes et le rendu client coûteux. Un chiffre avant/après, même simple, améliore beaucoup la revue.

Pour l’accessibilité, ne vous limitez pas aux screenshots. Vérifiez clavier, ordre de focus, focus visible, labels, messages d’erreur, focus trap de modal et reduced motion. Une UI générée par Claude Code peut paraître propre tout en oubliant ces détails.

Cas d’usage pratiques

Premier cas: auth et écrans admin. Les listes utilisateurs, changements de rôle et journaux d’audit doivent être protégés côté API ou data layer. Regardez autorisation, logs de données personnelles, preuve d’audit et tests d’accès non autorisé.

Deuxième cas: billing et webhooks. Un webhook de paiement doit vérifier la signature, être idempotent, gérer les retries, résister aux événements dupliqués, traiter l’annulation et logger sans données privées.

Troisième cas: migration de base de données. Ajouter une colonne peut casser la production si ancienne et nouvelle version de l’app cohabitent. Vérifiez default, not null, index, backfill, rollback et séquence expand-contract.

Quatrième cas: grand diff UI généré par IA. Quand Claude Code génère pages, formulaires, modales ou tableaux, vérifiez suppression accidentelle de CTA, changement d’events analytics, trous d’accessibilité, snapshots non expliqués et dépendances nouvelles.

Cinquième cas: site de contenu avec revenus. La revue d’une page article, produit ou lead form doit protéger le chemin de conversion. Si le lien vers lesproduits, le formulaire PDF gratuit ou le tracking de consultation casse, c’est un bug business même si la page s’affiche.

Pièges et CTA

Premier piège: croire les findings de Claude Code sans vérification. L’IA peut formuler des affirmations plausibles. Reliez chaque finding au diff, aux tests, aux docs officielles ou à une reproduction.

Deuxième piège: mélanger revue et correction. Demandez les findings, décidez les must-fix, puis corrigez. Le PR reste lisible.

Troisième piège: laisser passer du nettoyage IA non lié. Formatage, dépendances, config et tests supprimés peuvent se cacher dans un grand diff. Demandez explicitement la liste des unrelated changes.

Quatrième piège: confondre rollback de données et revert de code. Un revert ne restaure pas les données supprimées. Une migration high-risk demande backup, SQL de récupération, feature flag ou plan par étapes.

La revue protège aussi les revenus: billing, pages produit, PDF gratuit, Gumroad, analytics et CTA de consultation. Pour pratiquer, commencez par lachecklist gratuite. Pour des prompts, templates, CLAUDE.md et guards réutilisables, voyez lesproduits et modèles. Pour un déploiement sur un vrai repo, utilisez laformation et consultation.

J’ai testé cette forme sur trois scénarios: changement UI Next.js, migration de base de données et diff UI généré par Claude Code. Les champs les plus utiles étaient Risk level et Rollback plan. Ajouter plus de cases n’aidait pas autant qu’une preuve courte et précise.

Résumé

Une checklist de revue de code Claude Code n’est pas seulement un prompt. C’est un workflow qui relie classification du risque, preuve dans le PR, revue humaine, CI et branches protégées.

Commencez petit: ajoutez le modèle de PR, lancez le guard en mode indicatif, puis rendez-le obligatoire pour les changements high-risk. Combinez-le avecAI pair programming etCLAUDE.md best practices pour fixer le standard dans le dépôt.