Pendant des années, la réponse à la question « où déployer ceci sur Cloudflare » était simple : les sites statiques et les frontends allaient sur Pages, et la logique serverless allait sur Workers. En 2026, cette frontière s’est estompée, car Workers peut désormais servir des assets statiques directement, ce qui signifie qu’un seul Worker peut héberger l’ensemble de votre site, frontend et backend réunis. Cela a changé la recommandation de Cloudflare pour les nouveaux projets, et il vaut la peine de comprendre pourquoi avant de choisir un camp.
Ce guide explique ce qu’est chaque produit, comment le passage aux assets statiques a changé la décision Cloudflare Pages vs Workers, et donne une recommandation claire pour les nouveaux projets et pour quiconque se demande s’il faut migrer.
En résumé
- Pages est un hébergement connecté à git pour sites statiques et frameworks frontend, avec CI/CD intégré et déploiements de prévisualisation
- Workers est la plateforme de calcul serverless de Cloudflare, et elle sert désormais aussi des assets statiques, donc elle peut héberger des sites complets
- Pour les nouveaux projets en 2026, Cloudflare recommande Workers avec des assets statiques, car cela unifie frontend et backend dans un seul déploiement
- Pages reste entièrement pris en charge ; il n’y a pas lieu de précipiter le départ d’un projet Pages existant
- Choisissez selon votre flux de travail : Pages pour un déploiement statique pur en git-push, Workers pour tout ce qui mêle contenu statique et logique dynamique
Ce qu’est Cloudflare Pages
Cloudflare Pages est une plateforme pour déployer des sites web directement depuis un dépôt git. Vous connectez un dépôt GitHub ou GitLab, Cloudflare exécute votre commande de build, et le résultat est déployé sur la périphérie mondiale. Chaque push obtient un déploiement de prévisualisation avec sa propre URL, et la fusion vers votre branche de production met à jour le site en ligne. C’est le flux de travail Jamstack classique : pousser le code, obtenir un site déployé.
Pages prend aussi en charge le comportement dynamique via les Pages Functions, qui sont des Workers en coulisses, donc vous pouvez ajouter des routes d’API et de la logique côté serveur à un site par ailleurs statique. J’ai utilisé exactement cette approche pour construire un système complet d’inscription et de connexion sur Cloudflare Pages , qui montre jusqu’où un hôte « statique » peut aller.
Ce qu’est Cloudflare Workers
Cloudflare Workers est la plateforme de calcul serverless et d’hébergement serverless : du code qui s’exécute sur le réseau de Cloudflare, au plus près de vos utilisateurs, sans serveurs à gérer. Workers a commencé comme de pures fonctions pour les API, les middlewares et la logique en périphérie, et il se lie au reste de la plateforme, R2 , D1 , KV, Queues et Workers AI . Si vous construisez sur ces bindings de stockage, mes applications de bureau gratuites les rendent faciles à gérer : Easy Cloudflare R2 , Easy Cloudflare D1 et Easy Cloudflare KV .
La nouveauté clé de 2026, ce sont les Static Assets. Un Worker peut désormais servir directement un répertoire de fichiers statiques (HTML, CSS, JS, images), le Worker gérant toutes les routes dynamiques. Cela signifie qu’un seul Worker peut héberger votre frontend compilé et votre API dans un seul déploiement, ce qui nécessitait auparavant de répartir le travail entre Pages et Workers.
Ce qui a changé pour Pages vs Workers : les Static Assets
La raison pour laquelle cette comparaison a un sens aujourd’hui, c’est la capacité des assets statiques. Historiquement, si vous aviez un frontend React ou Astro plus une API backend, la répartition naturelle était Pages pour le frontend et un Worker distinct pour l’API. Deux projets, deux déploiements, deux choses à relier.
Avec les assets statiques sur Workers, vous déployez une seule fois. Le Worker sert votre build statique pour les requêtes normales et exécute votre code pour les routes d’API ou les pages rendues côté serveur. Pour les frameworks full-stack et les applications qui mêlent contenu statique et dynamique, c’est plus simple à construire, à déployer et à raisonner. C’est pourquoi Cloudflare oriente désormais les nouveaux projets full-stack vers Workers plutôt que Pages.
Pages vs Workers : côte à côte
| Critère | Cloudflare Pages | Cloudflare Workers |
|---|---|---|
| Objectif principal | Hébergement de site connecté à git | Calcul serverless + assets statiques |
| Hébergement statique | Oui (fonctionnalité de base) | Oui (via assets statiques) |
| Logique dynamique/serveur | Pages Functions | Native |
| CI/CD git + prévisualisations | Intégré | Via intégration CI / Wrangler |
| Bindings (R2, D1, KV, AI) | Oui | Oui, de première classe |
| Idéal pour | Sites statiques/Jamstack purs | Applications full-stack et API |
| Recommandation 2026 pour nouveaux projets | Toujours pris en charge | Préféré |
Quand choisir Pages
Dans la décision Pages vs Workers, Pages reste un excellent choix quand :
- Vous avez un site purement statique ou un build de framework frontend et voulez le flux de déploiement git-push le plus simple possible
- Vous appréciez le CI/CD intégré et les déploiements de prévisualisation sans rien configurer
- Vos besoins dynamiques sont légers et bien servis par les Pages Functions
- Vous êtes déjà sur Pages et ça fonctionne ; il n’y a aucune pénalité à rester
Quand choisir Workers
Dans la décision Pages vs Workers, Workers est le meilleur choix quand :
- Vous construisez une application full-stack qui mêle contenu statique et logique côté serveur conséquente
- Vous voulez frontend et backend dans un seul déploiement plutôt que deux projets coordonnés
- Vous vous appuyez fortement sur des bindings comme D1, R2, KV, Queues ou Workers AI
- Vous démarrez un nouveau projet en 2026 et voulez suivre la voie recommandée actuelle de Cloudflare
- Vous avez besoin d’un contrôle fin du routage, de la mise en cache et du traitement des requêtes
Cloudflare Pages vs Workers : faut-il migrer ?
Non, pas par réflexe. Si vous avez un projet Pages qui fonctionne, il reste entièrement pris en charge et aucune échéance ne force un déplacement. Migrez quand vous avez une raison concrète : vous ajoutez une logique backend substantielle, vous voulez regrouper un frontend/backend séparé en un seul déploiement, ou vous atteignez une limite propre à Pages que Workers résout.
Pour les projets greenfield dans le choix Pages vs Workers, commencez sur Workers avec des assets statiques. Pour un déploiement Pages existant qui vous satisfait, laissez-le jusqu’à ce qu’un vrai besoin apparaisse. La pire raison de migrer est la nouveauté ; la meilleure raison est d’unifier une application full-stack que vous auriez sinon dû scinder.
Points clés à retenir
- Pages est un hébergement connecté à git pour sites statiques et Jamstack avec CI/CD intégré et prévisualisations
- Workers est du calcul serverless qui sert désormais aussi des assets statiques, donc il peut héberger des sites complets
- Les Static Assets sont le changement qui permet à un seul Worker d’héberger frontend et backend ensemble
- Pour les nouveaux projets full-stack en 2026, Workers est la voie recommandée par Cloudflare
- Pages reste entièrement pris en charge ; migrez seulement quand vous avez une raison concrète
- Dans la décision Cloudflare Pages vs Workers, choisissez Pages pour la simplicité purement statique et Workers pour tout ce qui mêle contenu statique et logique réelle
Foire aux questions
Quelle est la différence entre Cloudflare Pages et Workers ? Pages est un hébergement connecté à git pour sites statiques et frontends avec CI/CD intégré et déploiements de prévisualisation. Workers est la plateforme de calcul serverless de Cloudflare. La frontière s’est estompée en 2026 car Workers peut désormais servir des assets statiques, permettant à un Worker d’héberger à la fois un frontend et un backend.
Dois-je utiliser Pages ou Workers pour un nouveau projet en 2026 ? Pour la plupart des nouveaux projets full-stack, Workers avec des assets statiques est désormais le choix recommandé par Cloudflare car il unifie frontend et backend dans un seul déploiement. Pour un site purement statique où vous voulez le flux git-push le plus simple, Pages reste une excellente option.
Cloudflare Pages est-il en cours d’abandon ? Non. Pages reste entièrement pris en charge. Cloudflare oriente désormais les nouveaux projets full-stack vers Workers, mais les projets Pages existants continuent de fonctionner et il n’y a aucune migration forcée.
Workers peut-il héberger un site web statique ? Oui. Avec la fonctionnalité des assets statiques, un Worker peut servir directement des fichiers statiques comme HTML, CSS, JS et images, tout en gérant aussi des routes dynamiques dans le code. C’est ce qui permet à un seul Worker d’héberger un site entier.
Pages et Workers utilisent-ils les mêmes bindings ? Les deux peuvent utiliser les bindings Cloudflare comme R2, D1, KV et Workers AI. Pages les expose via les Pages Functions, tandis que Workers les traite comme de première classe. Fonctionnellement, vous atteignez les mêmes services de la plateforme depuis l’un comme l’autre.
Dois-je migrer mon site Pages existant vers Workers ? Seulement si vous avez une raison concrète, comme ajouter une logique backend importante ou regrouper un frontend et un backend séparés en un seul déploiement. Un projet Pages qui fonctionne est entièrement pris en charge et n’a pas besoin d’être déplacé.
Commentaires