La compétence PR Review : comment nous vérifions chaque changement avant sa mise en ligne

Chaque fonctionnalité ou correction que nous livrons sur une application client passe d’abord par une révision. Nous l’appelons pr-review. Elle fait partie du système de révision que nous décrivons dans Comment nous révisons le code écrit par l’IA. Cet article explique cette vérification en détail : d’abord en mots simples pour les fondateurs, puis en détail pour les développeurs.

La version simple (pour les fondateurs)

Pensez à chaque changement dans votre application comme à une livraison. Avant de la mettre en tablette, quelqu’un ouvre la boîte et vérifie ce qu’il y a dedans.

La révision PR, c’est cette vérification. Elle ne regarde que ce qui a changé, donc elle est assez rapide pour tourner à chaque fois. Elle fait quatre choses :

1. Elle cherche les bugs. Le changement fait-il ce qu’il doit faire ? Que se passe-t-il avec un champ vide, un réseau lent, ou deux personnes qui cliquent en même temps ? A-t-il brisé quelque chose qui marchait avant ?

2. Elle compare le changement à nos règles. Nous tenons chaque application à 13 règles d’architecture. Par exemple : « un client ne peut modifier que ses propres données ». Un changement peut marcher aujourd’hui et quand même briser une règle qui vous coûtera cher plus tard.

3. Elle lance quelques vérifications ciblées. Les erreurs sont-elles signalées, ou cachées en silence ? Le nouveau comportement est-il testé ? Si la base de données a changé, sa conception tient-elle toujours ?

4. Elle donne une réponse claire. Prêt à mettre en ligne, pas prêt, ou prêt avec corrections. Les problèmes sont classés du plus grave au moins grave, chacun avec le fichier exact et la correction. Les tests manquants sont écrits, pas seulement listés.

Pourquoi c’est important : un bug attrapé avant la mise en ligne coûte quelques minutes. Le même bug trouvé par un client coûte sa confiance, et souvent des jours.

La version technique (pour les développeurs)

Portée

Le diff seulement. Par défaut, elle révise main...HEAD. S’il n’y a pas encore de commit, elle révise les changements indexés et non indexés. Pour un balayage de tout le code, utilisez plutôt la compétence de révision hebdomadaire.

Elle commence par lister les fichiers modifiés. Cette liste décide quelles passes conditionnelles s’exécutent.

Étape 1 : audits conditionnels

Source : sur mesure.

Ils s’exécutent seulement quand le diff les rend utiles :

• Audit du schéma. Migrations ou schema.dbml modifiés : contraintes manquantes, problèmes de normalisation, règles d’affaires absentes.
• Audit du modèle de domaine. Même déclencheur : frontières des agrégats, vocabulaire, logique qui fuit dans la mauvaise couche.
• Code mort et dérive. Fichiers supprimés ou renommés, ou dossier lib/ partagé touché : exports inutilisés, vieilles cales, ancien et nouveau chemin de code qui cohabitent.

Étape 2 : passe bugs

Source : adaptée de la compétence requesting-code-review de superpowers (MIT).

Un sous-agent neuf révise le diff : bugs, régressions, cas limites, comportements cassés, tests manquants. Il n’a aucune mémoire de la session qui a écrit le code, donc il révise ce qui est là, pas ce qui était voulu.

Étape 3 : passe architecture

Source : sur mesure.

Un deuxième sous-agent compare le diff aux 13 règles de Comment empêcher l’IA de transformer votre app Next.js en chaos architectural. Les routes ne font que coordonner. On valide à chaque frontière. Chaque UPDATE/DELETE porte un prédicat user_id. La lecture-puis-écriture se fait dans une transaction avec FOR UPDATE.

Les deux passes s’exécutent l’une après l’autre, jamais fusionnées dans une seule consigne. Un réviseur à qui on demande de tout trouver a tendance à trouver un problème et à s’arrêter.

Étape 4 : passes spécialisées

Source : sur mesure, sauf Simplification, qui est la commande intégrée /simplify de Claude Code.

En parallèle :

Passe	S’exécute quand	Cherche
Contrats d’erreur	Toujours	Blocs catch silencieux, échecs avalés, formats d’erreur incohérents
Lacunes de tests	Toujours	Comportements non testés, tests qui vérifient la mauvaise chose
TypeScript	Nouveaux types ou interfaces	Conversions dangereuses, types faibles, any aux frontières
Simplification	Toujours, en dernier	Duplication, réutilisation manquée, code qui peut être plus simple

Étape 5 : un seul rapport

Source : sur mesure.

Tout est fusionné dans code-review/{DATE}/full-review.md : constats bugs, constats architecture, constats spécialisés, puis une évaluation combinée.

Prêt à fusionner ? Oui | Non | Avec corrections

Critique   — tous les constats critiques de toutes les passes
Important  — tous les constats importants
Mineur     — tous les constats mineurs

Tendances  — le même problème vu plus d'une fois, avec une correction de fond

La section Tendances est celle qui compte le plus avec le temps. Si la même erreur apparaît à trois endroits, la correction est un changement de règle ou de liste de vérification, pas trois rustines séparées.

Étape 6 : correction des tests

Source : sur mesure.

Si la révision a trouvé des lacunes de tests, la compétence test-fix écrit les tests manquants. Sautée s’il n’y a aucune lacune et que tous les tests passent.

Étape 7 : court résumé

Source : sur mesure.

Vous recevez le verdict, les éléments critiques et importants, et les tests ajoutés. Le rapport complet reste dans le fichier.

Ce qui est sur mesure, ce qui est intégré, et pourquoi

Claude Code inclut sa propre commande /code-review. Alors pourquoi construire la nôtre ? Parce qu’une révision ne trouve que ce qu’elle sait chercher. Certaines vérifications sont les mêmes pour tous les projets. D’autres dépendent de nos règles et des erreurs que nous avons vu l’IA refaire encore et encore. Nous ne construisons pas sur mesure quand l’outil par défaut fait déjà le travail.

Partie	Source	Pourquoi
Passe simplification	Intégrée à Claude Code (/simplify), utilisée telle quelle	Repérer la duplication et la réutilisation manquée, c’est le même travail dans tous les projets. La version intégrée le fait bien et s’améliore à chaque version.
Passe bugs	Adaptée de la compétence requesting-code-review de superpowers (MIT)	La chasse aux bugs est surtout générique, et une bonne version ouverte existait déjà. Nous l’avons modifiée pour qu’elle tourne comme sous-agent neuf et alimente un seul rapport.
Passe architecture et les 13 règles	Sur mesure	Aucun réviseur général ne connaît vos règles. La révision intégrée ne signalera pas une route qui fait du travail de base de données, ni un UPDATE sans prédicat user_id, sauf si ça cause un bug évident.
Passes contrats d’erreur, lacunes de tests, TypeScript, schéma, modèle de domaine et code mort	Sur mesure	Chacune cible un défaut que nous trouvions sans cesse dans le code écrit par l’IA : erreurs avalées, tests qui vérifient la mauvaise chose, any aux frontières, contraintes manquantes, vieilles cales.
Correction des tests	Sur mesure	Les révisions générales listent les tests manquants. Celle-ci les écrit, donc la lacune est comblée avant la fusion.
Orchestration, rapport fusionné, verdict	Sur mesure	Quelle passe tourne quand, comment les constats sont fusionnés, et le verdict de fusion : c’est ce qui transforme des outils séparés en un seul processus.

Notre règle simple : utiliser l’outil par défaut quand le travail est le même pour tous les projets. Aller sur mesure quand la vérification dépend de vos règles ou d’un défaut qui revient sans cesse.

pr-review ou /code-review intégré de Claude

	/code-review	pr-review
Trouve les bugs	Oui	Oui
Vérifie vos règles d’architecture	Non	Oui, les 13
Spécialistes erreurs, tests et types	Non	Oui
Écrit les tests manquants	Non	Oui
Signale les erreurs qui se répètent	Non	Oui

Utilisez la commande intégrée pour une vérification rapide des bugs sur un petit changement. Utilisez pr-review avant de fusionner tout ce qui compte.

Quand un développeur senior prend le relais

pr-review fait le premier balayage, pas le dernier mot. Pour le code sensible côté sécurité (authentification, paiements, permissions, données personnelles, tout ce qui supprime ou déplace des données), un développeur senior de notre équipe lit le code à la main. Combien dépend de la sensibilité du code et de l’étape où en est l’application.

Étape	Ce qui est lu à la main
MVP	pr-review tourne à chaque changement. Les lectures à la main sont rares : la vitesse compte davantage, et une bonne partie de ce code sera peut-être jetée.
Avant le lancement	Un développeur senior lit tout le code sensible ligne par ligne avant l’arrivée des vrais utilisateurs.
En production, avec des revenus	Chaque changement au code sensible est lu par un développeur senior avant la fusion. Les autres changements passent par pr-review et des vérifications ponctuelles, selon leur importance.

Les outils trouvent les candidats. Un développeur senior lit le code et décide.

---

Obtenez le kit gratuitement

pr-review fait partie de notre plugin Claude Code gratuit, avec la révision hebdomadaire, les 13 règles, et toutes les vérifications qu’elles utilisent. Dans Claude Code, lancez :

/plugin marketplace add kbventures/ingenix-code-review
/plugin install code-review-kit@ingenix

Ensuite, lancez /code-review-kit:pr-review après votre prochain changement. Lisez la compétence elle-même sur GitHub (en anglais).

---

Vous voulez cette révision sur votre application ?

Si votre application a été construite vite avec l’IA et que les changements sont mis en ligne sans vraie vérification, nous installons la révision sur votre dépôt et vous expliquons le premier rapport : ce qui est cassé, ce qui est risqué, et les corrections qui comptent le plus.

Réserver un appel découverte gratuit