Cloudflare Workers vs Pages : la différence qui compte avant de choisir

La plupart des didacticiels sur Cloudflare Workers et Pages font une mauvaise comparaison. Cela place les deux comme des concurrents directs, comme s’il fallait choisir entre un framework et un autre. Les Workers et les Pages résolvent différents problèmes à différentes couches – et choisir sans comprendre cette distinction crée des architectures coûteuses ou nécessitant une refactorisation en six mois.

Ce que chacun est réellement

Workers est une plateforme informatique. Vous écrivez du code, le déployez avec wrangler deploy, et ce code s'exécute sur des isolats V8 distribués sur le réseau Cloudflare, actuellement dans plus de 300 points de présence. Le modèle d'exécution est piloté par les événements : chaque requête HTTP, message de file d'attente, déclencheur cron ou gestionnaire de courrier électronique génère une invocation. Le démarrage à froid est inférieur à 1 ms car les isolats V8 partagent le même processus, contrairement aux conteneurs qui partent de zéro.

Pages est une plateforme d'hébergement. Le cas central est le suivant : vous avez un site Web ou un SPA, vous créez git push, Cloudflare exécute votre build (npm run build, Hugo, Astro, peu importe), et les actifs statiques résultants sont distribués sur son CDN global. Les requêtes pour ces actifs (HTML, JS, CSS, images) sont servies directement depuis le CDN, sans passer par aucun environnement informatique.

Pages possède également des fonctions Pages, qui sont des scripts Workers déployés via une convention de répertoire (/functions). La confusion commence ici : les fonctions Pages s'exécutent sur le même runtime V8 que Workers, ont les mêmes liaisons (D1, KV, R2, objets durables), les mêmes limites de processeur et de mémoire. La différence entre Pages Functions et pur Workers n’est pas technique – elle est opérationnelle.

Le compte qui change tout

Sur le forfait rémunéré Workers (5 $/mois), vous avez 10 millions de demandes incluses et payez 0,30 $ par million au-delà. Chaque requête HTTP traitée par le runtime compte.

Dans Pages, les requêtes d'actifs statiques ne coûtent rien par requête : elles sont servies par le CDN de Cloudflare sans déclencher le runtime Workers. Vous payez pour les builds (20 $/mois pour le plan pro, avec jusqu'à 5 000 builds/mois et 5 builds simultanés). Les demandes de fonctions Pages consomment le même budget que les travailleurs.

Traduire un cas réel : un site Web avec 100 millions de requêtes mensuelles, 90 % pour les actifs statiques (bundles JS, images, pages HTML) et 10 % pour les routes API. Sur Pages, les 90 millions de requêtes statiques coûtent 0 $. Les 10 millions d’appels de Fonctions font partie des Fonctions gratuites du forfait pro. Dans une architecture équivalente avec des Workers purs servant les mêmes actifs via fetch() par rapport à un compartiment R2, vous paieriez 27 $/mois juste pour la différence (0,30 $ × 90 millions de requêtes au-dessus des 10 millions inclus).

Cette différence est structurelle et ne disparaît pas à mesure que l’échelle augmente, elle s’aggrave.

Là où les travailleurs ont un réel avantage

Certaines primitives n'existent que chez Workers. Les déclencheurs Cron – la possibilité d'exécuter du code à une heure planifiée – n'existent pas dans Pages. Si vous avez besoin d'un travail qui s'exécute toutes les heures pour synchroniser les données, traiter une file d'attente ou nettoyer les enregistrements expirés, il s'agit de Workers. Il n’a pas d’équivalent dans Pages.

Workers prend également en charge les consommateurs de files d'attente (traitent les messages des files d'attente Cloudflare de manière asynchrone), les Email Workers (reçoivent et traitent les e-mails) et les Workers for Platforms (distribution des scripts déployés par les utilisateurs, utile pour les SaaS multi-locataires). Ces déclencheurs non HTTP n'existent que dans le modèle Workers.

Les objets durables fonctionnent dans les deux cas, mais la coordination complexe entre plusieurs instances (par exemple, un serveur WebSocket avec état distribué) a tendance à être plus propre dans Workers, où vous avez un contrôle total sur le déploiement et le routage.

La superposition réelle

Pages Functions et Workers partagent exactement le même runtime. Les limites sont identiques : 128 Mo de mémoire (limite stricte), 10 Mo de script compressé sur le forfait payant, 1 000 sous-requêtes par appel sur le forfait payant, 30 s de CPU par requête. Les liaisons disponibles sont les mêmes : D1, KV, R2, Durable Objects, AI, Service Bindings pour appeler d'autres Workers.

Cela signifie qu'une API de milieu de gamme peut être entièrement construite sur des fonctions Pages sans rien sacrifier en termes de capacité d'exécution. La question n’est pas « lequel a le plus de puissance de calcul » mais plutôt « quel modèle de déploiement et de facturation est le plus adapté à ma charge de travail ».

Les critères de décision

L'heuristique fonctionne comme ceci : si votre projet comporte des actifs statiques générés par build (n'importe quel framework frontend, générateur de site statique, SPA), Pages est le point de départ naturel. Vous bénéficiez d'un CDN global pour les actifs sans frais par demande, de déploiements de prévisualisation automatiques par branche et d'un pipeline de build intégré. Les routes API sont en /functions et s'exécutent dans le même runtime Workers.

Si le projet est axé sur le calcul (sans actifs statiques importants ou avec des déclencheurs non HTTP tels que cron, files d'attente et courrier électronique), Workers est le choix direct. Le modèle de déploiement via wrangler.toml est plus explicite, versionnable dans le code et s'intègre mieux aux workflows CI/CD personnalisés.

La plupart des projets ne vivent pas à un seul extrême. Un SaaS typique possède une interface (Pages, avec CDN gratuit), une API (Fonctions Pages, même base de code, même déploiement) et un ensemble de tâches en arrière-plan (Workers séparés, avec déclencheurs cron). Ces travailleurs d’arrière-plan se connectent au projet Pages via des liaisons de service – des appels directs entre travailleurs sans passer par l’Internet public.

Ce que la documentation n'explique pas

Cloudflare documente les Workers et les Pages comme des produits distincts avec des pages séparées, ce qui masque un détail important : un projet Pages peut appeler des Workers externes via des liaisons de service, et les Workers externes peuvent servir les actifs d'un projet Pages. Ce ne sont pas des silos. Ce sont des pièces qui s’assemblent.

L’erreur la plus courante est de réimplémenter dans Workers ce que Pages fait gratuitement – servir des actifs statiques – parce que quelqu’un a d’abord lu sur Workers et a pensé que c’était « plus avancé ». Workers n’est pas plus avancé que Pages. C'est un outil différent pour un autre niveau du problème.