Guide d’utilisation de Codex : démarrage, 5 tips, et best practices

Name

Soren Atelier

Mis à jour le 16/03/2026

Codex n’est pas seulement un outil d’autocomplétion. C’est un agent de coding qui peut lire un dépôt, modifier du code, exécuter des commandes et préparer une review exploitable. En pratique, "utiliser Codex" ne consiste pas à apprendre une installation, mais à savoir quoi déléguer à l’agent et où garder le contrôle humain.

La règle la plus utile pour bien démarrer est simple : commencez par des tâches petites et explicites. Une demande large et vague produit souvent des itérations coûteuses. Une demande cadrée par le périmètre, l’objectif et les critères de fin donne des résultats plus stables.

Si vous voulez replacer Codex dans le paysage global, commencez par le hub AI Coding et Best Vibe Coding Tools 2026. Pour une comparaison directe avec Claude Code, lisez aussi Codex vs Claude Code Skills.

Réponse rapide : la bonne façon d’utiliser Codex

La progression recommandée :

1. Commencer par CLI ou App, pas les deux en même temps.
2. Enchaîner 2 à 3 tâches courtes.
3. Formaliser les règles dans AGENTS.md.
4. Étendre ensuite vers skills et subagents.

Le choix de départ dépend de votre mode de travail : CLI pour aller vite, App pour la review et le parallélisme, extension IDE pour limiter les changements d’outillage.

Qu’est-ce que Codex, concrètement ?

Codex est l’agent de coding d’OpenAI. En CLI, il opère sur votre répertoire local (lecture, édition, commandes). Dans l’App, vous gagnez en plus la review de diff, la gestion de worktrees et les tâches en arrière-plan. L’extension IDE reprend cette expérience côté éditeur.

Le point clé : si vous l’utilisez uniquement comme "chat qui écrit du code", vous perdez une grande partie de sa valeur. Les usages qui fonctionnent le mieux sont :

• comprendre un codebase inconnu rapidement ;
• implémenter des changements ciblés ;
• investiguer un bug avec hypothèses reproductibles ;
• vérifier avec tests/lint/build après modification ;
• préparer et améliorer la review de diff ;
• industrialiser des tâches récurrentes via skills et automations.

Démarrer avec Codex

1. Lancer une première session en CLI

Le bootstrap minimal documenté côté OpenAI :

npm i -g @openai/codex
codex

Au premier lancement, connectez-vous via compte ChatGPT ou clé API. Évitez de lancer immédiatement une grosse demande. Le premier tour doit servir à étalonner l’agent sur votre repo.

Exemple :

Résume la structure de ce dépôt et les dossiers importants.
Ne modifie rien pour l’instant : phase d’analyse uniquement.

2. Deuxième tour : un changement très local

Ensuite, demandez une modification simple et facilement relisible.

Modifie uniquement le texte de ce composant.
Limite la modification à un seul fichier et résume le diff final.

Ici, l’objectif est de vérifier la précision d’exécution, pas de maximiser la portée.

3. Troisième tour : inclure la vérification

Codex devient vraiment utile quand vous bouclez jusqu’à validation.

Corrige cet échec de test.
Après correction, exécute uniquement les tests liés et fais un résumé en 3 lignes.

Le gain vient du cycle complet read -> plan -> edit -> test -> review, pas d’une génération isolée. Le contrôle humain au centre sert à n’accepter que les changements expliqués et vérifiés.

Utilisation de base au quotidien

Faites d’abord expliquer, puis modifier

Sur un repo existant, demandez d’abord la lecture de contexte.

Résume la responsabilité de ce module et ses dépendances.
Propose ensuite 2 options de changement minimal.
N’édite pas encore.

Cette étape réduit fortement les faux départs.

Donnez des critères de fin explicites

Plus la notion de "done" est claire, plus la sortie est stable.

Exemple flou :

Améliore cette page.

Exemple exploitable :

Raccourcis l’introduction de cette page.
Le premier écran doit répondre à "ce que c’est" et "pourquoi c’est utile".
Garde la structure H2 actuelle et n’ajoute pas de bloc de code.

Travaillez le diff avec une logique de review

Dans l’App, la review pane permet d’inspecter les changements Codex et les autres changements non commités, puis de filtrer proprement (staged/unstaged + commentaires ligne à ligne).

Si ce mode de travail vous intéresse, lisez aussi Parallel Code Agents pour le lien entre worktree, isolation et review.

5 tips pour mieux exploiter Codex

Tip 1 : demander un plan avant l’implémentation

Remplacez "implémente" par "propose d’abord un plan". Cela réduit beaucoup les allers-retours.

Donne d’abord un plan en 3 étapes.
Puis implémente.

Tip 2 : cadrer systématiquement périmètre et interdits

Même sur une tâche courte, précisez :

• ce qui est modifiable ;
• ce qui est attendu ;
• ce qui ne doit pas bouger.

Modifie uniquement `components/header.tsx`.
Objectif : réduire l’espacement de navigation.
N’ajoute pas de dépendance et ne touche pas à la logique.

Tip 3 : déplacer les règles persistantes vers AGENTS.md

Répéter les mêmes consignes à chaque prompt est coûteux. Les règles durables doivent vivre dans AGENTS.md.

Mettez au minimum :

• la structure du repo ;
• les commandes build/test/lint ;
• les conventions de code ;
• les attentes de PR/review ;
• la définition de "done".

La commande /init en CLI peut générer une base de AGENTS.md, à ajuster ensuite à vos standards réels.

Un bon découpage évite les instructions contradictoires : le prompt pour l’intention de la tâche, AGENTS.md pour les règles globales, skills pour les procédures réutilisables, automations pour le périodique.

Tip 4 : utiliser les subagents pour paralléliser l’analyse et la review

Point important pour Codex (au 16 mars 2026) : les subagent workflows sont activés par défaut et visibles en CLI comme dans l’App. Vous pouvez demander à l’agent principal de déléguer des angles d’analyse à plusieurs subagents spécialisés.

Bonnes cibles :

• exploration d’un gros codebase ;
• review PR multi-angles ;
• comparaison de plusieurs options ;
• planification technique en plusieurs volets.

Exemple :

Compare cette branche à main et fais une review.
Délègue séparément security, bugs, test flakiness et maintainability
à des subagents, puis fournis une synthèse unique.

Le pattern le plus efficace est : distribution par angle -> analyse parallèle -> synthèse unique relisible.

Points d’attention :

• pas de subagent sans demande explicite ;
• coût token plus élevé (chaque subagent utilise son propre contexte/outillage) ;
• une tâche trop couplée se parallélise mal.

Le principe reste le même : ne parallélisez que ce qui est réellement découplable.

Tip 5 : toujours boucler jusqu’à test ou review

Le vrai bénéfice de Codex apparaît quand vous allez jusqu’à la validation :

• exécuter les tests ciblés ;
• lancer /review avec un angle complémentaire.

L’App facilite ce cycle via les commentaires inline et le tri rapide des changements.

Best practices

1. Monter en complexité par paliers

Progression recommandée :

1. analyse seule ;
2. modification mono-fichier ;
3. bugfix court ;
4. correctif + tests ;
5. changement multi-fichiers ;
6. subagents / automation.

Ce séquencement révèle vite les manques de règles ou d’environnement.

2. Garder approvals et sandbox stricts au départ

Les recommandations OpenAI vont dans ce sens : commencez avec des permissions prudentes, élargissez ensuite selon vos besoins. C’est particulièrement important sur les repos partagés ou proches de la prod.

3. Mettre les règles stables dans la config, pas dans le prompt

Un prompt surchargé de règles permanentes noie la tâche. Placez les règles durables dans AGENTS.md, les procédures répétées dans des skills, et les actions récurrentes en automations.

4. Utiliser worktree si plusieurs threads touchent le même repo

Si vous faites tourner plusieurs threads en parallèle, worktree réduit les collisions et simplifie la review/merge. C’est utile notamment quand :

• un thread traite un bugfix pendant qu’un autre met à jour la docs ;
• une tâche de fond tourne pendant que vous gardez la main localement ;
• vous voulez tester un axe sans polluer votre environnement principal.

5. Sélectionner les changements, ne pas les accepter en bloc

Le bon usage n’est pas "tout accepter", mais "filtrer proprement" via stage/revert/commentaires inline. Traitez Codex comme un accélérateur de brouillon + vérification, pas comme un pilote automatique.

Recommandations par profil

Débutant

Commencez par l’explication et le diagnostic plutôt que par la génération complète :

• "Que fait cette fonction ?"
• "Pourquoi cette erreur ?"
• "Propose une correction minimale."

Développeur solo

Très bon fit pour enchaîner cadrage, implémentation, test et review dans une même boucle. Les subagents sont particulièrement utiles pour séparer exploration et revue critique.

Équipe

La performance dépend plus de AGENTS.md, de la discipline de review et de la gestion des worktrees/skills que de la qualité d’un prompt individuel.

Quand Codex est moins adapté

Si l’objectif est de "tout déléguer en automatique" avec un cadrage flou, les résultats seront instables. Codex marche mieux dans un cadre explicite, relu et vérifié.

FAQ

Codex est-il adapté aux débutants ?

Oui, surtout pour comprendre du code, structurer un diagnostic et corriger de petites erreurs avant de viser des tâches plus larges.

Faut-il commencer par CLI ou App ?

CLI si vous êtes terminal-first. App si vous priorisez la review de diff, la visibilité et le parallélisme. En cas de doute, commencez par CLI puis élargissez.

Quand faut-il utiliser les subagents ?

Quand la tâche est découpable par angles indépendants (sécurité, tests, maintenabilité, etc.). Évitez de forcer le découpage sur des changements très couplés.

Comment répartir AGENTS.md et les skills ?

AGENTS.md pour les règles globales du repo. Skills pour des procédures spécialisées et réutilisables.

Peut-on accepter directement les modifications de Codex ?

Non. Validez toujours par tests et review de diff avant adoption.

Related Guides

• Hub AI Coding
• Parallel Code Agents expliqués
• Construire un agent type Claude Code avec Claude Agent SDK
• Best Vibe Coding Tools 2026
• Codex vs Claude Code Skills