Déployer : l'IA dans la boucle de revue

Objectifs

À l’issue de cette leçon, vous serez capable de :

• Faire relire chaque pull request par Claude selon les politiques de l’organisation
• Recentrer l’attention humaine sur l’intention et le risque

Ce qui change

Traditionnellement, la capacité de revue se planifie sur la production humaine : une pull request attend qu’un relecteur la lise en entier, la qualité varie avec la charge du relecteur, et l’auteur relance pendant que la file s’allonge.

Dans un cycle AI-native, chaque pull request reçoit les mêmes passes de revue, avec des remarques classées par gravité. Claude relit les pull requests entrantes, et traite les commentaires de revue sur les siennes. L’attention humaine monte d’un niveau : le changement fait-il ce que le plan prévoyait, et le risque est-il acceptable ?

Pour démarrer

• Prérequis : un CLAUDE.md à jour, des skills si les passes 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, réservé aux offres Team et Enterprise avec des dépôts GitHub et activé par un Owner de l’organisation Claude, soit l’action claude-code-action dans votre propre CI, avec des appels de modèle via Amazon Bedrock, l’Agent Platform de Google Cloud (ex-Vertex AI) ou Microsoft Foundry si nécessaire. Des règles de protection de branche qui exigent l’approbation d’un responsable du code.

Mise en œuvre

1. Démarrez avec le service géré : un Owner l’active et choisit les dépôts. Passez par claude-code-action dans votre CI si vous avez besoin de maîtriser la chaîne, ou de faire passer les appels par votre propre contrat cloud.
2. Écrivez un REVIEW.md à la racine du dépôt, découpé en passes : bogues et erreurs de logique ; sécurité et vulnérabilités ; conformité à la spécification (spec.md), au plan (plan.md) et aux principes de conception. Il définit aussi ce qui est important par opposition à un détail, et ce qu’il faut ignorer (fichiers générés, ce que la CI vérifie déjà). Le service géré lit le REVIEW.md de la branche de base, jamais celui de la pull request relue : une PR ne peut pas assouplir ses propres consignes de revue.
3. Le responsable technique fixe le seuil humain : les remarques n’approuvent ni ne bloquent seules une pull request ; la protection de branche exige toujours l’approbation d’un responsable du code.
4. Fermez la boucle de correction : avec claude-code-action, mentionner @claude sur un commentaire de revue lui fait traiter la remarque et pousser le correctif ; avec le service géré, @claude review demande une nouvelle revue. Pour les pull requests ouvertes par Claude, allez plus loin : une commande personnalisée qui balaie les commentaires non résolus et les vérifications en échec, les traite et pousse les correctifs, jusqu’à ce que la PR soit au vert et n’attende plus que l’approbation humaine.
5. Faites apprendre la revue : quand une erreur est signalée pour la deuxième fois, la correction entre dans le CLAUDE.md ; la revue lit ce fichier, et l’erreur est attrapée dès la pull request suivante.

# Consignes de revue
## Passes
Trois passes ; étiquette chaque remarque avec sa passe :
- Bogues : erreurs de logique, cas limites, régressions subtiles
- Sécurité : injections, failles d'authentification, données sensibles dans les journaux
- Conformité : le changement respecte spec.md, plan.md et nos principes de conception
## Ce qu'« Important » veut dire ici
Réservé à ce qui casserait un comportement, ferait fuir des données ou enfreindrait une politique.
## Limiter les détails
Au plus cinq remarques de détail par revue ; résumer le reste par un nombre.
## Ne pas signaler
Les fichiers générés sous src/gen/ et tout ce que la CI vérifie déjà.

La valeur de la passe de conformité : une remarque comme « le panneau interroge l’API à chaque affichage, alors que plan.md exige un cache (l’ancien système limite à 50 requêtes par seconde) » vient d’un document qu’un relecteur regardant le seul diff n’aurait pas ouvert.

Gouvernance et mesure

Le REVIEW.md s’applique à toutes les pull requests ; remarques, correctifs, évaluations et approbations sont tracés dans l’historique de la PR, qui devient l’enregistrement d’audit. L’approbation reste humaine, par la protection de branche, éclairée par les remarques.

• Indicateur avancé : le délai avant la première revue, qui doit tomber à quelques minutes, et la part des commentaires résolus sans qu’un humain touche la branche.
• Indicateur retardé : les défauts et vulnérabilités attrapés avant fusion, rapportés à ceux découverts après.

À vous de jouer

Votre REVIEW.md. Écrivez un REVIEW.md en trois passes, une définition de ce qui est « important » chez vous et la liste de ce qu’il faut ignorer. Faites relire trois pull requests récentes avec ces consignes, par exemple avec /code-review en local, et comparez aux commentaires humains de l’époque : qu’a-t-on attrapé de plus, qu’a-t-on manqué, quelles remarques étaient du bruit ?

Sources officielles : AI in the PR review loop (Claude Academy) · The AI-native SDLC playbook — Stage 5: Deploy · Code Review · Claude Code GitHub Actions

Points clés à retenir

• Chaque pull request reçoit les mêmes passes de revue — bogues, sécurité, conformité au plan — classées par gravité
• REVIEW.md définit les passes, ce qui est important et ce qu’il faut ignorer
• L’approbation reste humaine, par la protection de branche ; l’attention humaine porte sur l’intention et le risque
• Une erreur signalée deux fois entre dans le CLAUDE.md