Code review automatisé

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

Depuis l’app web, sélectionnez le repository concerné puis formulez votre demande en nommant les axes à couvrir. La différence entre un rapport vague et un rapport exploitable tient presque entièrement à cette précision initiale.

"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 ce qu’il renvoie sur une PR d’ajout de notifications, dans un projet réel :

## 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 configuration depuis l’app web tient en quatre étapes :

1. Connectez votre repository sur codex.openai.com
2. Activez la review automatique dans les paramètres du repo
3. Chaque nouvelle PR reçoit un commentaire de review de Codex
4. L’équipe peut configurer les critères de review

Les commentaires apparaissent directement dans la PR GitHub, au même endroit que ceux d’un reviewer humain. Ce détail conditionne l’adoption : une remarque qui oblige à ouvrir un autre outil ne sera lue par personne.

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, reviewer les changements locaux
codex "Review mes changements non committés. Identifie 
les problèmes avant que je crée la PR."

# Ou depuis l'IDE
# Ctrl+Shift+P → "Codex: Review Changes"

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. Écrivez-les une fois pour toutes à l’endroit où Codex les lira à chaque tâche :

## Code Review Standards
- 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