Un site qui ne tombe pas,
parce qu'il ne tourne pas.
Tu compiles chez toi, tu pousses le dossier de sortie, et c'est en ligne sur tous les nœuds. Pas de serveur à régler, pas de certificat à renouveler, pas de cache à comprendre — et si la dernière version est ratée, la précédente revient en un clic.
La page « Preuves » ne raconte rien : elle interroge le serveur qui te sert cette page et affiche ce qu'il répond, en-tête par en-tête.
Six choses que tu n'as plus à faire
Chacun de ces points correspond à une directive réellement posée dans la configuration de ton site — pas à une promesse commerciale.
Rien ne tourne
Aucun processus, aucun conteneur à surveiller, aucune fuite de mémoire à 3 h du matin. nginx lit des fichiers sur un disque — c'est la seule chose qui puisse tomber en panne, et c'est déjà la partie la plus éprouvée de la pile.
Le cache est déjà réglé
Les fichiers empreintés (le /_next/static d'un export Next, les app.a1b2c3.js d'un empaqueteur) partent avec un an de cache et immutable. Le HTML, lui, est marqué must-revalidate : après un déploiement, personne ne reste sur l'ancienne page.
HTTPS et en-têtes d'office
Certificat demandé automatiquement, HSTS d'un an, et trois en-têtes posés sur chaque réponse : nosniff, SAMEORIGIN, Referrer-Policy. Rien à configurer, rien à oublier.
Recopié sur chaque nœud
Une mise en ligne n'est pas un fichier posé sur un serveur : l'archive est distribuée à tous les nœuds de la flotte, qui la servent depuis leur propre disque. Un nœud qui tombe ne fait pas tomber le site.
Retour arrière instantané
Les cinq dernières mises en ligne restent restaurables d'un clic. Rien n'est recompilé, rien n'est retéléversé : on repointe le site sur une archive déjà présente.
_redirects et _headers
Le peu de « serveur » qu'un site statique peut avoir : deux fichiers texte, lus au déploiement et traduits en configuration. Les lignes refusées te sont montrées — une redirection mal écrite ne disparaît pas en silence.
Et aussi, sans rien demander
- gzip actif sur le HTML, le CSS, le JS, le JSON et le SVG
- robots.txt et sitemap.xml modifiables sans redéployer le site
- page 404 personnalisée (ton 404.html est servi tel quel)
- mode application d'une seule page : tout chemin inconnu rend index.html
- bouclier L7 par site : mode attaque, filtrage des robots, blocage des IA
- open_file_cache : sous une rafale, ce sont les appels système qui saturent en premier
Comment ce site est arrivé ici
Elles aboutissent au même endroit : une archive figée, recopiée sur les nœuds. Choisis selon l'endroit où ton site est compilé.
Depuis ta machine
La voie à prendre quand le site doit être compilé : ça se passe chez toi, seul le résultat part sur le réseau. Fonctionne aussi bien depuis un CI.
npm run build
npx ecloudserv-pages deploy --dir outDepuis un dépôt Git
Tu branches un dépôt public dans le tableau de bord, et un crochet redéploie à chaque push. Le dépôt doit contenir le site déjà compilé : rien n'est construit sur nos serveurs, ce serait y exécuter du code arbitraire.
git push origin main
# → le crochet fait le resteEn glissant un ZIP
Le plus court chemin pour un site déjà prêt : on dépose l'archive du dossier de sortie dans le tableau de bord, elle est lue, vérifiée et distribuée.
Tableau de bord → Pages
→ Déployer une archiveUne limite assumée : rien n'est compilé sur nos serveurs. Lancer le npm run build d'un dépôt quelconque chez nous reviendrait à y exécuter du code inconnu. C'est pourquoi la ligne de commande existe : elle compile là où le code est déjà de confiance, sur ta machine.