Héberger un site statique : Cloudflare, Netlify ou un VPS

Héberger un site statique paraît être la partie facile du projet. Le site est un dossier de fichiers HTML, CSS et images fabriqué au moment de la publication, et presque n’importe quel hébergement sait le servir. C’est ce qui rend le choix trompeur : tous le servent vite, et les différences n’apparaissent qu’au premier quota épuisé ou à la première redirection qui ne fait pas ce qu’on croyait.

Ce site et Palmora, un portail immobilier que nous opérons pour un client, sont construits avec Astro. Le site et l’application web de Challenge Us, une application de défis de groupe que nous avons développée, sont servis en fichiers statiques par Cloudflare depuis septembre 2026. Voici ce que nous retenons de ces choix, avec les règles que les éditeurs publient eux-mêmes. Si la question est encore de savoir s’il faut quitter WordPress, commencez par pourquoi migrer vers un site statique avec Astro.

Ce qu’un hébergeur de site statique doit faire

Avant de comparer des noms, la liste de ce qu’on attend :

• Construire et déployer à chaque publication, sans intervention manuelle, y compris quand le contenu vient d’un CMS : un site headless avec Astro et Sanity se reconstruit à chaque publication grâce à un webhook.
• Garder les versions précédentes et revenir à l’une d’elles en un geste quand une publication casse quelque chose.
• Servir des aperçus privés d’une branche, pour relire avant de publier.
• Gérer les redirections et les en-têtes (cache, sécurité, noindex des aperçus) dans des fichiers versionnés avec le site.
• Servir le HTTPS sur votre domaine, certificat compris.

Netlify et Cloudflare cochent ces cases. La différence est ailleurs : dans ce qui est compté.

Ce qui est compté, et pourquoi c’est le vrai critère

Les fichiers servis

Chez Cloudflare, la documentation des fichiers statiques des Workers indique que les requêtes vers ces fichiers ne sont ni facturées ni limitées, et que leur stockage n’ajoute aucun coût. Seules les requêtes qui exécutent le code du Worker, pour un rendu à la demande par exemple, suivent la grille tarifaire des Workers. Pour un site réellement statique, un pic de trafic ne change donc pas la facture.

Chez Netlify, la page qui explique les crédits décrit, en octobre 2026, des offres en crédits : 300 crédits par mois sur l’offre Free, 1 000 sur Personal, à partir de 3 000 sur Pro. Un déploiement en production consomme 15 crédits, un gigaoctet de bande passante 20, et dix mille requêtes 2 ; les aperçus de branche ne consomment rien. Sur l’offre Free, vingt déploiements en production suffisent donc à épuiser le mois. Ces montants changent : relisez la page avant de décider.

Le code exécuté

C’est là qu’arrivent la plupart des surprises. Un site « statique » garde souvent quelques fonctions : un formulaire, un webhook, une page rendue à la demande. Netlify compte ce calcul en crédits, 10 par gigaoctet-heure ; chez Cloudflare, chaque requête qui réveille le Worker est facturée selon sa grille. Une fonction appelée à chaque visite fait monter la facture au rythme du trafic, ce qui annule l’intérêt du statique. Mieux vaut des fonctions rares, appelées seulement quand un visiteur agit : l’article sur les formulaires et la recherche sur un site statique montre comment.

Le compte partagé

Le piège le moins visible : sur certaines offres, le solde est celui du compte, pas du site. La même page de Netlify le dit sans détour : une fois le solde de crédits épuisé, tous les projets du compte sont mis en pause, et leurs visiteurs trouvent une page « Site not available ». Un site qui n’appelle aucune fonction s’arrête donc aussi, parce qu’un autre projet a consommé le solde.

C’est pour cette raison que nous avons sorti Challenge Us, en septembre 2026, d’une équipe Netlify partagée avec d’autres projets, où un dépassement de quota mettait en pause tous les projets de l’équipe. La leçon vaut au-delà de ce cas : un client, ou un produit qui vit sa vie, gagne à avoir son propre compte d’hébergement.

Les réglages qui surprennent

L’ordre entre redirections et fichiers. Selon la documentation de Netlify, une règle de redirection ne s’applique pas quand un fichier existe à cette adresse, sauf si on la force avec un !. Selon celle de Cloudflare, une règle du fichier _redirects s’applique toujours, qu’un fichier existe ou non. Une même configuration se comporte donc différemment d’un hébergeur à l’autre. Le site de Challenge Us renvoie vers l’application toute adresse qui n’est pas une de ses pages : cette règle vit dans le code de son Worker plutôt que dans _redirects, où elle aurait masqué les pages du site.

La page index.html. Par défaut, selon sa documentation, Cloudflare redirige /index.html vers /. L’application web de Challenge Us désactive ce comportement : son service worker sert justement index.html à chaque ouverture, et une redirection à cet endroit ferait échouer l’ouverture de l’application.

Les en-têtes réellement servis. Un fichier d’en-têtes ne vaut que pour les réponses auxquelles l’hébergeur l’applique. Sur Palmora, dont les pages sont rendues côté serveur, les en-têtes de sécurité déclarés côté hébergeur ne s’appliquaient pas au HTML rendu par le serveur : configurés depuis des mois, jamais servis. Dès qu’une page est rendue à la demande, vérifiez la réponse elle-même, avec curl -sI sur l’adresse publique, plutôt que la configuration.

Aucun de ces réglages n’est grave une fois connu, et tous se vérifient avant la mise en ligne, sur l’adresse d’aperçu.

Et un serveur à soi ?

Servir un dossier de fichiers depuis un serveur privé est simple. Nous exploitons nous-mêmes un serveur unique qui héberge une douzaine de services pour cinq entreprises clientes : c’est le bon outil pour des applications métier, rarement le meilleur pour un site public. Les raisons :

• pas de diffusion mondiale sans ajouter un CDN devant ;
• les certificats, les mises à jour du système et la surveillance redeviennent votre affaire ;
• pas de retour arrière intégré, sauf à le construire.

Il se justifie quand une contrainte l’impose : un hébergement déjà payé et imposé, une exigence de localisation des données, ou des visiteurs derrière des réseaux d’entreprise ou dans des pays qui filtrent certains services. Dans ce dernier cas, l’hébergeur compte d’ailleurs moins que la page elle-même : polices et ressources hébergées sur le site, aucun appel à un service tiers.

Cloudflare, Netlify ou serveur à soi : ce qui change

Comment choisir, en quatre questions

1. Le site exécute-t-il du code à chaque visite ? Si non, un hébergeur qui ne compte pas les fichiers servis rend le trafic indifférent au budget.
2. Combien de déploiements par mois ? Chez un hébergeur qui les compte, un site publié dix fois par jour par une équipe éditoriale ne coûte pas ce que coûte un site mis à jour chaque semaine.
3. Le compte est-il partagé avec d’autres projets ? Si oui, que se passe-t-il quand l’un d’eux épuise le solde ?
4. Qui gère le domaine et le DNS ? Avoir le DNS chez le même acteur que l’hébergement simplifie les certificats et les bascules.

Répondez à ces quatre questions, puis testez la configuration sur une adresse d’aperçu avant d’attacher le domaine. Si votre site actuel tourne sous WordPress ou Drupal, notre migration vers un site statique reprend chaque adresse, met le site en ligne sur un hébergement à quelques euros par mois et surveille la bascule pendant quatorze jours.

Questions fréquentes

GitHub Pages suffit-il pour un site d’entreprise ?

Pour un site vitrine léger, il peut suffire techniquement. Mais les limites d’usage publiées par GitHub précisent que Pages n’est ni prévu ni autorisé pour faire tourner une activité en ligne, une boutique ou un site principalement tourné vers des transactions commerciales. Elles fixent aussi 1 Go par site publié et une limite indicative de 100 Go de bande passante par mois. Pour un site commercial, prenez un hébergeur fait pour cela.

Changer d’hébergeur fait-il perdre du référencement ?

Non, tant que les adresses, les redirections et les en-têtes restent identiques : le moteur retrouve les mêmes pages aux mêmes adresses. Le changement se fait au niveau du DNS, sans toucher au site. Avant de basculer, vérifiez sur l’adresse d’aperçu du nouvel hébergeur quelques pages clés, chaque redirection et le plan du site, puis recommencez une fois le domaine attaché.

L’hébergement d’un site statique est-il vraiment sans coût ?

Presque, tant que le site n’exécute pas de code : chez Cloudflare, les fichiers servis ne sont ni facturés ni limités, selon sa documentation. Le coût arrive avec les fonctions, avec les déploiements nombreux chez un hébergeur qui les compte, et avec les comptes partagés entre plusieurs projets. Lisez les limites de chaque offre, pas seulement son prix d’appel, et datez votre lecture : ces grilles changent.