Cloudflare Pages + Workers : la stack statique-mais-dynamique

Le rendu côté serveur (SSR) a été vendu pendant des années comme la solution moderne au SEO et à la performance. En pratique, pour un site à fort contenu — landing pages, articles, fiches produits — un HTML statique pré-rendu bat un SSR sur presque toutes les dimensions mesurées. Le HTML statique est lui-même déjà un rendu côté serveur : simplement, ce rendu s’est produit au moment du build plutôt qu’au moment de la requête. Google indexe le HTML statique aussi bien que le HTML SSR — mieux, même, parce qu’il est plus rapide à servir et donc mieux noté sur les Core Web Vitals.

Le coût opérationnel est l’autre différence décisive. Un site SSR sur Vercel ou Heroku doit maintenir un processus Node tourner en permanence, scaler horizontalement aux pics de trafic, payer la bande passante à mesure que l’audience croît. Un site statique sur Cloudflare Pages n’a aucun de ces coûts : le HTML est cache-able indéfiniment au edge, la bande passante est illimitée sur le plan gratuit, et il n’y a aucun processus à surveiller. Le coût marginal d’une page supplémentaire est nul.

La contrepartie est que toute véritable logique dynamique — afficher le nom de l’utilisateur connecté, lister son panier, calculer un prix personnalisé — doit être déléguée : soit à du JavaScript côté client qui appelle une API, soit à un Worker invoqué sur un endpoint spécifique. Pour la plupart des sites à vocation de contenu, ces moments dynamiques sont rares et isolés. Le Sandwich statique-mais-dynamique modélise exactement cette réalité.

Vercel et Netlify offrent une expérience de développement excellente, mais leur modèle tarifaire devient agressif à mesure que vous gagnez en audience. Vercel facture à partir de 20 $/mois le plan Pro et ajoute des surcoûts de bande passante au-delà des limites incluses. Netlify facture les minutes de build, ce qui devient sensible dès qu’un site a quelques centaines de pages générées dynamiquement. Pour un projet personnel ou un MVP, ces plans sont raisonnables ; pour un site qui déploie plus de 10 000 pages comme celui de Pillar, ils deviennent prohibitifs.

AWS S3 + CloudFront reste l’option historique « cloud lourd ». C’est techniquement solide, mais l’ergonomie est franchement hostile : vous configurez manuellement le bucket, vous attachez une distribution CloudFront, vous gérez les invalidations de cache, vous ajoutez un certificat ACM, vous écrivez une fonction Lambda@Edge si vous avez besoin de logique. Vous êtes responsable de chaque petit cran — ce qui est exactement le coût caché qu’un développeur ne veut pas porter sur dix années.

Cloudflare Pages occupe le milieu : le sucré ergonomique de Vercel sans l’extension tarifaire, la robustesse mondiale d’AWS sans la configuration. Le plan gratuit est genuinement utilisable en production. Les Workers s’intègrent en quelques lignes : un fichier JavaScript, une route, un déploiement. Le même CLI wrangler gère Pages, Workers, KV, R2, D1 — toute la pile reste cohérente.

Un Worker Cloudflare est, dans sa forme la plus simple, un fichier JavaScript qui exporte un objet avec une méthode fetch. Cette méthode reçoit une Request et renvoie une Response. C’est tout : pas de framework requis, pas de routeur obligatoire, pas de dossier node_modules à bundler. Pour un cas d’usage typique — rediriger l’utilisateur vers un Stripe Payment Link en fonction d’un slug de produit — le Worker complet tient en une vingtaine de lignes : lire l’URL entrante, extraire le slug, mapper le slug vers un https://buy.stripe.com/<ID> via un objet, renvoyer une Response.redirect.

Le modèle d’exécution diffère fondamentalement d’AWS Lambda. Lambda enveloppe chaque fonction dans un conteneur, ce qui entraîne des cold starts de 200 ms à 2 s sur Node. Les Workers utilisent les V8 isolates — le même mécanisme que les onglets de Chrome — et démarrent en moins d’une milliseconde. Cela élimine toute une catégorie de problèmes : vous n’avez pas besoin de garder le Worker « chaud », pas besoin d’optimiser le startup, pas besoin de provisionner des concurrences. Le Worker s’exécute, répond, disparaît.

Le plan gratuit Workers inclut 100 000 requêtes/jour et 10 ms de CPU par requête. Pour une redirection Stripe ou un proxy de formulaire vers Formspree, 10 ms sont largement suffisants : la logique réelle consomme typiquement 1 à 2 ms. Une fois sur le plan payé (5 $/mois minimum), vous obtenez 10 millions de requêtes incluses et 50 ms par requête. Pour la plupart des sites à vocation de contenu, vous resterez sur le free tier indéfiniment.

Pillar exploite un portefeuille de plus de 100 000 domaines premium. Cela se traduit, côté site public, par plus de 14 000 pages HTML statiques déployées sur Cloudflare Pages : fiches de domaine, pages catégorie, articles de la Learn Library, landings produit. Toutes ces pages sont générées au moment du build et servies depuis le edge sans qu’aucun code applicatif ne s’exécute à la requête.

La couche dynamique tient dans un seul Worker : un helper de redirection qui, étant donné un slug de domaine, renvoie vers le Stripe Payment Link correspondant. Quand un visiteur clique sur « Acheter ce domaine », le Worker s’éveille en moins d’une milliseconde, fait un lookup en mémoire, et renvoie une réponse 302 vers https://buy.stripe.com/<ID>. Stripe gère alors le paiement, le reçu, la sécurité. Aucune donnée de carte ne transite par notre infrastructure. C’est l’application directe de notre Zero-Secret Architecture.

L’empreinte opérationnelle est minimale : pas de serveur à patcher, pas de base de données à sauvegarder, pas d’astreinte à tenir. Le coût Cloudflare mensuel pour servir cette infrastructure mondialement est essentiellement nul. Le même argent qui aurait payé un cluster Kubernetes finance directement l’acquisition de domaines — ce qui est la vraie source de valeur de l’entreprise.