Refactoring et amélioration de code existant

Transformer du code legacy en code moderne

Le refactoring est l’une des tâches les plus chronophages du métier, et rarement la plus valorisée : personne ne vous félicite d’avoir découpé un fichier de 800 lignes. C’est exactement pour cette raison qu’il s’accumule, sprint après sprint, jusqu’à devenir la vraie cause de votre lenteur. Codex ramène des heures de travail manuel à quelques minutes tout en préservant le comportement existant — la seule chose qui compte vraiment dans un refactoring.

Refactoring de structure

Le cas le plus fréquent est le fichier fourre-tout que plus personne n’ose toucher parce qu’il est importé de partout.

"Refactore src/utils/helpers.ts : ce fichier fait 800 lignes. 
Sépare-le en modules thématiques dans src/utils/ (string.ts, 
date.ts, validation.ts, formatting.ts). Mets à jour tous les 
imports dans le projet."

Codex traite très bien cette famille de tâches : il identifie les fonctions, les regroupe par thème, crée les nouveaux fichiers, puis met à jour tous les imports du projet. C’est ce dernier point qui décourage habituellement l’entreprise manuelle — quarante fichiers à corriger, un oubli et le build casse au pire moment. Et le résultat est objectivement vérifiable : si les tests passaient avant et passent encore, le découpage est correct.

Modernisation de code

L’autre grand cas est la mise à jour vers des patterns modernes, où la transformation est mécanique mais si répétitive qu’on la remet toujours à plus tard.

"Migre tous les callbacks de src/lib/database.ts vers 
async/await. Conserve la gestion d'erreurs existante."

Le point de départ est du JavaScript à callbacks, avec sa gestion d’erreurs en cascade :

function getUser(id, callback) {
  db.query("SELECT * FROM users WHERE id = ?", [id], 
    (err, rows) => {
      if (err) return callback(err);
      callback(null, rows[0]);
    });
}

Voici ce que Codex en fait :

async function getUser(id: string): Promise<User> {
  const rows = await db.query(
    "SELECT * FROM users WHERE id = ?", 
    [id]
  );
  return rows[0];
}

Trois choses se sont produites en une seule passe : les types TypeScript sont apparus, les callbacks ont cédé la place à async/await, et la gestion d’erreurs s’est simplifiée puisque l’exception remonte désormais naturellement. La logique métier, elle, est identique — et c’est bien cela que vous vérifierez en revue, plutôt que l’élégance du résultat.

Amélioration de la qualité

Vous pouvez aussi viser une dimension de qualité précise plutôt qu’une transformation syntaxique, à condition d’énumérer les exigences.

"Dans src/api/, améliore la gestion d'erreurs :
- Remplace les try/catch génériques par des erreurs typées
- Ajoute des codes d'erreur HTTP appropriés
- Ajoute le logging avec le contexte de la requête
- Assure-toi que les erreurs Prisma sont mappées correctement"

Formulée ainsi, la demande devient vérifiable point par point en revue. « Améliore la gestion d’erreurs » livré seul aurait produit quelque chose de plausible et d’inutilisable, parce que ni vous ni l’agent n’auriez su dire à quel moment l’objectif était atteint.

Refactoring par pattern

La variante la plus puissante consiste à désigner un fichier déjà conforme et à demander la généralisation.

"Tous les composants React dans src/components/ qui utilisent 
useState pour des formulaires doivent être migrés vers 
react-hook-form. Applique le même pattern que 
src/components/LoginForm.tsx qui est déjà migré."

Codex lit le composant de référence, en extrait le pattern, puis l’applique aux composants concernés en traitant les cas particuliers — validation custom, effets de bord — au lieu d’opérer un remplacement aveugle. La conséquence pratique est intéressante : le premier composant, celui que vous migrez vous-même, paie pour tous les autres. Investissez du soin dans ce fichier modèle, il vaut une spécification.

Vérifier le refactoring

Codex exécute les tests après chaque refactoring, mais un refactoring qui passe les tests n’est pas pour autant livrable. Quatre vérifications forment le minimum, et chacune regarde un risque différent.

Le cas typique qui justifie cette liste : un déplacement de fichiers laisse les tests verts, parce qu’ils importent depuis un barrel file, mais casse le build de production sur un import circulaire que rien d’autre ne révèle. Ajoutez ces quatre commandes à votre AGENTS.md et Codex les exécutera après chaque modification, sans que vous ayez à y penser ni à les rappeler.

Points clés à retenir

• Le refactoring est la tâche où Codex apporte le plus de gain de temps
• Référencez un fichier modèle pour guider le pattern de refactoring
• Codex met à jour les imports et références dans tout le projet
• Vérifiez toujours avec les tests, le typage et le build après un refactoring
• Documentez les commandes de vérification dans AGENTS.md