Codex : guide complet pour bien débuter en 2026

En 2026, Codex n’est plus seulement un outil qui propose quelques lignes de code pendant que vous écrivez.

C’est un agent capable d’ouvrir un projet, lire ses fichiers, rechercher une fonction, modifier plusieurs parties du code, lancer des commandes, exécuter des tests et présenter les changements réalisés.

Vous pouvez lui demander d’expliquer une application que vous découvrez, de corriger un bug ou d’ajouter une fonctionnalité. Codex peut ensuite travailler dans le terminal, dans votre éditeur, depuis une application de bureau ou dans un environnement cloud connecté à GitHub.

Cela ne veut pas dire qu’il faut lui confier tout un projet sans contrôle.

Codex travaille mieux lorsque la mission est précise, que les règles du projet sont écrites et qu’il dispose d’une manière de vérifier son résultat.

Dans ce guide, nous allons suivre un même projet : une petite application interne appelée SupportBoard. Elle permet à une équipe de consulter les demandes reçues par ses clients.

Notre objectif sera d’ajouter un filtre pour afficher uniquement les demandes urgentes.

Ce fil conducteur va nous permettre de voir comment installer Codex, préparer le projet, rédiger une demande, vérifier les changements et utiliser les fonctions plus avancées.

Codex en 2026, un agent de développement à encadrer

Codex est l’agent de développement proposé par OpenAI. Un assistant de discussion produit surtout une réponse. Codex peut aussi réaliser des actions dans un environnement de travail.

La documentation officielle Codex le présente comme un agent capable d’aider à écrire, comprendre, revoir, déboguer et automatiser du travail de développement logiciel.

Il peut notamment :

• parcourir les dossiers d’un projet ;
• lire plusieurs fichiers ;
• rechercher une fonction ou une variable ;
• modifier le code ;
• créer de nouveaux fichiers ;
• lancer les tests ;
• exécuter un build ;
• utiliser Git ;
• examiner un changement ;
• préparer une pull request ;
• travailler avec des outils externes autorisés.

Le fonctionnement repose sur une boucle. Codex reçoit une mission. Il rassemble le contexte dont il a besoin. Il choisit une action, observe le résultat puis décide de continuer ou de corriger son approche.

Imaginons que vous lui demandiez :

Pourquoi la liste des demandes clients ne respecte-t-elle plus l’ordre des dates ?

Codex peut rechercher le composant qui affiche la liste, retrouver la fonction de tri, vérifier le format des dates puis lancer un test. Il ne se limite donc pas à produire un morceau de code à copier.

Assistant de discussion	Codex
Répond à partir du contexte fourni	Explore directement le projet autorisé
Propose du code	Peut modifier les fichiers
Vous laisse exécuter les commandes	Peut lancer les commandes
Travaille sur une réponse	Travaille sur un objectif
Ne voit pas toujours le résultat	Peut lire les erreurs et recommencer
Attend le prochain message	Peut enchaîner plusieurs étapes

Codex reste un outil. Il ne connaît pas automatiquement les règles de votre entreprise, les habitudes de votre équipe ou les conséquences d’une mauvaise modification. Il faut lui transmettre ce contexte.

Les quatre interfaces pour travailler avec Codex

OpenAI propose plusieurs interfaces. Elles utilisent le même environnement Codex, mais elles ne répondent pas exactement au même besoin.

Interface	Utilisation adaptée	Particularité
Application Codex	Gérer plusieurs missions et projets	Threads parallèles, worktrees, Git et automatisations
Codex CLI	Travailler depuis le terminal	Accès direct aux commandes et aux fichiers
Extension IDE	Travailler à côté du code	Disponible dans plusieurs éditeurs
Codex Web	Déléguer une tâche dans le cloud	Connexion à GitHub et création de pull requests

L’application Codex

L’application de bureau est disponible sur macOS et Windows. Elle regroupe les projets dans une barre latérale et permet d’ouvrir plusieurs fils de travail. Chaque fil correspond à une mission.

Vous pouvez demander à un agent de corriger un bug pendant qu’un autre prépare des tests sur une branche isolée.

L’application dispose d’un panneau de revue pour examiner les différences, commenter une partie du code, conserver certains changements ou en annuler d’autres.

Elle intègre également les worktrees Git. Chaque agent peut ainsi travailler sur une copie isolée du dépôt sans modifier directement votre branche principale.

Codex CLI

Codex CLI fonctionne dans le terminal. Vous ouvrez le dossier du projet, lancez la commande codex, puis discutez avec l’agent.

Cette interface convient bien lorsque vous utilisez déjà le terminal pour lancer les tests, gérer Git ou démarrer l’application.

Codex CLI est disponible sur macOS, Windows et Linux. Il peut lire, modifier et exécuter le code présent dans le dossier sélectionné.

L’extension pour les éditeurs

L’extension Codex fonctionne dans Visual Studio Code, Cursor, Windsurf, Visual Studio Code Insiders et les IDE JetBrains.

Elle apparaît dans une barre latérale. Vous pouvez discuter avec Codex tout en regardant les fichiers concernés.

L’extension peut aussi utiliser le contexte de l’éditeur : le fichier ouvert, la sélection actuelle ou les éléments que vous êtes en train de consulter.

Codex Web

Codex Web se connecte à GitHub. Chaque tâche est lancée dans un environnement cloud configuré pour le dépôt.

Codex peut y lire le projet, exécuter les commandes prévues, modifier le code puis proposer une pull request.

Cette approche convient aux missions que vous souhaitez déléguer sans garder une session locale ouverte. Vous pouvez suivre les journaux d’exécution, examiner les changements puis récupérer le résultat dans GitHub ou dans votre environnement local.

Choisir la bonne interface pour commencer

Pour une première utilisation, l’application Codex ou l’extension IDE est souvent plus agréable. Vous voyez le code, les messages et les différences dans une même interface.

Le terminal convient très bien si vous êtes déjà à l’aise avec les commandes du projet.

Codex Web devient intéressant lorsque votre dépôt se trouve sur GitHub et que vous souhaitez déléguer des tâches plus longues.

Vous n’êtes pas obligé de choisir une seule interface. La configuration, les instructions et certaines compétences peuvent être partagées entre l’application, le terminal et l’extension IDE.

Un même projet peut donc commencer dans l’éditeur puis continuer dans l’application Codex.

Installer Codex selon votre environnement

L’installation dépend de l’interface choisie. Pour commencer simplement, installez l’application Codex ou l’extension IDE. Si votre équipe travaille beaucoup dans le terminal, Codex CLI reste une bonne porte d’entrée.

Installer l’application de bureau

L’application Codex peut être téléchargée sur macOS ou Windows.

Sur Windows, elle peut aussi être installée depuis le terminal avec la commande suivante :

winget install Codex -s msstore

L’application Windows peut utiliser PowerShell directement ou fonctionner avec un projet présent dans WSL2. OpenAI recommande l’environnement natif pour la majorité des usages et WSL2 lorsque le projet dépend d’outils Linux.

Installer Codex CLI sur macOS ou Linux

Dans un terminal, lancez :

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Vous pouvez également utiliser npm :

npm install -g @openai/codex

Ou Homebrew sur macOS :

brew install --cask codex

Installer Codex CLI sur Windows

Dans PowerShell :

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

Après l’installation, placez-vous dans votre projet :

cd support-board

Puis lancez :

codex

Lors de la première ouverture, Codex vous demande de vous connecter avec votre compte ChatGPT ou avec une clé API.

Installer l’extension IDE

Dans Visual Studio Code ou un éditeur compatible, recherchez l’extension Codex.

Après l’installation, ouvrez le panneau Codex dans la barre latérale puis connectez votre compte.

L’extension démarre en mode agent. Elle peut donc lire les fichiers, exécuter des commandes et écrire dans le dossier du projet selon les autorisations définies.

Préparer SupportBoard avant la première demande

Avant de laisser Codex modifier SupportBoard, nous allons préparer un point de retour.

Vérifiez d’abord l’état du dépôt :

git status

Enregistrez les modifications importantes ou placez-les dans une autre branche.

Vous pouvez ensuite créer une branche pour notre fonctionnalité :

git switch -c feature/urgent-filter

L’objectif est de pouvoir comparer le travail de Codex et revenir en arrière sans perdre vos propres changements.

OpenAI recommande d’utiliser des points de contrôle Git avant et après les tâches confiées à Codex.

Vérifiez ensuite que les commandes du projet fonctionnent.

npm install
npm test
npm run typecheck
npm run dev

Codex pourra réutiliser ces commandes plus tard.

Un agent devient beaucoup plus efficace lorsqu’il sait comment prouver que son travail fonctionne.

Première mission, comprendre le projet

Ne commencez pas par demander à Codex d’écrire du code. Demandez-lui d’abord de découvrir le projet.

Parcours ce projet sans modifier les fichiers. Explique-moi où démarre l’application, où sont récupérées les demandes clients, quel composant affiche la liste, comment les demandes urgentes sont identifiées et quelles commandes permettent de lancer les tests. Indique les fichiers concernés.

Cette demande remplit plusieurs objectifs. Elle vérifie que Codex peut lire le projet. Elle vous montre sa compréhension de l’architecture. Elle permet aussi de repérer une mauvaise interprétation avant la moindre modification.

Codex peut répondre que l’application utilise React, que les demandes sont récupérées dans src/api/tickets.ts, que la liste est affichée dans src/components/TicketList.tsx, que l’urgence est stockée dans le champ priority et que les tests utilisent Vitest.

Vous pouvez alors corriger son analyse si une règle métier manque.

La valeur “critical” doit aussi être considérée comme urgente. Le filtre ne doit pas modifier l’ordre actuel des demandes.

Cette précision paraît petite, mais elle évite une erreur dans la fonctionnalité finale.

Un plan clair avant toute modification

Notre objectif est d’ajouter un bouton permettant d’afficher uniquement les demandes urgentes.

Au lieu de demander directement “ajoute le filtre”, demandez un plan.

Prépare un plan pour ajouter un filtre “Demandes urgentes”. Une demande est urgente si sa priorité est “high” ou “critical”. Le filtre doit pouvoir être activé et désactivé. L’ordre actuel de la liste ne doit pas changer. Les autres filtres doivent continuer à fonctionner. Ajoute des tests. Ne modifie encore aucun fichier.

Codex peut alors proposer d’ajouter un état pour le filtre, d’ajouter un bouton dans la barre d’outils, d’appliquer le filtre avant l’affichage, de conserver la fonction de tri existante et de compléter les tests du composant.

Lisez ce plan. Vérifiez qu’il ne prévoit pas une nouvelle logique alors qu’une fonction existe déjà. Vérifiez aussi qu’il ne souhaite pas déplacer inutilement plusieurs composants.

Un bon plan n’a pas besoin d’être long. Il doit montrer que Codex a compris le résultat et les limites.

Laisser Codex appliquer la modification

Lorsque le plan vous convient, autorisez l’implémentation.

Applique ce plan. Réutilise les composants et les fonctions déjà présents. Évite de modifier les fichiers qui ne sont pas concernés. Pendant le travail, lance les tests du composant TicketList, ajoute les cas “high” et “critical”, puis vérifie que le filtre désactivé conserve le comportement actuel. À la fin, présente les fichiers modifiés et les commandes exécutées.

Codex peut maintenant ouvrir le composant, ajouter l’état du filtre, créer le bouton, adapter la liste affichée, écrire les tests, lancer Vitest, lire une éventuelle erreur, corriger le code et relancer les tests.

L’agent ne s’arrête pas forcément après sa première modification. Il peut observer l’échec d’un test et continuer jusqu’à obtenir un résultat cohérent.

C’est ici que Codex se distingue d’un générateur de code. Il travaille dans une boucle composée d’actions et de vérifications.

Relire le résultat avec la même exigence qu’une revue humaine

Même lorsque tous les tests passent, examinez les changements. Regardez le diff :

git diff

Dans l’application Codex, le panneau de revue permet d’ajouter des commentaires directement sur les lignes modifiées, de restaurer un bloc ou de conserver uniquement certains fichiers.

Posez ensuite quelques questions à Codex :

• Explique-moi pourquoi tu as placé le filtre dans ce composant.
• Cette modification peut-elle casser les autres filtres ?
• As-tu ajouté une nouvelle logique qui existe déjà ailleurs ?
• Qu’est-ce qui n’a pas pu être vérifié ?

Vous pouvez aussi lancer une revue séparée avec la commande :

/review

Dans Codex CLI, cette commande ouvre plusieurs types de revue. Vous pouvez examiner les changements non enregistrés, un commit précis ou les différences avec une branche de base.

La revue est réalisée par un agent séparé qui lit le diff sans modifier votre arborescence de travail.

Demandez-lui de se concentrer sur un point précis :

Vérifie surtout les risques de régression dans les filtres et l’accessibilité du nouveau bouton.

La structure d’une bonne demande

Vous n’avez pas besoin d’écrire un texte très long pour obtenir un bon résultat. Une demande utile contient cinq éléments.

Le résultat attendu. Dites ce qui doit fonctionner à la fin.

Le contexte. Expliquez les règles qui ne sont pas visibles dans le nom de la tâche.

Le périmètre. Indiquez où Codex peut intervenir.

Les limites. Précisez ce qui ne doit pas changer.

La preuve attendue. Expliquez comment vérifier le travail.

Voici la demande complète :

Ajoute un filtre permettant d’afficher uniquement les demandes urgentes. Une demande est urgente lorsque sa priorité vaut “high” ou “critical”. Travaille dans TicketList et ses tests. Ne modifie pas l’API et conserve l’ordre actuel de la liste. Ajoute les tests nécessaires, lance-les puis exécute le contrôle des types. Présente les fichiers modifiés et les éléments qui n’ont pas pu être vérifiés.

Demande vague	Demande plus utile
Corrige l’application	Reproduis le bug, identifie sa cause puis ajoute un test
Améliore ce composant	Réduis les répétitions sans modifier son interface publique
Ajoute des tests	Couvre les cas high, critical et filtre désactivé
Le site est lent	Mesure d’abord les étapes lentes avant toute modification
Refais cette page	Reproduis la maquette sans modifier les routes existantes

AGENTS.md, les règles permanentes du projet

Vous ne devriez pas répéter les mêmes consignes dans chaque message. Codex peut lire des fichiers AGENTS.md avant de commencer son travail. La documentation OpenAI sur AGENTS.md explique comment ces fichiers servent à décrire les commandes, conventions et règles du projet.

Pour SupportBoard, nous pouvons créer :

# SupportBoard

SupportBoard est une application interne utilisée par l'équipe de support.

## Commandes

- Installer : npm install
- Lancer : npm run dev
- Tests : npm test
- Types : npm run typecheck
- Format : npm run lint

## Règles

- Utiliser TypeScript.
- Ne pas ajouter de dépendance sans validation.
- Réutiliser les composants présents dans src/components.
- Ne pas modifier l'API publique sans le signaler.
- Une priorité high ou critical est urgente.

## Vérification

- Ajouter un test pour chaque correction de bug.
- Lancer les tests concernés après chaque modification.
- Lancer le contrôle des types avant de terminer.

## Git

- Ne pas pousser directement sur main.
- Ne pas créer de commit sans demande.

Le fichier doit contenir ce que Codex ne peut pas déduire facilement. Il ne sert pas à recopier toute la documentation du projet.

Vous pouvez aussi placer un fichier AGENTS.md dans un sous-dossier. Les consignes deviennent alors plus précises pour cette partie du projet.

Par exemple, un dossier consacré aux paiements peut imposer des contrôles supplémentaires.

Permissions et sécurité dans Codex

Codex peut exécuter des commandes. Il faut donc comprendre ses limites. En local, Codex utilise un bac à sable appliqué par le système d’exploitation. La documentation OpenAI sur le sandboxing Codex distingue clairement le périmètre technique du bac à sable et les demandes d’approbation.

Les deux contrôles ne jouent pas le même rôle :

• le bac à sable définit ce que Codex peut techniquement atteindre ;
• la politique d’approbation définit quand il doit vous demander votre accord.

Une commande comme un test local peut être exécutée dans le projet. Une commande qui veut accéder à Internet, écrire dans un autre dossier ou effectuer une action plus large peut demander une confirmation.

Vous pouvez examiner les permissions avec :

/permissions

Évitez de donner un accès total uniquement pour ne plus voir de demandes d’approbation.

Pour un premier projet, gardez les réglages par défaut. Autorisez ensuite uniquement les actions dont vous comprenez l’effet.

Soyez particulièrement prudent avec les suppressions de fichiers, les migrations de bases de données, les déploiements, les commandes exécutées avec des droits élevés, les actions sur un environnement de production et l’envoi de secrets vers un service externe.

Une commande locale ratée peut souvent être corrigée. Une suppression dans une base de production peut être beaucoup plus difficile à annuler.

Le choix du modèle selon la mission

En juin 2026, OpenAI recommande de commencer avec GPT-5.5 pour la majorité des missions dans Codex.

Ce modèle est destiné aux tâches de code complexes, à l’utilisation d’outils, à la recherche et aux workflows qui demandent plusieurs étapes.

Modèle	Utilisation
GPT-5.5	Missions complexes, recherche, débogage et travail long
GPT-5.4	Développement professionnel et usage d’outils
GPT-5.4 mini	Tâches plus courtes et consommation réduite
GPT-5.3-Codex-Spark	Itérations rapides, en aperçu pour les abonnés Pro

Vous pouvez changer de modèle avec :

/model

Il n’est pas toujours nécessaire d’utiliser le modèle le plus puissant.

Pour renommer plusieurs fichiers, ajouter un test proche de tests existants ou effectuer une transformation répétitive, GPT-5.4 mini peut suffire.

Pour comprendre un bug qui traverse l’interface, l’API et la base de données, GPT-5.5 sera généralement plus adapté.

Les anciens modèles GPT-5.2 et GPT-5.3-Codex sont indiqués comme obsolètes dans Codex avec une connexion ChatGPT.

Le coût de Codex en 2026

Les prix suivants sont ceux affichés par OpenAI au 21 juin 2026. Ils sont exprimés en dollars et peuvent varier selon le pays, la devise et les taxes. La page officielle de tarification Codex reste la source à vérifier avant une décision d’achat.

Formule	Prix affiché	Usage prévu
Free	0 $ par mois	Découverte et petites tâches
Go	8 $ par mois	Tâches légères
Plus	20 $ par mois	Sessions régulières
Pro 5x	100 $ par mois	Utilisation intensive
Pro 20x	200 $ par mois	Volume plus élevé
Business standard	20 $ par utilisateur en annuel ou 25 $ au mois	Équipe utilisant ChatGPT et Codex
Business Codex	Paiement à l’usage	Accès Codex sans accès complet à ChatGPT
API	Paiement selon les jetons	Scripts, CI et automatisations

Codex est actuellement inclus dans les plans Free, Go, Plus, Pro, Business, Edu et Enterprise, avec des limites différentes. Plus inclut un usage élargi de Codex. Pro propose des limites cinq ou vingt fois supérieures à celles de Plus selon la formule choisie.

Le nombre de messages n’est pas toujours fixe. La consommation dépend du modèle, de la taille du projet, de la quantité de contexte, de la durée de la mission et du nombre d’actions réalisées.

Une demande qui modifie deux lignes consomme moins qu’une mission qui parcourt tout un dépôt, lance plusieurs agents et exécute une longue série de tests.

Lorsque les limites incluses sont atteintes, les utilisateurs Plus et Pro éligibles peuvent acheter des crédits supplémentaires. Une clé API peut également être utilisée pour les tâches locales avec une facturation selon l’usage.

Certaines fonctions cloud, comme les revues GitHub intégrées, ne sont pas disponibles avec une connexion reposant uniquement sur une clé API.

Les fonctions avancées à découvrir ensuite

Les fonctions avancées deviennent utiles lorsqu’un même besoin revient souvent. Vous n’avez pas besoin de tout activer pendant la première semaine.

Les worktrees

Un worktree crée un espace Git séparé. Dans l’application Codex, plusieurs agents peuvent travailler sur le même dépôt sans modifier la même copie locale.

Vous pouvez confier le filtre urgent à un agent et les tests d’accessibilité à un autre. Chaque travail reste isolé jusqu’au moment où vous décidez de récupérer les changements.

Les skills

Une skill regroupe des instructions, des ressources et parfois des scripts.

Vous pouvez créer une skill décrivant la manière dont votre équipe traite un bug : reproduire le problème, écrire un test, rechercher la cause, appliquer une correction limitée, lancer les vérifications et préparer un résumé.

Codex peut ensuite réutiliser cette procédure dans l’application, le terminal ou l’extension IDE.

Une skill contient un fichier SKILL.md. Elle peut être appelée directement ou choisie automatiquement lorsque sa description correspond à la mission.

Les automatisations

L’application Codex permet de planifier des tâches récurrentes.

Vous pouvez créer une automatisation qui examine chaque matin les échecs de la CI, prépare un rapport ou recherche certaines erreurs.

Les résultats arrivent dans une file de revue. Vous pouvez alors reprendre le fil, demander une correction ou fermer la mission.

MCP

MCP permet de connecter Codex à des outils ou à des sources de contexte externes.

Vous pouvez lui donner un accès contrôlé à une documentation, un navigateur, Figma ou un outil de développement.

L’objectif est d’éviter les copier-coller entre plusieurs plateformes.

Un serveur MCP peut fonctionner localement ou être accessible à distance. Certaines connexions utilisent OAuth ou un jeton d’accès.

N’ajoutez pas un serveur uniquement parce qu’il paraît pratique. Chaque connexion donne à Codex de nouvelles informations ou de nouvelles actions. Vérifiez toujours le fournisseur, les autorisations et les données accessibles.

Les sous-agents

Codex peut lancer plusieurs agents spécialisés puis réunir leurs résultats.

Pour une grosse fonctionnalité, vous pouvez demander :

Utilise plusieurs agents pour analyser l’interface, examiner l’API, vérifier les tests et rechercher les risques de sécurité. Réunis ensuite les résultats dans un seul plan.

Les sous-agents sont utiles lorsque plusieurs recherches peuvent être réalisées en parallèle. Ils consomment toutefois plus de ressources, car chacun utilise son propre contexte et ses propres outils.

La revue dans GitHub

Codex peut examiner une pull request dans GitHub. Vous pouvez demander une revue avec une mention @codex review ou activer les revues automatiques pour un dépôt.

Codex lit le diff, suit les règles du dépôt et publie une revue centrée sur les problèmes importants. Cette revue complète le travail humain, mais elle ne remplace pas la validation finale d’un développeur.

Le suivi depuis le téléphone

Codex est également présent en aperçu dans l’application mobile ChatGPT.

Lorsque votre téléphone est relié à une machine qui exécute Codex, vous pouvez suivre les fils actifs, examiner les résultats, approuver une commande, changer de modèle ou répondre à une question.

Les fichiers et les identifiants restent sur la machine hôte. Le téléphone reçoit les mises à jour comme les différences, les tests et les demandes d’autorisation.

Les erreurs fréquentes avec Codex

Donner une mission trop large. Une demande comme “améliore toute l’application” laisse trop de choix à l’agent. Codex peut modifier l’architecture, déplacer des fichiers ou changer des comportements que vous souhaitiez conserver. Découpez le travail.

Accepter le premier résultat sans revue. Un test qui passe ne prouve pas que toute l’application fonctionne. Le test peut être incomplet. La modification peut aussi respecter la technique tout en violant une règle métier. Lisez le diff et vérifiez le comportement dans l’application.

Utiliser l’IA pour une règle déjà claire. Codex n’a pas besoin de décider si un montant dépasse 1 000 euros. Une condition classique suffit. Réservez le raisonnement de l’agent aux tâches qui demandent réellement de comprendre plusieurs fichiers, une erreur ou un contexte incomplet.

Ne pas définir de fin. Sans preuve attendue, Codex décide lui-même du moment où la mission est terminée. Ajoutez toujours une vérification : test, build, capture d’écran, commande, exemple d’entrée et de sortie ou comportement observable.

Mélanger plusieurs missions dans le même fil. Une conversation consacrée au filtre urgent ne devrait pas devenir ensuite une refonte du système de connexion. Ouvrez un nouveau fil pour une mission différente. Le contexte restera plus lisible et Codex aura moins de risques de réutiliser des hypothèses devenues inutiles.

Sécurité et confidentialité

Codex travaille directement avec votre code. Il faut donc vérifier les données présentes dans le dépôt.

Ne placez pas de mot de passe, de clé privée ou de jeton d’accès dans un fichier suivi par Git.

Pour Codex Cloud, OpenAI recommande d’activer l’authentification multifacteur, car le service peut interagir directement avec les dépôts connectés.

Sur les comptes personnels, les réglages liés à l’amélioration des modèles peuvent être modifiés. Codex dispose aussi de contrôles propres concernant le partage d’environnements complets. Ces réglages se trouvent dans les paramètres Codex et ne suivent pas forcément les réglages généraux de ChatGPT.

Pour les offres Business et Enterprise, OpenAI indique que les données professionnelles ne sont pas utilisées par défaut pour entraîner les modèles. Les offres Enterprise ajoutent des contrôles liés aux accès, à la conservation, à la résidence des données et aux journaux d’audit.

Une routine de travail simple

Voici une méthode que vous pouvez reprendre pour vos premières missions.

1. Préparer une branche propre. Vérifiez Git et enregistrez votre travail actuel.
2. Demander une exploration. Laissez Codex comprendre le projet sans modifier les fichiers.
3. Corriger son contexte. Ajoutez les règles métier ou les limites qu’il ne pouvait pas deviner.
4. Demander un plan. Vérifiez les fichiers, les étapes et les tests prévus.
5. Autoriser une modification limitée. Évitez les refontes inutiles et les changements hors périmètre.
6. Exiger une preuve. Demandez les tests, le contrôle des types ou le build adapté au projet.
7. Examiner le diff. Lisez les fichiers modifiés et demandez une revue séparée.
8. Tester vous-même. Ouvrez l’application et vérifiez le comportement réel.
9. Créer le commit. Conservez un historique clair une fois le travail validé.
10. Améliorer les instructions. Ajoutez dans AGENTS.md les règles qui devront être retenues lors des prochaines missions.

Le bon niveau d’attente en 2026

Codex apporte peu de valeur si vous lui demandez uniquement de générer une fonction isolée.

Son intérêt apparaît lorsqu’il peut suivre tout un parcours : comprendre le dépôt, retrouver les fichiers concernés, préparer un plan, modifier le code, lancer les commandes, lire les erreurs, ajuster la correction, examiner le diff et préparer le travail pour une revue humaine.

Pour une personne qui débute, Codex peut aider à comprendre l’organisation d’un projet. Il faut toutefois lire ses explications et ses modifications au lieu d’accepter chaque résultat.

Pour un développeur expérimenté, il peut accélérer les recherches, les tests, les refactorisations et les tâches répétitives.

Pour une équipe, son efficacité dépend beaucoup de la qualité du dépôt. Des commandes fiables, des tests utiles, un historique Git propre et un bon fichier AGENTS.md rendent l’agent plus précis.

Codex ne remplace pas la responsabilité du développeur. Il réduit surtout le temps passé à chercher, modifier, tester et préparer le travail.

En 2026, la meilleure manière de commencer reste de choisir une mission limitée.

Demandez à Codex de comprendre le projet. Faites-lui préparer un plan. Donnez-lui des limites claires. Exigez une preuve. Examinez ensuite le résultat comme vous le feriez avec le travail d’un collègue.

Une fois cette méthode maîtrisée, vous pourrez déléguer des tâches plus longues, utiliser plusieurs agents et automatiser certains contrôles sans perdre la maîtrise du projet.