Publier un site créé avec Codex

Codex peut vous aider à créer un site, mais la publication dépend du flux utilisé. Un site créé avec ChatGPT Sites peut être déployé et partagé depuis Sites. Si Codex a produit un projet de code dans un dossier ou un dépôt, vous pouvez le publier avec un hébergeur connecté à Git pour gérer séparément la construction et l’exécution.

Choisissez d’abord où le site doit vivre

ChatGPT Sites permet de créer, héberger et partager des sites ou applications légères. La page officielle indique qu’un site peut être public et relié à un domaine personnalisé. La fonctionnalité est en bêta publique ; sa disponibilité varie selon le forfait, l’espace de travail et la région. Si elle couvre votre besoin, utilisez la publication intégrée et vérifiez les droits d’accès avant le partage. Il n’est pas nécessaire de déplacer chaque résultat de Codex vers un autre fournisseur.

Un déploiement depuis un dépôt est une autre option. Il convient si vous voulez conserver le code dans votre flux Git, choisir le processus de build et d’hébergement, ou administrer un serveur et ses services séparément. Le guide OpenAI de Codex Cloud décrit des environnements de travail reliés à des dépôts ; cela ne fait pas de Codex l’hébergeur du dépôt.

1. Vérifiez ce que Codex a créé

Ouvrez les fichiers du projet et identifiez son framework et ses dépendances. Consultez package.json, le lockfile, le README et les consignes de build. Demandez à Codex de retrouver les commandes d’installation, de build et de démarrage dans ces fichiers au lieu de les deviner.

Puis distinguez ces cas :

• Site statique : le build produit du HTML, du CSS, du JavaScript et des ressources, souvent dans un dossier dist ou out. Un hébergement statique peut servir cette sortie.
• Application avec serveur : elle a besoin d’un processus à chaque requête, par exemple un serveur Node.js, une API, un worker ou un rendu côté serveur. Un dossier statique ne publie pas ce processus.
• Services externes : la connexion, une base de données, les envois de fichiers, l’e-mail ou une API d’IA peuvent fonctionner hors du site. Publier le frontend ne migre ni comptes, ni utilisateurs, ni données.

Si le projet ne s’ouvre que sur localhost, consultez d’abord la liste pour publier un site encore local.

2. Placez le projet dans un dépôt Git

Relisez les changements de Codex et testez le site en local. Excluez de Git les dossiers générés, les fichiers .env, les clés privées, les sauvegardes de base de données et les données utilisateur. Ne poussez pas de secrets dans un dépôt public. Créez un commit et poussez-le vers un fournisseur Git accessible à l’hébergement.

Projects accepte GitHub, GitLab et Bitbucket. Connectez le dépôt, choisissez la branche de production et vérifiez le framework détecté et les paramètres de build. Un projet JavaScript statique peut utiliser npm ci, npm run build et dist, mais le lockfile et la sortie réelle du projet font foi. Pour un exemple React et Vite testé, consultez le guide de déploiement depuis Git.

Le déploiement automatique lors d’un push dépend de la connexion au fournisseur et d’un webhook configuré et vérifié. Confirmez qu’il est actif avant de compter sur la publication de chaque commit. Projects affiche le commit en ligne et les logs du build ; corrigez la commande ou le dossier de sortie avant de connecter le domaine si le build échoue.

3. Configurez le runtime et les services

Si l’application a besoin d’une API ou d’un backend toujours actif, déployez-le comme service au lieu de choisir un dossier statique. Les services Projects fonctionnent dans des conteneurs et sont comptés dans le quota d’un forfait payant. Vérifiez les forfaits et limites Projects. Une application qui demande un serveur Node.js complet peut aussi convenir à un VPS administré par vos soins, selon le framework et le niveau d’administration souhaité.

Enregistrez les valeurs de production dans l’environnement d’hébergement et remplacez les identifiants de développement. Mettez à jour les URL de retour OAuth, les domaines autorisés, CORS, les règles d’accès à la base de données et les callbacks e-mail pour l’adresse HTTPS finale. Si le site appelle une API externe, sa clé privée doit rester côté serveur ; une variable intégrée au JavaScript du navigateur est visible par les visiteurs.

4. Testez l’adresse publiée

Ouvrez l’URL HTTPS depuis un autre appareil. Vérifiez la page d’accueil, une route interne saisie directement, les rechargements, les images, les formulaires, la connexion et chaque appel API. Consultez les logs du build et l’état du service. Si le site est public, testez-le aussi dans une session sans compte.

Quand tout fonctionne, connectez le domaine définitif et vérifiez à nouveau le DNS, le certificat, les redirections et les paramètres OAuth.

Codex produit du code, mais il n’existe pas d’intégration en un clic entre Codex et Hostbrid. ChatGPT Sites peut suffire pour un site léger si ses contrôles et sa disponibilité actuelle conviennent. Avec un dépôt, Git transporte le code et Projects construit la configuration vérifiée ; les services serveur et les intégrations externes demandent leur propre configuration et leurs tests.

Sources : ChatGPT Sites · OpenAI Academy : ChatGPT Sites · Using Codex Cloud · Guide Projects de Hostbrid