Mettre en ligne un site React ou Vite généré par IA
Un aperçu de projet qui fonctionne précède le site prêt à publier. Demandez à l’assistant les fichiers du build, puis testez ce que les visiteurs recevront.
Par l’équipe SayLive
Sur cette page
TL;DR
Pour déployer un site React ou Vite généré par IA sur un hébergement statique, transformez le projet par un build en fichiers prêts pour le navigateur, puis publiez le dossier de sortie, généralement nommé dist. SayLive a lui aussi besoin de ces fichiers : il sert le résultat statique, tandis que le code serveur exige un autre hébergeur. Vérifiez les liens directs vers les pages et leur rechargement avant de considérer le déploiement comme terminé.
Pourquoi l’aperçu fonctionne-t-il avant que le site soit prêt ?
L’assistant a construit un site qui semble correct dans son aperçu. C’est un progrès, mais le dossier du projet peut encore demander une préparation avant qu’un navigateur ordinaire puisse utiliser ses fichiers sur un hébergement statique.
Le build est cette étape de préparation. Il transforme les sources, les fichiers utilisés pour développer le site, en HTML, CSS, JavaScript du navigateur et ressources associées. Le résultat est le livrable destiné à l’hébergement statique. Gardez les sources pour les prochaines modifications, mais demandez à l’assistant d’identifier séparément le dossier de sortie.
Pour le projet React/Vite de ce guide, cherchez dist et faites confirmer par l’assistant l’emplacement de sortie configuré. Le nom seul ne prouve rien : un dossier peut contenir d’anciens fichiers issus d’un build précédent. Ce qui compte, c’est que les sources actuellement validées aient produit les fichiers que vous allez publier.
Que demander à l’assistant ?
Préparez ce projet React/Vite pour un hébergement statique. Examinez ses instructions de build, identifiez les dépendances serveur, lancez le build de production si vous le pouvez et confirmez le dossier de sortie. Vérifiez les fichiers produits, y compris les images et les liens directs vers les pages intérieures. Gardez le design validé. Si vous ne pouvez pas exécuter de commandes, dites-moi exactement lesquelles lancer et ne présentez pas un build non testé comme une réussite.
Un build de production désigne la version terminée destinée aux visiteurs. Laissez l’assistant lire les instructions du projet au lieu de deviner une commande à partir du nom du dossier. S’il signale une erreur, demandez-en la cause et un build corrigé avant de publier. Envoyer un résultat incomplet complique le diagnostic du problème suivant.
Demandez si l’assistant a exécuté le build ou seulement décrit les étapes. Une commande suggérée et une commande exécutée ne constituent pas la même preuve. Vous devez savoir laquelle justifie l’affirmation que les fichiers sont prêts.
Pourquoi une page intérieure échoue-t-elle au rechargement ?
Une route côté client est une adresse de page gérée par JavaScript dans le navigateur du visiteur. Cliquer sur À propos peut changer l’adresse en /about alors que la même application reste ouverte. Mais une personne qui ouvre directement /about demande cette adresse à l’hébergeur avant que l’application ait démarré. Sans fichier correspondant ni règle de routage, elle peut obtenir une erreur de page introuvable.
Ces routes ont besoin d’une règle de repli : une instruction qui sert la page d’entrée de l’application pour les adresses de ses pages, afin que le navigateur puisse finir d’ouvrir la bonne vue. Demandez à l’assistant de vérifier la prise en charge et la configuration documentées de la destination. Ce guide ne suppose pas que SayLive fournit cette règle de repli.
Si la destination ne prend pas en charge la règle nécessaire, demandez à l’assistant d’adapter la navigation ou de produire de vraies pages statiques à ces adresses. Répétez ensuite les tests de lien direct et de rechargement. Un clic réussi depuis l’accueil ne teste pas le même parcours que l’arrivée d’un visiteur par un lien enregistré.
| Ce que vous voyez | Ce qu’il faut examiner |
|---|---|
| L’accueil fonctionne ; une page intérieure échoue au rechargement | Le routage côté client et la prise en charge d’une règle de repli par l’hébergeur |
| La page s’ouvre sans images ni mise en forme | Des fichiers manquants ou des chemins qui ne correspondent pas au dossier publié |
| Le site en ligne affiche encore le contenu d’hier | Vérifier si les fichiers envoyés proviennent du dernier build |
| L’interface s’ouvre ; une action sur les données échoue | Une dépendance serveur ou une interaction inachevée |
Que ne peut pas exécuter un hébergement statique ?
L’hébergement statique sert des fichiers préparés. Le JavaScript de ces fichiers peut toujours s’exécuter dans le navigateur du visiteur : les menus et les autres interactions du navigateur peuvent donc fonctionner. Le code qui doit s’exécuter sur un serveur est un besoin distinct. Produire les pages visibles par un build ne transforme pas les vérifications de mots de passe, les opérations en base de données ou les fonctions serveur en fichiers statiques.
SayLive prend en charge le HTML, le CSS, le JavaScript du navigateur et les images, sans comptes, bases de données ni code serveur. Demandez à l’assistant d’identifier ce que fait réellement chaque bouton important. Si une fonction centrale exige un serveur, choisissez un hébergeur adapté à l’application au lieu de livrer une interface qui semble fonctionner alors que cette fonction manque.
Un build terminé confirme que des fichiers ont été produits. Il ne prouve pas que toutes les fonctions marcheront chez l’hébergeur choisi. Testez le site issu du build et le site publié.
Que conserver pour la prochaine mise à jour ?
Gardez ensemble le projet source, les instructions de build et les fichiers finaux validés. Pour la prochaine modification, changez les sources, relancez le build et publiez les nouveaux fichiers produits. Modifier uniquement les fichiers finaux peut laisser les sources en décalage ; un build ultérieur risque alors de remplacer votre correction.
SayLive propose les versions et le retour arrière, et chaque version peut être téléchargée en ZIP. Consultez la documentation pour cette procédure. Une archive des fichiers publiés est utile aux côtés du projet source ; elle ne remplace pas les éléments nécessaires pour le reconstruire.
Une fois les vérifications techniques passées, faites la relecture du contenu. Vérifiez les noms, les coordonnées et les images aussi soigneusement que les routes. C’est cette version publiée que les visiteurs reçoivent.
Questions fréquentes
Puis-je publier les fichiers sources React directement sur SayLive ?
Lancez d’abord le build du projet et publiez les fichiers statiques produits. SayLive sert les fichiers finaux du navigateur ; il ne fournit pas un environnement de développement qui construit ou exécute le projet source.
Le dossier de sortie s’appelle-t-il toujours dist ?
Confirmez avec l’assistant le dossier de sortie configuré. Dist est le dossier à chercher dans cette procédure, mais la configuration du projet détermine ce que vous devez publier.
Pourquoi /about fonctionne-t-il au clic mais pas au rechargement ?
Le navigateur peut gérer la navigation une fois l’application ouverte, alors que l’hébergeur ne sait pas répondre à une requête directe vers /about. Vérifiez la règle de repli du routage ou générez une page statique pour cette adresse.
Statique signifie-t-il que la page ne peut pas être interactive ?
Non. Le JavaScript du navigateur peut gérer les interactions. La limite concerne le code qui doit s’exécuter sur un serveur, ce que l’hébergement de fichiers statiques ne fait pas.
Faut-il relancer le build après une modification ?
Oui, lorsque vous modifiez le projet source. Relancez le build et publiez les nouveaux fichiers produits pour que les fichiers en ligne contiennent la modification validée.
Comment passer du projet à une adresse en ligne ?
Les guides de publication expliquent comment connecter votre assistant. Si vous travaillez dans Cursor, utilisez son guide de publication. L’étape supplémentaire de ce projet est le build : l’assistant doit envoyer les fichiers finaux qu’il produit, avec la page d’entrée à la racine du site, au lieu de traiter tout le dossier de développement comme le site web.