Héberger React, Vue et des sites statiques connectés à des API externes

Oui, vous pouvez héberger un projet réalisé avec React, Vue ou un autre framework JavaScript lorsque le résultat de la compilation est un site statique. L'hébergement sert les fichiers HTML, CSS, JavaScript et les images déjà finalisés ; il n'a pas besoin de garder Node.js en cours d'exécution pour les afficher.

Une application moderne est généralement divisée en deux parties :

Frontend : il est compilé avec Vite, Webpack, Rollup ou un autre outil et génère un répertoire comme dist, build ou out. Vous pouvez le compiler sur votre compte avec Node.js et npm, y compris dans Deploy+, et publier le résultat normalement.
Backend externe : la base de données, l'authentification ou le stockage restent chez Supabase, Firebase, Strapi Cloud, Sanity, Airtable ou tout autre fournisseur. Le navigateur du visiteur se connecte à leur API en HTTPS : ce service n'est donc ni installé ni exécuté sur l'hébergement.

L'hébergement doit seulement être compatible avec ce qui s'exécute sur lui. Une API externe ne nécessite aucune prise en charge particulière de la part de l'hébergement.

Deux façons d'appeler l'API externe

Dans un frontend entièrement statique, la communication suit ce parcours :

Visitante → HTML, CSS y JS del hosting → API del proveedor

Dans ce cas, le navigateur appelle directement le fournisseur. Son API doit accepter les requêtes provenant de votre domaine via CORS, et vous devez y configurer les domaines autorisés et les URL de retour de l'authentification.

Vous pouvez aussi intercaler un backend PHP hébergé sur le compte :

Visitante → frontend del hosting → PHP del hosting → API del proveedor

PHP peut effectuer des requêtes HTTPS sortantes vers des API externes, avec cURL, Guzzle ou le client HTTP de frameworks comme Laravel. L'API doit être accessible et autoriser l'origine réseau, les identifiants et l'opération ; ses restrictions ou celles du serveur peuvent limiter une connexion donnée. Cette architecture est utile lorsque vous devez conserver une clé privée, valider ou transformer les données avant de les envoyer, ou éviter qu'une opération sensible s'exécute depuis le navigateur. PHP intervient bien dans ces requêtes, mais l'API et ses données restent hébergées chez le fournisseur externe.

Les restrictions CORS du navigateur ne s'appliquent pas à la communication entre PHP et le fournisseur. L'API continuera d'exiger ses identifiants, droits et limites d'utilisation habituels.

Quels projets conviennent et lesquels nécessitent un autre environnement

Projet ou fonction	Hébergement mutualisé	Raison
React, Vue, Svelte ou Angular compilés en site statique	Oui	Le serveur ne fait que livrer les fichiers générés
Projet Vite, Webpack ou Rollup dont le résultat est du HTML, CSS et JS	Oui	Node.js sert pendant la compilation, pas à la réception des visites
Astro ou un autre générateur configuré avec une sortie statique	Oui	Toutes les pages sont générées avant le déploiement
Next.js avec `output: 'export'`	Oui	`next build` crée un export statique dans `out`
Frontend qui interroge Supabase, Firebase, Strapi Cloud, Sanity, Airtable ou une autre API	Oui	Le service s'exécute hors de l'hébergement
Frontend qui interroge une API externe via PHP	Oui	PHP peut effectuer des requêtes HTTPS sortantes
Express, Nest, Koa ou un autre serveur Node.js écoutant sur un port	Non	Nous ne prenons pas en charge les programmes qui écoutent sur un port
Next.js avec SSR, Server Actions, routes d'API dynamiques ou fonctions serveur	Non	Nécessite le runtime de Next.js pour répondre aux requêtes
Serveur WebSockets	Non	Nous ne prenons pas en charge les programmes qui écoutent sur un port
Tâche Node.js permanente	Non	Nécessite un processus Node continu, sans prise en charge officielle

Pour les cas qui nécessitent un serveur ou un processus Node permanent, utilisez un environnement qui prend en charge et gère ce runtime, comme une plateforme d'applications ou un VPS. Les workers de files d'attente et les consommateurs écrits en PHP peuvent, eux, rester actifs en tant que processus persistants dans les offres Avanza, Max et Elastic, et le temps réel dans une application Laravel se résout avec un service compatible Pusher. Vous n'avez pas toujours besoin d'un accès root : cela dépend du service choisi. Le nom du framework ne détermine pas à lui seul la compatibilité : ce qui compte, c'est que le build aboutisse à des fichiers statiques ou que l'application exige d'exécuter un serveur.

Le cas de Next.js

Next.js peut fonctionner des deux façons, c'est pourquoi il suscite souvent des doutes. Pour produire un site statique, configurez l'export, par exemple dans next.config.mjs :

const nextConfig = {
  output: 'export',
};

export default nextConfig;

Lors de l'exécution de next build, Next.js crée le répertoire out, qui contient les fichiers à publier. La documentation des exports statiques de Next.js détaille les fonctions prises en charge par ce mode.

Un export statique ne peut pas résoudre à chaque visite une logique qui dépend d'un serveur Next.js, comme le SSR, les cookies lus côté serveur, les Server Actions ou les routes d'API dynamiques. Si le projet utilise ces fonctions, vous devez les adapter à une API externe ou à des endpoints PHP, ou héberger l'application dans un environnement qui prend en charge son runtime serveur.

Publier le projet avec Deploy+

Vous pouvez publier un frontend compilé avec Deploy+ : chaque déploiement clone le dépôt dans une nouvelle version, y exécute le build et ne la rend publique que lorsque toutes les commandes se sont terminées correctement.

Lors de la connexion du dépôt :

À l'étape Projet, choisissez Frontend compilé. Deploy+ propose dist comme racine web et un script qui exécute npm ci et npm run build.
Vérifiez le répertoire généré par votre projet. Conservez dist pour la configuration habituelle de Vite, mais remplacez-le par build, out ou un autre chemin si votre outil utilise un nom différent. Un export statique de Next.js utilise out.
Vérifiez le script proposé. Chaque ligne s'exécute dans un shell indépendant : toutes les lignes qui utilisent npm, npx ou node doivent donc activer NVM sur cette même ligne. Le profil est déjà préparé ainsi.
Dans Automatisation, activez Déployer au push si vous voulez que chaque modification de la branche choisie génère une nouvelle version.

Deploy+ vérifie Node.js avant d'exécuter un script qui en a besoin et l'installe automatiquement s'il n'est pas encore disponible sur le compte. Si votre package.json exige une version précise, sélectionnez-la avant le premier déploiement depuis Hébergement → votre service → Gestionnaire de paquets, comme l'explique le guide d'installation de Node.js et npm.

Si npm ci indique que le fichier de verrouillage est absent ou ne correspond pas, préparez-le en développement, testez les dépendances et enregistrez package-lock.json à côté de package.json avant de déployer. Conserver le fichier de verrouillage permet d'installer les mêmes versions des dépendances à chaque build.

Le script s'exécute avant l'activation de la release. Si l'installation des dépendances ou le build échouent, la version précédente reste publiée et les visiteurs ne reçoivent pas un site à moitié compilé. Si vous détectez un problème après la publication, ouvrez l'historique et utilisez Revenir à cette version sur une release antérieure. Lorsque cette release est encore conservée, Deploy+ change seulement le lien symbolique et le retour prend quelques secondes ; si elle a déjà été supprimée lors du nettoyage des anciennes versions, il devra la reconstruire depuis le dépôt et cela prendra plus de temps.

Le retour arrière change le code et les assets publiés, mais n'annule pas les opérations déjà effectuées dans l'API externe et ne restaure ni les données ni la configuration du fournisseur.

Le `.env` de Deploy+ et les clés du service externe

Deploy+ conserve le fichier .env dans le dossier partagé et le lie dans chaque release avant d'exécuter le script. Dans un frontend statique, le bundler lit les variables pendant le build : il n'existe aucun processus Node.js qui relise .env lorsqu'une visite arrive.

Toute valeur incluse dans le JavaScript compilé peut être vue par un visiteur depuis son navigateur. Changer le nom de la variable ou l'enregistrer dans un fichier .env ne la rend pas secrète.

N'incluez dans le bundle que des valeurs publiques, par exemple :

L'URL de l'API ou l'identifiant du projet.
Une clé que le fournisseur décrit expressément comme publique, publiable ou destinée au navigateur.
Des identifiants publics d'analytics ou de configuration.

N'incluez pas de mots de passe, clés d'administration, clés secrètes, clés service_role, jetons privés ni identifiants de base de données. Si une opération nécessite l'un de ces secrets, effectuez-la depuis PHP et conservez l'identifiant dans le .env partagé ou dans un autre fichier de configuration hors de la racine web. Chargez-le dans PHP via le système de configuration du framework ou une bibliothèque pour .env, sans l'envoyer au navigateur ni l'écrire dans les journaux.

Vite intègre au bundle les variables avec le préfixe VITE_, comme l'indique sa documentation sur les variables d'environnement. Next.js fait de même avec NEXT_PUBLIC_. En outre, ces valeurs sont figées à la compilation : si vous en modifiez une, vous devez relancer le build et déployer le résultat.

Les fournisseurs ne nomment pas tous leurs identifiants de la même façon et ne proposent pas tous une clé adaptée au navigateur. Consultez toujours leur documentation. Par exemple :

Supabase destine la clé publishable au navigateur et réserve la secret au serveur. Les anciens noms anon et service_role en sont les équivalents hérités. Sa documentation des clés indique que la clé publique doit s'accompagner de Row Level Security et de droits minimaux.
La configuration web et les clés de Firebase sont publiques par conception. Firebase protège les données au moyen des Security Rules et d'App Check, et non en cachant cette configuration.

Les clés publiques ne remplacent pas les contrôles d'accès. Activez chez le fournisseur les règles par utilisateur, les politiques de lignes, les droits de stockage, les restrictions d'utilisation et les autres protections appropriées.

Routes internes d'une SPA

Si votre application est une SPA avec un unique index.html et gère les routes dans le navigateur, un rechargement direct de /panel pourrait renvoyer une erreur 404. Dans ce cas, ajoutez dans son répertoire public un fichier .htaccess qui conserve les fichiers réels et envoie les autres routes vers index.html :

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.html [L]

Incluez le .htaccess dans le répertoire que l'outil copie dans le build ; il ne suffit pas de le laisser dans un dossier du dépôt qui n'est pas publié. La règle doit s'appliquer uniquement au frontend : si vous partagez la racine avec des endpoints PHP ou des routes d'API, excluez-les expressément pour ne pas leur renvoyer du HTML.

Cette règle est destinée aux SPA avec routage côté client. Ne l'utilisez pas telle quelle dans un export qui génère déjà un fichier HTML distinct pour chaque route.

Après la publication, ouvrez le site depuis son domaine définitif et testez l'accès direct à une route interne, la connexion, les appels à l'API et l'envoi de fichiers s'il existe.

CORS n'authentifie pas les utilisateurs et ne protège pas à lui seul l'API face à d'autres clients. Si vous ajoutez un intermédiaire PHP, validez la session et les droits et limitez les destinations et les opérations : ne créez pas un proxy ouvert qui accepte n'importe quelle URL du visiteur. Configurez aussi des délais d'attente et vérifiez le résultat avant de répéter des opérations ayant des effets.