Réponse courte
Activez la revue de code de Codex pour un dépôt GitHub, puis laissez-le examiner automatiquement chaque demande de fusion quand elle est marquée comme prête, ou demandez une revue avec un commentaire comme « @codex review for security vulnerabilities ». Traitez ses commentaires comme ceux d’un second réviseur attentif, pas comme l’approbation.
Question de suivi Que doit encore vérifier un réviseur humain?
Une revue de code est l’étape où quelqu’un d’autre que l’auteur lit une modification proposée avant qu’elle rejoigne le code principal. Sur GitHub, cette modification arrive sous forme de demande de fusion (pull request, ou PR) : un ensemble de modifications accompagné d’une description de ce qu’elles sont censées faire. Les bonnes revues repèrent les bogues tôt, mais les revues approfondies prennent du temps, et les équipes occupées survolent souvent.
Le 15 septembre, OpenAI a lancé GPT-5-Codex, un GPT-5 entraîné davantage sur du vrai travail logiciel, et en a fait le modèle par défaut de la revue de code de Codex. OpenAI affirme que le modèle ne se contente pas de lire les lignes modifiées. Il compare la description de la PR avec les changements réels, parcourt le reste de la base de code à la recherche du code qui en dépend, et peut exécuter le code et ses tests dans un bac à sable pour voir ce qui se passe vraiment.
La configuration
Codex est inclus dans les forfaits payants de ChatGPT : Plus, Pro, Business, Edu et Enterprise. La revue de code s’exécute dans le nuage et se configure par Codex sur le Web, relié à votre compte GitHub.
- Branchez le dépôt. Dans Codex, liez votre compte GitHub et donnez-lui accès au dépôt à examiner.
- Activez la revue de code pour ce dépôt dans les paramètres de Codex.
- Choisissez comment les revues démarrent. Une fois la fonction activée, Codex examine automatiquement une PR quand elle passe de l’état de brouillon à « ready for review » (prête pour la revue) et publie ses constats sur la PR. Vous pouvez aussi demander une revue en tout temps en écrivant un commentaire qui mentionne
@codex review. - Ciblez la revue quand c’est utile. Ajoutez quelques mots après la mention pour dire quoi chercher :
@codex review for security vulnerabilities
@codex review for outdated dependencies
@codex review: does this change keep the public API backward compatible?
Si Codex suggère des changements, vous pouvez répondre dans le même fil et lui demander de les faire, puis examiner sa correction comme n’importe quelle autre modification.
Une demande de fusion concrète
Supposons qu’un coéquipier ouvre une PR intitulée « Apply member discount at checkout » (appliquer le rabais des membres au paiement). La description dit que les membres obtiennent 10 % de rabais sur les commandes de plus de 50 $ US. Le changement clé ressemble à ceci :
def order_total(items, is_member):
subtotal = sum(item.price * item.quantity for item in items)
if is_member and subtotal > 50:
subtotal = subtotal * 0.10
return round(subtotal, 2)
Un coup d’œil humain rapide pourrait le laisser passer : la condition est juste et le nombre 0.10 correspond à la description. Un commentaire de revue du genre que Codex est conçu pour produire signalerait le vrai problème. L’exemple ci-dessous est une illustration, pas une vraie réponse de Codex :
Bogue (gravité élevée) :
subtotal * 0.10fait payer aux membres 10 % du prix au lieu de leur accorder 10 % de rabais. La description de la PR dit que les membres obtiennent un rabais : il faudrait doncsubtotal * 0.90. Le test existanttest_member_totalne couvre pas les commandes de plus de 50 $ US, et c’est pourquoi il passe encore. Je suggère d’ajouter un test pour une commande de membre de 60 $ US (résultat attendu : 54,00 $ US).
Ce commentaire montre ce qui rend une revue automatisée utile : il relie le code à l’intention déclarée, explique pourquoi les tests n’ont pas repéré l’erreur et propose une vérification. OpenAI rapporte que, dans son évaluation sur des commits (validations) de projets populaires à code source ouvert, des ingénieurs d’expérience ont noté chaque commentaire de revue pour son exactitude et son importance, et ont trouvé les commentaires de GPT-5-Codex moins susceptibles d’être faux ou insignifiants. C’est important, car un réviseur qui signale trop de broutilles finit par être ignoré.
À essayer : dans un dépôt de test, ouvrez une petite PR qui contient un bogue volontaire, comme une erreur de décalage d’un dans une boucle, et décrivez le comportement voulu dans le texte de la PR. Commentez @codex review et voyez s’il trouve le bogue, comment il l’explique et s’il suggère un test.
Obtenir de meilleures revues
Rédigez une vraie description de PR. Codex vérifie le changement par rapport à ce que la PR dit qu’il devrait faire. « Fix stuff » ne lui donne rien à comparer; « Les membres obtiennent 10 % de rabais sur les commandes de plus de 50 $ US » lui donne une cible claire.
Gardez les consignes dans le dépôt. Codex lit AGENTS.md, un fichier texte de votre dépôt qui contient des consignes pour l’agent, et OpenAI affirme que GPT-5-Codex suit ces consignes de plus près que les modèles précédents. Des notes comme la façon de lancer les tests ou les dossiers qui contiennent du code généré l’aident à travailler comme un membre de votre équipe.
Gardez les PR petites. Un seul changement par PR permet à Codex comme aux personnes de mieux voir ce qui compte.
Connaissez le modèle de sécurité. Par défaut, Codex travaille dans un bac à sable isolé, avec l’accès au réseau désactivé, ce qui limite ce que le code examiné peut faire et réduit le risque que des consignes cachées dans le code orientent l’agent.
Que doit encore vérifier un réviseur humain?
Le conseil d’OpenAI elle-même est de traiter Codex comme un réviseur de plus dans l’équipe, jamais comme un substitut aux personnes. Codex est bon pour suivre la logique et lancer des tests; les personnes savent des choses qui ne sont pas écrites dans le code.
Un réviseur humain devrait encore vérifier :
- L’objectif. Est-ce seulement le bon changement? Règle-t-il le problème qu’ont vraiment les utilisateurs, et correspond-il aux décisions de produit prises dans des réunions et des documents que l’agent n’a jamais vus?
- La conception et la maintenabilité. L’équipe comprendra-t-elle ce code dans un an? S’inscrit-il dans la façon dont le système est censé évoluer?
- La sécurité en contexte. Qui peut atteindre ce code, quelles données y passent, et qu’essaierait un attaquant? Une revue automatisée peut signaler des tendances; une personne sait quels risques comptent pour ce produit.
- La revue elle-même. Lisez les commentaires de Codex d’un œil critique. Un commentaire assuré peut quand même être faux, et l’absence de commentaire ne prouve pas que le code est sûr.
- La décision finale. Approuver et fusionner devrait rester la responsabilité d’une personne, avec son nom au dossier.
Utilisé ainsi, Codex attrape davantage d’erreurs mécaniques avant qu’une personne regarde, et les réviseurs humains consacrent leur attention aux questions auxquelles eux seuls peuvent répondre.
Sources
- Introducing upgrades to Codex — OpenAI, 15 septembre 2025
- Addendum to GPT-5 system card: GPT-5-Codex — OpenAI, 15 septembre 2025
- Introducing 'GPT-5-Codex,' further improving GPT-5's coding capabilities and supporting work in editors and terminals — GIGAZINE, 16 septembre 2025