Une production
NetDTL

DTLonCodex — Guide utilisateur

Guide pratique du logiciel OpenAI Codex

OutilDTLonCodex
TypeGuide utilisateur OpenAI Codex
LangueFrançais

OpenAI Codex — Guide utilisateur

Version de travail française, d'après la documentation officielle OpenAI Codex et la présentation documentaire DEC/VSI.

Préface

Ce guide explique comment se servir d'OpenAI Codex pour travailler sur du code, reviser des changements, automatisér des tâches et exploiter les surfaces App, CLI, IDE et Web.

Il suppose que l'utilisateur dispose d'un compte ou d'une clé API autorisée et que Codex est disponible dans son plan ou son organisation.

Public visé

Ce guide s'adresse aux utilisateurs qui veulent lancer Codex, choisir une surface, confier une tâche, examiner les changements et régler les principaux mécanismes de personnalisation et de sécurité.

Structure du document

Ce guide contient les chapitrès suivants :

  • Chapitre 1 : démarrage et choix de surface.
  • Chapitre 2 : utilisation de la Codex App.
  • Chapitre 3 : utilisation du CLI.
  • Chapitre 4 : utilisation de l'extension IDE.
  • Chapitre 5 : utilisation de Codex Web et Cloud.
  • Chapitre 6 : guider Codex.
  • Chapitre 7 : vérifier et finaliser le travail.
  • Chapitre 8 : personnaliser Codex.
  • Chapitre 9 : permissions, bac à sable et dépannage courant.
  • Chapitre 10 : scénarios courants.

Conventions

Les commandes sont données en chasse fixe. Les exemples doivent être adaptés au projet, au shell et aux règles locales. Les opérations qui modifient des fichiers, exécutent des commandes ou accèdent au réseau peuvent demander une approbation.

1. Démarrer

1.1 Choisir la surface à utilisér

Utilisez la Codex App lorsque vous voulez piloter plusieurs projets, gérer des fils en parallèle, travailler avec des worktrees, examiner des diffs et utilisér les fonctions intégrées de bureau.

Utilisez le CLI lorsque vous travaillez principalement dans un terminal ou que vous voulez automatisér des tâches.

Utilisez l'extension IDE lorsque vous voulez que Codex voie naturellement le contexte de l'éditeur et travaille au plus près des fichiers ouverts.

Utilisez Codex Web ou Cloud lorsque vous voulez déléguer un travail à un environnement distant configuré.

1.2 Préparer un projet

Avant de lancer une tâche :

  1. Ouvrez le dossier du projet.
  2. Vérifiez l'état Git.
  3. Notez les commandes de test ou de vérification importantes.
  4. Décrivez clairement le résultat attendu.
  5. Précisez les limites : fichiers à ne pas toucher, style à conserver, tests à exécuter.

Il est prudent de créer un point de contrôle Git avant une tâche qui peut modifier le code.

1.3 Rédiger une bonne demande

Une demande efficace contient l'objectif, le contexte utile, les contraintes, les fichiers ou zones concernées, le niveau de risque accepté et la vérification attendue.

Exemple :

Trouve pourquoi le test de paiement échoue et corrige uniquement la cause probable.
Lis d'abord les fichiers de test et de service de paiement.
Garde les changements minimaux et lance le test concerne.

2. Utiliser la Codex App

2.1 Installer et ouvrir

Installez l'application Codex pour macOS ou Windows depuis la page officielle. Ouvrez l'application, puis connectez-vous avec un compte ChatGPT ou une clé API OpenAI.

Certaines fonctions peuvent varier selon le mode d'authentification, le plan et les politiques d'organisation.

2.2 Sélectionner un projet

Dans l'application, ajoutez ou sélectionnez le dossier du projet. Un projet correspond à un codebase ou à une partie cohéremment bornée d'un codebase.

Si un dépôt contient plusieurs applications indépendantes, créez des projets distincts afin de garder un perimêtre de travail clair.

2.3 Choisir le mode du fil

Au lancement d'un fil, choisissez un mode :

  • Local : Codex travaille dans le dossier courant.
  • Worktree : Codex crée un worktree Git pour isoler les changements.
  • Cloud : Codex travaille dans un environnement distant configuré.

Choisissez Worktree pour essayer une idée, exécuter plusieurs tâches en parallèle ou protéger votre répertoire courant.

2.4 Envoyer une première demande

Dans le compositeur, décrivez la tâche. Pour un premier contact avec un projet, demandez une analyse :

Explique l'organisation de ce projet et indique les commandes utiles pour le tester.

Pour une modification ciblee :

Ajoute la validation manquante dans le formulaire d'inscription.
Respecte le style existant et lance les tests pertinents.

2.5 Suivre le travail

Pendant l'exécution, surveillez le plan propose, les fichiers lus, les commandes demandées, les changements produits, les messages d'erreur et les demandes d'approbation. Réorientez Codex si le travail sort du périmètre voulu.

2.6 Utiliser le terminal intégré

Chaque fil dispose d'un terminal associé au projet ou au worktree. Utilisez-le pour lancer des commandes de vérification :

git status
npm test
pnpm run lint

Codex peut lire la sortie du terminal lorsque la surface le permet. Vous pouvez donc lui demander d'analyser un échec de test déjà visible.

2.7 Examiner les différences Git

Ouvrez le panneau de diff pour voir les fichiers modifiés. Vérifiez que les bons fichiers ont changé, que les modifications sont minimales, que les tests ou preuves sont présents et qu'aucune donnée sensible n'a été ajoutée.

Ajoutez des commentaires inline si vous voulez que Codex corrige une ligne ou une section précise.

2.8 Commit, push et pull request

Lorsque les changements sont corrects, utilisez les fonctions Git intégrées ou le terminal pour préparer le commit.

Avant de pousser :

  1. Relisez le diff.
  2. Lancez les tests requis.
  3. Vérifiez le message de commit.
  4. Créez la pull request si le workflow du projet le demande.

2.9 Utiliser le navigateur intégré

Pour vérifier une application web locale :

  1. Démarrez le serveur de développement.
  2. Ouvrez la page dans le navigateur intégré.
  3. Inspectez le rendu.
  4. Ajoutez des commentaires sur les éléments visuels à corriger.
  5. Demandez à Codex d'appliquer les corrections.

Le navigateur intégré ne remplace pas un navigateur connecté à votre profil. Il n'est pas destiné aux flux d'authentification complexes.

2.10 Utiliser des images et artefacts

Glissez une image dans le prompt pour la fournir comme contexte. Pour des documents, feuilles de calcul, présentations ou PDF, indiquéz le type de fichier attendu, la structure, les critères de vérification et le chemin de sortie souhaité si nécessaire.

3. Utiliser le CLI

3.1 Lancer une session interactive

Depuis le répertoire du projet :

codex

Vous pouvez aussi fournir une demande initiale :

codex "Explique cette base de code"

Codex ouvre une interface terminale interactive qui peut lire le dépôt, proposer un plan, modifier des fichiers et exécuter des commandes selon les autorisations.

3.2 Interagir pendant une session

Pendant une session CLI, envoyez des prompts et extraits de code, examinez les plans et diffs, acceptez ou refusez les opérations contrôlees, utilisez les commandes slash disponibles et quittez la session lorsque le travail est termine.

3.3 Reprendre une session

Pour rouvrir une session récente :

codex résumé

Pour reprendre la dernière session du répertoire courant :

codex résumé --last

Pour afficher aussi les sessions d'autres répertoires :

codex résumé --all

La reprise conserve le transcript, l'historique de plan et le contexte utile de la session.

3.4 Lancer avec un modèle particuliér

Lorsque vous devez choisir explicitement un modèle :

codex --model gpt-5.5

Dans une session, utilisez la commande de changement de modèle fournie par l'interface.

3.5 Exécuter en mode non interactif

Pour des workflows automatisés, utilisez le mode non interactif lorsque disponible :

codex exec "Exécute les tests et résumé les échecs"

Le mode non interactif convient aux tâches bornées. Fournissez un prompt précis et configuréz les permissions avant de l'intégrer à une chaîne automatique.

3.6 Utiliser le mode distant

Un serveur d'application peut exposer une connexion WebSocket. Le cliént CLI peut s'y connecter avec une URL distante et une authentification configurée.

N'utilisez une connexion non chiffrée que pour localhost ou un tunnel de confiance. Pour une machine distante, prévoyez authentification et TLS selon les règles officielles.

4. Utiliser l'extension IDE

4.1 Installer l'extension

Installez l'extension Codex dans l'éditeur pris en charge. Ouvrez ensuite le panneau Codex depuis la barre latérale.

4.2 Se connecter

Connectez-vous avec votre compte ChatGPT ou une clé API OpenAI. L'extension démarre en mode agent par défaut lorsque la configuration l'autorise.

4.3 Travailler avec le contexte de l'éditeur

Ouvrez les fichiers pertinents avant de poser une question. Vous pouvez demander :

Explique le fichier ouvert et indique les fonctions à risque.

Où :

Corrige le problème dans la fonction sélectionnée sans modifier l'API publique.

4.4 Synchroniser avec la Codex App

Lorsque la Codex App et l'extension IDE sont ouvertes sur le même projet, elles peuvent synchroniser le contexte et les fils. Utilisez cette synchronisation pour alterner entre travail dans l'éditeur et revue plus large dans l'application.

5. Utiliser Codex Web et Cloud

5.1 Choisir une tâche cloud

Utilisez Cloud pour les tâches qui peuvent s'exécuter dans un environnement distant : analyse de dépôt, correction isolée, migration, génération de tests, revue ou tâche parallèle longue.

Évitez d'envoyer une tâche cloud lorsque le résultat dépend d'un fichier local non pousse, d'un secret local ou d'un outil indisponible dans l'environnement.

5.2 Configurer l'environnement

Avant de confier une tâche cloud, vérifiez l'accès au dépôt, les dépendances, les commandes de test, l'accès réseau, les variables et secrets autorises, ainsi que les politiques d'organisation.

5.3 Récupérer les résultats

Examinez le résumé, les fichiers modifiés, les logs et les tests exécutés. Ramenez les changements dans votre workflow Git selon les procédures du projet.

6. Guider Codex

6.1 Donner des instructions courtes et vérifiables

Préférez :

Ajoute un test pour le cas ou le montant est nul, puis corrige la validation si le test échoue.

Evitez les demandes trop larges sans critere :

Améliore tout le module.

6.2 Encadrer les changements

Indiquez clairement les fichiers autorises, les fichiers interdits, le niveau de refactorisation accepte, les tests obligatoires et le format de réponse attendu.

6.3 Demander une revue

Pour une revue de code :

Fais une revue de ce diff. Priorise les bugs, regressions, risques de sécurité et tests manquants.
Ne modifie pas les fichiers.

6.4 Demander une correction prudente

Pour une correction :

Trouve la cause la plus probable de l'échec et corrige-la avec le plus petit changement raisonnable.
Explique les fichiers modifiés et les tests lancés.

6.5 Fournir des preuves attendues

Ajoutez la vérification désirée :

Lance le test unitaire concerne et indique le résultat exact.
Si le test ne peut pas être lance, explique pourquoi.

7. Vérifier et finaliser

7.1 Lire le résumé

À la fin d'une tâche, vérifiez que le résumé répond à la demande initiale : objectif atteint, fichiers modifiés, tests lancés, limitations et suites possibles.

7.2 Contrôler le diff

Avant de valider :

git status
git diff

Assurez-vous qu'aucun fichier non lié n'est modifié.

7.3 Lancer les tests

Lancez les tests recommandes par Codex ou ceux du projet :

npm test
pnpm test
pytest
cargo test

Adaptez ces commandes à votre stack.

7.4 Demander une deuxième passe

Si un détail manque :

Le changement est bon, mais ajoute un test pour le cas limite X et relance uniquement ce test.

Si le résultat est trop large :

Reviens à une correction plus minimale. Garde uniquement les changements nécessaires au bug signale.

8. Personnaliser Codex

8.1 Ajouter un fichier AGENTS.md

Dans le dépôt, créez un fichier AGENTS.md pour les règles durables :

# Instructions pour Codex

- Utiliser pnpm, pas npm.
- Lancer `pnpm test` avant de proposer un commit.
- Ne pas modifier les fichiers générés dans `dist/`.
- Pour les composants React, suivre les patterns de `src/components`.

Placez un AGENTS.md plus spécifique dans un sous-répertoire si des règles différentes s'appliquent à cette zone.

8.2 Mettre à jour AGENTS.md après une erreur récurrente

Si Codex repete une mauvaise hypothèse, demandez-lui de formaliser la correction :

Ajoute dans AGENTS.md que les migrations de base de données doivent être créées avec l'outil interne, pas à la main.

8.3 Utiliser une skill

Utilisez une skill lorsqu'un workflow revient souvent : release, revue, génération de documentation, vérification de données ou création d'artefact.

Vous pouvez invoquer explicitement une skill si son nom est connu :

$nom_de_skill Prépare la note de version à partir du diff courant.

8.4 Configurer MCP

Utilisez MCP lorsque Codex doit accéder à des outils ou données externes : tickets, docs internes, bases de connaissances, dépôts, services de design ou autres systèmes d'équipe.

Dans la Codex App, ouvrez la section MCP des réglages pour activer un serveur recommandé ou ajouter une configuration.

8.5 Utiliser les hooks

Employez les hooks pour automatisér des contrôles autour des actions Codex, par exemple vérifier une politique avant une commande ou journaliser certains événements.

8.6 Utiliser les automations

Pour créer une tâche recurrente, décrivez la fréquence, le projet concerné, la demande, le résultat attendu et le canal de notification ou de résumé.

Exemple :

Crée une automation quotidienne qui vérifie les échecs de tests recents et produit un court rapport.

Utilisez une automation de fil lorsque la récurrence doit conserver le contexte de la conversation courante.

9. Permissions, bac à sable et dépannage

9.1 Comprendre les approbations

Lorsque Codex demande une approbation, lisez l'action demandee, les fichiers ou ressources concernes, la durée de l'autorisation et le niveau de risque.

Si vous hésitez, accordez la portée la plus étroite ou refusez et demandez une autre approche.

9.2 Comprendre le bac à sable

Le bac à sable limite l'accès de Codex. Si une commande échoue par manque d'accès, choisissez entre accorder une permission ciblee, déplacer les fichiers nécessaires dans le projet, demander une solution qui n'a pas besoin de cet accès ou ouvrir un projet plus adapte.

9.3 Gérer l'accès réseau

Si Codex doit vérifier une information récente ou installér une dépendance, il peut avoir besoin du réseau. Accordez l'accès seulement si la tâche le justifie et si la politique du projet l'autorise.

9.4 Quand Codex ne trouve pas les bons fichiers

Donnez une indication de routage :

Lis d'abord `src/payments/` et `tests/payments/`. Ignore `legacy/` sauf si nécessaire.

Si cette indication sera utile à long terme, ajoutez-la dans AGENTS.md.

9.5 Quand Codex propose trop de changements

Reformulez avec une contrainte explicite :

Reduis le changement au minimum nécessaire. Pas de refactorisation hors du fichier concerne.

9.6 Quand les tests échouent

Demandez une analyse bornée :

Analyse cet échec de test. Ne modifie rien avant d'avoir identifie la cause probable.

Puis, si la cause est claire :

Applique la correction minimale et relance ce test uniquement.

9.7 Quand utilisér une autre surface

Passez à l'IDE si le contexte principal est un fichier ouvert ou une sélection. Passez à la Codex App si vous devez gérer des fils, worktrees, diffs et artefacts. Passez au CLI si le travail est terminal-first ou scriptable. Passez au Cloud si la tâche doit être déléguée à distance.

10. Scénarios courants

10.1 Comprendre une base de code inconnue

Demandez d'abord une cartographie avant toute modification :

Explique l'organisation de ce projet. Identifie les modules principaux, les commandes de vérification et les fichiers à lire avant de modifier le code.
Ne modifie rien.

Si le projet est volumineux, bornez la recherche :

Concentre-toi sur le parcours d'authentification. Lis les fichiers pertinents et résume le flux de bout en bout.

Lorsque la synthèse est correcte, demandez à Codex de proposer une consigne durable :

Propose une section AGENTS.md courte pour aider les prochaines sessions à trouver les bons fichiers d'authentification.

10.2 Corriger un bug avec risque faible

Commencez par la reproduction :

Reproduis ou localise l'échec signale. Ne corrige rien avant d'avoir indique la cause probable et les fichiers concernés.

Puis demandez la correction :

Applique la correction minimale pour cette cause probable. Évite toute refactorisation non nécessaire. Lance le test le plus cible.

Terminez par une vérification :

Résumé le changement, le test lance et les risques restants.

10.3 Ajouter une petite fonctionnalité

Fournissez la définition de fini :

Ajoute le filtre "archives" à la liste des dossiers.
Le filtre doit être visible dans l'interface, persiste dans l'URL et couvert par un test.
Respecte les patterns existants.

Si Codex propose une architecture trop large :

Garde l'implementation locale à ce module. Ne crée pas de nouvelle abstraction sauf si elle existe déjà dans le projet.

10.4 Faire une revue de pull request

Dans une surface qui voit le diff, demandez :

Fais une revue de ce diff comme reviewer senior.
Liste d'abord les bugs ou régressions probables, avec fichier et ligne.
Mentionne ensuite les tests manquants.
Ne commente pas le style sauf s'il cache un risque.

Pour transformer la revue en corrections :

Corrige uniquement les points P1 et P2 de la revue. Laisse le reste intact.

10.5 Travailler sur une interface web

Démarrez le serveur local, puis demandez à Codex de vérifier :

Ouvre l'application locale dans le navigateur intégré, vérifie la page de connexion et corrige les problèmes visibles de mise en page.
Teste desktop et mobile si possible.

Ajoutez des commentaires dans le navigateur intégré si un élément visuel précis doit être corrige, puis demandez :

Traite les commentaires du navigateur et vérifie à nouveau le rendu.

10.6 Produire un document ou artefact

Donnez la forme attendue :

Crée un document Markdown de référence pour ce module.
Structure : preface, public visé, concepts, API, erreurs, exemples.
Ne documente que le comportement présent dans le code.

Pour un artefact bureautique :

Crée une présentation de 8 diapositives à partir de ces notes.
Ajoute une diapositive de synthese, une diapositive risques et une diapositive prochaines étapes.
Vérifie le rendu avant de me donner le fichier.

10.7 Mettre en place une automation

Décrivez la récurrence et le résultat attendu :

Crée une automation hebdomadaire pour ce projet.
Chaque lundi matin, elle doit vérifier les dépendances obsolètes, résumer les mises à jour importantes et ne modifier aucun fichier.

Pour un suivi dans le même fil :

Ajoute une automation de fil qui me relance toutes les 30 minutes tant que le deploiement n'est pas termine.

10.8 Ajouter une intégration externe

Lorsque l'information vit hors du dépôt, préférez MCP ou un plugin :

Configure ou utilise le connecteur approprie pour lire le ticket Linear lié à cette branche, puis résumé les criteres d'acceptation.

Si l'outil n'est pas disponible :

Indique quelle intégration manque, quelles permissions seraient nécessaires et quelle information je peux te fournir manuellement.

10.9 Nettoyer après une tâche

Avant de clore :

Vérifie l'état Git, liste les fichiers modifiés et indique les commandes de test exécutées.
Signale tout fichier non lié à la tâche.

Si les changements doivent être séparés :

Propose un decoupage en commits logiques. Ne stage rien sans confirmation.

10.10 Écrire une instruction durable

Après plusieurs corrections de trajectoire, demandez :

Transforme mes corrections récurrentes en instructions AGENTS.md courtes, sans dupliquer ce qui existe déjà.

Relisez la proposition avant de l'accepter. Les instructions durables doivent rester petites, spécifiques et utiles aux prochaînes sessions.

Sources

  • OpenAI Developers, Codex Overview, consulté le 12 juin 2026.
  • OpenAI Developers, Codex Quickstart, consulté le 12 juin 2026.
  • OpenAI Developers, Codex app features, consulté le 12 juin 2026.
  • OpenAI Developers, Codex CLI features, consulté le 12 juin 2026.
  • OpenAI Developers, Codex customization, consulté le 12 juin 2026.
  • OpenAI Developers, documentation Codex liée à sandboxing, configuration, MCP, skills et automatisation, consultée le 12 juin 2026.