Codex : le codage agentique dans votre environnement

Codex est l'outil de codage agentique d'OpenAI : il lit votre codebase, planifie une modification, écrit le code, lance vos tests, puis vous remet un diff à relire avant que quoi que ce soit ne parte en production. Vous comprenez déjà la boucle agentique dans l'abstrait. Cette leçon l'ancre dans un workflow réel : vous confiez une tâche à Codex, il travaille dans un environnement isolé, et vous restez le relecteur qui approuve ou rejette le résultat.

Ce qu'est réellement Codex

Aujourd'hui, « Codex » désigne une famille de surfaces, pas un bouton unique. Vous en croiserez trois :

• Codex dans le cloud, accessible depuis la vue Codex à l'intérieur de ChatGPT, où chaque tâche tourne dans son propre conteneur sandboxé avec votre repo cloné dedans.
• Le CLI Codex, un agent de terminal open source que vous exécutez localement sur le code de votre machine.
• L'extension IDE Codex pour VS Code et les éditeurs similaires, qui amène le même agent à côté de vos fichiers.

Les trois reposent sur des modèles optimisés pour Codex et partagent la même idée de fond : l'agent obtient un accès en lecture/écriture à une vraie copie de travail de votre projet, plus un shell, ce qui lui permet d'exécuter réellement des commandes au lieu de deviner du code.

Le point de départ officiel est la documentation Codex. Lisez les pages sur l'environnement et la configuration avant de lancer quoi que ce soit de sérieux ; les valeurs par défaut concernant l'accès réseau et les approbations comptent.

Pourquoi « agentique » change le métier

Dans Canvas (l'outil de la leçon précédente), vous éditez un document ou un fichier de façon collaborative. Codex est différent : il opère sur tout le repo et peut exécuter. Cette seule capacité, lancer une commande et lire la sortie, transforme un générateur de code en agent. Il écrit un test, le lance, voit qu'il échoue, modifie l'implémentation, relance. Vous ne copiez-collez plus des extraits. Vous relisez une modification terminée et testée.

Mise en place : le CLI en local

Utilisons le CLI, car c'est lui qui rend la boucle la plus visible. Installation et authentification :

npm install -g @openai/codex
cd ~/projects/billing-service
codex

Au premier lancement, il s'authentifie via votre compte ChatGPT (ou une clé APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète →) et détecte le repo. À partir de là, vous pouvez saisir une tâche en langage naturel au prompt.

Le fichier le plus important que vous pouvez ajouter est AGENTS.md à la racine du repo. Voyez-le comme des instructions personnalisées limitées à cette codebase : il indique à Codex comment construire, tester et se comporter. Codex le lit automatiquement.

# AGENTS.md

## Commands
- Install: `poetry install`
- Test: `poetry run pytest -q`
- Lint: `poetry run ruff check .`

## Conventions
- Type hints required on all new functions.
- Tests live next to the module they cover, named `test_*.py`.
- Never edit files under `migrations/` without flagging it.

C'est là toute la différence entre un agent qui patauge et un agent qui s'adapte à votre projet. Passez dix minutes dessus et chaque tâche future coûtera moins cher.

Démonstration concrète : implémenter une petite fonctionnalité et lancer les tests

Voici le scénario. Notre billing-service possède un module discount. Nous voulons une nouvelle fonction qui applique une remise en pourcentage au total d'une commande, avec validation. Et nous la voulons testée. Observez la boucle agentique.

Étape 1 : donner la tâche

Au prompt Codex :

Add a function `apply_percentage_discount(total, percent)` to
discount.py. It returns the discounted total. Raise ValueError if
percent is not between 0 and 100. Add unit tests covering valid
input, the boundaries, and invalid input. Run the test suite.

Notez ce que nous avons précisé et ce que nous n'avons pas précisé. Nous avons décrit un comportement et des cas limites, pas une implémentation. Nous lui avons explicitement demandé de lancer les tests, et c'est l'instruction qui active la boucle.

Étape 2 : l'agent planifie et lit

Codex commence par explorer. Il fait un grep sur discount.py, lit les fonctions existantes pour s'aligner sur le style, et regarde comment les autres tests sont structurés. C'est cette étape de lecture avant écriture qui rend payants un `AGENTS.md` propre et un repo bien tenu : l'agent imite ce qu'il voit.

Il énonce ensuite un plan court : crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éererLe rapport entre les interactions (likes, commentaires, partages) et le reach d'un contenu, utilisé pour mesurer la réaction de l'audience au regard du nombre de personnes touchées.Voir la définition complète → la fonction, ajouter test_discount.py, lancer pytest.

Étape 3 : il écrit le code

Il produit quelque chose comme ceci et l'écrit sur le disque :

def apply_percentage_discount(total: float, percent: float) -> float:
    if not 0 <= percent <= 100:
        raise ValueError(f"percent must be between 0 and 100, got {percent}")
    return total * (1 - percent / 100)

Ainsi qu'un fichier de tests correspondant, avec les cas demandés.

Étape 4 : il lance les tests (la boucle)

C'est la partie qu'un simple chat ne peut pas vous offrir. Codex exécute poetry run pytest -q dans le sandbox. Supposons qu'un test de cas limite échoue à cause d'une comparaison en virgule flottante. L'agent voit la sortie en échec, modifie le test pour utiliser pytest.approx, et relance. Vert. Il fait tout cela sans vous demander, parce que le travail s'est déroulé dans un environnement isolé, pas sur votre branche de production.

Vous verrez chaque commande et sa sortie défiler dans le terminal. Cette transparence est le point clé : vous observez le raisonnement, vous ne faites pas confiance à une boîte noire.

Étape 5 : l'étape de relecture

Quand la boucle se stabilise, Codex vous montre un diff unifié de tout ce qu'il a modifié. Rien n'est encore commité. Vous le lisez comme une pull request :

• apply_percentage_discount correspond-elle à vos attentes en matière d'arrondi ? (Peut-être voulez-vous round(..., 2).)
• Les tests sont-ils pertinents, ou passent-ils trivialement ?
• A-t-il touché un fichier qu'il n'aurait pas dû toucher ?

Vous pouvez approuver, demander une révision en langage naturel (« arrondis le résultat à 2 décimales et ajoute un test pour ça »), ou jeter. L'étape de relecture n'est pas négociable. L'agent est rapide et compétent, et il se trompe encore parfois : vous restez la porte d'entrée.

Modes d'approbation : quelle longueur de laisse

Codex vous laisse régler son degré d'autonomie. Les libellés exacts évoluent, mais le spectre reste le même :

• Suggest / lecture seule : il propose des modifications et des commandes, mais demande avant d'agir.
• Auto / workspace-write : il modifie les fichiers et lance des commandes dans le répertoire de travail sans demander, mais reste sandboxé.
• Accès complet : il peut tout exécuter, y compris des appels réseau. À utiliser rarement et en connaissance de cause.

Une bonne valeur par défaut pour du vrai travail est le mode intermédiaire avec l'accès réseau désactivé. L'agent peut éditer et tester librement mais ne peut pas atteindre internet, ce qui élimine toute une catégorie d'accidents (et les risques de prompt injection s'il lit des fichiers non fiables). N'activez le réseau que lorsqu'une tâche a réellement besoin de récupérer une dépendance.

Codex dans le cloud et tâches en parallèle

Le CLI est parfait pour travailler aux côtés de l'agent. Le Codex cloud dans ChatGPT est conçu pour la délégation. Vous connectez un repo GitHub, puis vous confiez une tâche (« corrige le test instable dans test_orders.py ») et le laissez tourner dans son propre conteneur. Vous pouvez lancer plusieurs tâches en parallèle et repasser plus tard.

Quand le Codex cloud a terminé, il peut ouvrir une pull request directement sur GitHub. Votre étape de relecture devient une revue de PR classique avec la CI attachée, c'est-à-dire exactement là où une équipe rigoureuse veut placer le point de contrôle humain. C'est le modèle pour le travail par lots : triez trois petits bugs le lundi matin en décrivant chacun d'eux, puis relisez trois PR autour d'un café.

La place de Codex par rapport au reste de l'écosystème

Vous disposez désormais de plusieurs surfaces agentiques dans le monde OpenAI. Ne pas les confondre évite les mauvais usages :

• Codex sert à travailler dans *votre* codebase : lire, éditer, lancer des tests, ouvrir des PR. C'est de l'ingénierie.
• Advanced Data Analysis (Code Interpreter) exécute du Python dans un sandbox jetable pour analyser un fichier ou produire un graphique. Il n'est pas connecté à votre repo et n'est pas fait pour y livrer du code.
• Canvas est une surface d'édition ciblée sur un document ou un fichier unique, avec vous dans la boucle à chaque modification. Il ne fait pas tourner votre suite de tests sur un projet.
• L'agent ChatGPT navigue, clique et utilise des outils pour accomplir des tâches web et informatiques générales. Ce n'est pas un agent de codage.

Si vous construisez votre propre agent logiciel plutôt que d'utiliser ces produits, c'est l'Agents SDK et la Responses API, qui exposent le function calling et l'usage d'outils comme primitives. Codex est la version produit, spécialisée codage, de ces mêmes idées, avec le sandbox, l'intégration au repo et la relecture de diff déjà en place pour vous.

Un rythme d'ingénierie réaliste

Voici comment les équipes l'utilisent concrètement au quotidien :

1. Des tâches cadrées, pas des souhaits vagues. « Ajoute la validation des entrées sur l'endpoint d'inscription, avec des tests » fonctionne. « Améliore la codebase » non. Des tâches petites et vérifiables gardent la boucle honnête et les diffs relisables.
2. Faites des tests le contrat. Comme Codex les exécute, une suite de tests solide est votre volant. Demandez-lui d'écrire le test d'abord quand le comportement est précis.
3. Maintenez `AGENTS.md` vivant. Quand l'agent fait deux fois quelque chose d'agaçant, c'est une instruction manquante, pas une défaillance du modèle. Ajoutez la règle.
4. Relisez chaque diff comme une PR. Traitez la sortie de l'agent exactement comme le premier jet d'un ingénieur junior : solide en général, subtilement faux à l'occasion, et toujours de votre responsabilité dès que vous mergez.

Points clés à retenir

• La boucle, c'est la valeur : Codex lit, écrit, *exécute* vos commandes et itère sur les échecs, le tout dans un sandbox. Incluez toujours « lance les tests » dans votre tâche pour que la boucle se déclenche vraiment.
• Écrivez un `AGENTS.md` à la racine de votre repo, avec les instructions de build, de test et les conventions. C'est l'étape de configuration au plus fort effet de levier, et elle rend chaque tâche plus précise.
• Par défaut : workspace-write avec accès réseau désactivé. N'accordez l'accès complet que pour les tâches spécifiques qui l'exigent.
• La relecture du diff est votre travail, pas une option. Approuvez, révisez ou jetez comme pour une pull request ; utilisez le Codex cloud pour ouvrir de vraies PR quand vous voulez la CI et la revue d'équipe dans le circuit.
• Utilisez la bonne surface : Codex pour votre codebase, Code Interpreter pour une analyse ponctuelle, Canvas pour l'édition d'un fichier unique, et l'Agents SDK quand vous construisez vous-même des agents.