L'IA dans la boucle de revue des PR

Claude donne et reçoit des revues. Il examine les PR entrantes par rapport aux politiques de l'organisation et répond aux commentaires de revue sur ses propres PR. Cela permet aux ingénieurs de se concentrer sur le comportement dans leur revue de PR, qui se résume à juger l'intention et le risque.

Ce qui change

Pour commencer

• Prérequis : un fichier CLAUDE.md mis à jour depuis l'étape 3 : Construction, des Skills, si les passes de revue doivent appliquer des politiques écrites, et des sous-agents définis.
• Infrastructure : un dépôt avec l'intégration Claude installée, soit le service géré Code Review activé par un propriétaire de votre organisation Claude, soit la claude-code-action exécutée dans votre propre CI, avec des appels de modèle via Amazon Bedrock, Vertex AI de Google Cloud, ou Microsoft Foundry si nécessaire (le guide CI/CD couvre les options de déploiement). Des politiques de protection de branche exigeant l'approbation d'un propriétaire de code sont également utiles.

Comment l'exécuter

1. Le service géré Code Review est le moyen le plus rapide de démarrer. Un propriétaire de votre organisation Claude l'active et sélectionne les dépôts. Exécutez la revue dans votre propre CI avec la claude-code-action lorsque vous avez besoin de contrôler le pipeline ou que vous souhaitez que les appels API soient acheminés via votre propre accord cloud (le guide CI/CD couvre cette tuyauterie).
2. Le tech lead rédige la politique de revue sous forme de REVIEW.md à la racine du dépôt, divisée en passes qui importent à l'organisation : bugs et erreurs logiques ; sécurité et vulnérabilités ; conformité par rapport à la spécification (spec.md issu du guide des exigences), au plan de mise en œuvre (plan.md issu du guide du mode plan), et aux principes de conception. REVIEW.md définit également ce qui compte comme Important par opposition à un Nit, et ce qu'il faut ignorer.
3. Le tech lead définit le seuil humain. Les constats n'approuvent ni ne bloquent une PR à eux seuls, et la protection de branche exige toujours l'approbation d'un propriétaire de code. Un ingénieur plateforme qui souhaite conditionner les fusions aux constats peut lire les décomptes de gravité que l'exécution de vérification publie sous forme de décompte lisible par machine.
4. Lorsqu'un relecteur ou l'auteur mentionne @claude sur un commentaire de revue, Claude traite le commentaire et pousse le correctif. Le fil de la PR enregistre à la fois la demande et la modification. Cette boucle de correction passe par la claude-code-action. Dans le service géré, commenter @claude review demande plutôt une nouvelle revue. Pour les PR ouvertes par Claude, allez plus loin et laissez Claude superviser la PR jusqu'à la fusion. Les équipes enveloppent la boucle dans une commande slash personnalisée qui parcourt les commentaires de revue non résolus et les vérifications en échec sur la PR, les traite, et pousse les correctifs, jusqu'à ce que la PR soit au vert et n'attende plus que l'approbation d'un propriétaire de code.
5. Les constats de revue alimentent en retour CLAUDE.md. Lorsqu'une revue signale une erreur pour la deuxième fois, la correction est intégrée à CLAUDE.md dans le cadre de cette revue, et comme la revue lit CLAUDE.md, l'erreur est détectée dès la PR suivante. La revue signale également lorsqu'un changement a rendu CLAUDE.md obsolète.
6. Une fois par mois, le tech lead ajuste la configuration en évaluant les constats afin que le relecteur s'améliore, et en plafonnant le volume de Nit dans REVIEW.md. Les chemins générés et tout ce que la CI applique déjà sont exclus.

À quoi cela ressemble

REVIEW.md :

# Review instructions
## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles
## What Important means here
Reserve Important for findings that would break behavior, leak data
or breach a policy. Style and naming are nits.
## Cap the nits
Report at most five nits per review; summarize the rest as a count.
## Do not report
Generated files under src/gen/ and anything CI already enforces.

Cet exemple correspond à ce que l'exécution de vérification répertorie pour une pull request qui ajoute un panneau de statut de sinistre au portail client d'un assureur, où claims-core est l'ancien système interne derrière le backend du portail :

Le premier constat n'existe que parce que la passe de conformité lit le plan.md validé, qu'un relecteur regardant uniquement le diff n'aurait pas ouvert.

Considérations de gouvernance

La séparation des tâches est préservée, car l'agent qui a écrit le code n'a aucun moyen de l'approuver. La politique de revue définie dans REVIEW.md s'applique à toutes les PR, et les constats, correctifs, évaluations et approbations sont consignés dans l'historique de la PR, de sorte que la PR constitue le registre d'audit. L'approbation provient d'un humain via la protection de branche, éclairée par les constats.

Comment le mesurer

• Indicateur avancé : le délai avant la première revue, qui devrait se réduire à quelques minutes, et la part des commentaires de revue résolus sans qu'un humain touche à la branche, avec des données stockées directement sur Git.
• Indicateur retardé : les défauts et vulnérabilités détectés avant la fusion, comparés à ceux qui échappent à la production, à partir de l'historique des PR et du suivi des incidents.