OpenAI a lancé ChatGPT Work début juillet. La communication officielle se résumait à : « utilise Work pour les tâches, Chat pour les réponses. » Simon Willison, qui teste les LLMs depuis plus longtemps que la plupart des gens n’en ont entendu parler, vient de publier une analyse complète après des heures d’exploration. Résultat : Work n’est pas Chat avec des options supplémentaires. C’est un environnement d’exécution à part entière, avec quatre fonctionnalités qu’on ne trouve nulle part dans Chat. Deux d’entre elles changent vraiment quelque chose pour un builder solo.
Ce que Work a que Chat n’a pas (et qu’OpenAI n’a pas bien expliqué)
Willison a listé les quatre différences concrètes entre les deux interfaces :
- Exécution de code avec accès internet complet. Dans ChatGPT Chat classique, le bac à sable de code est fermé derrière un proxy restrictif. Work Cloud lève cette restriction : il peut cloner des repos GitHub, installer des dépendances npm ou pip, et interagir avec n’importe quelle API externe. À titre de comparaison, Claude Code permet l’accès internet mais sur une allowlist de domaines très courte (PyPI, npm, GitHub, point). Work est ouvert par défaut.
- Un navigateur Chrome headless complet. Pas un simple outil de recherche : un vrai Chrome piloté par Playwright. Work peut charger une page, remplir des formulaires, exécuter du JavaScript sur le DOM et prendre des screenshots. Si le site demande une connexion avec 2FA, Work peut te passer la main pour entrer le code sans que tes identifiants transitent par le modèle lui-même.
- Un filesystem persistant entre sessions. ChatGPT Chat repart d’un dossier vide à chaque conversation. Work maintient un volume partagé entre toutes tes sessions Work. Willison a 171 dossiers de travail accumulés sur le sien. Les fichiers créés dans une session sont accessibles dans la suivante.
- Des sous-agents en parallèle. Chat ne peut pas orchestrer d’autres instances du modèle. Work peut lancer des sous-agents Sol, Luna ou Terra pour déléguer des sous-tâches en simultané.
Ce que tu peux faire avec ça, concrètement
Le cas d’usage le plus direct pour un builder : tu demandes à Work de cloner un repo GitHub, d’installer ses dépendances, et d’appeler une API externe pour te renvoyer un résultat traité. Avant Work, ce type de workflow nécessitait soit de configurer un environnement local, soit de passer par un outil comme Replit ou Colab. Maintenant c’est dans l’interface de chat, disponible depuis le mobile.
Le navigateur headless, lui, donne accès à ce que Willison appelle « shot-scraper depuis ton téléphone ». En pratique : extraire des données d’un site qui n’a pas d’API, prendre des screenshots automatisés pour un rapport, ou faire du QA visuel sans setup. Ce type d’automatisation était réservé aux devs qui savaient installer Playwright. Là c’est une ligne de prompt.
Il y a aussi un quatrième outil que Willison mentionne et que je trouve sous-estimé : ChatGPT Sites. Work peut builder et déployer un site complet sur Cloudflare Workers, avec HTML, JavaScript, base de données D1 et stockage R2. Willison a créé un exemple fonctionnel en une seule conversation. Ce n’est pas un concurrent de Webflow ou WordPress. Mais pour un MVP, un outil interne ou une landing page de test, la vitesse d’exécution est difficile à battre.
« Use Chat when you want an answer. Use Work when you want an outcome. »
OpenAI, reformulation personnelle de Willison, la distinction qu’ils auraient dû communiquer dès le premier jour
La question de sécurité que Willison soulève et qu’OpenAI n’a pas encore répondue
Willison utilise depuis longtemps le concept de « lethal trifecta » pour décrire les risques des agents IA : un système qui combine accès à des données privées, exposition à du contenu tiers non contrôlé, et un canal de sortie pour exfiltrer des informations. ChatGPT Work coche les trois cases en même temps.
Le navigateur headless peut charger n’importe quelle page. Ces pages peuvent contenir des instructions d’injection de prompt conçues pour manipuler l’agent. L’agent a accès à ton filesystem persistant et peut faire des requêtes HTTP. Si quelqu’un a pris le temps de placer une charge dans une page que tu demandes à Work de visiter, la surface d’attaque est réelle.
OpenAI affirme utiliser le même mécanisme d’auto-review que Codex. Willison note que ce n’est pas documenté en détail, et qu’il aimerait plus de transparence. Ce n’est pas une raison de ne pas utiliser Work. Mais c’est une raison de ne pas lui donner accès à ton mot de passe manager ou à des documents confidentiels au même moment où tu lui demandes de visiter des pages inconnues.
Ce qui reste flou après l’article de Willison
Work est disponible à partir de 20 $ par mois. Willison note que les sessions Work sont décomptées du quota Codex, pas du quota Chat, ce qui signifie que tu peux tomber à court plus vite que prévu si tu fais tourner des agents intensifs.
La vraie confusion vient du fait qu’OpenAI a lancé Work sans expliquer ses outils ni ses system prompts. Willison a dû demander à Work de builder un site listant ses 223 outils enregistrés pour comprendre ce qu’il avait entre les mains. Ce n’est pas un reproche rhétorique : un builder qui ne sait pas ce que son outil peut faire ne peut pas en tirer la valeur maximale.
La bonne nouvelle : l’article de Willison fait maintenant office de documentation officieuse. Si tu utilises ChatGPT Work, lis-le avant de lancer quoi que ce soit de complexe. Il a fait le travail à ta place.
Quel modèle mettre sur quelle tâche de ton activité, et pour quel coût réel : c’est ce que tranche l’audit et cadrage IA.
Source primaire : Understanding ChatGPT Work de Simon Willison (30 août 2026). Page officielle ChatGPT Work.