Si vous gérez des applications web ou des sites à fort trafic, vous connaissez le vieux compromis. D'un côté, un serveur dédié (un VPS, une instance AWS EC2) vous donne de la flexibilité, et en échange vous surveillez des bases de données qui saturent et une facture d'hébergement qui grimpe. De l'autre, le tout statique (l'approche JAMstack) est rapide et bon marché, mais il faut recompiler le site entier à chaque modification de contenu. Pendant des années, on choisissait sa douleur.
En 2026, cette frontière s'est estompée. L'edge computing (le calcul exécuté au plus près de l'utilisateur), popularisé par Cloudflare, couplé à la souplesse du framework Astro, a fait émerger une troisième voie : un serverless qui coûte réellement presque rien et démarre instantanément.
C'est l'architecture qui se cache sous EmDash, le CMS open source de Cloudflare. Une précision honnête avant d'aller plus loin : EmDash lui-même en est au stade de preview développeur (version 0.1.0), à considérer comme une direction, pas comme un choix de production par défaut. Nous avons décrit ce que c'est dans notre décryptage d'EmDash comme alternative à WordPress. Cet article porte sur la couche en dessous : la stack Cloudflare (Workers, R2, D1) qui rend une application moderne peu coûteuse à exploiter et rapide par défaut, et sur ce qui la distingue du modèle serverless que la plupart des équipes connaissent déjà.
Cloudflare Workers vs AWS Lambda : la fin du cold start
Le serverless promet depuis longtemps un marché simple : vous ne payez que ce que vous exécutez, et vous arrêtez de penser aux machines. Le défaut, dans le modèle traditionnel qu'AWS Lambda a rendu célèbre, c'est le cold start.
Ce qu'est vraiment un cold start
Un cold start (démarrage à froid : la latence qu'ajoute une fonction serverless quand elle n'a pas tourné depuis un moment) vient du fait que la plateforme doit démarrer un environnement d'exécution neuf. Dans le modèle à conteneurs derrière Lambda, lorsqu'une fonction est restée inactive, le fournisseur démarre un conteneur virtualisé complet avant d'exécuter votre code. Le premier utilisateur après une période d'inactivité attend ce démarrage. Selon le langage et la configuration, c'est une limite documentée du modèle à machine virtuelle, et c'est exactement la latence qu'on ne veut pas sur une page de paiement ou un appel d'API.
Les isolats V8 : déjà chauds par conception
Les Cloudflare Workers changent le modèle technique au lieu d'optimiser l'ancien. Plutôt qu'un conteneur par fonction, les Workers s'exécutent dans des isolats V8 : la technologie de bac à sable légère qui sépare les onglets de votre navigateur Chrome. Une seule instance d'exécution gère des centaines, voire des milliers d'isolats et bascule de l'un à l'autre, la mémoire de chacun étant cloisonnée des autres.
La documentation de Cloudflare est explicite sur l'effet : ce modèle « élimine les cold starts du modèle à machine virtuelle », et un isolat donné démarre « environ cent fois plus vite qu'un processus Node sur un conteneur ou une machine virtuelle », tout en consommant un ordre de grandeur de mémoire en moins au démarrage.
[ AWS Lambda ] : Requête --> démarrage conteneur virtualisé --> latence (cold start) --> exécution [ Cloudflare ] : Requête --> isolat V8 (déjà chaud) --> exécution, pas de cold start
Résultat concret : votre code s'exécute sur le réseau Cloudflare présent dans 337 villes et plus de 100 pays, au plus près de vos utilisateurs, sans payer de taxe au démarrage sur la première requête.
Un cold start, c'est la taxe que vous payez pour démarrer une machine. Les Workers n'en démarrent aucune.
C'est quoi un cold start, et pourquoi les Cloudflare Workers n'en ont pas ? Un cold start est le délai qu'ajoute une fonction serverless quand elle doit démarrer un environnement d'exécution neuf après une période d'inactivité. Les Cloudflare Workers l'évitent parce qu'ils tournent dans des isolats V8 déjà chargés dans un processus actif : aucun conteneur à démarrer par requête.
Compute, données et stockage sur l'edge : le triptyque complet
Une fonction très rapide ne sert à rien si elle attend ensuite une base de données située à l'autre bout de la planète. C'est là que l'offre Cloudflare va plus loin qu'une simple couche de calcul, et qu'il vaut la peine de dépasser le résumé en une ligne : elle couvre les données et le stockage sur le même réseau.
D1 : du SQL distribué à côté de votre code
D1 est la base de données SQL native de Cloudflare, bâtie sur SQLite. Là où des montages PostgreSQL ou MySQL classiques centralisent les données dans une seule région, D1 est conçue pour garder la donnée près des Workers qui la lisent, de sorte que les requêtes se résolvent en quelques millisecondes au lieu de traverser des continents. Sur le plan gratuit, elle couvre 5 millions de lignes lues par jour, 100 000 lignes écrites par jour et 5 Go de stockage, soit une marge confortable pour un site de contenu ou une petite application.
R2 : le stockage objet sans la taxe d'egress
Si vous avez utilisé AWS S3, vous connaissez le schéma : stocker des fichiers coûte peu, mais les récupérer (les frais d'egress, facturés sur les données qui sortent du stockage) est l'endroit où la facture gonfle en silence. R2 supprime cette ligne. Cloudflare ne facture aucun frais d'egress sur R2 : que vos utilisateurs téléchargent 10 Mo ou 10 To d'images, vous payez l'espace stocké, pas le fait de le servir. Le plan gratuit couvre 10 Go de stockage par mois. Pour tout site riche en médias, cette seule différence redessine le modèle de coût.
R2 facture-t-il des frais d'egress ? Non. R2 offre une bande passante de sortie gratuite quand la donnée est servie directement depuis lui. Vous payez l'espace de stockage et les opérations, pas la sortie des données, ce qui constitue la principale différence de coût avec S3.
Le modèle scale-to-zero : payer seulement quand ça tourne
Pour un développeur ou une startup, c'est le modèle financier qui paraît presque trop beau. C'est le principe du scale-to-zero (mise à l'échelle jusqu'à zéro).
Si votre site ou application ne reçoit aucune visite pendant la nuit, vos Workers ne s'exécutent pas, votre base D1 dort, et votre consommation est nulle. Aucune instance allumée en permanence n'égrène une facture pendant que personne ne vient. Les plans gratuits sont assez larges pour que beaucoup de projets secondaires et de MVP tournent à l'année sans rien débourser : 100 000 requêtes Workers par jour, 5 Go sur D1, 10 Go sur R2. Vous basculez vers de l'usage payant quand le vrai trafic arrive, pas avant. Côté prix, les Workers de Cloudflare ne facturent qu'au-delà de ces seuils : c'est le point qui surprend le plus les équipes habituées à payer une capacité réservée en permanence.
C'est quoi le scale-to-zero ? C'est une infrastructure qui ne consomme rien (et ne coûte rien) en l'absence de trafic, puis monte en charge automatiquement quand les requêtes arrivent. Vous ne payez pas de capacité allumée en permanence, contrairement à un serveur toujours actif ou à une instance réservée.
Étude de cas : migration WordPress vers Cloudflare EmDash
Ce n'est pas un test de laboratoire. brixio.io tourne sur EmDash et Astro, sur l'infrastructure Cloudflare.
Les coûts d'infrastructure restent réduits pour un site de contenu comme le nôtre, et les pics de trafic sont absorbés sans aucune configuration serveur de notre côté, pas de machine à surdimensionner, pas de couche de cache à empiler.
Astro + Cloudflare : le bon couplage
Pour relier ces briques proprement, le framework Astro est le choix naturel. Grâce à son adaptateur Cloudflare natif, Astro s'exécute directement dans l'environnement d'exécution de Cloudflare (workerd), si bien que le même projet sert à la fois des pages statiques et de la logique dynamique.
Vous compilez en hybride :
- Les pages de contenu pur (articles, landing pages) sont générées en HTML statique léger via l'architecture en îles d'Astro (Islands Architecture : le motif qui n'embarque aucun JavaScript par défaut et isole les composants interactifs dans leurs propres « îles »).
- Les routes dynamiques (une API, l'authentification, une requête vers D1) sont transformées en Cloudflare Workers automatiquement à la compilation.
Vous obtenez la vitesse du statique pour le SEO, là où les pages doivent être légères et explorables, et la puissance du serverless pour les parties de l'application qui ont réellement besoin d'exécuter du code. Une seule base de code, un seul déploiement, deux modes d'exécution. Bâtir la logique applicative sur mesure par-dessus, c'est précisément notre développement d'applications sur mesure.
Astro + Cloudflare, est-ce bon pour le SEO ? Oui. Astro génère par défaut un HTML statique et léger via son architecture en îles, ce qui sert l'explorabilité et les Core Web Vitals, tandis que les fonctionnalités dynamiques tournent en Workers sans rendre toute la page côté client.
Conclusion : le choix de la raison technique
Gérer des serveurs Linux, appliquer des correctifs sur des VPS et régler des configurations Nginx devient une compétence du passé pour le déploiement web de base. En déplaçant votre logique sur l'edge avec Astro et Cloudflare, vous cessez d'entretenir des machines pour vous concentrer sur la livraison : la performance est élevée par défaut, la mise à l'échelle est prise en charge, et les coûts fixes tombent près de zéro quand le trafic baisse.
Le plus dur, comme toujours, n'est pas la mise en ligne. C'est d'exploiter le résultat dans la durée : régler Cloudflare, le sécuriser, le garder rapide sous trafic réel. C'est précisément ce que fait Brixio.
La suite de la série
- Le CMS lui-même : ce qu'est EmDash, et s'il constitue une alternative à WordPress crédible. (Article 1.)
- Sécurité et architecture : déplacer son code chez un tiers soulève de vraies questions de sécurité. Comment le modèle d'isolats de Cloudflare protège les applications, et comment il repense la sécurité des CMS, en profondeur. Lire Plugins WordPress vs isolats Cloudflare : le modèle de sécurité. (Article 3, à venir.)
Questions fréquentes
Lambda démarre un conteneur pour une fonction inactive, ce qui ajoute de la latence à la première requête après une accalmie. Les Workers s'en passent : ils tournent dans des isolats V8 au sein d'un processus déjà actif, ce qui « élimine les cold starts du modèle à machine virtuelle » selon Cloudflare.
Pour beaucoup de charges, oui, et les raisons structurelles comptent plus que le tarif affiché : les Workers descendent à zéro (pas de trafic, pas de coût), et le stockage associé (R2) n'a pas de frais d'egress, là où une facture AWS gonfle souvent. Le plan gratuit Workers couvre 100 000 requêtes par jour, de quoi faire tourner la plupart des MVP et projets secondaires sans frais.
Pas de trafic, pas d'exécution, pas de facture. Vos Workers et votre base D1 restent au repos jusqu'à une requête : une nuit creuse ne coûte rien au lieu de facturer une capacité inutilisée.
Non. Servir des données depuis R2 est gratuit ; vous ne payez que le stockage et les opérations. C'est cette ligne d'egress qui gonfle d'ordinaire une facture S3 équivalente.
Oui. Les pages sont livrées en HTML statique par défaut, donc légères et faciles à explorer ; seules les parties réellement dynamiques tournent en Workers.
