Guide d'utilisation de Codex CLI : modèles, pièges et jugement

Codex CLI est l'agent de codage natif en terminal publié par OpenAI. Il est fondamentalement différent des outils « interactifs » comme Claude Code ou Cursor — Codex vise une « autonomie sans surveillance de plusieurs heures ». Vous lui donnez une instruction, il peut lire le code, exécuter les tests et modifier les fichiers tout seul dans son sandbox, puis s'arrêter pour attendre votre revue.

Cet article ne couvre pas l'installation (la documentation officielle est très claire), mais uniquement quatre jugements clés.

I. Comment choisir le modèle

Principe : start cheap, scale up

Codex CLI prend en charge plusieurs modèles. D'après mes tests, la logique de sélection est la suivante : par défaut, on démarre avec gpt-5-mini, puis on passe au modèle complet lorsque la complexité de la tâche augmente. Ne lancez pas directement un gros modèle — pour beaucoup de tâches de base (ajout de commentaires, correction de lint, petits refactorings), le mini est largement suffisant et bien plus rapide.

Le cache permet de diviser les coûts par deux

Codex utilise automatiquement la mise en cache du prompt : tant que votre contexte de conversation ne change pas radicalement, les tokens touchant le cache coûtent environ 10 % du prix normal. Sur les longues tâches réelles, l'écart de coût entre avec et sans cache peut dépasser le double. Donc : n'ouvrez pas constamment de nouvelles sessions, essayez de terminer la tâche dans une seule session.

Le piège du format de sortie des petits modèles

Le modèle mini ne respecte parfois pas le protocole agent (par exemple, il se termine prématurément ou n'écrit pas de résumé final). Pas de panique : demandez-lui simplement de « continue ». Mais pour les refactorings complexes en plusieurs étapes, mieux vaut passer au grand modèle dès le départ, plutôt que d'essayer en boucle avec le petit modèle et gaspiller des tokens.

II. Comment éviter les pièges

Le sandbox est en lecture seule par défaut, n'oubliez pas d'approuver

Codex s'exécute dans un sandbox où le système de fichiers est en lecture seule par défaut. Lorsqu'il modifie un fichier, une demande de permission apparaît et vous devez l'approuver manuellement. Cela semble sûr, mais il y a un point contre-intuitif : seuls les changements de fichiers déclenchent une fenêtre ; l'exécution de commandes (y compris les opérations d'écriture) est autorisée par défaut.

Cela signifie qu'avant d'approuver, il faut bien réfléchir : superficiellement vous approuvez une écriture de fichier, mais avant cela, l'agent a peut-être exécuté des commandes arbitraires. Pour les scénarios à haut risque, l'inverse de --dangerously-bypass-approvals-and-sandbox est recommandé — c'est-à-dire garder le comportement par défaut et examiner strictement.

Ne mettez pas la configuration au mauvais niveau

L'ordre de recherche de la configuration de Codex est : niveau projet → niveau utilisateur → niveau global. Beaucoup de gens écrivent la configuration au mauvais endroit, ce qui cause des comportements anormaux dans certains projets (par exemple, le prompt ne s'applique pas, le modèle ne change pas). L'ordre de vérification :

1. codex.md à la racine du projet
2. ~/.codex/config.toml
3. config global

Rapports de suppression de fichiers sous Windows

Des utilisateurs Windows de la communauté ont signalé que Codex supprime parfois des fichiers — il s'agit de « modifications de mauvais fichiers » plutôt que de « suppression de répertoires entiers ». Aucune conclusion officielle pour l'instant, mais le contexte des rapports suggère un lien avec des mappages de sandbox non conformes, la casse des chemins ou la troncature des chemins longs. Si vous utilisez Windows : vérifiez git status immédiatement après chaque tâche, et ne lancez jamais de grosses tâches sur un espace de travail sans commits.

III. Comment enchaîner le workflow

Le processus recommandé en cinq étapes :

1. Plan d'abord

Dans la description de tâche donnée à Codex, la première ligne doit être : « Ne commence pas à agir, élabore un plan en t'appuyant sur la base de code, affiche le plan et attends confirmation ». Cette étape évite qu'il parte dans la mauvaise direction — c'est aussi le point de correction le moins coûteux.

2. Isolation avec Git worktree

Commencez par ouvrir un espace de travail avec git worktree add sur une branche propre, puis laissez Codex travailler dedans. Ainsi, même s'il casse le code, votre branche principale reste intacte.

3. Validation en cinq étapes

Après chaque tâche, passez les cinq contrôles dans l'ordre :

1. Revue de code : examinez git diff ligne par ligne, en particulier les lignes supprimées et l'ampleur des modifications
2. Compilation/syntaxe : type-check ou build
3. Tests unitaires : module ciblé
4. Régression : tests globaux des modules concernés
5. Smoke test manuel : si le comportement UI/CLI change, exécutez-le vous-même

4. Clôture après les retours

Si la revue donne lieu à des demandes de modification, collez-les une par une pour qu'il les corrige, plutôt que de dire vaguement « il y a des problèmes, corrige encore ». Codex exécute très bien les retours précis, mais tourne en rond sur les retours flous.

IV. Quand utiliser Codex

Choisissez l'outil selon la « nature de la tâche », pas selon la « taille du modèle ».

Adapté à Codex

• Tâches autonomes de longue durée : refactorings en masse, migrations, mises à jour de dépendances qui prennent des dizaines de minutes, voire des heures
• Tâches avec des critères d'acceptation clairs : vous pouvez écrire des conditions comme « après modification, tous les tests passent, le lint passe »
• Modifications à grande échelle dans un monorepo : changement d'interfaces ou de structures de données entre modules, sans validation manuelle une par une

Non adapté à Codex

• Décisions de conception nécessitant des interactions humaines fréquentes : choix d'architecture, conception d'API — Codex ne vous offre pas ce « sentiment de discussion »
• Refactorings lourds : renommages à grande échelle, extraction de modules — Claude Code a une meilleure compréhension
• Itérations front-end rapides : modifications de styles, ajustements de mise en page — Cursor offre un retour immédiat bien supérieur

Résumé

La valeur de Codex ne réside pas dans une « conversation plus intelligente », mais dans une « exécution fiable sans surveillance ». La bonne façon de l'utiliser : des critères d'acceptation clairs, un environnement isolé, une validation par étapes, et des retours précis. Si vous faites ces quatre choses, c'est l'outil de transformation en masse le plus puissant que vous avez ; sinon, ce n'est qu'un autre chat coûteux.