Héberger une application Node.js : VPS, PaaS et serverless

Héberger une application Node.js ne ressemble pas à héberger un site statique ou une page PHP. Node fait tourner un processus de longue durée qui possède son propre serveur HTTP : l'hébergeur doit donc maintenir ce processus en vie, le redémarrer en cas de plantage, et router le trafic public vers lui. Ce guide passe en revue les trois options réalistes et les briques nécessaires quelle que soit celle que vous choisissez.

Trois façons d'héberger Node.js

Presque tous les déploiements relèvent de l'un de ces modèles. Le bon choix dépend de la part du serveur que vous voulez gérer et du comportement de votre trafic.

• VPS (auto-géré) — vous obtenez une machine Linux avec un accès root complet. Contrôle maximal et coût prévisible, mais vous installez et maintenez vous-même Node, le gestionnaire de processus, le reverse proxy et TLS.
• PaaS (platform-as-a-service) — vous poussez le code (souvent via Git) et la plateforme construit, exécute et scale le processus pour vous. Moins de contrôle, mise en ligne plus rapide, généralement facturé à l'usage.
• Serverless / fonctions — vous déployez des handlers individuels plutôt qu'un serveur permanent. La plateforme les démarre à la demande. Idéal pour un trafic en pics ou faible, mais sans état et soumis aux démarrages à froid.

Maintenir le processus en vie avec PM2

Sur un VPS, lancer node server.js dans votre shell s'arrête dès que vous vous déconnectez, et rien ne redémarre après un plantage. Un gestionnaire de processus résout les deux. PM2 est le choix courant :

npm install -g pm2

# démarrer l'app et la nommer
pm2 start server.js --name web

# redémarrage automatique après un reboot serveur
pm2 startup
pm2 save

# commandes utiles au quotidien
pm2 list
pm2 logs web
pm2 restart web

PM2 fait aussi tourner votre app en mode cluster pour utiliser tous les cœurs CPU, la façon la plus simple de scaler une seule machine :

pm2 start server.js --name web -i max

Un reverse proxy devant Node

N'exposez pas Node directement sur le port 80/443. Placez un reverse proxy comme Nginx devant : il termine TLS, sert efficacement les fichiers statiques et peut router plusieurs apps sur une seule machine. Un bloc serveur Nginx minimal qui transmet le trafic à une app Node écoutant sur le port 3000 :

server {
  listen 80;
  server_name example.com;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

Les en-têtes Upgrade et Connection comptent si votre app utilise les WebSockets. Pour HTTPS, la voie habituelle est un certificat gratuit Let's Encrypt via certbot, qui modifie cette config pour vous.

Variables d'environnement et configuration

Ne codez jamais les secrets en dur (URL de base de données, clés d'API) dans votre source. Lisez-les depuis l'environnement avec process.env, et laissez la plateforme les injecter :

const port = process.env.PORT || 3000;
const dbUrl = process.env.DATABASE_URL;

app.listen(port, () => {
  console.log(`écoute sur ${port}`);
});

Sur un VPS, vous pouvez les garder dans un fichier .env (chargé par une bibliothèque, et exclu de Git) ou les passer via le fichier ecosystem de PM2. Sur un PaaS, vous les définissez dans le tableau de bord. Lisez toujours process.env.PORT — les plateformes managées vous attribuent le port.

Un flux de déploiement propre

Quel que soit votre hébergement, visez un déploiement reproductible plutôt que d'éditer les fichiers sur le serveur à la main :

• Récupérez le nouveau code (git pull ou un artefact CI).
• Installez uniquement les dépendances de production : npm ci --omit=dev.
• Lancez l'étape de build si vous en avez une (npm run build).
• Rechargez le processus sans coupure : pm2 reload web.

Sur un PaaS, toute cette séquence est déclenchée par un git push ; sur un VPS vous pouvez la scripter ou la brancher à un runner CI.

Quelle option choisir ?

Option	Vous gérez	Idéal quand
VPS	OS, Node, PM2, Nginx, TLS	Vous voulez le contrôle et un coût prévisible
PaaS	Juste votre code + variables d'env	Vous voulez livrer vite et scaler facilement
Serverless	Des handlers individuels	Trafic en pics ou faible, traitement sans état

Si vous débutez, un seul VPS bien configuré avec PM2 et Nginx fera tourner confortablement la plupart des apps Node et vous apprend ce que les plateformes managées automatisent. Passez à un PaaS ou au serverless quand le scaling ou la charge opérationnelle devient le goulot d'étranglement — pas avant.