> ## Documentation Index
> Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Personnaliser Code Review

> Ajustez ce que Code Review signale sur vos pull requests avec REVIEW.md et CLAUDE.md : recalibrez la sévérité, ignorez des chemins, ajoutez des vérifications et identifiez quelle copie s'applique.

Vous pouvez modifier ce que [Code Review](/docs/fr/code-review) signale sur votre dépôt en y committant des instructions. C'est ainsi que vous réduisez le volume de nits, mettez fin aux commentaires sur les fichiers générés ou ajoutez une règle qui compte pour votre équipe. Placez-les dans l'un de ces deux fichiers :

* **`CLAUDE.md`** : des [instructions de projet](/docs/fr/memory) que Claude Code lit pour chaque tâche, revues comprises. Code Review les lit comme contexte de projet et signale les modifications qui les enfreignent.
* **`REVIEW.md`** : des instructions réservées aux revues. Utilisez-le pour indiquer ce que votre équipe souhaite voir signalé, à quel niveau de sévérité, et ce qu'il faut ignorer.

Ajoutez `REVIEW.md` à la racine de votre dépôt et fusionnez-le. Ensuite, [protégez votre branche par défaut](#which-branch-review-md-is-read-from).

<Note>
  Pour modifier le niveau de détail des revues ou le moment où elles s'exécutent, demandez à un Owner de modifier le [niveau de revue](/docs/fr/code-review-setup#set-the-default-review-level) ou le [paramètre **Review runs**](/docs/fr/code-review-setup#set-when-reviews-run).
</Note>

<h2 id="use-claude-md-for-project-wide-rules">
  Utiliser CLAUDE.md pour les règles à l'échelle du projet
</h2>

Code Review lit les fichiers `CLAUDE.md` de votre dépôt comme contexte de projet. Une modification qui enfreint l'une de leurs règles devient un résultat au [niveau de sévérité](/docs/fr/code-review-pull-requests#severity-levels) adapté au problème.

Une revue lit le fichier `CLAUDE.md` à la racine de votre dépôt ainsi que les fichiers `CLAUDE.md` des répertoires parents de chaque fichier modifié. Le fichier `CLAUDE.md` d'un sous-répertoire est lu lorsque la pull request modifie un fichier sous ce chemin.

<h2 id="use-review-md-for-review-only-rules">
  Utiliser REVIEW\.md pour les règles propres aux revues
</h2>

`REVIEW.md` est un fichier situé à la racine de votre dépôt qui adapte Code Review à votre dépôt. Vous pouvez également ajouter un `REVIEW.md` dans un sous-répertoire pour ajouter des vérifications sur les modifications sous ce chemin, en plus du fichier racine.

Les agents qui détectent les problèmes et les agents qui les vérifient reçoivent son contenu en tant qu'instructions de revue de votre dépôt, en complément des consignes de revue par défaut de Code Review. L'étape qui rédige la revue finale le consulte avant de fixer la sévérité et de rédiger le résumé.

Cet exemple d'arborescence comporte un fichier racine et un fichier de sous-répertoire :

```text theme={null}
your-repo/
├── REVIEW.md            # Root file
├── services/
│   └── billing/
│       └── REVIEW.md    # Adds checks for changes under services/billing/
└── src/
```

Avant de vous appuyer sur un fichier de sous-répertoire, protégez votre branche par défaut et vérifiez [ce qu'une revue lit selon la configuration de vos branches](#what-a-review-reads-for-each-branch-setup).

<Note>
  Le service Code Review et la [commande `/code-review`](/docs/fr/code-review-local) locale sont deux outils distincts, et ils lisent des fichiers différents. Le service lit à la fois `CLAUDE.md` et `REVIEW.md`. La commande `/code-review`, que vous exécutez dans une session Claude Code sur votre propre machine, lit vos fichiers `CLAUDE.md` mais pas `REVIEW.md`. Placez dans `CLAUDE.md` les consignes que vous souhaitez appliquer aux deux endroits, et réservez `REVIEW.md` aux règles propres à la revue des pull requests.
</Note>

<h3 id="example-review-md">
  Exemple de REVIEW\.md
</h3>

Ce `REVIEW.md` recalibre la sévérité pour un service backend, plafonne les nits, ignore les fichiers générés et ajoute des vérifications propres au dépôt.

```markdown theme={null}
# Review instructions

## What Important means here

Reserve Important for findings that would break behavior, leak data,
or block a rollback: incorrect logic, unscoped database queries, PII
in logs or error messages, and migrations that aren't backward
compatible. Style, naming, and refactoring suggestions are Nit at
most.

## Cap the nits

Report at most five Nits per review.

## Do not report

- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file
- Test-only code that intentionally violates production rules

## Always check

- New API routes have an integration test
- Log lines don't include email addresses, user IDs, or request bodies
- Database queries are scoped to the caller's tenant
```

<h3 id="choose-what-to-write-in-review-md">
  Choisir ce qu'il faut écrire dans REVIEW\.md
</h3>

`REVIEW.md` est un fichier Markdown de forme libre qui modifie ce qu'une revue détecte et signale. Il ne modifie pas le format de la revue. Identifiez le problème que vous rencontrez, puis ajoutez une instruction semblable à celle indiquée. L'[exemple](#example-review-md) utilise les quatre premières.

* **Les mauvais éléments sont marqués Important** : redéfinissez ce que signifie 🔴 Important pour votre dépôt. Le calibrage par défaut cible le code de production, et un dépôt de documentation, un dépôt de configuration ou un prototype peuvent nécessiter une définition beaucoup plus restreinte. Indiquez quelles catégories de résultats sont Important et lesquelles sont tout au plus Nit. Vous pouvez également faire l'inverse, par exemple en traitant toute violation de `CLAUDE.md` comme Important.
* **Trop de nits** : plafonnez le nombre de commentaires 🟡 Nit publiés par une même revue. Un plafond comme « signaler au maximum cinq nits » permet de garder des revues exploitables.
* **Commentaires sur des fichiers générés ou sur ce que la CI vérifie déjà** : listez les chemins et les catégories de résultats pour lesquels Claude doit s'abstenir de signaler quoi que ce soit. Les candidats courants sont le code généré, les fichiers de verrouillage et les dépendances vendorisées, ainsi que tout ce que votre CI applique déjà, comme le linting ou la vérification orthographique. Pour les chemins qui méritent une certaine revue sans examen complet, fixez plutôt un seuil plus élevé : « dans `scripts/`, ne signaler que si c'est quasi certain et grave. »
* **Une règle d'équipe n'est pas vérifiée** : ajoutez les règles que vous souhaitez voir signalées sur chaque pull request, comme « les nouvelles routes d'API doivent avoir un test d'intégration. »
* **Des résultats s'avèrent erronés** : exigez des preuves avant qu'une catégorie de résultats soit publiée. Par exemple, « les affirmations sur le comportement nécessitent une citation `file:line` dans le source, et non une déduction à partir du nommage » réduit les faux positifs qui coûteraient sinon un aller-retour à l'auteur.

Certaines de ces instructions [nécessitent que le fichier racine se trouve sur une branche par défaut protégée](#which-branch-review-md-is-read-from).

Limitez `REVIEW.md` aux instructions qui modifient le comportement de la revue, et laissez le contexte général du projet dans `CLAUDE.md`.

<h3 id="which-branch-review-md-is-read-from">
  Depuis quelle branche REVIEW\.md est lu
</h3>

Code Review lit `REVIEW.md` depuis la branche de base de la pull request ou depuis la branche par défaut, jamais depuis les modifications de la pull request elle-même. Pour modifier le comportement de la revue, fusionnez d'abord la modification de `REVIEW.md`.

Conservez `REVIEW.md` sur votre branche par défaut et protégez cette branche. Lorsqu'une revue lit la copie présente sur une branche par défaut protégée, soit la première ligne du tableau ci-dessous, elle respecte ces instructions du fichier racine :

* Abaisser la sévérité d'un résultat
* Exclure des chemins, des fichiers ou des catégories de problèmes
* Plafonner les commentaires de type nit

<h4 id="what-counts-as-branch-protection">
  Ce qui compte comme protection de branche
</h4>

Code Review considère ces paramètres comme une protection :

* **Branche par défaut** : une règle de protection de branche classique ou un ruleset
* **Toute autre branche** : un ruleset uniquement

Un ruleset compte lorsqu'il restreint les mises à jour ou exige des pull requests avec au moins une approbation. S'il exige des pull requests, il doit également révoquer cette approbation lors d'un nouveau push ou exiger que l'approbation intervienne après le dernier push.

<h4 id="what-a-review-reads-for-each-branch-setup">
  Ce qu'une revue lit selon la configuration des branches
</h4>

Trouvez la situation de votre dépôt dans la première colonne du tableau ci-dessous.

| Protection de branche | Copie lue | Fichiers lus |
| :- | :- | :- |
| La branche par défaut est protégée, et la pull request la cible ou cible une branche qu'aucun ruleset ne protège | Branche par défaut | Fichiers racine et de sous-répertoire |
| La pull request cible une autre branche protégée par un ruleset | Cette branche de base | Fichiers racine et de sous-répertoire |
| La branche par défaut n'est pas protégée, et la branche de base n'a aucune règle de protection, quel qu'en soit le type | Branche par défaut | Fichier racine |
| Code Review ne peut pas confirmer les paramètres de protection. Cela inclut une branche par défaut non protégée avec une branche de base qui n'a qu'une règle classique | Aucune | Aucun |

Si le check run mentionne `REVIEW.md`, consultez [Le check run mentionne REVIEW.md](/docs/fr/code-review-troubleshooting#the-check-run-mentions-review-md).

<h2 id="related-resources">
  Ressources associées
</h2>

* [Code Review](/docs/fr/code-review) : ce qu'est le service et comment se déroule une revue
* [Lire et demander des revues sur une pull request](/docs/fr/code-review-pull-requests#severity-levels) : ce que signifie chaque niveau de sévérité et comment les résultats apparaissent
* [Configurer Code Review](/docs/fr/code-review-setup) : le niveau de revue et le moment où les revues s'exécutent, définis par un Owner
* [Effectuer une revue en local avec `/code-review`](/docs/fr/code-review-local) : la commande `/code-review`, ses arguments et ses niveaux d'effort
* [Mémoire](/docs/fr/memory) : comment les fichiers `CLAUDE.md` fonctionnent dans Claude Code