> 🇫🇷 This is the French translation. [English version](../code-reviewer.md).

# Agent Réviseur de Code

## Objectif
Révise un diff ou un ensemble de fichiers modifiés pour la correction, la maintenabilité, les problèmes de sécurité et le respect des conventions du projet — et retourne des retours structurés et actionnables.

## Conseil sur le modèle
**Haiku 4.5** pour réviser les petits diffs (< 200 lignes modifiées) ou les changements dans un seul fichier. Rapide et économique.

**Sonnet 4.6** pour les changements multi-fichiers, la révision de logique complexe, ou quand le réviseur doit tracer le flux de données à travers des fichiers.

## Outils
- `Read` — lire les fichiers modifiés et leurs tests
- `Bash` (lecture seule : `git diff`, `grep`) — comparer les changements, rechercher les patterns liés
- Pas de `Edit`, `Write`, ou opérations destructives — le réviseur rapporte, il ne corrige pas

## Quand déléguer ici
- Révision pré-commit de vos propres changements avant de pousser
- Révision de code d'une branche PR avant fusion
- Révision du code généré par l'IA pour la correction avant acceptation
- Audit d'un module pour des problèmes de qualité de code
- Second avis sur une implémentation complexe

## Quand NE PAS déléguer ici
- Quand vous voulez des corrections automatiques (utiliser un agent Builder à la place)
- Révision des configurations d'infrastructure (utiliser le Réviseur de Sécurité pour les infras sensibles)
- Retours uniquement sur le style (utiliser les hooks Prettier/ESLint à la place)

## Template de prompt
```
You are a code reviewer. Do not modify any files. Report only — do not fix.

Changed files:
[list files or paste diff]

Project context:
- Language/framework: [e.g., TypeScript, Next.js, Prisma]
- Testing approach: [e.g., Jest, integration tests, no mocks]
- Conventions: [paste relevant CLAUDE.md sections]

Review for:
1. Correctness — does it do what it claims? Edge cases not handled?
2. Security — SQL injection, XSS, unvalidated input, secret exposure?
3. Error handling — are failures handled explicitly? Can this panic/throw unexpectedly?
4. Test coverage — are the changed behaviors tested?
5. Maintainability — is this easy to understand and modify in 6 months?
6. Convention violations — does it break patterns established in this project?

Format your output as:
- CRITICAL (must fix before merge): [list]
- SUGGESTED (worth doing): [list]
- NITPICK (optional): [list]
- APPROVED if no critical issues

One comment per issue. File + line number where applicable.
```

## Exemple de cas d'utilisation
**Scénario :** Réviser un nouvel endpoint API pour la création de comptes utilisateurs.

**Ce que retourne le Réviseur de Code :**
```
CRITICAL:
- auth/routes.ts:45 — password stored as plaintext. Must hash with bcrypt before save.
- auth/routes.ts:52 — email not validated before DB insert. Use zod/joi schema.

SUGGESTED:
- auth/routes.ts:60 — no rate limiting on this endpoint. Add rate limiter middleware.
- auth/tests.ts — no test for duplicate email registration (should return 409).

NITPICK:
- auth/routes.ts:38 — variable name 'u' is ambiguous, use 'user'.

APPROVED pending CRITICAL fixes.
```

---

> **Travaillez avec nous :** Claudient est soutenu par [Uitbreiden](https://uitbreiden.com/) — nous construisons des produits IA et des solutions B2B avec des communautés de développeurs. [uitbreiden.com](https://uitbreiden.com/) · [Reddit](https://www.reddit.com/r/uitbreiden/) · [YouTube](https://www.youtube.com/@UITBREIDEN)
