Le refactoring avec Codex : un plan, un objectif et une revue à chaque étape

Ce que Codex fait pour le refactoring

• Il avance dans un backlog de refactoring par petites étapes, chacune dans sa propre pull request.
• Il lance les tests avant et après chaque étape, et s’arrête quand ils échouent.
• Il fait la partie mécanique des migrations : renommages dans toute la base de code, mises à niveau d’API, passage à une nouvelle bibliothèque.
• Il supprime le code mort et la logique dupliquée, et explique chaque suppression.

Les fonctionnalités de Codex pour le refactoring

Comment configurer Codex pour le refactoring

1. Connectez les outils

   Il n’y a rien à connecter. Ce qui rend un refactoring sûr, c’est une commande de test que Codex peut lancer et une limite à la taille de chaque étape : mettez les deux dans AGENTS.md.

   # Dans la CLI : valider le plan, puis fixer la ligne d’arrivée
   /plan Propose un plan de migration pour le module billing
   /goal Termine la migration et garde les tests au vert

2. Écrivez les règles dans AGENTS.md

   Codex lit AGENTS.md avant tout travail : ~/.codex/AGENTS.md, puis les fichiers de la racine du dépôt jusqu’au dossier où il travaille. Mettez-y les règles de la tâche, ou dans une skill sous .agents/skills/ si elles sont longues. Voir le guide d’AGENTS.md.

   ## Règles de refactoring
   - Aucun changement de comportement. Si un test doit changer, arrête-toi et demande.
   - Lance `npm test` avant de commencer et après chaque étape.
   - Une étape par pull request, moins de 400 lignes modifiées.
   - Tiens REFACTOR.md à jour : coche ce qui est fait, ajoute ce
     que tu as trouvé.
   - Ne touche pas à migrations/, aux fichiers générés ni aux API
     publiques sans demander.

3. Lancez-le sans l’interface interactive

   codex exec exécute une tâche puis s’arrête. La progression part sur stderr et le message final sur stdout ; -o l’écrit aussi dans un fichier et --json diffuse les événements en flux. Le sandbox est en lecture seule sauf si vous passez --sandbox workspace-write.

   # Le premier jour, puis la même session le lendemain
   codex exec --sandbox workspace-write "Fais la première étape de REFACTOR.md"
   codex exec resume --last "Continue avec la prochaine étape non cochée de REFACTOR.md"

4. Planifiez-le

   Créez une tâche planifiée dans l’application de bureau ChatGPT ou sur le web (la CLI ne les gère pas), ou lancez codex exec depuis cron. Voir comment rendre Codex proactif.

Source : documentation de Codex

Limites et sécurité

• Sans tests, il ne peut pas distinguer un refactoring d’un changement de comportement. Ajoutez d’abord des tests sur la zone concernée.
• Une grosse réécriture d’un seul coup est difficile à relire. De petites étapes mergées une à une sont plus sûres, et au final plus rapides.
• Il ne sait pas quel code étrange est voulu. Signalez ces endroits par un commentaire ou dans les règles.
• Par défaut, Codex exécute les commandes dans un sandbox : les écritures restent dans l’espace de travail et le réseau est coupé. Réservez danger-full-access à un runner ou à un conteneur isolé.

Claude Code ou Codex pour le refactoring ?

Les règles se transposent. Écrivez-les une fois dans AGENTS.md et mettez @AGENTS.md dans CLAUDE.md : les deux agents lisent alors le même fichier.

Pas à pas pour l’autre agent : le refactoring avec Claude Code.

Confiez le refactoring à quelqu’un dont c’est le travail

Les commandes tournent quand quelqu’un pense à les lancer. Crewmark transforme votre propre Codex en employé IA doté d’un rôle, d’un objectif chiffré, d’horaires de travail et d’une pulsation : le travail se fait selon un planning et apparaît sur un tableau.

1. Partez du rôle

   Prenez l’ingénieur logiciel IA et mettez ces règles dans sa fiche de poste.

2. Mettez le travail sur son tableau

   Ajoutez la tâche comme ticket récurrent. L’employé se réveille au rythme de sa pulsation, l’accomplit et rend compte dans un commentaire.

3. À voir aussi

   La revue de code vérifie chaque étape avant son merge.

FAQ