Codex pour la revue de code : faire relire vos PR par l'IA sans lui laisser tout modifier

Une PR de 800 lignes arrive avec un titre qui dit seulement fix, et une description réduite à “quelques corrections”. Vous regardez le diff sans savoir où se trouve le vrai risque, et vous n’avez pas envie de parcourir chaque fichier ligne par ligne. Quelqu’un écrit dans un commentaire de PR : @codex review for auth bypass and PII logging. Quelques minutes plus tard, un inline comment pointe vers logger.info(user.email).

Il faut alors décider : laisser Codex corriger, modifier le code vous-même, ou demander d’abord à l’équipe métier si cette ligne de log est conforme. Ce guide clarifie les conditions de déclenchement, l’écriture des Review guidelines, le sens de P0/P1, le flux de traitement et la frontière de confirmation humaine.

@codex review n’est pas une formule magique

@codex review n’est pas un interrupteur qui autorise l’IA à modifier le code. C’est une demande faite à Codex pour lire le diff de la PR et publier des review comments selon vos règles. Le déclenchement, le périmètre de vérification et la suite à donner aux résultats dépendent toujours de la configuration et du jugement humain.

Déclenchement et réglages GitHub Cloud

Pour utiliser Codex en code review, le repository doit être configuré avec Codex Cloud, et vous devez avoir accès aux code review settings. Deux déclencheurs existent : écrire @codex review dans un commentaire de PR, ou activer Automatic reviews dans les settings pour que Codex publie une review lorsqu’une nouvelle PR est opened for review.

Une fois déclenché, Codex lit le diff de la PR, suit la repository guidance, généralement les Review guidelines dans AGENTS.md, et publie des inline comments sous forme de revue GitHub standard. @codex review n’est pas une approval. Automatic reviews ne veut pas dire approbation automatique. Les changements sensibles, comme auth, payment ou data migration, demandent encore une confirmation humaine.

Vous pouvez combiner les déclencheurs de PR et les workflows CI avec des branch protection rules pour que l’AI review reste un contrôle parmi d’autres. Pour configurer les déclencheurs de PR, voir l’article précédent sur les déclencheurs PR GitHub Actions.

Se concentrer sur P0/P1, pas sur un journal de bord

Par défaut, Codex ne marque que les problèmes de priorité P0/P1. P0 correspond à un problème bloquant : security regressions, auth bypass, data loss. P1 correspond à un problème à corriger : performance, concurrency, logging sensitive data.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Ce focus évite l’explosion des review comments, maintient un signal élevé et réduit le bruit de faible valeur. Vous pouvez remplacer la règle par défaut dans la section Review guidelines d’AGENTS.md, par exemple en demandant à Codex de regarder uniquement auth bypass, PII logging et concurrency, sans commenter le code style, confié à Prettier, ni la minor performance hors hot path. La section suivante montre comment écrire ces Review guidelines.

Écrivez les Review guidelines dans AGENTS.md, pas dans chaque commentaire de PR

Les Review guidelines déterminent les priorités et le périmètre de Codex review. Elles doivent être écrites dans le fichier AGENTS.md du repository, pas répétées à chaque PR comment.

Lecture hiérarchique d’AGENTS.md et écriture des Review guidelines

Codex lit AGENTS.md avant de commencer. La lecture part du Git root et descend vers le répertoire de travail courant ; les instructions les plus proches sont les plus spécifiques. Par exemple, un AGENTS.md dans auth/ peut remplacer les règles globales et se concentrer seulement sur les risques liés à auth.

Une section Review guidelines typique :

## Review guidelines

Ne regarder que les risques suivants:
1. Security regressions(auth bypass、path traversal)
2. PII logging(user.email、phone number)
3. Concurrency issues(race condition、deadlock)

Ne pas regarder:
- Code style(automatisé avec Prettier)
- Minor performance(hors hot path)

L’avantage : toutes les PR partagent une même base de règles, vous évitez de les répéter en commentaire, et l’AGENTS.md proche des fichiers modifiés peut être plus précis.

À noter : la longueur des fichiers d’instructions est limitée par project_doc_max_bytes, à 32 KiB par défaut. Un fichier trop long peut être tronqué. La version complète d’AGENTS.md, avec Project rules, Review guidelines et Coding style, mérite un autre article de la série Codex. Ici, on se limite à la structure et à la priorité des Review guidelines.

Dans le Codex app review pane, regardez le diff avant de décider

Le review pane de Codex app ne montre pas seulement les suggestions de l’IA. Il reflète l’état complet du repository Git. Par défaut, il se concentre sur les uncommitted changes, mais vous pouvez aussi basculer vers all branch changes ou last turn changes.

Inline comments et PR context

Les inline comments du review pane sont attachés directement aux lignes du diff. Vous pouvez vous appuyer sur ces retours précis pour décider de la suite : demander un fix à Codex, corriger vous-même, ou marquer le finding comme false positive. Après /review, les résultats apparaissent sous forme d’inline comments dans le review pane.

Si Codex a accès à GitHub et que le projet courant est sur une PR branch, l’app peut afficher le PR context : reviewer feedback, changed files, PR description. Il faut pour cela installer et authentifier GitHub CLI avec gh auth login. Sinon, les PR details peuvent ne pas apparaître, et vous ne verrez que le diff local.

Contrôler la granularité : stage/revert par file ou hunk, pas tout le commit

Le review pane permet de stage, unstage ou revert à l’échelle du entire diff, du file ou du hunk. Évitez de revert tout un commit dès qu’un finding apparaît, surtout quand plusieurs fichiers sont concernés. Le travail par hunk permet de conserver les changements sûrs et de retirer seulement la partie risquée.

Traiter les review findings : après @codex fix, relire le diff, la CI et les tests

Quand Codex signale un P0/P1, ne confiez pas immédiatement tout à @codex fix. Il faut d’abord vérifier que le finding est réel, que la correction est raisonnable et que le changement ne touche pas une zone sensible demandant une validation d’équipe.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Tableau de triage des review findings

Un flux exécutable pour traiter les findings

Confirmer que le finding est réel : regardez la ligne du diff pointée par l’inline comment, puis vérifiez que le problème existe vraiment.

Définir la frontière de correction : auth, payment et data migration sont des changements sensibles, à valider humainement. style et minor perf peuvent souvent être ignorés ou confiés à la toolchain.

Choisir le mode de traitement :

• Laisser Codex corriger : écrivez @codex fix the P1 issue dans le commentaire de PR ; Codex démarre une cloud task à partir du PR context
• Corriger vous-même : modifiez le code à la main, testez localement, puis push
• Demander des tests : ouvrez une follow-up issue ou expliquez le besoin en commentaire
• Marquer un false positive : expliquez la raison en commentaire pour éviter les répétitions

Relire le diff et la CI : même si @codex fix a le droit de push sur la PR branch, vous devez vérifier le diff, le résultat CI et la couverture de tests. Un fix Codex n’est ni un merge automatique, ni une CI validée, ni une approval d’un reviewer humain.

Faire confirmer les changements sensibles : auth bypass, payment flow et data migration touchent des frontières de sécurité. Un reviewer de l’équipe doit valider. Ne sautez pas cette étape.

Ce qu’il ne faut pas faire

• Ne pas push/merge automatiquement : @codex fix demande à l’IA de modifier du code, ce n’est pas une permission de merge
• Ne pas sauter la CI : même si Codex corrige le problème, la CI doit encore vérifier que les autres tests ne cassent pas
• Ne pas ignorer les reviewers humains : l’AI review est une deuxième vérification, pas un remplacement du reviewer d’équipe
• Ne pas donner trop de droits à Codex : main branch push, force push et write access aux dossiers sensibles doivent rester limités

Les frontières de sécurité et de permissions pour les changements sensibles seront détaillées dans un prochain article de la série Codex sur les permissions et les secrets. Pour les bonnes pratiques CI, voir le guide précédent sur la pipeline CI GitHub Actions.

Commit message et PR description : laissez l’IA rédiger, mais pas inventer la norme

@codex generate commit message ou @codex generate PR description peut demander à Codex de rédiger à partir du diff et du PR context. Relisez le résultat, ne l’utilisez pas tel quel. Le commit message doit suivre Conventional Commits, pas un format improvisé.

Conventional Commits et modèle de commit message

Le format Conventional Commits est <type>[optional scope]: <description>. Les types fréquents : fix pour une version PATCH, feat pour une version MINOR, et un footer BREAKING CHANGE ou un ! pour un changement incompatible.

Exemple :

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

fix(auth): prevent bypass in login flow

- Add session validation before auth redirect
- Reject expired tokens within 5 minutes

Refs: #123

Pourquoi utiliser Conventional Commits : c’est un standard largement adopté. Des toolchains comme semantic-release, auto-changelog et commitlint s’appuient sur ce format pour générer des changelogs et déterminer les versions. Inventer sa propre convention casse ces automatisations et augmente le coût de collaboration.

Modèle de PR description

Une PR description doit contenir au moins cinq parties :

1. Contexte : pourquoi ce changement existe (retour utilisateur, problème de performance, risque de sécurité)
2. Périmètre du changement : quels modules sont touchés (auth, payment, logging)
3. Tests : scénarios vérifiés (tests locaux, couverture CI, vérification manuelle)
4. Risques : limites connues (concurrence, comportement sous forte charge)
5. Rollback : comment revenir vite en arrière (revert commit, feature flag, config toggle)

Après génération par Codex, vérifiez que ces cinq parties sont complètes, que la description est exacte et que les risques ou le rollback ne manquent pas. Ne commitez pas directement le texte généré, surtout sur les changements sensibles.

Pour générer commit message et PR description, vous pouvez écrire une instruction précise dans le PR comment, par exemple @codex generate commit message following Conventional Commits, afin que l’IA respecte le format standard.

Résumé

Codex review est une deuxième vérification à fort signal, pas une permission de merge. @codex review demande à l’IA de lire le diff et de publier des inline comments ; Automatic reviews automatise seulement l’étape de déclenchement, pas l’approval ni le merge.

Flux essentiel :

1. Dans les Review guidelines d’AGENTS.md, concentrez-vous sur 1 ou 2 risques, comme auth bypass, PII logging ou concurrency. N’essayez pas de tout couvrir
2. P0/P1 est le focus par défaut pour éviter l’explosion des review comments. P0 doit être corrigé ; P1 demande une décision de traitement
3. Après un finding, regardez la ligne du diff pointée par l’inline comment et confirmez que le problème est réel. Les changements sensibles, comme auth, payment ou data migration, demandent une confirmation humaine
4. Après @codex fix, vérifiez encore le diff, le résultat CI, la couverture de tests et l’avis humain. Ne push/mergez pas automatiquement, ne sautez pas la CI et n’ignorez pas les reviewers
5. Utilisez Conventional Commits pour les commit messages. N’inventez pas de format : la toolchain dépend du standard pour générer les changelogs et déterminer les versions

Actions concrètes :

• Ajoutez AGENTS.md à votre repository et rédigez une courte section Review guidelines centrée sur 1 ou 2 risques
• Essayez @codex review sur la prochaine PR et regardez si les inline comments respectent vos règles
• Pour les changements sensibles, lisez les prochains articles de la série Codex sur les permissions, les secrets et les postmortems avant de décider d’utiliser @codex fix

Articles liés

• Déclencheurs PR GitHub Actions : configurer les déclencheurs PR et les branch protection rules
• Bonnes pratiques CI avec GitHub Actions : contrôles CI et responsabilités des reviewers humains
• Comparatif des assistants de code IA : Claude Code vs Cursor vs Copilot : choisir un outil d’AI coding