Lors du DevDay du 29 septembre, OpenAI a affirmé que les développeurs « peuvent exécuter Codex là où ils en ont besoin : sur un ordinateur, à distance depuis un téléphone ou dans le cloud depuis n’importe quel appareil ». La phrase du récapitulatif du DevDay qui importe le plus pour une équipe vient juste après : des environnements de développement réutilisables « permettent de démarrer les tâches rapidement et offrent à votre équipe un environnement partagé avec des paramètres et des permissions approuvés ». Codex cloud est disponible sur les forfaits Plus, Pro, Business, Healthcare, Education et Enterprise.
Pour un développeur individuel, cela règle la question. Pour une équipe qui utilise déjà Claude Code sur une station de travail, Codex sur un serveur de build et Gemini sur l’ordinateur portable d’un collaborateur, cela ajoute un emplacement de plus. Le travail démarre désormais dans le cloud d’OpenAI, sur vos propres machines ou depuis un téléphone dans le train, et chaque endroit conserve son propre historique d’exécution. Savoir quel agent tourne sur quoi, ce qui s’est terminé et ce qui attend une revue implique de vérifier un endroit supplémentaire. La véritable question n’est donc pas « cloud ou local ? », mais plutôt : quelle tâche doit s’exécuter où, et où conserve-t-on la trace de ce travail ?
En résumé
Codex cloud est la solution idéale pour les tâches Codex qui doivent démarrer rapidement, continuer à tourner pendant la mise en veille de votre ordinateur portable ou être lancées depuis un smartphone, ainsi que pour les équipes souhaitant une configuration validée unique plutôt que de laisser chacun configurer son propre hôte. Vos propres Computers s’imposent lorsqu’une tâche nécessite Claude Code ou un autre Runtime non-Codex, des ressources matérielles supérieures à la VM par défaut de votre forfait, ou des fonctionnalités signalées comme non prises en charge dans la documentation des environnements cloud d’OpenAI : dépôts GitLab, utilisation du navigateur (browser use) ou services privés accessibles via SSH ou un protocole de base de données. Aucun de ces choix ne dicte qui a assigné le travail ni qui le valide : cela reste du ressort de l’équipe, au sein d’une Task.
Ce qu’offre un environnement Codex cloud
Un environnement cloud, selon la documentation d’OpenAI, « est la configuration réutilisable qu’utilisent les tâches : dépôts, dépendances, outils et paramètres d’accès ». Vous sélectionnez des dépôts GitHub, puis Codex les analyse, installe les dépendances et les outils, teste le workflow et demande tout ce qu’il ne parvient pas à déduire. Vous examinez le rapport de configuration et publiez l’environnement. Chaque nouvelle tâche démarre alors à partir de ce système de fichiers publié dans son propre espace de travail isolé, et les tâches « peuvent continuer à fonctionner pendant la mise en veille de votre ordinateur ».
Le modèle d’accès est bien plus rigoureux qu’un simple script d’installation contenant un jeton collé en clair. Les variables d’environnement sont transmises directement aux programmes. Les secrets réseau n’atteignent jamais les processus : les programmes reçoivent un espace réservé (placeholder), et un proxy y substitue le véritable identifiant uniquement pour les destinations HTTPS autorisées. L’accès à Internet est un paramètre que vous activez puis restreignez, à l’aide de présélections pour gestionnaires de paquets ou d’une liste personnalisée de domaines. Les services privés sont accessibles via un VPN, Tailscale étant le fournisseur pris en charge à ce jour, et les espaces de travail Enterprise peuvent demander des connexions OIDC pour obtenir des identifiants cloud éphémères.
Le lancement des tâches est tout aussi flexible. La présentation générale de Codex Cloud mentionne le web, l’application de bureau, le mobile et la CLI Codex, et les espaces de travail Enterprise avec délégation Cloud peuvent lancer des tâches depuis @ChatGPT dans Slack ou Microsoft Teams. Un environnement Enterprise peut être partagé avec l’espace de travail, ce qui permet à un nouveau collègue de démarrer directement depuis la configuration approuvée au lieu de devoir tout reconstruire. Pour les projets Codex, cela élimine une véritable source de dérive de configuration.
La gamme d’OpenAI elle-même aborde l’hébergement comme un choix au cas par cas selon la charge de travail, et non comme une réponse unique. Les Dots bénéficient chacun de leur propre machine cloud, et l’API Agents fonctionne avec un environnement hébergé par OpenAI ou auto-hébergé, comme nous l’avons expliqué dans qui exécute les agents. Codex peut désormais fonctionner indifféremment aux deux endroits.
Ce qu’offre un Computer Sharkly
Un Computer est un appareil connecté, un serveur ou un conteneur sur lequel un Agent peut exécuter des tâches. Selon les termes de la documentation de Sharkly Computers, il « fournit le système d’exploitation, les fichiers, les identifiants, l’accès au réseau et les outils nécessaires à un Agent ». Un léger service local l’enregistre, détecte les Runtimes qui y sont installés, reçoit les exécutions en file d’attente et transmet la progression en continu. Ce service établissant la connexion vers l’extérieur, une installation classique ne requiert aucun port entrant ouvert.
Trois caractéristiques sont essentielles pour cette comparaison. Premièrement, un même Computer peut exposer plusieurs Runtimes. Sharkly prend en charge Claude Code, Codex, Gemini, OpenCode, OpenClaw et Hermes ; un Runtime ACP personnalisé permet de gérer un outil que le service local ne détecterait pas, et un seul Computer peut desservir plusieurs Agents. Deuxièmement, l’isolation s’effectue par Task. En mode Temporary, chaque Task dispose d’un répertoire isolé, et les exécutions liées à un dépôt peuvent exploiter un worktree vierge — c’est ainsi que les agents parallèles évitent les conflits de fusion. En mode Specified, une exécution réutilise un répertoire local configuré avec ses dépendances, ses caches et ses services locaux déjà en place, une exécution à la fois. Troisièmement, vous gardez la main sur vos identifiants : un Agent gère des variables d’environnement classiques et secrètes, chaque exécution ne reçoit que l’environnement et les identifiants auxquels elle a droit, et un Computer en visibilité Personal reste accessible uniquement à son propriétaire.
La contrepartie, en toute franchise, est que la gestion de l’hôte vous incombe également. Si un Computer passe hors ligne, les nouvelles exécutions patientent jusqu’à sa reconnexion. L’application de bureau peut empêcher la mise en veille et, sur macOS, continuer à fonctionner capot fermé lorsque le système l’autorise, mais les longues exécutions sans surveillance ont plutôt leur place sur un serveur que vous contrôlez, comme nous l’expliquions dans notre article sur l’exécution distante des agents de code. La facturation reste inchangée : les Computers et les Runtimes ne consomment pas de sièges sur les forfaits de Sharkly, Sharkly ne vend pas de tokens, et un Agent Codex utilise le forfait ChatGPT ou la clé d’API avec lesquels sa CLI Codex est connectée.
Codex cloud ou votre propre Computer : tableau de décision
Chaque entrée relative à Codex cloud ci-dessous est issue de la documentation des environnements cloud d’OpenAI au 30 septembre. Les entrées concernant les Computers proviennent de la documentation de Sharkly.
| Besoins de la tâche | Option recommandée | Pourquoi |
|---|---|---|
| Un correctif lancé depuis un smartphone, ordinateur portable fermé | Codex cloud | Les tâches peuvent être lancées depuis un mobile et continuer à s’exécuter pendant la veille de votre ordinateur |
| Une configuration validée unique pour tous les membres de l’équipe | Codex cloud (partagé dans un espace de travail Enterprise) | Un seul environnement publié ; chaque tâche conserve son propre espace de travail |
| Aucun hôte à maintenir | Codex cloud | Codex prépare, teste et exécute l’environnement |
| Claude Code, Gemini, OpenCode ou un autre Runtime non-OpenAI | Votre Computer | Un Computer peut héberger plusieurs Runtimes côte à côte |
| Utilisation du système ou d’un navigateur (computer/browser use) au sein de la tâche | Votre Computer | La documentation indique que l’utilisation du système et du navigateur n’est pas encore prise en charge dans les environnements cloud |
| Un dépôt sur GitLab ou GitHub Enterprise Server | Votre Computer | Également mentionné comme une limitation actuelle du cloud |
| SSH, un protocole natif de base de données ou un DNS privé | Un Computer situé sur ce réseau | Le VPN cloud gère le trafic HTTP et HTTPS sur IPv4, sans DNS privé, SSH ni protocoles natifs de base de données |
| Ressources matérielles spécifiques, ou supérieures à la VM par défaut | Votre Computer, ou une demande Enterprise | Par défaut : 2 vCPU, 8 Gio de mémoire, 8 Gio d’espace disque sur Plus ; 4 vCPU, 16 Gio, 32 Gio sur Pro, Business et Enterprise. Pour des capacités supérieures ou sur mesure, contactez l’équipe commerciale d’OpenAI |
| Un très gros dépôt avec un état local lourd à reconstruire | Un Computer local, mode Specified | Réutilise le répertoire existant plutôt que d’en préparer une copie |
| Des skills hébergés uniquement sur votre ordinateur portable | Votre Computer | Les skills personnels locaux ne sont pas synchronisés vers les environnements cloud, contrairement aux skills du dépôt |
Voyez cela comme une grille d’arbitrage. Utilisez Codex cloud lorsque la tâche relève de Codex, que ses dépendances sont publiques ou accessibles via du HTTPS autorisé, et que la personne qui la lance n’est pas forcément devant son bureau. Utilisez vos propres Computers lorsque la tâche requiert un Runtime, du matériel ou un réseau spécifiques que vous avez délibérément choisis.
Une ligne est volontairement absente : « des données qui ne doivent pas quitter notre réseau ». Travailler sur votre propre Computer permet de conserver le dépôt, les caches et les secrets sur du matériel que vous contrôlez. Mais cela n’empêche pas les prompts de transiter vers le fournisseur du modèle, car tout ce que le Runtime envoie à son modèle quitte malgré tout votre infrastructure. OpenAI trace la même distinction pour son propre produit : la documentation de l’API Agents précise que « le choix d’un bac à sable auto-hébergé ne rend pas l’API Agents éligible au ZDR ». Le choix de l’hébergement détermine où résident le code et les identifiants. La rétention des données fait l’objet d’un contrat distinct avec le fournisseur de votre modèle.
C’est dans le placement hybride que le tableau de bord prend tout son sens
La plupart des équipes adopteront une approche hybride. Les correctifs rapides sur Codex seront lancés depuis un smartphone dans un environnement cloud, tandis que la migration nécessitant la base de staging tournera sous la forme d’un Agent sur un Computer situé à l’intérieur du réseau. C’est une répartition logique, mais elle produit deux listes de travail distinctes.
De par sa conception, Codex cloud isole strictement les tâches : l’accès à un environnement partagé, précise la documentation, « ne donne pas accès à la tâche de quelqu’un d’autre ». C’est un choix par défaut judicieux pour la confidentialité. Mais cela implique aussi que si la configuration est partagée, le travail ne l’est pas. Dès lors, pour répondre à la question : « que font les agents de l’équipe en ce moment ? », qu’il s’agisse de tâches cloud ou sur vos Computers, il faut se tourner vers un autre outil. Formalisez d’abord les règles de routage :
Where does this Task run?
1. Needs a non-Codex Runtime -> Agent on a Computer
2. Needs SSH, a database protocol, or private DNS -> Computer inside that network
3. Needs GitLab, GitHub Enterprise Server, or browser use -> Computer
4. Codex work, allowlisted HTTPS, started away from a desk -> Codex cloud
5. Someone must accept the result -> a Task with an Assignee and a reviewer, wherever it ran
La règle numéro cinq est précisément celle qui rend cette répartition gérable. Dans Sharkly, la Task fait office de référence centrale : progression, journaux d’exécution, points de blocage et résultats y sont tous consignés, et une exécution en attente de validation humaine arrive directement dans l’Inbox du responsable. Un Agent Codex et un Agent Claude Code tournant sur le même Computer rendent compte sur le même tableau, chacun s’appuyant sur le modèle configuré pour son Runtime. Pour le travail exécuté dans Codex cloud, le lien s’établit via la pull request : indiquez l’identifiant de la Task dans le nom de la branche ou le titre de la PR, et l’intégration GitHub de Sharkly se charge de rattacher la PR à la Task. Ainsi, la validation reste centralisée en un seul endroit. Notre article sur les exécutions d’agents qui dépassent votre journée de travail aborde en détail la revue de ces processus longs et autonomes.
Les agents explorent, exécutent, testent et rendent compte. Les humains donnent la direction, accordent les autorisations et valident le résultat. Ce contrat ne change pas, quel que soit l’endroit où l’exécution a eu lieu.
Ce que cela implique pour votre organisation
Codex cloud est une excellente réponse à la question « où exécuter Codex ? ». En revanche, il n’a pas été conçu pour répondre à la question : « sur quoi travaille chacun de nos agents, quel que soit son Runtime, et qui a validé son travail ? ». Conservez un Computer pour les tâches qui requièrent vos propres Runtimes, votre matériel ou votre réseau, confiez à Codex cloud les tâches déclenchées depuis un mobile ou ordinateur fermé, et centralisez le suivi des deux en un seul endroit.
Si vous souhaitez continuer à utiliser plusieurs agents de code sans vous enfermer dans un seul écosystème, c’est exactement la problématique pour laquelle Sharkly a été conçu.
