05 — Workflows GitHub — Codex — Le guide pratique

Ce que tu vas apprendre

Configurer Codex natif GitHub pour les revues et tâches PR
Revoir une PR avec une méthode : findings d’abord, compliments après
Répondre aux commentaires de review avec preuves
Traiter les échecs CI comme des problèmes de débogage
Publier des changements avec un résumé propre

Prérequis

Modules 01 à 04 maîtrisés
Un repo connecté à GitHub
Accès à Codex Cloud (pour les features GitHub-native)

La valeur de Codex se mesure dans la review, le triage CI et le shipping. Ces workflows demandent des preuves claires, un périmètre soigné et le bon contexte GitHub. Règle : review pour les bugs et risques d’abord. Pas de summary avant les findings.

Étapes

1. Configurer Codex dans GitHub

1. Connecter le repo à Codex Cloud
2. Activer Code review dans les paramètres Codex du repo
3. Activer Automatic reviews si chaque PR doit avoir une première passe
4. Ajouter un AGENTS.md avec les règles de review spécifiques au repo

Exemple de AGENTS.md pour guider la review :

## Review guidelines

- Traiter les commandes cassées et les chemins de fichiers incorrects dans la doc comme P1
- Vérifier que les workflows modifiés nomment toujours la bonne commande de validation
- Signaler les étapes de vérification manquantes comme un problème de correction

Place les guidelines générales à la racine du repo. Ajoute des AGENTS.md plus profonds seulement quand un sous-arbre a des risques différents du reste.

2. Revoir une PR

Ordre de review :

@diagram:steps
Comprendre la surface de changement
Chercher les régressions comportementales
Chercher les tests manquants
Chercher les hypothèses ambiguës ou non sûres
Résumer seulement après que les findings sont clairs

Checklist de review :

Le comportement changé est identifié en premier
Les bugs sont cherchés avant les problèmes de style
Les tests manquants ou assertions faibles sont signalés
Les hypothèses risquées sont vérifiées contre le code
Les fichiers sont cités quand on soulève un finding
Les résumés restent secondaires par rapport aux findings

Bons exemples de langage de review :

“src/auth.ts ligne 42 : la vérification de null est manquante”
“tests/auth.test.ts : aucun test pour le cas token expiré”
“Le changement de config/default.json casse l’environnement de staging”

Mauvais exemples :

“Bonne PR, quelques remarques”
“Ça a l’air bien dans l’ensemble”
Un résumé sans findings

3. Utiliser @codex dans GitHub

Bonnes utilisations :

Première passe de review directement dans le thread PR
Une tâche de suivi ciblée sur une PR ouverte
Une correction bornée pour un finding de review accepté
Un comportement de review spécifique au repo via AGENTS.md

Commandes disponibles :

@codex review
# Review générale de la PR

@codex review for security regressions
# Review ciblée sur un aspect

Template de tâche PR :

@codex corrige les échecs CI sur cette PR.

Périmètre :
- Reste dans les échecs de test et build déjà visibles sur cette PR
- Ne refactorise pas le code sans rapport

Vérification :
- Lance la commande échouante d'abord
- Relance la commande passante après correction

Retourne :
- Fichiers modifiés
- Cause racine
- Résultat de vérification
- Risques restants

4. Répondre aux commentaires de review

Traite les commentaires de review comme des inputs à évaluer, pas des instructions à obéir aveuglément.

Boucle de réponse forte :

Lire le commentaire attentivement
Confirmer la prétention technique
Implémenter la plus petite correction justifiée
Vérifier le résultat
Répondre avec ce qui a changé et ce qui a été validé

5. Corriger un échec CI

Un check qui échoue est un problème de débogage avec de meilleurs logs.

Séquence utile :

Identifier le job qui échoue
Lire la sortie de l’étape échouante
Reproduire localement si possible
Isoler la plus petite correction
Relancer la vérification la plus pertinente

À éviter :

Changer du code avant de comprendre l’échec
Grouper des nettoyages sans rapport dans la correction

6. Publier les changements

La publication doit être la fin d’un workflow vérifié, pas le début.

Avant de publier :

Confirmer que le diff est dans le périmètre
Confirmer que la vérification est complète
Écrire un résumé concis de ce qui a changé
Noter les risques restants

Template de résumé de PR :

## Résumé
- Changement 1
- Changement 2

## Validation
- Commande et résultat
- Commande et résultat

## Risques
- Limitation restante
- Élément de suivi

Vérification

Le repo est connecté à Codex Cloud
Les reviews automatiques sont activées si pertinent
Un AGENTS.md existe avec les règles de review du repo
La review commence par les findings, pas les compliments
Les commentaires de review sont traités avec preuves
Les échecs CI sont reproduits avant correction
Le résumé de PR inclut validation et risques

Pièges courants

Commencer par les résumés au lieu des findings → Les findings d’abord, le reste après
Utiliser Codex GitHub-native pour du travail dépendant de l’état local non commité → Garde le local pour ça
Deviner les échecs CI sans lire les logs → Les logs disent ce qui échoue, pas ton intuition
Publier avant que la vérification soit complète → Un résumé sans preuve = pas prêt à merger
Traiter une review Codex comme une approbation finale → Toujours valider par un humain
Demander “corrige ça” sans périmètre, exclusions et vérification → Le brief de tâche est obligatoire

Récapitulatif

Workflow	Commande / Action	Output
Review PR	`@codex review`	Findings ordonnés par sévérité
Tâche ciblée	`@codex [brief]`	Fichiers + cause + vérification
Fix CI	Lire logs → reproduire → corriger	Commit + re-run CI
Publier	`git push` + résumé	PR avec validation et risques

Pour aller plus loin

Inspiré du guide codex-howto de anup4khandelwal (MIT)