ChatGPT Sites : le bouton « Publier » pensé pour les néophytes ?

Un site publié sans quitter la conversation

ChatGPT Sites permet de décrire un site ou une application légère dans le chat, de le prévisualiser, puis de le publier via une URL du type nom-du-site.chatgpt.site. La fonctionnalité est disponible en beta publique sur les plans payants, avec un déploiement progressif : Pro, Pro Lite, Enterprise et Edu en premier, Plus et Business ensuite.

Un Site peut servir de tableau de bord, de suivi de projet, de calendrier de publication, de prototype produit ou de portail interne. Un nom de domaine personnalisé peut être relié, à condition de le posséder déjà, sauf sur le plan Enterprise où l'option n'est pas encore proposée.

Sous le bouton Publier, un vrai pipeline Git et Cloudflare

Derrière l'apparente simplicité se cache une chaîne technique classique : code, build, version, déploiement. Un test réalisé sur un Site simple montre que le projet est un véritable dépôt Git local, modifiable à la main dans des fichiers Next.js et React standards. Ce dépôt est aussi poussé vers un second dépôt, privé, géré par OpenAI et utilisé comme référence pour la publication.

Au moment de publier, le code est compilé vers une sortie compatible Cloudflare Worker. Un fichier de configuration lie le projet à un identifiant Sites et à des ressources associées, comme une base de données ou un espace de stockage. Chaque publication crée une version reliée à un commit précis, ce qui permet de savoir exactement ce qui tourne en ligne.

Cette architecture impose aussi des limites nettes :

• pas de serveur Node.js permanent, le site tourne dans un environnement edge
  
• pas de langages serveur classiques comme PHP ou Ruby en production
  
• pas de base de données traditionnelle, uniquement les ressources proposées par Sites
  
• des fichiers volumineux à éviter dans le dépôt, images et vidéos lourdes comprises
  

Un référencement moins mauvais qu'on pourrait le croire

L'absence de backend classique laisse penser que ces sites seraient difficiles à indexer. L'examen du code source d'un Site test contredit cette idée reçue. Le titre, la description, le H1 et le texte principal sont bien présents dans le HTML brut, avant toute exécution de JavaScript, exactement ce qu'un moteur de recherche ou un robot d'indexation a besoin de lire.

Deux faiblesses réelles subsistent : l'absence de balises Open Graph, qui appauvrit l'aperçu lors d'un partage sur les réseaux sociaux, et l'autorité limitée d'un sous-domaine partagé comme chatgpt.site face à un nom de domaine propre. Le problème n'est donc pas l'indexabilité du site, mais son positionnement une fois indexé.

Une dépendance pensée dès la conception

Modifier les fichiers en local est possible, mais republier un Site nécessite de repasser par ChatGPT, dans l'espace Work ou Codex, pour relancer la compilation et la mise en ligne. Aucune option d'export simple n'a été observée pour reprendre entièrement la main sur l'hébergement ailleurs.

Ce fonctionnement rappelle le lock-in déjà connu chez des constructeurs de sites comme Webflow ou Squarespace, transposé à un assistant conversationnel. L'utilisateur ne loue plus seulement un hébergement, il loue la capacité même de continuer à faire vivre un projet qu'il pense pourtant posséder. Rester abonné devient la condition implicite pour garder un site à jour.

OpenAI vise-t-il vraiment Vercel, ou plutôt Claude et Gemini

La comparaison la plus utile n'est pas avec Vercel ou Netlify, mais avec ce que proposent déjà les concurrents directs d'OpenAI.

• Google AI Studio permet depuis mai 2026 un déploiement en un clic vers Cloud Run, avec authentification, base de données et hébergement via Firebase directement intégrés au flux de création. Techniquement plus complet, mais réservé à un outil développeur séparé de l'interface Gemini grand public.
  
• Gemini, dans son interface conversationnelle classique via Canvas, génère du code sans l'héberger : aucun bouton de publication, aucune URL en direct.
  
• Claude propose un bouton Publier qui transforme un artifact en page publique à l'adresse claude.ai/public/artifacts, mais uniquement statique, sans nom de domaine personnalisé, sans base de données ni versioning.
  

OpenAI n'est donc probablement pas le premier à combiner génération et hébergement par IA. Sa vraie nouveauté est ailleurs : intégrer ce parcours complet directement dans l'interface de chat grand public, plutôt que dans un outil technique séparé. Quand les modèles se ressemblent de plus en plus en qualité de réponse, la différenciation se déplace vers la capacité à livrer un résultat final directement utilisable et partageable.

Et si ces sites nourrissaient aussi les modèles d'OpenAI ?

Le web s'oriente vers un modèle où les agents IA paieraient pour accéder au contenu : le protocole x402, porté notamment par Coinbase et Cloudflare, permet à un serveur de réclamer un paiement en stablecoin avant de livrer une ressource à un agent, sans compte ni abonnement préalable. Cloudflare justifie sa propre passerelle de monétisation par un constat simple : les robots d'indexation IA sollicitent le contenu bien plus intensément que les visiteurs humains, ce que les modèles publicitaires classiques ne couvrent pas.

Dans ce contexte, héberger directement des millions de sites générés par ses propres utilisateurs donnerait à OpenAI un accès natif à du contenu frais, sans avoir à franchir les péages que le reste du web commence à ériger contre ses agents. Rien ne confirme officiellement cette intention : c'est une lecture possible de l'incitation économique en jeu.