Code review automatisé — Codex — Développement Assisté par IA

Leçon corrigée le 3 novembre 2026 d’après les pages Code review et Use Codex in GitHub de la documentation de Codex et l’aide du CLI 0.166.0 : la revue se déclenche par @codex review ou par la revue automatique activée dans les réglages, en local par codex review --uncommitted ou /review ; la section d’AGENTS.md s’intitule ## Code Review Rules. La commande d’extension « Codex: Review Changes » et l’adresse codex.openai.com sont retirées, et l’exemple de rapport est présenté comme une illustration. Sources : Code review · Use Codex in GitHub.

Améliorer la qualité du code avec des reviews IA

Dans la plupart des équipes, la revue de code est devenue le goulot d’étranglement du flux de livraison : les pull requests s’empilent parce que les relecteurs compétents sont eux-mêmes occupés à écrire du code. Codex ne remplace pas le relecteur humain, il prend en charge la première passe — celle qui consiste à repérer les oublis évidents, les écarts par rapport à l’architecture en place et les cas de figure jamais testés. Quand un développeur ouvre enfin la PR, il n’a plus à signaler qu’il manque un test sur le chemin d’erreur ; il consacre son attention aux décisions qui demandent un jugement métier.

Lancer une review sur une PR

Sur GitHub, le plus direct est de mentionner Codex dans un commentaire de la pull request : @codex review. Codex réagit (👀), puis publie sa revue dans la PR. Dans l’application de bureau, le module Code Review affiche la description de la PR, les fichiers modifiés, les commentaires et les vérifications, et vous permet d’interroger Codex sur le changement. Dans les deux cas, la qualité du rapport dépend de la précision de la demande : nommez les axes à couvrir.

"Review la PR #142. Vérifie :
- La cohérence avec l'architecture existante
- Les problèmes de sécurité potentiels
- La couverture de tests
- La qualité du code TypeScript
- Les edge cases non gérés"

Codex analyse le diff, mais il lit également le contexte des fichiers modifiés — pas uniquement les lignes changées — puis rend un rapport structuré. Voici, à titre d’illustration, le genre de rapport qu’on peut attendre sur une PR d’ajout de notifications :

## Review PR #142 — Ajout du système de notifications

### Sécurité
⚠️ src/api/routes/notifications.ts:34
  Le paramètre userId vient du body de la requête sans 
  vérification. Un utilisateur pourrait envoyer des 
  notifications au nom d'un autre. Utilisez req.user.id 
  du middleware d'authentification.

### Architecture
✅ Le service suit le même pattern que les autres services
⚠️ Le fichier notification.service.ts fait déjà 200 lignes.
  Considérez séparer les canaux (email, webhook) dans 
  des fichiers distincts.

### Tests
❌ Pas de test pour le cas où le service email est 
   indisponible (timeout/erreur réseau)
⚠️ Les tests mockent la DB mais pas le service email

### Code quality
💡 La fonction sendBatch pourrait utiliser Promise.allSettled 
   au lieu de Promise.all pour ne pas échouer si une 
   notification sur 50 échoue.

Observez la nature des remarques plus que leur mise en forme. La faille sur userId est exactement ce qu’un relecteur pressé laisse passer un vendredi soir : le code compile, les tests passent, et pourtant n’importe quel utilisateur peut écrire au nom d’un autre. La suggestion sur Promise.allSettled, elle, traduit une compréhension du comportement attendu — un envoi groupé ne doit pas capoter parce qu’une adresse sur cinquante rebondit — et non l’application mécanique d’une règle de style.

Cibler la review sur un domaine

Une review générale dilue l’attention sur cinq sujets à la fois. Quand vous préparez une mise en production sensible, demandez plutôt une passe spécialisée sur un périmètre restreint. Pour la sécurité, la formulation ressemble à ceci :

"Review de sécurité sur les fichiers modifiés dans 
src/api/ lors des 5 derniers commits. Cherche :
- Injections SQL
- XSS potentiels  
- Authentification manquante
- Données sensibles exposées
- Permissions non vérifiées"

Codex connaît les patterns de vulnérabilité courants et sait les reconnaître dans votre code, y compris lorsqu’ils sont dissimulés derrière une couche d’abstraction maison. Le même principe s’applique à la performance, à ceci près que l’on y traque des symptômes de nature très différente — non plus une faille, mais une requête exécutée cent fois là où une seule suffirait :

"Analyse les performances de src/services/report.service.ts.
Identifie :
- Les requêtes N+1 vers la base de données
- Les boucles qui pourraient être parallélisées
- Les données chargées mais non utilisées
- Les calculs qui pourraient être mis en cache"

Automatiser la review dans GitHub

Une fois la pratique installée dans l’équipe, rendez-la systématique plutôt que dépendante de la mémoire de chacun. La documentation de Codex décrit la configuration ainsi :

Connectez votre dépôt GitHub à Codex (il faut les droits push ou d’administration sur ses réglages).
Ouvrez les réglages de revue de code.
Choisissez le dépôt, puis activez Automatic review sous Review code.

Chacun peut aussi activer la revue automatique de ses propres PR dans ses préférences personnelles, et choisir quand elle se déclenche (Review trigger), sans avoir à écrire @codex review. Cette revue cloud n’exige pas de créer un environnement Codex Cloud. Les commentaires apparaissent directement dans la PR GitHub, au même endroit que ceux d’un relecteur humain — un détail qui conditionne l’adoption : une remarque qui oblige à ouvrir un autre outil ne sera lue par personne. La revue des merge requests GitLab existe aussi, en préversion.

Se relire avant d’ouvrir la PR

Le meilleur moment pour corriger un problème reste celui où personne d’autre ne l’a encore vu. Depuis l’IDE ou le CLI, une auto-review sur les changements non committés coûte quelques secondes et vous épargne un aller-retour complet de relecture :

# Depuis le CLI, sans interaction : relire les changements non committés
codex review --uncommitted

# Ou relire une branche par rapport à main
codex review --base main

Dans une session interactive, la commande /review fait la même chose sur votre arbre de travail ; dans l’application de bureau, Code Review propose aussi de relire les changements locaux.

Essayez sur votre prochaine branche avant de la pousser : vous constaterez que la moitié des remarques que vous receviez habituellement de vos collègues sont déjà traitées, et que la conversation en review démarre à un niveau plus intéressant.

Fixer vos standards dans AGENTS.md

Une review n’a de valeur que si elle applique les critères de votre équipe et non ceux d’un projet imaginaire. Codex cherche dans le dépôt les fichiers AGENTS.md et suit leurs règles de revue : ajoutez une section ## Code Review Rules au fichier le plus proche du code concerné, avec des sous-titres ### pour regrouper les vérifications.

## Code Review Rules

### API
- Toute route API doit vérifier l'authentification
- Les données utilisateur doivent être validées avec Zod
- Pas de any TypeScript (utiliser unknown + type guard)
- Les erreurs doivent être loguées avec le contexte
- Les fonctions > 50 lignes doivent être décomposées
- Les commentaires TODO doivent avoir un ticket associé

Codex appliquera ces standards à chaque review, avec une constance qu’aucun relecteur humain ne tient sur trois cents pull requests d’affilée.

Points clés à retenir

Codex effectue une première passe de review pour filtrer les problèmes évidents
Les reviews peuvent être spécialisées : sécurité, performance, architecture
L’intégration GitHub permet des reviews automatiques sur chaque PR
Utilisez la review avant de créer la PR pour gagner du temps
Documentez vos standards dans AGENTS.md pour une review cohérente