Choisissez votre type d'application et votre hébergeur pour obtenir la commande de build, le dossier de sortie et le fichier de réécriture qui évite les 404 au rafraîchissement sur Vercel, Netlify, Cloudflare et GitHub Pages.
Pour déployer une application React, lancez le build de production, puis confiez le dossier de sortie à un hébergeur : dist pour Vite, out pour un export statique Next.js. Les applications monopages ont aussi besoin d'une réécriture qui renvoie les chemins inconnus vers index.html, sinon rafraîchir un lien profond renvoie une 404. Une application Next.js complète demande un hébergeur qui exécute Node.js.
Sortie du build selon le type d'application
La plupart des déploiements React ratés tiennent à trois choses : le mauvais dossier de sortie, une réécriture manquante pour les routes côté client, ou une fonctionnalité Next.js qui exige un serveur envoyée vers un hébergeur statique. Choisissez ci-dessous votre type d'application et votre hébergeur pour voir le réglage et le fichier exacts pour ce couple, chacun tiré de la documentation officielle de l'hébergeur.
Le routeur vit dans le navigateur, mais un rafraîchissement demande au serveur un fichier comme /about/index.html qui n'existe pas. Une réécriture qui renvoie index.html pour les chemins inconnus permet au routeur de reprendre la main. Chaque hébergeur a sa propre syntaxe pour cette règle.
Pas si votre build ne contient pas de 404.html à la racine. D'après la documentation de Cloudflare, Pages traite alors le projet comme une application monopage et sert l'index racine pour tout chemin qui ne correspond pas à un vrai fichier.
Uniquement sous forme d'export statique avec output: 'export'. GitHub Pages sert des fichiers et ne peut pas exécuter le serveur Next.js, donc les fonctionnalités comme les server actions, les cookies, les réécritures et le rendu à la demande n'y sont pas disponibles.
Une redirection envoie le navigateur vers une nouvelle URL, ce qui change la barre d'adresse. Une réécriture sert un autre fichier tout en conservant l'URL demandée, et c'est ce dont une application monopage a besoin. Netlify signale une réécriture avec le statut 200.
Définissez-les dans les paramètres du projet chez l'hébergeur, pas dans un fichier .env commité. N'oubliez pas que les variables livrées au navigateur sont publiques : gardez les clés qui doivent rester privées sur un serveur ou dans des fonctions serverless.
Où placer la règle fourre-tout (d'après la documentation de chaque hébergeur, octobre 2026)
La même règle que le fichier _redirects d'une ligne. Le statut 200 conserve l'adresse demandée par le visiteur.
Adapté du workflow du guide de déploiement de Vite (qui fixe chaque action sur un commit). Il lance le build à chaque push sur main et publie dist. Activez GitHub Actions comme source dans Settings, puis Pages.
Importez le dépôt ; Vercel détecte Vite. Ajoutez ce fichier à la racine du projet pour que les liens profonds chargent l'application.
Commande de build npm run build, dossier de publication dist. Enregistrez cette ligne dans public/_redirects pour que Vite la copie dans dist.
Connectez le dépôt et choisissez le preset Vite. Aucune règle n'est nécessaire tant que dist ne contient pas de 404.html à la racine, car Pages sert alors l'index racine pour les chemins inconnus.
Réglez base sur le nom de votre dépôt, lancez le build avec GitHub Actions et publiez dist. GitHub Pages accepte un 404.html personnalisé mais pas de règles de réécriture, la solution courante consiste donc à copier index.html vers 404.html après le build ; ces liens profonds se chargent alors avec un statut 404.
Vercel compile Next.js directement, un export statique est donc facultatif ici. Gardez-le seulement si vous voulez les mêmes fichiers partout.
Réglez le dossier de publication sur out. Chaque route a déjà son propre fichier HTML, aucune réécriture fourre-tout n'est donc nécessaire.
Utilisez npm run build avec le dossier de sortie out. L'export inclut un 404.html, Pages le sert donc pour les chemins manquants au lieu de la page d'accueil.
L'export statique est le seul moyen d'exécuter Next.js ici. Si le site se trouve sous un chemin de dépôt, réglez basePath pour qu'il corresponde.
Importez le dépôt et déployez. Vercel fait partie des adaptateurs vérifiés listés dans la documentation de déploiement de Next.js.
Netlify exécute Next.js via sa propre intégration, que la documentation de Next.js ne liste pas encore comme adaptateur vérifié. Consultez sa documentation pour d'éventuelles fonctionnalités manquantes.
Cloudflare exécute Next.js sur Workers via sa propre intégration, elle non plus pas encore adaptateur vérifié. Suivez son guide dédié au framework plutôt que le flux statique de Pages.
Impossible. GitHub Pages ne fait que servir des fichiers et ne peut pas exécuter next start. Passez à un export statique ou choisissez un hébergeur qui exécute Node.js.
Vite + React
Export statique Next.js
Application Next.js complète
Vercel
Netlify
Cloudflare Pages
GitHub Pages
Qu'avez-vous créé ?
Où va-t-elle tourner ?
Toutes les combinaisons application et hébergeur
Copier
Commencer gratuitement · Sans carte bancaire