Présentation
Codex est un agent de développement logiciel conçu par OpenAI. Plutôt que de se limiter à compléter une ligne dans un éditeur ou à produire du code dans une conversation, il peut examiner un dépôt, retrouver les fichiers concernés par une demande, effectuer des modifications coordonnées, lancer les outils du projet et présenter le résultat au développeur. Son intérêt apparaît surtout lorsque la tâche traverse plusieurs fichiers ou exige une succession d'actions : comprendre, intervenir, tester, corriger et vérifier ce qui a changé.
Le même agent est accessible par plusieurs interfaces. Codex CLI s'utilise depuis le terminal, l'extension IDE accompagne le travail dans l'éditeur et le mode Codex de l'application de bureau ChatGPT rassemble les projets et les sessions. Sur le Web, Codex Cloud peut exécuter des tâches dans des environnements distants associés à des dépôts. L'accès mobile sert notamment à consulter et piloter certaines tâches à distance ; il ne remplace pas un environnement de développement natif installé sur un téléphone.
Cette diversité répond à deux besoins distincts. Une intervention locale permet de travailler dans le répertoire du projet avec les outils déjà installés ; une tâche cloud peut être déléguée dans un environnement isolé, puis restituée sous forme de modifications à examiner. L'application de bureau propose en outre des worktrees Git, utiles pour isoler plusieurs travaux sans mélanger leurs changements dans la même copie du dépôt.
Local ne signifie pas IA hors ligne. Dans une session locale, les fichiers et commandes sont manipulés sur la machine du développeur, mais le modèle utilisé est généralement hébergé et du contexte du projet lui est transmis pour traiter la demande. Cette différence compte pour les dépôts privés, les secrets et les organisations soumises à des règles de traitement des données.
Codex est inclus dans les offres ChatGPT, y compris Free et Go, avec des limites qui varient selon la formule. Le CLI et l'extension IDE peuvent aussi être utilisés avec une clé API et une facturation séparée à la consommation. Enfin, le cœur CLI et le SDK sont open source sous licence Apache 2.0, mais cela ne rend pas libres les modèles, l'extension IDE ou le service cloud. Il faut distinguer l'ouverture des outils clients de celle de l'ensemble du produit.
Fonctionnalités
Comprendre un dépôt avant de toucher au code
Codex peut parcourir les fichiers et les répertoires, rechercher des symboles, consulter la configuration d'un projet et utiliser les commandes disponibles dans son environnement. Une demande comme « pourquoi cette route échoue-t-elle ? » peut l'amener à suivre le chemin entre une interface, une API et des tests plutôt qu'à proposer une correction sans avoir vu le code concerné.
Cette exploration débouche sur des interventions multi-fichiers : création d'une fonctionnalité, correction d'une régression, migration de dépendances, refactorisation ou mise à jour de tests. L'agent peut décrire son approche et adapter ses modifications après une erreur de compilation. Il reste toutefois dépendant de la qualité du contexte, des accès accordés et de la précision de la tâche. Une instruction trop large peut produire un diff beaucoup plus important que prévu.
La bonne unité de travail n'est donc pas « écris-moi un fichier », mais une modification vérifiable dans un projet existant. Le développeur garde la responsabilité de définir le périmètre et de vérifier que le comportement final répond réellement au besoin.
Terminal et IDE : travailler avec ses outils habituels
Codex CLI démarre depuis le répertoire d'un projet. Il peut y lire et modifier les fichiers autorisés, exécuter les commandes de compilation, lancer les tests ou consulter l'état Git. L'interface interactive permet de reprendre une session, de choisir les paramètres disponibles et de demander une revue des changements. Le mode non interactif codex exec sert, lui, aux scripts et aux pipelines automatisés.
L'extension IDE apporte le contexte de l'éditeur : fichiers ouverts, sélection de code, explications et modifications consultables à côté du travail en cours. Elle est documentée pour les environnements de la famille VS Code, ainsi que pour des intégrations comme JetBrains et Xcode. Les possibilités exactes diffèrent selon l'éditeur et l'intégration ; il ne faut pas supposer qu'un menu ou une fonction existe partout de la même façon.
Sur Windows, macOS et Linux, le CLI peut fonctionner directement dans l'environnement du projet. Sous Windows, une exécution native et des workflows WSL2 sont documentés. Le choix importe notamment pour les dépendances, les chemins de fichiers et les outils Linux dont dépend un dépôt.
Application de bureau, worktrees et tâches parallèles
Dans l'application de bureau ChatGPT, Codex permet d'ouvrir un projet et de choisir où exécuter une tâche : dans le répertoire local, dans un worktree Git isolé ou dans un environnement cloud configuré. La vue des différences et les commandes Git permettent ensuite d'examiner ce qui a été modifié, de conserver une partie du travail ou de l'annuler avant intégration.
Un worktree offre une séparation pratique lorsqu'il faut corriger un bug pendant qu'une autre tâche prépare une fonctionnalité. Chacun travaille dans sa propre copie liée au dépôt, sans écraser les fichiers non validés de la session principale. Cela ne dispense pas de gérer les conflits au moment de réunir les changements, mais évite de transformer une seule branche en chantier partagé entre plusieurs agents.
Le mode de bureau inclut également un terminal associé au projet. Il reste possible de lancer soi-même un test, d'examiner une sortie d'erreur ou de reprendre la main sur Git sans quitter le contexte de travail.
Codex Cloud : déléguer une tâche dans un environnement distant
Codex Cloud exécute les demandes dans des conteneurs isolés associés à un dépôt et à une branche ou un commit. L'environnement peut installer ses dépendances, lancer des scripts de configuration et fournir les outils nécessaires au travail. L'agent inspecte alors le code, apporte des modifications et tente de les vérifier avant de présenter une réponse et un diff.
L'intérêt est de lancer plusieurs tâches indépendantes en parallèle sans monopoliser l'ordinateur principal. Une correction, une mise à jour documentaire et un travail de test peuvent progresser dans des environnements distincts. Le résultat peut ensuite être examiné et, selon les intégrations et autorisations, transformé en pull request.
Le service doit néanmoins être configuré : accès au dépôt, dépendances, secrets éventuels et règles réseau ne sont pas automatiquement identiques à ceux de la machine locale. Pendant l'exécution de l'agent cloud, l'accès Internet est désactivé par défaut, sauf si l'environnement autorise explicitement une ouverture limitée ou plus large. Le code est traité dans une infrastructure distante, ce qui doit être pris en compte avant de connecter un dépôt sensible.
Tests, revue de code et opérations Git
Codex peut lancer les tests et outils déjà présents dans un projet, analyser leurs résultats et reprendre une modification lorsque les contrôles échouent. Il peut aussi demander ou produire une revue de code à partir d'un diff, d'une branche ou de changements non encore validés. Cette revue cherche des défauts potentiels ; elle ne modifie pas nécessairement les fichiers et peut être réalisée séparément de l'implémentation.
Avec un dépôt GitHub connecté à Codex Cloud, une revue peut être demandée depuis une pull request et, selon la configuration, déclenchée automatiquement. L'agent peut également traiter certains commentaires et proposer un correctif sur la branche autorisée. Les protections de branche, validations humaines et contrôles CI conservent leur rôle : une revue assistée par IA n'est ni une garantie de sécurité ni une preuve que tous les cas fonctionnels ont été couverts.
La valeur pratique vient de la boucle modification → contrôle → lecture du diff, plutôt que d'une promesse de code correct dès la première tentative. Les tests du projet restent la référence pour les règles vérifiables automatiquement.
Instructions AGENTS.md, skills et outils connectés
Un fichier AGENTS.md peut définir les conventions d'un dépôt : architecture, commandes à employer, règles de modification, formatage et contraintes propres au projet. Codex lit ces instructions avant de commencer une tâche et peut combiner des consignes globales avec celles d'un répertoire particulier. Cette mémoire de projet réduit la nécessité de répéter le même contexte, sans rendre les consignes textuelles infaillibles.
Les skills ajoutent des procédures et ressources réutilisables. Les plugins et serveurs MCP peuvent relier Codex à des outils ou services externes lorsque l'interface utilisée et les autorisations le permettent. Il devient ainsi possible de combiner une méthode de travail avec des ressources documentaires, des tickets ou des outils d'équipe sans intégrer toutes les instructions dans chaque demande.
Ces mécanismes ne remplissent pas le même rôle qu'un test automatique. Pour imposer réellement une contrainte de syntaxe, une politique de formatage ou une vérification de sécurité, il reste préférable de l'inscrire dans un validateur, un hook ou la CI. Une instruction AGENTS.md décrit ce qu'il faut faire ; un contrôle exécutable permet de vérifier que cela a été fait.
Automatisations, CLI scriptable et SDK
Au-delà des sessions interactives, Codex peut participer à des workflows répétables. La commande codex exec, le SDK et les intégrations CI permettent par exemple de lancer une analyse ciblée, de préparer une modification ou de produire un retour de revue dans le cadre d'un processus automatisé. La GitHub Action officielle relie ces tâches à des événements de dépôt et aux autorisations définies dans le workflow.
Les tâches planifiées permettent, dans les environnements éligibles, de confier à Codex des opérations récurrentes sur un projet local ou un environnement adapté. Cette capacité peut servir à une maintenance documentaire, à un examen périodique ou à un travail de préparation, mais elle suppose que les fichiers, les outils et le contexte nécessaires soient disponibles lors de l'exécution.
L'automatisation doit être dimensionnée avec soin : un agent capable de modifier des fichiers et d'exécuter des commandes ne devrait pas recevoir par défaut tous les droits d'un compte de production. Les tâches sensibles nécessitent des autorisations limitées, des journaux consultables et un moyen de revenir sur les modifications.
Permissions, bac à sable et traitement des données
Codex dispose de politiques d'approbation et de sandboxing destinées à limiter les fichiers, commandes et accès réseau autorisés. L'implémentation dépend de la plateforme : les mécanismes utilisés sous macOS, Linux et Windows ne sont pas identiques. Le développeur peut ajuster le degré d'autonomie selon son contexte, mais ouvrir davantage l'environnement augmente également les conséquences possibles d'une mauvaise interprétation ou d'une instruction malveillante présente dans le dépôt.
Le contenu des fichiers, journaux ou sorties de commandes peut contenir des informations confidentielles. Les clés API, fichiers .env, données clients et accès de déploiement ne doivent donc pas être exposés inutilement. Le simple fait de lancer Codex depuis un terminal local ne signifie pas que toutes les données restent sur le disque, puisque du contexte est transmis au modèle hébergé. Les sessions cloud, quant à elles, s'exécutent dans l'infrastructure gérée par OpenAI.
Les règles d'utilisation des données dépendent du compte et du mode d'authentification. Pour Business, Enterprise, Edu et l'API, OpenAI indique ne pas utiliser par défaut les entrées et sorties professionnelles pour entraîner ses modèles ; des options de partage spécifiques peuvent exister pour certaines organisations API. Sur les offres personnelles, les conversations peuvent contribuer à l'amélioration des modèles si le réglage correspondant n'est pas désactivé. Les politiques de conservation et les autorisations d'un espace de travail doivent être examinées avant tout usage sensible.
Offres ChatGPT et facturation API : deux voies différentes
Codex est intégré aux offres Free, Go, Plus, Pro, Business, Edu et Enterprise, mais les quotas et fonctions varient. Les offres gratuites permettent un usage limité ; les formules payantes donnent accès à davantage de capacité et, selon le plan, à des fonctions cloud ou d'organisation supplémentaires. Des crédits peuvent permettre de prolonger l'utilisation lorsque l'offre le prévoit.
| Accès | Principe de facturation |
|---|---|
| ChatGPT Free / Go | Codex inclus avec des quotas adaptés à des tâches ponctuelles ou légères. |
| ChatGPT Plus / Pro | Codex inclus avec des capacités et limites variables selon la formule ; crédits supplémentaires possibles pour les comptes éligibles. |
| Business / Edu / Enterprise | Accès et contrôles administratifs selon le contrat, les rôles et le modèle de crédits ou de facturation retenu. |
| Clé API OpenAI | Consommation facturée séparément aux tarifs API des modèles utilisés ; certaines fonctions propres à ChatGPT et à Codex Cloud ne sont pas accessibles. |
La distinction évite une confusion fréquente : se connecter avec une clé API ne consomme pas automatiquement le quota d'un abonnement ChatGPT. À l'inverse, une connexion ChatGPT ne crédite pas un projet API. Les tarifs, quotas, modèles disponibles et règles de partage peuvent évoluer ; le tableau d'utilisation du compte et la page officielle des tarifs font référence pour les conditions effectivement applicables.
Cas d’usage
Comprendre puis corriger une régression dans un projet existant
Une fonctionnalité ne répond plus après une mise à jour. Codex peut rechercher le point d'entrée, suivre les appels entre plusieurs composants, consulter les tests et proposer une correction ciblée. Une fois le patch appliqué, il lance les vérifications disponibles et expose le diff pour que le développeur puisse vérifier la portée de l'intervention.
Cet usage est particulièrement intéressant lorsqu'une erreur implique plusieurs couches du logiciel. Le résultat reste à valider par un test fonctionnel ou une reproduction réelle du problème : une suite de tests verts peut ne pas couvrir le scénario initial.
Préparer une fonctionnalité sans perturber le travail en cours
Un développeur peut ouvrir un worktree distinct pour confier à Codex une fonctionnalité pendant qu'il poursuit ses propres modifications sur une autre branche. L'agent explore les conventions du dépôt, construit une première implémentation, écrit les tests pertinents puis présente les fichiers modifiés.
Le travail peut ensuite être relu, ajusté et intégré avec Git. Cette organisation est surtout utile pour les tâches suffisamment délimitées pour progresser de manière indépendante ; plusieurs agents modifiant la même zone du code peuvent au contraire multiplier les conflits.
Réviser une pull request et renforcer les contrôles
Avant une fusion, Codex peut examiner les changements à la recherche d'erreurs de logique, de régressions potentielles ou de défauts de gestion des cas limites. La revue peut être demandée localement ou depuis GitHub lorsque l'intégration cloud est configurée.
Les règles AGENTS.md peuvent préciser les invariants à surveiller, tandis que la CI reste chargée du formatage, des tests et des vérifications déterministes. Codex ajoute ainsi un examen contextuel, mais ne remplace ni la revue humaine ni les protections du dépôt.
Automatiser une maintenance technique répétitive
Une équipe peut employer la CLI ou le SDK pour préparer des migrations simples, vérifier périodiquement certaines parties du code ou maintenir une documentation technique synchronisée avec les changements du projet. Les automatisations peuvent être exécutées dans un environnement défini, avec des permissions limitées et des contrôles après modification.
Le gain dépend surtout de la qualité du workflow. Une tâche répétitive bien décrite, dotée de tests et d'une procédure de validation, convient davantage à l'automatisation qu'une demande vague donnant à l'agent toute liberté sur un dépôt entier.
Conclusion
Codex propose une manière de travailler où l'assistant ne se contente plus de fournir du code à copier : il intervient dans le projet, utilise les outils du développeur et produit des modifications vérifiables. Cette différence change la nature de l'échange. Il devient possible de confier un problème complet plutôt qu'une suite de fragments de fichiers, à condition de définir clairement ce qui doit être modifié et comment reconnaître un résultat correct.
La pluralité des environnements est un élément central de son approche. Le CLI conserve la proximité du terminal, l'IDE replace l'assistance à côté du code, l'application de bureau facilite l'organisation des projets et des worktrees, tandis que Codex Cloud permet de déléguer des travaux dans des environnements isolés. Il ne s'agit pas d'interfaces parfaitement interchangeables : elles n'ont ni les mêmes accès ni les mêmes contraintes de sécurité et de collaboration.
L'ouverture du CLI et du SDK sous Apache 2.0 constitue un autre trait important pour les développeurs qui souhaitent examiner ou intégrer certains composants. Cette ouverture reste partielle : les modèles hébergés, l'extension IDE et Codex Cloud ne deviennent pas open source parce que le client terminal l'est.
Le principal compromis concerne l'autonomie. Autoriser l'agent à lire un dépôt, modifier des fichiers ou lancer des commandes peut réduire les manipulations répétitives, mais déplace une partie du travail vers la définition du périmètre, la gestion des permissions et la vérification du résultat. Les instructions de projet apportent un cadre ; les tests, les règles Git et la revue humaine apportent des contrôles exécutables et observables.
Enfin, Codex fonctionne avec des modèles hébergés. Les entreprises doivent donc examiner les politiques de données, tandis que les particuliers doivent distinguer les quotas inclus dans ChatGPT de la facturation séparée par API. Pour explorer une base de code, corriger des bugs, développer des fonctionnalités, revoir des changements ou automatiser une maintenance bien définie, Codex est un environnement de développement agentique dont l'utilité dépend autant de la qualité du projet et de ses contrôles que des capacités de l'agent.
Points d’attention
-
Codex n'est pas une IA exécutée intégralement hors ligne. Même lorsqu'il intervient sur des fichiers locaux, le traitement de la demande implique généralement des modèles hébergés et la transmission de contexte.
-
Le statut open source concerne notamment le CLI et le SDK sous Apache 2.0. L'extension IDE, Codex Cloud et les modèles ne partagent pas automatiquement cette licence.
-
Les interfaces n'ont pas les mêmes capacités. Terminal, IDE, application de bureau, Web et accès mobile diffèrent par leurs possibilités d'exécution, leurs intégrations et leurs autorisations.
-
Les tâches cloud utilisent des environnements distants configurés. Accès aux dépôts, installation des dépendances, secrets et réseau doivent être réglés avant de leur confier un projet sensible.
-
Les quotas inclus dans ChatGPT et la facturation API sont distincts. Une clé API entraîne une consommation facturée séparément ; les limites et crédits des offres peuvent évoluer.
-
Les permissions et le bac à sable limitent les risques sans les supprimer. Contrôlez particulièrement les commandes destructrices, les fichiers sensibles, les services connectés et les possibilités d'accès réseau.
-
Un diff généré ou un test réussi ne garantit pas que la tâche est correctement terminée. La revue du code, les vérifications fonctionnelles et les protections Git restent nécessaires.
-
Les instructions
AGENTS.mdguident l'agent mais ne remplacent pas un validateur. Les contraintes incontournables doivent être vérifiées par des tests, des outils de qualité ou la CI. -
Les règles de traitement des données varient selon le compte. Les offres professionnelles et l'API disposent d'engagements distincts des réglages d'entraînement des offres personnelles ; consultez la politique applicable à votre espace de travail.