En septembre 2025, OpenAI a présenté GPT-5-Codex, la première version de GPT-5 optimisée pour la programmation agentique. En décembre 2025, nous avons lancé la version 5.2. C’est à ce moment-là que les utilisateurs ont commencé à croire qu’ils pouvaient compter sur des agents de programmation autonomes. Nous avons notamment constaté que le modèle pouvait suivre des instructions de manière fiable pendant beaucoup plus longtemps.
J’ai voulu voir jusqu’où il pouvait aller. J’ai donc donné à Codex un dépôt vide, un accès complet et une seule mission : créer un outil de design en partant de zéro. Je l’ai ensuite laissé travailler avec GPT-5.3-Codex, avec le niveau de raisonnement réglé sur « Très élevé ». Codex a travaillé environ 25 heures sans interruption, utilisé quelque 13 millions de tokens et généré près de 30 000 lignes de code.
Il s’agissait d’une expérience, sans mise en production. Codex s’en est bien sorti sur les points qui comptent pour les tâches de longue durée : respecter le cahier des charges, garder le cap, effectuer les vérifications et corriger les erreurs au fur et à mesure.
À quoi ressemble une session Codex de longue durée ?
J’ai demandé à Codex de créer une page récapitulative à partir des données de la session :
Voici également les statistiques de la session dans la CLI et le nombre de tokens utilisés :
Ces captures d’écran illustrent une évolution de fond : en programmation agentique, l’horizon temporel compte de plus en plus, au-delà de ce qu’un modèle peut résoudre en une seule étape.
C’est l’horizon temporel qui change la donne
Dire que « les modèles sont devenus plus intelligents » ne suffit pas à décrire cette évolution. En pratique, les agents peuvent maintenir une démarche cohérente plus longtemps, mener à bien des tâches plus importantes de bout en bout et reprendre le travail après une erreur sans perdre le fil.
Les travaux de METR sur les évaluations de l’horizon temporel permettent de situer cette tendance. La durée des tâches de développement logiciel que les agents de pointe réussissent dans environ 50 % et 80 % des cas augmente rapidement : elle double à peu près tous les sept mois. Consultez l’étude Mesurer la capacité de l’IA à mener à bien des tâches de longue durée (METR).
Notre récente annonce du lancement de GPT-5.3-Codex décrit deux avancées concrètes pour le travail des agents :
- Le modèle enchaîne mieux les étapes d’une tâche (planifier → implémenter → valider → corriger).
- Il est plus facile de le réorienter en cours de route sans relancer toute la session : le travail déjà accompli est conservé.
Je me suis aussi inspiré des articles de Cursor sur les systèmes de programmation autonomes capables de travailler dans la durée, notamment de leur expérience de création d’un navigateur : Comment Cursor a créé un navigateur web avec des agents à grande échelle.
L’équipe de Cursor écrit que les modèles d’OpenAI sont « bien meilleurs lorsqu’il s’agit de travailler longtemps en autonomie : ils suivent les instructions, restent concentrés, évitent de s’écarter de l’objectif et vont jusqu’au bout de l’implémentation avec précision ».
Comment Codex garde le fil sur les tâches de longue durée
Pour travailler dans la durée, la boucle dans laquelle évolue l’agent compte davantage qu’un seul très long prompt.
Dans Codex, cette boucle se déroule à peu près ainsi :
- Planification
- Modification du code
- Exécution des outils (tests, build, lint)
- Examen des résultats
- Correction des erreurs
- Mise à jour de la documentation et de l’état d’avancement
- Reprise de la boucle
Cette boucle donne à l’agent :
- Des retours concrets (erreurs, diffs, journaux)
- Un état conservé en dehors du modèle (dépôt, fichiers, documentation, arbres de travail, sorties des commandes)
- La possibilité d’être réorienté au fil du temps (vous pouvez ajuster sa démarche en fonction des résultats)
C’est aussi ce qui rend les modèles Codex plus efficaces dans les interfaces Codex que dans une fenêtre de discussion générique. Le harnais d’exécution fournit un contexte structuré (métadonnées du dépôt, arborescence des fichiers, diffs, sorties des commandes) et impose de vérifier les critères de fin de tâche avant de conclure.
Nous avons récemment publié un article qui décrit plus en détail la boucle de l’agent Codex.
Nous avons également lancé l’application Codex pour vous permettre d’utiliser cette boucle au quotidien :
- Fils de discussion parallèles dans plusieurs projets (vous pouvez poursuivre votre travail pendant les tâches de longue durée)
- Skills (standardisez la planification, l’implémentation, les tests et le compte rendu)
- Automatisations (exécutez les tâches récurrentes en arrière-plan)
- Arbres de travail Git (isolez les sessions, gardez des diffs faciles à examiner et limitez les allers-retours)
Comment j’ai préparé le test
J’ai choisi un outil de design pour cette « expérience » parce que c’est un test exigeant : il faut une interface, un modèle de données, des opérations d’édition et la prise en charge de nombreux cas limites. Impossible de faire illusion. Les défauts d’architecture se manifestent très vite.
J’ai confié à GPT-5.3-Codex un cahier des charges détaillé et réglé le niveau de raisonnement sur « Très élevé ». Le modèle a travaillé environ 25 heures sans interruption, en gardant le fil et en livrant du code de qualité. À chaque jalon atteint, il a également effectué des vérifications (tests, lint et vérification des types).
L’idée centrale : une mémoire persistante du projet
La technique la plus importante a consisté à donner au projet une mémoire persistante. J’ai consigné le cahier des charges, le plan, les contraintes et l’état d’avancement dans des fichiers Markdown que Codex pouvait consulter autant de fois que nécessaire. Il a ainsi gardé le cap, avec des critères stables pour déterminer quand le travail était « terminé ».
Les liens ci-dessous pointent vers les fichiers du dépôt. Voici le rôle de chacun :
Prompt.md (cahier des charges et livrables)
Objectif : fixer la cible pour éviter que l’agent ne « construise quelque chose d’impressionnant qui ne répond pas au besoin ».
Principales rubriques du fichier :
- Objectifs et éléments hors périmètre
- Contraintes impératives (performances, déterminisme, expérience utilisateur, plateforme)
- Livrables (ce qui doit exister à la fin du projet)
- Critères pour déclarer le travail « terminé » (vérifications et déroulé de la démo)
Le prompt initial demandait à Codex de prendre ce fichier comme cahier des charges complet du projet et d’élaborer un plan découpé en jalons :
Plan.md (jalons et validations)
Objectif : découper un travail ouvert en une suite d’étapes que l’agent peut achever et vérifier.
Principales rubriques du fichier :
- Jalons suffisamment courts pour être atteints en un seul tour de boucle
- Critères d’acceptation et commandes de validation pour chaque jalon
- Règle d’arrêt en cas d’échec de la validation : corriger l’erreur avant de poursuivre
- Décisions consignées pour éviter de revenir sans cesse sur les mêmes choix
- Architecture prévue pour le code source
Nous avons récemment intégré un mode plan à l’application Codex, à la CLI et à l’extension pour IDE. Ce mode décompose une tâche importante en une suite d’étapes claires que vous pouvez examiner avant toute modification. Vous pouvez ainsi convenir de la démarche dès le départ. Si des précisions sont nécessaires, Codex vous posera des questions complémentaires. Pour activer ce mode, utilisez la commande slash /plan.
Implement.md (instructions d’exécution fondées sur le plan)
Objectif : servir de guide d’exécution. Ce fichier indique précisément à Codex comment procéder : suivre le plan, limiter les diffs au périmètre prévu, exécuter les validations et mettre à jour la documentation.
Principales consignes du fichier :
- Suivez le fichier Markdown du plan, qui fait référence pour chaque jalon.
- Exécutez la validation après chaque jalon et corrigez immédiatement les erreurs.
- Limitez les diffs au périmètre prévu, sans l’élargir.
- Mettez à jour le fichier Markdown de documentation au fur et à mesure.
Documentation.md (avancement et décisions au fil des livraisons)
Objectif : servir de mémoire partagée et de journal d’audit. Grâce à ce fichier, je peux m’absenter plusieurs heures et comprendre à mon retour ce qui s’est passé.
Principales rubriques du fichier :
- État du jalon en cours (travail accompli et prochaines étapes)
- Décisions prises et raisons de ces choix
- Instructions pour lancer l’outil et en faire la démo (commandes et tests rapides de bon fonctionnement)
- Problèmes connus et points à reprendre
Voici comment Codex vérifiait concrètement les jalons pendant la session :
Une vérification à chaque jalon
Codex ne s’est pas contenté d’écrire du code en espérant qu’il fonctionne. Après chaque jalon, il a exécuté les commandes de vérification et corrigé les erreurs avant de poursuivre.
Voici quelques exemples de commandes de contrôle qualité qu’il avait pour consigne d’utiliser :
Voici comment Codex a corrigé des problèmes signalés par le lint :
Ce que l’agent a construit
Le résultat était imparfait et demandait encore du travail avant une mise en production, mais l’outil existait et on pouvait le tester. La question pour cette session allait au-delà de « Est-ce que ça compile ? » : « Est-ce que l’outil respecte les instructions et fonctionne vraiment ? »
Principales fonctionnalités implémentées :
- Édition dans le canvas (cadres, groupes, formes, texte, images et icônes, boutons, graphiques)
- Collaboration en temps réel (synchronisation de la présence, des curseurs, des sélections et des modifications entre les onglets)
- Réglages dans l’inspecteur (géométrie, styles, texte)
- Gestion des calques (recherche, renommage, verrouillage, masquage et réorganisation)
- Repères, alignement et magnétisme
- Enregistrement et restauration d’instantanés dans l’historique
- Relecture de la chronologie et création d’une branche à partir d’un point antérieur
- Mode prototype (zones interactives et navigation dans le parcours)
- Commentaires (fils de discussion épinglés pouvant être marqués comme résolus puis rouverts)
- Export (enregistrement, import et export, avec export via la CLI au format JSON ou en code React + Tailwind)
Ce qu’il faut retenir pour les tâches de longue durée avec Codex
La réussite de cette session ne tenait pas à un seul prompt astucieux. Elle reposait sur la combinaison de plusieurs éléments :
- Un objectif et des contraintes explicites (fichier de spécification)
- Des jalons assortis de points de contrôle et de critères d’acceptation (
plans.md) - Un guide précisant comment l’agent doit procéder (
implement.md) - Des vérifications continues (tests, lint, vérification des types et build)
- Un journal d’avancement et d’audit tenu à jour (
documentation.md) pour pouvoir examiner la session à tout moment
C’est dans cette direction qu’évolue la programmation sur des tâches de longue durée : moins de surveillance au quotidien, davantage de délégation avec des garde-fous.
Essayez Codex sur une de vos tâches de longue durée
Cette session Codex de 25 heures donne un aperçu de la façon dont nous développerons des logiciels. Au-delà des prompts ponctuels et des échanges rapprochés de la programmation en binôme, nous pouvons désormais confier à un coéquipier une part substantielle du travail, qu’il mènera de bout en bout. Vous intervenez aux jalons pour l’orienter, sans avoir à superviser chaque ligne de code.
Avec Codex, nous voulons que l’agent travaille mieux en équipe, qu’il tienne davantage compte du contexte réel de votre projet et que des garde-fous vous permettent de compter sur son travail, de l’examiner et de le livrer facilement. Nous constatons déjà que les développeurs avancent plus vite lorsque l’agent prend en charge les tâches courantes d’implémentation et de vérification. Ils peuvent alors se concentrer sur ce qui compte le plus : la conception, l’architecture, les décisions produit et les problèmes inédits pour lesquels il n’existe pas de solution toute faite.
Cette évolution ira au-delà du métier de développeur. À mesure que Codex comprendra mieux les intentions et offrira un cadre de travail plus sûr (plans, validations, aperçus, retours en arrière), davantage de personnes qui ne développent pas de logiciels pourront créer et affiner leurs projets sans passer leurs journées dans un IDE. D’autres évolutions sont prévues dans les différentes interfaces de Codex et dans ses modèles. Notre objectif reste le même : faire de l’agent un coéquipier à qui vous pouvez confier des tâches de longue durée sans avoir à le surveiller en permanence.
Pour tenter l’expérience, commencez par ces ressources :