Codex CLI ou Cloud : préparer un environnement réutilisable

Préparez un environnement Codex Cloud réutilisable, suivez vos tâches depuis votre téléphone et choisissez quand travailler dans le cloud ou avec Codex CLI.

Wednesday, October 7, 2026Omid Saffari
Codex CLI ou Cloud : préparer un environnement réutilisable

Codex CLI ou Cloud : si vous voulez confier un test en échec à Codex avant de quitter votre bureau et laisser la tâche continuer avec votre ordinateur éteint, le mode cloud répond à ce besoin. Codex Cloud fournit un environnement de projet réutilisable, accessible sur le Web et sur téléphone pour suivre le travail, orienter l’agent et examiner le résultat.

Ce qui a changé le 30 septembre

Cette nouvelle version facilite la répétition des tâches dans le cloud : le dépôt, les dépendances, les scripts et les réglages peuvent être prêts avant le lancement de la tâche suivante. Vous pouvez suivre l’avancement et orienter Codex depuis votre téléphone ou un autre ordinateur. L’expérience de l’application de bureau arrive aussi sur le Web et sur mobile. Ce sont les changements présentés dans l’annonce d’OpenAI du 30 septembre 2026.

Imaginez l’environnement comme un atelier déjà équipé. L’outillage et les matériaux restent prêts ; chaque tâche dispose de son propre établi. Une dépendance est un paquet logiciel dont votre projet a besoin, et le dépôt regroupe son code sous gestion de versions.

L’intérêt concret : le travail de développement peut avancer sans que vous gardiez votre ordinateur allumé. Codex Cloud s’exécute sur des machines gérées par OpenAI. Créez et publiez l’environnement depuis l’application de bureau ou le Web, puis retrouvez-le sur les appareils pris en charge. Chaque tâche possède ses propres fichiers de travail. Le guide d’aide d’OpenAI sur Cloud explique cette séparation.

Mon conseil : commencez par une petite tâche dont vous pouvez vérifier le résultat. Un agent qui travaille en arrière-plan devient surtout utile lorsque vous avez déjà défini ce qu’est un résultat correct.

Quels abonnements donnent accès à Codex Cloud ?

L’accès au cloud nécessite un compte Plus, Pro, Business, Enterprise, Healthcare ou Education éligible, selon le déploiement et les réglages de l’espace de travail. Free et Go donnent accès à Codex, mais pas à Codex Cloud. Les accès Guest, K-12 et les sièges Enterprise en lecture seule ne permettent pas de créer des environnements cloud. Ces distinctions proviennent de la page d’OpenAI sur la disponibilité selon l’abonnement.

Abonnement ChatGPTAccès à Codex CloudTarif public de l’abonnement
PlusÉligible, selon le déploiement et les réglages$20/mois
Pro, tous les niveauxÉligible, selon le déploiement et les réglages$100, $200 ou $500 USD/mois
BusinessÉligible, selon les réglages de l’espace de travail$20/utilisateur/mois avec 2+ utilisateurs en facturation annuelle ; $25/utilisateur/mois en facturation mensuelle
Enterprise et EducationÉligible, selon les réglages de l’espace de travailEnterprise et Edu : contacter le service commercial
HealthcareÉligible, selon les réglages de l’espace de travailAucun tarif indiqué ici
Free et GoCloud non inclusNe donne pas accès à Cloud

Ces tarifs d’abonnement viennent de la page tarifaire actuelle de Codex, consultée le 7 octobre 2026. L’éligibilité au cloud ne signifie pas que chaque membre peut utiliser tous les réglages.

Comment les tâches cloud consomment-elles votre quota ?

Au lancement, les environnements standard n’entraînent pas de frais distincts pour la machine virtuelle. Une machine virtuelle est l’ordinateur distant qui exécute la tâche. L’utilisation du modèle reste comptabilisée dans les limites habituelles de Codex, ainsi que dans les crédits ou la facturation applicables. Les offres à quota partagé peuvent mutualiser la consommation entre Codex, ChatGPT Work, ChatGPT for Excel et Workspace Agents, lorsque ces produits sont disponibles ; les contrats Enterprise fondés sur les tokens facturent en USD plutôt qu’en crédits. Les règles d’utilisation d’OpenAI détaillent ce décompte.

Les messages en local et les conversations cloud partagent le quota de votre abonnement, et des limites hebdomadaires peuvent s’appliquer. Les tâches cloud peuvent consommer davantage de quota que les messages en local. Les estimations de messages affichées sur la page tarifaire concernent l’usage local ; elles ne garantissent pas un nombre de tâches cloud. Les utilisateurs Plus et Pro éligibles peuvent acheter des crédits supplémentaires sans changer d’abonnement. Consultez votre tableau de bord de consommation pour connaître les limites et les horaires de réinitialisation en vigueur. La page tarifs et consommation de Codex explique les facteurs qui entrent en jeu.

Si vous payez déjà un abonnement éligible, essayez une tâche bien délimitée avant d’acheter plus de capacité. Le calcul économique est le suivant : temps d’intervention économisé, moins le temps consacré à entretenir la configuration, à orienter l’agent et à vérifier le résultat, en comptant séparément les éventuels crédits supplémentaires. Déplacer une tâche hors de votre ordinateur n’est rentable que si ce bilan s’améliore.

Pour comparer plus largement les abonnements et l’API, consultez les tarifs de Codex en 2026. Cloud nécessite une connexion avec ChatGPT ; une session CLI locale utilisant une clé API relève d’une facturation API distincte. Les options d’authentification expliquent la différence.

Préparer un environnement réutilisable

Commencez par un projet dont les tests s’exécutent de manière fiable avant de déléguer une modification plus importante. Suivez la procédure actuelle de configuration des environnements cloud, plutôt que l’ancien workflow.

  1. Connectez le dépôt. Sur le Web ou dans l’application de bureau, choisissez Work in > Cloud > Select environment > Create environment. Sélectionnez les dépôts GitHub et connectez GitHub si l’interface vous le demande.
  2. Préparez le projet. Sélectionnez Get started. Laissez Codex examiner le projet, installer les dépendances et lancer les tests. Fournissez les informations manquantes et les versions requises.
  3. Vérifiez le script de configuration. Install script consigne la préparation des dépendances ; Start skill consigne le démarrage des services et les conditions qui confirment qu’ils sont prêts. Affinez la configuration dans la conversation.
  4. Configurez les valeurs. Sélectionnez Manage à côté des variables d’environnement ou des secrets réseau. Pour un secret réseau, saisissez sa clé, sa valeur et les domaines autorisés.
  5. Réglez l’accès à Internet. Activez Allow Codex to access internet si nécessaire. Choisissez Package managers ou Custom domains only, en ajoutant les hôtes requis. All (unrestricted) autorise un accès plus large.
  6. Publiez et lancez la tâche. Vérifiez les fichiers, la configuration et les contrôles effectués. Enregistrez, puis sélectionnez Publish. Une fois le message Environment published affiché, lancez une nouvelle tâche. Pour modifier la configuration ensuite, utilisez Edit, puis Republish.

Pendant la conversation de préparation, fournissez à Codex les véritables commandes d’installation et de test du projet, la version requise de l’environnement d’exécution et les services nécessaires. Demandez-lui d’indiquer ce qui a réussi et ce qu’il n’a pas pu vérifier. Il s’agit d’instructions à adapter, pas d’un script de configuration universel.

Pour un premier essai, j’utiliserais des données de test synthétiques et l’accès aux services le plus restreint qui permette de reproduire la tâche. Si le téléchargement d’un paquet échoue, examinez séparément le nom d’hôte et l’authentification avant d’élargir l’accès à Internet.

Un schéma architectural relie la préparation du dépôt, la configuration publiée, une tâche cloud distincte et le pilotage depuis un téléphone.
Préparez et publiez l’atelier une fois, puis donnez à chaque tâche son propre espace de travail.

Trois tâches pour bien commencer

Choisissez une tâche avec un point de départ précis, un périmètre limité et des preuves que vous pourrez examiner ensuite. Les briefs ci-dessous sont des propositions à adapter à votre dépôt.

Corriger un test en échec

Si vous êtes fondateur et qu’un échec reproductible bloque votre livraison, déléguez l’enquête et un correctif ciblé. Fournissez la commande qui échoue et sa sortie. Demandez à Codex de préserver le comportement attendu, d’expliquer la cause et d’indiquer les vérifications effectuées.

Un brief possible :

Reproduis cet échec avec la commande de test documentée dans le projet. Trouve la cause et apporte le correctif minimal qui résout réellement le problème. Ne réduis pas les exigences de l’assertion pour faire passer le test. Exécute le test ciblé et les tests connexes pertinents. Résume les fichiers modifiés, les résultats et les incertitudes restantes.

C’est la tâche que je recommande le plus pour commencer, car l’état avant et après est observable. Même si le test passe, il faut examiner le diff : le correctif doit réparer le comportement, pas simplement masquer l’échec.

Rédiger une migration

Si vous développez le backend et modifiez le schéma d’une base de données, demandez le fichier de migration, les points de compatibilité à examiner et des tests sur des données jetables. Une migration est une modification versionnée de la structure de la base ou des données qu’elle contient.

Un brief possible :

Prépare la migration pour ce changement de schéma en respectant les conventions du dépôt. Explique la compatibilité avec l’application actuelle, les possibilités de retour arrière et les risques de perte de données. Teste sur des jeux de données jetables lorsque c’est possible. Ne l’exécute pas en production et ne la déploie pas.

Le résultat attendu est une implémentation que vous pouvez examiner et un plan de déploiement plus clair. Écrire la migration ne règle pas les questions de verrouillage en production, de durée du backfill ou de coexistence entre l’ancienne et la nouvelle version de l’application. Ces décisions restent du ressort de la personne responsable du déploiement.

Examiner une pull request

Si vous maintenez un projet et attendez les modifications d’un collègue, précisez la branche ou les commits de la PR, ainsi que sa branche de référence. Demandez des constats étayés, sans modifier les fichiers de travail.

Un brief possible :

Examine cette pull request par rapport à sa branche de référence. Concentre-toi sur la justesse du code, les autorisations, la compatibilité et les tests manquants. Pour chaque problème relevé, indique son emplacement dans un fichier, un scénario d’échec concret et les éléments qui le démontrent. Ne modifie aucun fichier et ne fusionne pas la PR.

Pour la revue intégrée à GitHub, la procédure documentée par OpenAI prévoit un dépôt connecté et un commentaire @codex review sur la PR. Le guide de configuration des revues GitHub décrit ce fonctionnement. Code Review, Security Review et les intégrations GitHub et Linear existantes continuent d’utiliser Codex Cloud (Legacy) pendant la transition. La page d’aide sur Cloud confirme cette distinction.

Une demande de revue dans une nouvelle tâche cloud et une revue automatique sur GitHub correspondent à des workflows distincts.

Trois autres tâches à déléguer

Après la correction d’un test en échec, je classerais les tâches suivantes selon leur facilité à délimiter et à vérifier. Chacune est une proposition de workflow, pas le compte rendu d’un résultat obtenu.

À qui cela peut servirTâche proposéeIntérêt potentiel
À la personne qui maintient un SaaS et met à jour une dépendanceMettre à jour un paquet, corriger les appels concernés et exécuter les vérifications pertinentesTransforme un travail courant de compatibilité en correctif à examiner
À une équipe qui reprend un service qu’elle connaît malSuivre le parcours d’une requête et documenter ses dépendances ainsi que ses points de défaillanceFournit une carte concrète pour amorcer la prochaine enquête humaine
À un développeur qui refactorise un schéma de code récurrentModifier un module avec des tests qui préservent le comportement et un diff limitéPermet d’évaluer l’approche avant de l’étendre à toute la base de code

Conservez le critère d’acceptation dans le brief. « Améliore cette base de code » laisse trop de décisions ouvertes pour constituer une première mission utile.

Suivre et orienter une tâche depuis son téléphone

Revenez à la même tâche pour poursuivre son travail. Ouvrir une nouvelle tâche crée un espace de travail distinct et ne récupère pas les modifications non commitées de la première. Faites un commit des travaux importants. Par défaut, la fenêtre de récupération de la machine virtuelle sauvegardée va jusqu’à sept jours après le début du dernier tour de conversation ou la dernière reprise de la tâche ; il ne s’agit pas d’une règle de conservation de l’historique des conversations. Les indications d’OpenAI sur l’état des tâches précisent ce qui est sauvegardé.

Sur mobile, ouvrez Codex et sélectionnez l’environnement publié. Rouvrez la tâche pour suivre l’avancement et envoyer vos corrections. La présentation de Cloud décrit ce workflow entre appareils.

Un bon message de pilotage tranche une décision :

  • « Garde le correctif dans le parseur ; préserve la structure de la réponse publique. »
  • « Utilise une base de test jetable pour tester la migration. »
  • « Arrête-toi après le correctif et le rapport de tests ; laisse le déploiement en attente de revue. »

J’utiliserais le téléphone pour préciser le périmètre et vérifier l’avancement, puis un écran plus grand pour examiner un diff conséquent. L’accès distant à une tâche qui s’exécute sur votre ordinateur reste dépendant de cette machine ; il n’offre pas l’exécution ordinateur éteint de Cloud. La page d’aide d’OpenAI distingue ces deux modes.

Codex CLI ou Cloud : lequel choisir ?

Choisissez le cloud lorsqu’une tâche bien cadrée doit avancer de manière autonome. Choisissez la CLI locale lorsque le travail dépend des fichiers et des outils de développement déjà présents sur votre ordinateur.

La CLI peut examiner un dépôt local, modifier des fichiers et exécuter les outils installés. Ouvrez le répertoire du projet, lancez codex et connectez-vous avec ChatGPT. Elle peut aussi déléguer des tâches via codex cloud : l’interface de départ ne détermine donc pas où le travail s’exécute. Le guide de la CLI couvre les deux possibilités.

Les choix ci-dessous sont mes recommandations.

Type de tâcheCloud ou localPourquoi
Test en échec reproductible avant votre départCloudDes outils prêts et un critère d’acceptation clair conviennent au travail autonome
Préparer une migration avec des jeux de données jetablesCloudVous pouvez examiner le code et les preuves fournies par les tests avant de décider du déploiement
Examiner une PR loin de votre bureauCloudL’enquête peut avancer dans un dépôt déjà préparé
Petite modification nécessitant des décisions humaines fréquentesLocalLes échanges rapides dans le terminal facilitent le pilotage régulier
Travail nécessitant un SDK ou un simulateur propre à un appareilLocalUtilisez la chaîne d’outils déjà présente sur votre machine
Diagnostiquer un comportement dans votre application ou votre navigateur localLocalRestez au plus près de l’application en cours d’exécution et du contexte de l’appareil
Exécuter un script local reproductible ou une commande de CICLI localeLes workflows CLI s’intègrent aux scripts et aux pipelines

Les environnements Cloud actuels ne prennent pas en charge le pilotage de l’ordinateur ou du navigateur, GitLab, ni GitHub Enterprise Server auto-hébergé. Les skills personnels locaux ne sont pas synchronisés. Les limites actuelles comptent davantage qu’une préférence générale pour le cloud.

Deux espaces de travail à l’architecture structurée comparent le cloud, avec un ordinateur fermé et un téléphone, au travail local, avec un ordinateur ouvert et des outils installés.
Choisissez selon les besoins d’exécution : travail distant autonome ou accès direct à votre chaîne d’outils locale.

Limiter les accès et examiner le diff

Sachez ce que l’environnement peut atteindre. Les domaines autorisés déterminent les destinations réseau accessibles à la machine virtuelle ; ils n’accordent pas de droits sur les services. Les secrets réseau propres à l’environnement autorisent également leurs domaines. Les exigences Enterprise Agent Security s’appliquent en complément des réglages de l’environnement. Les pages configuration réseau et Agent Security décrivent ces contrôles.

Choisissez le bon mode de transmission des identifiants. Les variables d’environnement directes sont accessibles aux programmes. Les secrets réseau passent par des valeurs de substitution du proxy pour les destinations HTTPS approuvées sur le port 443, pendant la configuration et les tâches ; les identifiants bruts restent ainsi hors des processus et fichiers locaux. La page sur la gestion des secrets explique ce mécanisme.

Pour une première tâche de développement, je garderais les identifiants de production hors de l’environnement et utiliserais des accès de développement strictement limités. Avant de fusionner, lisez le diff, vérifiez la sortie des tests, examinez les changements de dépendances et confirmez que le correctif correspond au brief. Une suite de tests qui passe est un élément à évaluer, pas une raison de sauter la revue.

L’éligibilité d’un compte Healthcare ne signifie pas que Cloud est couvert par le BAA d’OpenAI, son accord encadrant le traitement des données de santé protégées. OpenAI demande de ne pas traiter de données de santé protégées dans Codex Cloud. Les restrictions de données de Cloud fixent cette limite.

Pour les contrôles d’équipe, consultez comment configurer la sécurité de Codex après DevDay.

Quels produits créer autour de ces workflows ?

La piste la plus solide est un kit pour corriger les tests qui bloquent une livraison, dédié à une seule stack. Vendez un workflow réutilisable et sa validation aux équipes qui perdent du temps sur des tests en échec. La vérification DataForSEO du 7 octobre estime à 1,600 le nombre de recherches mensuelles sur Google aux États-Unis pour « automated software testing tools ». Ce chiffre mesure l’intérêt pour ce type de travail, pas une demande spécifique pour Codex Cloud.

La plus petite version utile pourrait réunir des instructions pour le dépôt, des jeux de données de test reproductibles, des briefs de correction ciblés et un guide de préparation de l’environnement. Mesurez si les correctifs proposés préservent le comportement attendu et réduisent l’effort de revue. La difficulté vient de la diversité des infrastructures de test : couvrir de nombreuses stacks rendrait ce petit kit coûteux à maintenir.

Un pack de vérification des migrations pourrait servir aux équipes qui utilisent un framework et une base de données donnés. DataForSEO estime à 1,300 le nombre de recherches mensuelles aux États-Unis pour « database migration tools ». Un MVP pourrait fournir des modèles de migration, des données de test jetables, des contrôles de compatibilité et des prompts de revue qu’un développeur exécute dans un environnement préparé. La difficulté tient au comportement en production : un pack réutilisable ne peut pas promettre qu’un déploiement sur une vraie base sera sûr ou rapide.

Un pack de preuves pour les revues de PR pourrait aider les responsables de projet à uniformiser la manière de demander et d’évaluer les constats. DataForSEO estime à 1,300 le nombre de recherches mensuelles aux États-Unis pour « ai code review », et les questions observées dans la recherche incluent « Can ChatGPT do a code review? ». Commencez par des consignes pour le dépôt, des briefs de revue et un format de preuves pour les problèmes relevés. La difficulté : la revue intégrée existe déjà ; le pack doit apporter une appréciation propre au domaine et des contrôles utiles.

Ces trois produits sont des pistes fondées sur les possibilités documentées de délégation de tâches. Les volumes de recherche estiment l’intérêt pour un type de travail ; ce ne sont ni des nombres de clients ni des prévisions de chiffre d’affaires. Commencez par le kit de correction : son critère d’acceptation est plus facile à mesurer que la qualité générale d’une revue.

ChatGPT peut-il faire une revue de code ?

Oui. Codex dispose d’un workflow documenté de revue des PR GitHub, et vous pouvez aussi lui confier une tâche d’examen. Précisez la branche de référence et les risques à vérifier. La décision de fusionner reste humaine.

Le code généré par l’IA est-il sûr ?

Évaluez le correctif lui-même. Examinez les changements de comportement, les autorisations, les dépendances, les tests et les hypothèses non vérifiées. Ni une explication soignée ni des tests au vert ne prouvent que tous les cas importants sont couverts.

Les revues de code valent-elles le temps qu’on y consacre ?

Utilisez une revue par un agent lorsqu’un examen supplémentaire peut détecter une erreur coûteuse. Suivez les constats utiles et les fausses alertes. Si cette revue demande plus de travail qu’elle n’en économise, réduisez son périmètre.

À essayer dès lundi

Choisissez un dépôt avec une commande de test fiable. Préparez et publiez son environnement, déléguez un petit échec reproductible, puis consultez la tâche depuis votre téléphone après avoir quitté votre bureau. Examinez le correctif avant de fusionner. Notez l’effort de préparation, l’effort de revue et la consommation du quota. Réutilisez l’environnement si cet essai améliore votre workflow.

Pour intégrer ce workflow au processus de livraison de votre équipe, mettez en place un système de production IA.

Dernière mise à jour
7 oct. 2026
Catégorie
Build

Préférez ce site dans Google

Ajouter omidsaffari.com comme source préférée dans la recherche Google

Marquez omidsaffari.com comme source préférée et Google le met en avant pour vous dans Top Stories, AI Overviews et AI Mode.

Articles similaires
GitHub Copilot Pro et autres offres : calculer le vrai coût en 2026

GitHub Copilot Pro et autres offres : calculer le vrai coût en 2026

Prix de GitHub Copilot Pro, Pro+, Max, Business et Enterprise : crédits IA, coût des modèles et trois factures détaillées pour choisir et maîtriser son budget.6 oct. 2026Build
Copilot CLI : le guide pour travailler dans le terminal

Copilot CLI : le guide pour travailler dans le terminal

Installez GitHub Copilot CLI, connectez-vous et passez des tests à la pull request. Découvrez les tarifs, les crédits IA, les modèles et les permissions.6 oct. 2026Build
Scraping web en 2026 : huit outils, trois usages à distinguer

Scraping web en 2026 : huit outils, trois usages à distinguer

Quel outil de scraping web choisir pour une IA, une veille sans code ou une collecte à grande échelle ? Comparez huit solutions, leurs tarifs et limites.6 oct. 2026Build
Agent memory : quelle mémoire faut-il à vos agents IA ?

Agent memory : quelle mémoire faut-il à vos agents IA ?

Comprenez la mémoire des agents IA : contexte, sessions, stockage durable, coûts et méthodes pour corriger les faits périmés et isoler les données clients.5 oct. 2026Build
Base de données vectorielle : combien coûte Pinecone en 2026 ?

Base de données vectorielle : combien coûte Pinecone en 2026 ?

Tarifs Pinecone en 2026 : Starter gratuit, Builder à $20, minimums payants et coûts de 1M à 100M vecteurs selon les requêtes. Calculez votre budget.5 oct. 2026Build
Lovable gratuit ou payant : le guide des alternatives en 2026

Lovable gratuit ou payant : le guide des alternatives en 2026

Comparez les alternatives à Lovable gratuit ou payant : tarifs en dollars, crédits, backend et export du code pour choisir sans sous-estimer la migration.5 oct. 2026Build
LLM observability en 2026 : quel outil choisir selon votre équipe et votre budget ?

LLM observability en 2026 : quel outil choisir selon votre équipe et votre budget ?

Comparez six outils d’observabilité LLM : coûts selon la taille de votre équipe, limites gratuites, licences et hébergement pour choisir en production.5 oct. 2026Build
OpenCode : le guide pour coder avec le modèle de votre choix

OpenCode : le guide pour coder avec le modèle de votre choix

Installez OpenCode, connectez votre modèle, corrigez un vrai bug et configurez AGENTS.md et les plugins. Comprenez les coûts de l’API et de Zen.4 oct. 2026Build
Newsletter

Une lettre, chaque dimanche.Des systèmes qui tournent, pas des hot takes.

Hebdomadaire. Pas de spam. Désabonnement à tout moment.