Déployer un ZIP sur Vercel, Netlify ou Cloudflare

Un export HTML autonome n’a pas besoin d’un serveur applicatif complexe. Il lui faut surtout un hébergeur capable de servir les fichiers, gérer HTTPS, mettre le contenu en cache et associer votre domaine. Vercel, Netlify et Cloudflare Pages couvrent ce besoin, mais leur expérience de déploiement n’est pas identique.

1. Préparer le ZIP avant l’envoi

Décompressez le fichier dans un dossier de travail. La racine publiée doit contenir index.html. Ouvrez ensuite le site avec un serveur local pour détecter les chemins qui fonctionnent uniquement depuis votre ordinateur ou depuis le domaine source.

test local

cd votre-site
python3 -m http.server 8080
# puis ouvrez http://localhost:8080

index.html se trouve bien dans le dossier que vous allez publier.
Les liens internes utilisent des chemins compatibles avec le domaine final.
Les pages secondaires et la page 404 sont présentes.
Aucune clé privée ou variable secrète n’est incluse dans les fichiers publics.
Les formulaires ont une destination réelle ou affichent clairement leur état de démonstration.

2. Choisir selon votre workflow, pas selon le logo

Vercel convient bien aux équipes qui veulent une expérience CLI fluide et qui prévoient peut-être d’ajouter ensuite des fonctions ou un framework. Netlify reste très pratique pour un dépôt manuel par glisser-déposer et propose aussi un workflow Git/CLI. Cloudflare Pages est intéressant lorsque votre domaine, votre DNS et votre couche réseau sont déjà chez Cloudflare, ou lorsque vous souhaitez utiliser Wrangler et l’écosystème Workers.

Pour une landing statique, la performance perçue sera généralement davantage déterminée par le poids de vos images, polices et scripts que par le choix entre ces trois plateformes. Privilégiez donc l’outil que votre équipe saura mettre à jour et restaurer sans friction.

3. Déployer le dossier sur Vercel

Pour un site composé de HTML, CSS et JavaScript côté client, aucun build n’est nécessaire. Depuis la racine du projet, vous pouvez lancer la CLI. Le premier déploiement vous guide pour créer ou rattacher un projet ; l’option de production publie ensuite la version destinée au domaine principal.

Vercel CLI

npx vercel
# après vérification de la preview
npx vercel --prod

Dans l’interface, choisissez un preset générique ou “Other” lorsqu’aucun framework n’est utilisé, et laissez la commande de build vide. Si votre site se trouve dans un sous-dossier, définissez ce dossier comme racine du projet au lieu de déplacer artificiellement les fichiers.

Une configuration vercel.json n’est nécessaire que pour des besoins spécifiques comme les redirections, les en-têtes ou une réécriture de routes. Gardez-la courte et versionnée avec le site.

4. Déployer sur Netlify

Pour une mise en ligne immédiate, Netlify Drop accepte un dossier ou un ZIP contenant les fichiers du site. C’est le chemin le plus rapide pour obtenir une URL de preview sans créer d’abord un dépôt Git. Pour une maintenance régulière, préférez ensuite un projet lié à Git ou la CLI.

Dépôt manuel

Glissez le dossier contenant index.html dans la zone Netlify Drop, puis ouvrez l’URL de preview générée.

Validation

Testez toutes les routes, les formulaires, les fichiers lourds et le comportement du domaine temporaire.

Passage en workflow durable

Reliez un dépôt Git ou utilisez la CLI afin que chaque mise à jour soit traçable et réversible.

Netlify CLI

npx netlify deploy --dir .
# puis, après validation de la preview
npx netlify deploy --prod --dir .

Un déploiement manuel ne lance pas automatiquement une commande de build : publiez donc le dossier final, pas les sources d’un projet qui nécessiterait encore une compilation. Pour un site XportFrame statique, le dossier exporté constitue déjà la sortie à publier.

5. Déployer sur Cloudflare Pages

Cloudflare Pages permet de connecter un dépôt Git ou d’envoyer directement des assets préconstruits. Pour un dossier statique, Wrangler fournit une commande claire. Créez d’abord le projet dans votre compte si nécessaire, puis déployez le dossier qui contient l’index.

Wrangler

npx wrangler pages deploy .   --project-name=votre-projet

Décidez au départ si le projet sera principalement piloté par Git ou par upload direct. Les règles d’intégration et les possibilités de changement de mode peuvent évoluer ; vérifiez la documentation officielle au moment de créer le projet. Si vous utilisez un fichier Wrangler, gardez-le dans le dépôt et considérez-le comme une partie de la configuration de production.

6. Connecter le domaine et préparer les redirections

Ne supprimez pas l’ancien hébergement avant d’avoir validé l’URL temporaire. Ajoutez ensuite le domaine personnalisé dans la plateforme choisie et suivez les valeurs DNS indiquées. Le certificat HTTPS est généralement provisionné après la propagation DNS, mais conservez une fenêtre de migration pendant laquelle l’ancienne version peut encore servir les visiteurs.

Préparez une table de redirections avant le basculement. Chaque URL importante de l’ancien site doit conserver son chemin ou pointer vers une destination pertinente. Évitez de rediriger toutes les pages vers l’accueil : cela dégrade l’expérience et rend le diagnostic SEO difficile.

Attention aux previews

Les URLs de preview servent à valider les changements. Vérifiez qu’elles ne deviennent pas la version canonique et protégez-les ou marquez-les comme non indexables lorsque le contenu ne doit pas apparaître dans les moteurs.

7. Prévoir un rollback avant la mise en production

Un déploiement n’est sûr que si vous savez revenir à la version précédente. Conservez le ZIP validé, son hash ou sa date, et une copie de la configuration DNS. Les plateformes gardent généralement un historique de déploiements ; familiarisez-vous avec l’action de restauration avant d’en avoir besoin.

La dernière version stable est archivée séparément du dossier de travail.
Le domaine peut être repointé vers l’ancien hébergement si une panne majeure survient.
Les formulaires et outils de mesure sont testés après le basculement, pas seulement avant.
Une personne clairement identifiée peut décider et exécuter le rollback.
Les changements DNS, redirections et en-têtes sont documentés.

8. Décision rapide

Choisissez Netlify pour une première mise en ligne manuelle très directe, puis migrez vers Git ou la CLI pour les mises à jour répétées.
Choisissez Vercel si votre équipe aime le workflow CLI/preview et envisage d’ajouter plus tard des fonctions ou un framework.
Choisissez Cloudflare Pages si votre domaine et votre réseau sont déjà gérés chez Cloudflare ou si vous utilisez Wrangler et Workers.

Dans tous les cas, le dossier exporté reste le même. C’est précisément l’intérêt d’un HTML portable : vous pouvez changer d’hébergeur sans reconstruire le site.

Sources officielles à vérifier au moment du déploiement

Votre ZIP ne dépend d’aucun hébergeur.

Prévisualisez le site, vérifiez les routes, puis déposez le même export sur la plateforme qui convient aujourd’hui — et déplacez-le demain si nécessaire.

Tester avec une URL →