Déployez votre build Vite ou React depuis le dossier dist

Un build front-end moderne est, par nature, un dossier de fichiers statiques, c'est tout l'intérêt de l'étape de build. Vite, Create React App, Vue CLI, l'adaptateur statique de SvelteKit et Astro produisent tous un index.html ainsi que des bundles JS/CSS avec empreinte et vos assets. Aucun serveur n'est nécessaire pour les servir ; il vous faut juste un endroit où déposer les fichiers. Compresser ce dossier et le déposer ici est le chemin le plus court entre npm run build et une URL publique, sans CI, sans configuration de déploiement et rien à installer.

Chaque outil nomme le dossier de sortie différemment : Vite écrit dist/, Create React App écrit build/, un export statique Next ou Nuxt écrit out/, Jekyll et 11ty écrivent _site/ et public/. Pas besoin de retenir lequel, si votre ZIP contient l'un de ces dossiers (ou un unique dossier englobant créé en compressant depuis le bureau), nous détectons la vraie racine web et servons depuis celle-ci. Compressez la sortie du build plutôt que votre code source ; importer un projet brut sans build ne s'affichera pas, et nous vous préviendrons si nous ne trouvons pas d'index.html.

Les applications monopages routent dans le navigateur : /dashboard et /settings sont gérés par React Router ou Vue Router, pas par des fichiers HTML distincts. Cela signifie qu'un visiteur qui ouvre directement un lien profond, ou actualise une page interne, a besoin que le serveur renvoie index.html pour que son router prenne le relais. Activez le mode SPA et c'est exactement ce qui se passe : les chemins inconnus retombent sur index.html avec un code 200, si bien que les actualisations et les liens profonds partagés fonctionnent au lieu de renvoyer une 404. Laissez-le désactivé pour un site multipage classique et les chemins inconnus renvoient une vraie 404 (ou votre propre 404.html).

Les bons outils de build ajoutent une empreinte à vos bundles, app.4f3a9c2b.js, justement pour pouvoir les mettre en cache indéfiniment. Nous respectons cela : les assets avec hash de contenu sont servis avec un cache immuable d'un an, si bien que les visites répétées sont instantanées, tandis que votre index.html est servi sans cache pour qu'un nouvel import s'affiche immédiatement. Vous obtenez la performance d'un cache agressif sans le piège classique d'un fichier HTML obsolète pointant vers des bundles qui n'existent plus. Publiez un nouveau build en déposant un nouveau ZIP ; l'URL reste la même et les visiteurs reçoivent la nouvelle version dès leur prochain chargement.

Un build hébergé sur une URL aléatoire convient pour un aperçu, mais une vraie application veut une vraie adresse. Avec l'offre Pro, connectez votre domaine ou sous-domaine et nous provisionnons le HTTPS automatiquement, aucune configuration de certificat, aucun renouvellement. Cela en fait un foyer légitime pour un petit front-end de production : un outil interne, un site marketing, une application de documentation, un livrable client. Tout ce dont le navigateur a besoin pour exécuter votre application est servi correctement ; il n'y a simplement pas de backend, ce qui est la limite honnête de l'hébergement statique.

Ceci sert uniquement vos fichiers statiques compilés, rien d'autre : pas de rendu côté serveur à la requête, pas de routes API, pas de base de données. Si votre application appelle une API externe depuis le navigateur en HTTPS, cela continue de fonctionner. Si elle dépend de code serveur, composants serveur Next.js rendus par requête, endpoints SvelteKit, secrets d'environnement lus côté serveur, il vous faut une plateforme qui exécute ce serveur, et vous devriez exporter un build entièrement statique ou héberger ailleurs. Dit simplement : apportez votre sortie compilée, obtenez un hébergement statique rapide ; apportez une application dépendante d'un serveur, et l'hébergement statique n'est pas le bon outil.