Pour mettre en ligne une application web, vous compilez le code en fichiers statiques, vous les placez chez un hébergeur qui les sert en HTTPS, vous lui donnez les secrets dont l'application a besoin, et vous faites pointer un nom de domaine vers lui. Avec un créateur d'application IA, vous pouvez vous arrêter à la première étape : le créateur publie l'application pour vous. Si vous voulez un autre hébergeur, exportez le code vers GitHub et connectez le dépôt à Vercel ou Netlify, ou faites tourner l'application sur votre propre serveur.
Ce guide suppose une application avec un backend Supabase, ce que génère Cadrant, notre créateur. Les prix des hébergeurs tiers ne sont pas cités : ils changent souvent, consultez les pages des éditeurs.
Les trois façons de mettre en ligne une application web créée avec l'IA
Il y a trois endroits où héberger l'application : l'hébergement du créateur, un hébergeur comme Vercel ou Netlify, ou un serveur que vous gérez. Ils diffèrent surtout par la part du travail que vous faites vous-même.
- L'hébergement du créateur. Vous cliquez sur Publier et l'application est en ligne sur une URL du créateur, ou sur votre propre domaine. Rien à configurer à part le domaine. Votre code reste dans la chaîne de publication du créateur.
- Un hébergeur après un export GitHub. Vous poussez le code dans un dépôt GitHub, vous connectez le dépôt à un hébergeur, et celui-ci compile et déploie à chaque push. Vous contrôlez les paramètres de build et les variables d'environnement.
- Votre propre serveur. Vous louez une machine virtuelle, installez un serveur web, copiez les fichiers compilés, et gérez le certificat et les mises à jour. C'est le plus de contrôle et le plus de travail.
| Option | Comment l'application est mise en ligne | Ce que vous gérez vous-même | Limites |
|---|---|---|---|
| Hébergement du créateur (Cadrant) | Bouton Publier, URL du créateur ou votre domaine | Les enregistrements DNS du domaine, le projet Supabase | Lié au créateur : partir suppose d'exporter le code, ce qui demande le plan Pro sur Cadrant |
| Vercel ou Netlify | Dépôt connecté à l'hébergeur, déploiement à chaque push | Le dépôt, les paramètres de build, les variables d'environnement, le DNS, le plan de l'hébergeur | Les limites du plan de l'hébergeur s'appliquent, et le code est modifié à deux endroits sauf si le créateur pousse vers GitHub pour vous |
| Votre propre serveur | Vous copiez les fichiers compilés sur une machine que vous administrez | Tout : serveur, serveur web, renouvellement du certificat, mises à jour de sécurité, sauvegardes, supervision | Du temps. Utile pour la conformité ou des exigences particulières, rarement pour un premier lancement |
Ce que mettre en ligne implique concrètement
Mettre en ligne, c'est quatre choses : un build, la configuration dont l'application a besoin à l'exécution, une base de données qui reste où elle est, et un certificat HTTPS. Le premier et le dernier sont automatiques chez tout hébergeur moderne.
Le build
Une application React est écrite dans des fichiers qu'un navigateur ne sait pas exécuter directement. L'étape de build les compile en fichiers HTML, JavaScript et CSS simples, en général dans un dossier nommé dist ou build. L'hébergeur lance la commande de build (souvent npm run build) et sert ce dossier.
Variables d'environnement et secrets
Il existe deux types de valeurs, et les confondre est l'erreur de lancement la plus courante. Les valeurs publiques, comme l'URL du projet Supabase et sa clé publique (anon), sont embarquées dans l'application et conçues pour être visibles. Les valeurs secrètes, comme une clé secrète Stripe ou une clé de service d'e-mail, ne doivent jamais figurer dans le code de l'application ni dans une variable que le build expose au navigateur. Elles se placent côté serveur.
Dans une application créée avec Cadrant, les secrets vivent dans l'onglet Environnement du panneau Base de données et sont lus par les fonctions edge de Supabase : ils ne font donc jamais partie du bundle frontend. Voir la documentation sur les variables d'environnement. Si vous déployez ailleurs, l'hébergeur vous demande de ressaisir uniquement les valeurs publiques ; les secrets restent dans Supabase. Vercel précise que chacun de ses environnements (préproduction, production) peut avoir ses propres variables, ce qui permet de tenir les clés de test à l'écart des clés réelles.
La base de données reste sur Supabase
Déplacer le frontend vers un autre hébergeur ne déplace pas les données. La base de données, les comptes utilisateurs et les fichiers restent dans le projet Supabase, qui se trouve dans votre propre compte Supabase. C'est pourquoi changer d'hébergeur prend quelques minutes et ne fait rien perdre. Deux choses à faire après tout changement d'adresse : ajouter le nouveau domaine dans les réglages d'authentification, et tester la connexion. La documentation de Supabase indique que la Site URL, qui vaut localhost par défaut, doit être remplacée par votre URL de production, et que les URL de redirection forment une liste autorisée à laquelle les redirections de connexion doivent correspondre. Sans cela, les e-mails de confirmation et de réinitialisation de mot de passe pointent au mauvais endroit. Le détail est dans le guide Supabase sur les URL de redirection.
Le certificat HTTPS
Les navigateurs détournent les visiteurs des sites sans HTTPS, et la connexion ne fonctionne pas correctement sans lui. Vercel, Netlify et Cadrant émettent et renouvellent le certificat pour vous une fois le domaine vérifié. Sur votre propre serveur, vous l'installez et le renouvelez vous-même, en général avec un outil d'autorité de certification gratuite, et il faut veiller à ce que le renouvellement continue de fonctionner.
Comment connecter un domaine personnalisé
Connecter un domaine, c'est ajouter des enregistrements DNS chez l'entreprise qui gère le domaine, pour que le nom pointe vers votre hébergeur. Chaque hébergeur indique les enregistrements exacts ; recopiez-les tels quels plutôt que ceux d'un tutoriel.
- Achetez le domaine si vous n'en avez pas. Pour choisir un nom et une extension, lisez comment choisir l'extension d'un nom de domaine.
- Ajoutez le domaine dans les réglages de l'hébergeur. Celui-ci affiche alors les enregistrements à créer.
- Créez ces enregistrements chez votre fournisseur DNS (votre registrar, Cloudflare, etc.).
- Attendez que l'hébergeur affiche le domaine comme vérifié, puis ouvrez le site sur le domaine et testez la connexion.
Enregistrement A ou CNAME
Un enregistrement A fait pointer un nom vers une adresse IP, et un enregistrement CNAME fait pointer un nom vers un autre nom. La documentation de Vercel indique qu'un domaine racine comme example.com se configure avec un enregistrement A et un sous-domaine comme app.example.com avec un enregistrement CNAME, et que chaque projet a sa propre valeur de CNAME. La documentation de Netlify recommande, pour le domaine racine, un enregistrement ALIAS si votre fournisseur DNS le gère, et sinon un enregistrement A, plus un CNAME pour www. Les valeurs diffèrent selon l'hébergeur et le projet : utilisez celles affichées dans votre tableau de bord.
Domaine racine ou www
Le domaine racine (apex) est example.com, sans rien devant. Un sous-domaine est tout ce qui se place devant, comme www ou app. En DNS standard, un CNAME ne peut pas se placer sur la racine, ce qui explique que les configurations de domaine racine utilisent des enregistrements A, ALIAS ou ANAME. Netlify recommande vivement de faire d'un sous-domaine www votre domaine principal, car un domaine racine principal peut nuire aux performances avec certains fournisseurs DNS. La documentation de Cadrant donne le même conseil : préférez un sous-domaine comme app.monsite.com pour éviter les limites des domaines racines. Ajoutez les deux versions et redirigez l'une vers l'autre, pour que les visiteurs arrivent sur l'application dans les deux cas.
Propagation DNS
Un changement DNS peut mettre de quelques minutes à un jour ou plus pour atteindre tout le monde. La documentation de Netlify indique de compter jusqu'à 48 heures. Suivez l'avancement avec un outil comme dnschecker.org ou la commande dig, et cherchez d'anciens enregistrements en conflit sur le même nom : un ancien enregistrement A ou CNAME est la cause habituelle d'un domaine qui ne se valide jamais.
Comment Cadrant publie
Cadrant publie depuis le bouton Publier : vous choisissez un slug pour obtenir une URL Cadrant du type votre-app.cadrant.app, ou vous sélectionnez un domaine personnalisé ajouté dans la section Domaines. L'hébergement HTTPS et un domaine personnalisé sont inclus dans tous les plans payants, et une application publiée ne consomme pas de crédits.
Pour un domaine personnalisé, Cadrant affiche trois enregistrements DNS à créer chez votre registrar : un enregistrement TXT qui prouve la propriété, un CNAME qui valide le certificat et permet son renouvellement automatique, et un CNAME de routage. Pour un domaine racine, l'enregistrement de routage demande un ALIAS ou un ANAME si votre fournisseur le gère. La validation prend de quelques minutes à quelques heures ; un bouton Actualiser met à jour le statut. Cliquer de nouveau sur Publier remplace la version en ligne, et vous pouvez dépublier à tout moment. Les étapes complètes sont dans la documentation sur la publication.
La limite à connaître : il s'agit de l'hébergement du créateur. Si vous voulez votre propre hébergeur, l'export du code et le push GitHub sont réservés au plan Pro. Les tarifs sont sur la page des tarifs, et le créateur lui-même est décrit sur la page créateur d'application IA.
Tester sur une copie de préproduction avant de modifier l'application en ligne
Une copie de préproduction est un second déploiement de l'application, avec sa propre adresse et ses propres données de test, où vous vérifiez une modification avant que de vrais utilisateurs la voient. Dès que des personnes dépendent de votre application, testez d'abord là.
Chez un hébergeur, c'est intégré. Vercel crée un déploiement de prévisualisation, avec sa propre URL, pour chaque branche ou pull request, et permet d'attribuer un domaine de préproduction et des variables d'environnement séparées. Sa documentation indique que les déploiements de prévisualisation n'utilisent pas vos variables de production, et qu'un build de production peut aussi être mis en attente jusqu'à ce que vous le promouviez. Netlify propose des aperçus de déploiement similaires. L'intérêt de variables séparées est de pouvoir utiliser un projet Supabase distinct pour la préproduction, afin qu'un test ne touche jamais de vrais clients.
Dans un créateur, la copie de préproduction la plus simple est un projet dupliqué, connecté à un second projet Supabase et publié sur un second sous-domaine comme staging.votredomaine.com. Modifiez et testez là, puis reproduisez la modification sur le projet en ligne. Cela coûte un emplacement de projet, et les deux copies peuvent diverger, donc gardez la liste des changements courte. Appliquez d'abord les changements de base de données à la préproduction, et vérifiez les politiques comme expliqué dans notre guide sur la sécurité au niveau des lignes de Supabase (RLS).
Comment revenir en arrière après un mauvais déploiement
Revenir en arrière, c'est remettre en ligne la dernière version qui fonctionnait, et ce n'est rapide que si la version précédente a été conservée. Décidez comment vous feriez avant d'en avoir besoin.
- Dans Cadrant. Chaque prompt crée une nouvelle version, conservée indéfiniment. Vous pouvez prévisualiser n'importe quelle version passée et y revenir. Revenir en arrière ne supprime pas les versions suivantes, vous pouvez donc avancer de nouveau. Après le retour, cliquez sur Publier pour mettre cette version en ligne. Le retour restaure l'application, pas les données déjà modifiées dans la base. Voir la documentation sur le versionnage.
- Chez un hébergeur. Les hébergeurs conservent les déploiements précédents et peuvent réaffecter le domaine de production à un déploiement plus ancien, ou bien vous annulez le commit dans Git et laissez l'hébergeur redéployer.
- Sur votre propre serveur. Gardez le dossier du build précédent à côté du build actuel et rebasculez dessus.
Checklist avant le lancement
Avant d'annoncer que l'application est en ligne, vérifiez ces dix points. La plupart des problèmes de lancement figurent dans cette liste.
Pour le volet sécurité plus en profondeur, consultez notre guide sur la sécurité du vibe coding. Pour comparer ce que l'application peut faire avant de vous engager avec un créateur, partez de la liste des créateurs d'application IA.