OpenAI teste un Codex qui continue à travailler jusqu’à ce que vous lui disiez de dormir

Vous demandez à Codex de préparer une application pour son lancement. Il termine les tests, corrige le responsive et livre sa réponse. Puis, au lieu de s’arrêter, il crée une nouvelle tâche : vérifier la documentation. Ensuite une autre : rechercher les erreurs silencieuses. À quel moment ce zèle devient-il du travail inutile ? OpenAI expérimente précisément ce passage d’un agent qui exécute une demande à un agent qui cherche lui-même la prochaine action.

Le 27 août 2026, WIRED a révélé le test d’un « Persistent mode » dans Codex. Un porte-parole d’OpenAI a confirmé l’expérimentation au média, tout en précisant qu’aucun lancement immédiat n’était prévu. Le mode n’est donc pas une fonction que tous les utilisateurs peuvent activer aujourd’hui.

Persistent mode : ce qu’OpenAI teste réellement dans Codex

Le changement fusionné le 26 août dans le dépôt open source de Codex ajoute persistent au protocole des niveaux de raisonnement et aux types du SDK TypeScript. Il prévoit aussi de n’afficher ce choix dans l’interface en ligne de commande que lorsqu’un modèle le déclare. Ce détail compte : voir l’option dans le code du client ne prouve pas qu’un compte ou un modèle puisse déjà l’utiliser.

Le même changement conserve la valeur dans la configuration locale, mais la traduit encore différemment lorsqu’elle est envoyée à la Responses API. Il ressemble donc à une infrastructure préparatoire et testable, pas à l’annonce d’un produit fini. OpenAI peut modifier, limiter ou abandonner ce comportement avant une éventuelle sortie.

WIRED rapporte que l’instruction associée présente le mode comme capable de continuer à travailler jusqu’à ce que l’utilisateur le mette en sommeil. Le média décrit également une couche de « proactivity » : après la tâche demandée, l’agent pourrait créer des suivis, les poursuivre entre plusieurs sessions et envoyer avec parcimonie un message utile à l’utilisateur.

Le gabarit visible dans le dépôt de Codex ajoute cependant des freins essentiels. Avant un suivi, l’agent doit définir son périmètre, le résultat attendu, la preuve nécessaire et une condition d’arrêt. Il doit privilégier une boucle déjà ouverte plutôt qu’inventer un projet sans rapport. Surtout, le mode n’étend pas l’autorisation initiale.

Quand la demande est terminée, le travail utile ne l’est pas toujours

Une tâche peut satisfaire sa formulation sans atteindre l’objectif réel. « Corrige le formulaire » peut laisser un test manquant. « Prépare cette application pour un lancement public » peut produire une version fonctionnelle sans documentation de restauration, sans parcours mobile vérifié ou avec une dépendance vulnérable.

Un agent persistant pourrait fermer ce type de boucle sans attendre un nouveau prompt. Mais il peut aussi confondre amélioration possible et travail nécessaire. Une application n’est jamais « totalement optimisée » : on peut toujours ajouter des tests, réécrire une couche, produire un rapport ou essayer une autre architecture.

La bonne question n’est donc pas « combien de temps Codex peut-il continuer ? ». Elle est : quel nouveau travail est encore justifié par l’objectif autorisé, et quelle preuve permettra de l’arrêter ?

Le protocole utile : « prépare cette application pour un lancement public »

Le test le plus instructif ne consiste pas à demander à l’agent de tourner longtemps. Il consiste à lui donner un objectif large, des limites explicites et une définition mesurable de « prêt ». Le scénario suivant est une proposition Okibata ; il ne s’agit pas d’un benchmark réalisé par OpenAI ni d’un essai du Persistent mode.

Objectif : prépare cette application pour un lancement public contrôlé.

Tu peux modifier le dépôt et exécuter les validations locales autorisées.
Tu ne peux pas déployer, acheter un service, envoyer un message externe,
modifier les données de production ou élargir le périmètre sans accord.

Avant chaque nouvelle tâche de suivi, indique :
1. le risque ou le critère de lancement concerné ;
2. la preuve qui justifie le travail ;
3. le changement minimal prévu ;
4. le test qui confirmera le résultat ;
5. la condition d’arrêt.

Arrête-toi lorsque tous les critères bloquants sont prouvés ou lorsqu’une
décision, un accès ou une autorisation humaine est indispensable.

Préparez avant le départ une courte grille de lancement : build reproductible, tests critiques, absence de secret, installation documentée, parcours principal utilisable au clavier et sur mobile, sauvegarde et retour arrière compris. Une formulation comme « améliore tout ce que tu peux » ne fournit aucune frontière vérifiable.

Observez ensuite les tâches que l’agent se crée. Les premières peuvent être évidentes : build en échec, test absent, libellé inaccessible. Les suivantes révèlent la qualité de son jugement : choisit-il un problème réellement bloquant ou une amélioration simplement intéressante ? Recommence-t-il une vérification déjà réussie ? Produit-il un document parce qu’il sert le lancement ou parce qu’écrire un document est facile ?

Mesurer les tokens et les modifications après le point « terminé »

Pour comparer un agent persistant à un workflow borné, marquez l’instant où un humain compétent aurait accepté la tâche. Tout ce qui suit appartient à une deuxième phase. Il ne faut pas l’évaluer seulement en tokens : une correction critique trouvée tard peut justifier beaucoup de calcul, tandis que dix petits changements esthétiques peuvent coûter peu et dégrader le produit.

Relevez au minimum ces huit indicateurs :

• tokens d’entrée, de raisonnement et de sortie consommés avant et après le point d’acceptation ;
• durée machine et temps humain de revue dans chacune des deux phases ;
• nombre de tâches de suivi créées, terminées, abandonnées ou répétées ;
• fichiers et lignes modifiés après l’objectif initial ;
• nouveaux tests qui détectent réellement une régression ;
• défauts bloquants découverts après le premier résultat ;
• régressions introduites par les améliorations supplémentaires ;
• part des changements finalement conservés dans la version livrée.

Ajoutez un journal très court pour chaque suivi : raison, preuve initiale, résultat, coût et décision humaine. Vous pourrez alors distinguer un agent coûteux parce qu’il a découvert un problème important d’un agent coûteux parce qu’il a continué à produire.

La documentation officielle d’OpenAI sur GPT-5.6 recommande déjà de mesurer réussite, complétude, tokens, latence et coût sur des tâches représentatives. Elle rappelle aussi que les longues sessions amplifient le contexte répété. Le modèle le plus intelligent n’est donc pas automatiquement le meilleur choix pour chaque suivi : une étape de classification ou de documentation peut parfois être routée vers un modèle moins coûteux, si l’évaluation confirme la qualité.

Un agent persistant doit avoir trois listes : faire, demander, interdire

Une permission générale comme « travaille de manière autonome » est trop floue. Pour chaque projet, séparez les actions en trois groupes.

1. Faire sans interrompre : lire les fichiers du dépôt, lancer des tests non destructifs, modifier le code demandé, préparer une documentation locale et analyser les résultats.
2. Demander avant d’agir : déployer, envoyer un message, créer une dépense, modifier une ressource externe, traiter des données sensibles ou changer matériellement l’objectif.
3. Interdire : supprimer des données de production, contourner une protection, exposer un secret, désactiver un contrôle pour réussir un test ou réécrire un historique partagé sans autorisation.

Ces règles doivent s’appliquer à chaque tâche auto-créée. Une nouvelle carte « corriger la base de production » n’hérite pas magiquement d’un droit d’écriture parce qu’elle a été proposée par l’agent lui-même. La documentation officielle OpenAI conseille justement de définir les frontières entre inspection, modification locale, écriture externe, action destructive et extension du périmètre.

Notre guide explique comment définir dans AGENTS.md ce qu’un agent persistant n’a pas le droit de modifier. Ce fichier peut aussi fixer les commandes de test, les sources de vérité et les conditions qui exigent une validation humaine. Il ne remplace toutefois pas les permissions techniques du système, du dépôt ou de l’API.

Ce que vous pouvez utiliser aujourd’hui sans attendre Persistent mode

Persistent mode reste un test sans calendrier public. Codex propose déjà des mécanismes différents pour le travail long : un objectif durable, des tâches planifiées, des reprises de contexte et des workflows où l’utilisateur peut suivre ou interrompre le travail. La page de cas d’usage officielle d’OpenAI présente notamment la possibilité de donner à Codex un objectif durable pour un travail de longue durée.

Ces fonctions ne doivent pas être rebaptisées « Persistent mode ». Aujourd’hui, notre guide Codex décrit les modes réellement disponibles et la manière de les encadrer. Pour une tâche répétitive, une automatisation avec heure, périmètre et condition de fin sera souvent plus prévisible qu’une consigne illimitée.

La comparaison avec Gauntlet Loop permet de distinguer une boucle contrôlée d’un agent qui crée lui-même la prochaine tâche. Une boucle classique répète une procédure connue jusqu’à un seuil. La proactivité ajoute une décision plus délicate : choisir le prochain problème à résoudre. Elle peut apporter davantage de valeur, mais aussi davantage de dérive.

Le futur avantage de Persistent mode ne sera pas qu’un agent reste éveillé plus longtemps. Ce sera sa capacité à reconnaître une boucle vraiment ouverte, à produire la preuve qui la ferme et à s’arrêter avant que la recherche d’amélioration ne devienne elle-même le problème. Le meilleur agent persistant devra savoir travailler sans relance — et savoir pourquoi il est temps de dormir.