Chapitre 9.5 — Zéro-downtime & logs

⏱️ TL;DR — Déployer une nouvelle version ne doit pas afficher une page blanche à tes visiteurs. Le principe du zéro-downtime : builder à côté (l’ancienne version continue de servir), puis basculer en une opération rapide. Sur un service Node, systemctl restart coupe une poignée de secondes — souvent acceptable ; le vrai zéro-coupure demande soit le cluster reload de PM2, soit des releases par symlink (la technique industrielle, détaillée en Partie 13). On branche un healthcheck (/api/health) pour vérifier qu’une version est vivante avant de basculer, on apprend à lire et faire tourner les logs (journald), et on tranche enfin, sans dogme, quand un VPS bat Vercel pour du Next.js — et quand c’est l’inverse.

🎯 Objectifs

• Comprendre le principe du zéro-downtime : builder à côté, basculer vite.
• Savoir ce que valent reload vs restart pour un service Node.
• Brancher un healthcheck applicatif et s’en servir avant de basculer.
• Lire, filtrer et faire tourner les logs applicatifs (journald, rotation).
• Décider quand héberger sur VPS plutôt que sur Vercel (et l’inverse).
• Dérouler une checklist de déploiement Next manuel fiable.

Le problème : déployer sans page blanche

Le déploiement naïf est brutal : tu git pull, tu npm run build dans le dossier en cours d’exécution, puis tu redémarres. Pendant tout le build (dizaines de secondes à minutes) et le redémarrage, ton site est cassé ou down. Pire : si le build échoue à mi-chemin, tu as un .next/ corrompu et un site mort, sans version saine sous la main.

Le principe du zéro-downtime inverse l’ordre : on prépare la nouvelle version à côté, pendant que l’ancienne sert toujours, et on ne bascule que lorsque la nouvelle est prête et vérifiée. Trois approches, de la plus simple à la plus robuste.

Approche 1 — Build à côté puis restart

La version simple, sans outillage : tu build dans un dossier neuf, et tu ne touches au service qu’une fois le build réussi.

# L'ancienne version tourne toujours et sert les visiteurs pendant tout ca
cd /var/www/formacampus
git pull origin main       # recupere la nouvelle version
npm ci                     # deps exactes
npm run build              # BUILD : si ca echoue, on s'arrete AVANT de toucher au service
# -> build OK ? seulement maintenant on bascule :
sudo systemctl restart formacampus-web

Le point clé : le restart n’arrive qu’après un build réussi. Si npm run build plante, tu n’as pas redémarré : l’ancienne version tourne encore, ton site est toujours debout. La coupure se réduit aux quelques secondes du redémarrage de Node (le temps que le nouveau process démarre et réécoute sur 3000).

💡 Réflexe — Ne redémarre jamais avant d’avoir un build vert. Enchaîne npm ci && npm run build && sudo systemctl restart formacampus-web avec des && : si une étape échoue, les suivantes ne s’exécutent pas, et le service n’est pas touché. C’est la version pauvre mais efficace du « on ne bascule que si c’est prêt ».

reload vs restart pour un service Node

Sur Nginx, systemctl reload recharge la config sans couper — magique. Sur un service Node, c’est différent, et il faut être honnête.

• restart = stop puis start. Le process meurt, un nouveau démarre. Il y a une brève fenêtre (secondes) où l’app ne répond pas. Pendant cette fenêtre, Nginx renvoie 502 aux requêtes qui tombent pile là.
• reload = envoyer un signal pour recharger sans redémarrer. Mais une app Node ne sait pas recharger son code à chaud par défaut : il n’y a pas d’ExecReload utile pour un next start standard. reload sur un service Node basique ne fait donc rien d’utile (voire échoue si aucun ExecReload n’est défini).

Conclusion sans détour : pour un service systemd Node classique, c’est restart, avec sa micro-coupure. Le vrai zéro-coupure vient d’ailleurs :

• PM2 cluster (pm2 reload) : redémarre les instances une par une, il y en a toujours une qui répond (chapitre 9.3).
• Releases par symlink : deux versions coexistent, Nginx (ou un lien current) bascule de l’une à l’autre de façon atomique — la technique industrielle, montée en Partie 13.

⚠️ Piège — Croire que systemctl reload formacampus-web déploie ta nouvelle version « sans coupure ». Pour un service Node standard, reload ne recharge pas le code de l’app (Node ne gère pas ça tout seul) : au mieux il ne fait rien, au pire il échoue. Ne te fie pas à un reload silencieux pour penser que c’est déployé — vérifie que la nouvelle version répond vraiment (voir le healthcheck ci-dessous). Pour Node, le déploiement passe par restart ou par une bascule de release.

Approche 2 — Releases par symlink (l’atomique)

La technique pro (façon Capistrano/Deployer) : chaque déploiement crée un dossier daté, on y build, puis on fait pointer un lien symbolique current vers cette nouvelle release — en une opération atomique. Le service tourne sur current. Le rollback est instantané : on repointe current vers la release précédente.

# Schema (detaille en Partie 13)
/var/www/formacampus/
  releases/
    2026-07-15_1430/   <- nouvelle version, buildee ici
    2026-07-14_0900/   <- version precedente, gardee pour rollback
  current -> releases/2026-07-15_1430   <- le lien que le service suit

On construit tranquillement dans le nouveau dossier (l’ancien sert toujours), puis ln -sfn bascule current d’un coup, et un restart rapide fait repartir Node sur la nouvelle release. Rollback = repointer le lien et redémarrer. On industrialise ça en Partie 13 — CI/CD ; ici, retiens le principe : préparer à côté, basculer atomiquement, garder l’ancienne pour revenir en arrière.

Le healthcheck : savoir qu’une version est vivante

Comment être sûr que la nouvelle version tourne avant de l’annoncer prête ? On expose une route healthcheck minuscule qui répond « je suis en vie ». Par convention, /api/health.

// Une route Next (app/api/health/route.ts) qui renvoie un statut simple
// GET /api/health -> 200 {"status":"ok"}
{
  "status": "ok"
}

Après un déploiement, on teste la route avant de considérer que c’est bon :

# Attendre que la nouvelle version reponde 200 sur son healthcheck
curl -fsS http://127.0.0.1:3000/api/health && echo "  <- app en vie"
# -f : echoue si code HTTP >= 400  |  -s : silencieux  |  -S : montre l'erreur

Le healthcheck sert trois publics : ton script de déploiement (ne bascule que si /api/health répond 200), ton monitoring (Partie 14, qui pingue cette route et t’alerte si elle tombe), et un futur load balancer (Partie 15, qui retire une instance malade du rotation).

💡 Réflexe — Fais un healthcheck honnête mais léger. S’il se contente de renvoyer 200 {"status":"ok"}, il dit juste « le process Node répond ». Si tu veux qu’il atteste que l’app est réellement opérationnelle, fais-lui vérifier une dépendance critique (un SELECT 1 sur la base). Mais garde-le rapide et sans effet de bord : il est appelé souvent (monitoring, LB), il ne doit ni ramer ni écrire quoi que ce soit.

Lire et gérer les logs applicatifs

En service systemd, tout ce que ton app écrit sur la sortie standard (console.log, console.error) est capturé par journald. Pas besoin de fichier de log à gérer toi-même : journalctl est ta fenêtre.

journalctl -u formacampus-web -f              # suivre en direct (Ctrl+C pour sortir)
journalctl -u formacampus-web -n 200 --no-pager   # les 200 dernieres lignes
journalctl -u formacampus-web --since "1 hour ago"   # filtre par temps
journalctl -u formacampus-web -p err          # seulement les erreurs (priorite >= err)
journalctl -u formacampus-web --since today | grep -i "500"  # chercher un motif

La rotation : journald plafonne tout seul la taille de ses journaux (configurable dans journald.conf via SystemMaxUse) — tu n’as pas de disque qui se remplit sans fin, contrairement à un fichier .log naïf. Si ton app écrit aussi dans un fichier (/var/log/formacampus/…), là tu dois gérer la rotation avec logrotate, sinon le disque se remplit. On approfondit l’observabilité (métriques, alerting, agrégation) en Partie 14.

⚠️ Piège — Une app trop bavarde (console.log à chaque requête) noie les vraies erreurs et remplit les journaux. En prod, logue utile : les erreurs et les événements importants, pas chaque détail. Et si tu écris dans un fichier en plus de la sortie standard, branche logrotate dès le début — un /var/log/… sans rotation finit toujours par saturer le disque et faire tomber la machine, parfois des mois plus tard, au pire moment.

🔒 Sécurité — Attention à ce que tu logues. Un console.log(user) qui déverse un objet entier peut cracher des données personnelles (RGPD) ou des secrets (token, mot de passe) dans les journaux — lisibles par quiconque a accès au serveur, et conservés. Ne jamais loguer un mot de passe, un token, un numéro de carte ni un profil complet. Logue des identifiants (userId), pas des contenus sensibles.

VPS ou Vercel pour du Next.js ? Le rappel nuancé

Next.js est fait par Vercel, et Vercel héberge Next admirablement. Alors pourquoi ce cours ? Parce que le choix dépend du contexte, pas d’une religion.

La vérité : les deux sont légitimes. Vercel achète du confort ; un VPS achète du contrôle et un coût maîtrisé, au prix de l’administration — celle que ce cours t’apprend. Beaucoup d’équipes commencent sur Vercel et rapatrient sur VPS quand le coût, le RGPD ou les services longue durée l’exigent : c’est exactement le parcours de FormaCampus.

🧭 Sur FormaCampus — FormaCampus quitte son PaaS pour un VPS Ubuntu : facture qui grimpait avec le SSR, données d’apprenants à garder en UE (RGPD), et besoin de workers longue durée (envoi de mails, génération de certificats PDF) qu’un serverless coupait. Son déploiement type aujourd’hui : git pull && npm ci && npm run build, curl du /api/health pour vérifier, puis systemctl restart formacampus-web — coupure de deux secondes, absorbée par le Restart et les retries. Bientôt, la Partie 13 rendra tout ça automatique (GitHub Actions + releases par symlink) et zéro-coupure.

Checklist de déploiement Next manuel

Le pense-bête à dérouler à chaque déploiement, tant que ce n’est pas automatisé :

1. Code à jour : git pull origin main sur la branche de prod.
2. Deps : npm ci (jamais install en prod).
3. Env : les variables/secrets sont en place (.env.production hors git) ; rappel : NEXT_PUBLIC_* sont figées au build.
4. Build : npm run build — et on s’arrête là s’il échoue (le site tourne encore).
5. Bascule : systemctl restart formacampus-web (ou bascule de symlink).
6. Vérif : curl -f http://127.0.0.1:3000/api/health répond 200, et systemctl status est active (running).
7. Logs : un œil sur journalctl -u formacampus-web -f pour repérer une erreur au démarrage.
8. Public : curl -I https://formacampus.fr en 200 depuis l’extérieur — le vrai test utilisateur.

🐚 Au terminal — Le déploiement complet en une ligne enchaînée, sûre (chaque && ne passe que si le précédent réussit) :

cd /var/www/formacampus \
  && git pull origin main \
  && npm ci \
  && npm run build \
  && sudo systemctl restart formacampus-web \
  && sleep 3 \
  && curl -fsS http://127.0.0.1:3000/api/health && echo "  <- deploiement OK"

📚 La doc — Pour la rotation de fichiers de log : man logrotate. Pour journald : man journalctl et man journald.conf (dont SystemMaxUse). Le déploiement par releases atomiques et l’automatisation complète (build en CI, bascule sans coupure, rollback) sont le sujet de la Partie 13 — CI/CD ; la supervision (alerting sur le healthcheck) celui de la Partie 14.

✏️ Exercices

Exercice 1 — Le déploiement casse le site. Un collègue déploie ainsi : git pull, puis npm run build dans le dossier live, et le build échoue à mi-parcours — le site est maintenant down avec un .next/ corrompu. Qu’aurait-il fallu faire pour que le site reste debout ?

Exercice 2 — reload ou restart ? Pour appliquer une nouvelle version de code sur un service systemd Node classique (next start), quelle commande, et pourquoi pas l’autre ?

Exercice 3 — VPS ou Vercel ? Une équipe a une app Next avec SSR intensif, une facture PaaS qui explose, des données d’utilisateurs à garder en UE, et un worker d’envoi d’e-mails longue durée. Recommande, avec trois raisons.

🧠 Quiz de révision

Fin de la Partie 9. Ton front Next.js tourne en production, en service, en HTTPS, et tu sais le redéployer. On applique la même rigueur aux autres stacks : Partie 10 — Autres stacks (PHP, Symfony, WP…), à commencer par l’API Symfony de FormaCampus.