Cloudflare Pages : Déployer un Site en 13 Étapes [2026]

Déployer un site web sans gérer le moindre serveur, avec un plan gratuit qui inclut 500 builds par mois et de la bande passante illimitée : c’est la promesse de Cloudflare Pages. Depuis que la plateforme a fusionné son expérience développeur avec Cloudflare Workers en 2026, elle est devenue une option sérieuse face à Vercel et Netlify pour héberger des sites statiques et des applications avec rendu serveur. Ce tutoriel vous accompagne pas à pas, de la création du compte jusqu’au déploiement d’un projet complet avec fonctions serverless, base de données D1 et domaine personnalisé.

Vous allez construire un projet réel : un site Astro avec une fonction Pages Functions qui interroge une base D1 et un stockage KV, connecté à un dépôt GitHub avec déploiements de prévisualisation automatiques. Comptez environ 60 à 75 minutes pour suivre l’ensemble des 13 étapes, en supposant que vous avez déjà Node.js installé.

Pourquoi Cloudflare Pages en 2026 : ce qui a changé

Cloudflare a publié en juillet 2026 un billet intitulé “Bringing a unified developer experience to Cloudflare Workers and Pages”, qui acte la convergence entre les deux produits. Concrètement, les Pages Functions tournent désormais sur le même moteur d’exécution que Workers, avec le même accès aux bindings KV, D1 et R2. Depuis mars 2026, Workers a atteint la parité fonctionnelle avec Pages pour les assets statiques, le rendu côté serveur (SSR) et les domaines personnalisés, ce qui signifie que les deux approches partagent désormais la même infrastructure sous-jacente.

Un second billet, “Making Cloudflare the best place for your web applications” publié le 15 juillet 2026, annonce une simplification du modèle de facturation entre Workers et Pages, avec des paliers de mémoire et de calcul plus lisibles. Pour un développeur qui débute aujourd’hui, la conséquence pratique est simple : Pages reste la porte d’entrée la plus rapide pour déployer un site depuis un dépôt Git, tandis que Workers convient mieux à des cas d’usage API purs sans build. Rien n’indique un abandon du produit, au contraire, Cloudflare le présente comme la façade frontend de sa plateforme complète.

Ce tutoriel cible spécifiquement Cloudflare Pages plutôt que les Workers nus, parce que l’intégration Git automatique et les déploiements de prévisualisation par branche restent, pour l’instant, l’expérience la plus simple pour un site avec contenu qui évolue régulièrement.

Prérequis et versions nécessaires

Avant de commencer, vérifiez que vous disposez des éléments suivants. Aucun ne doit être payant pour suivre ce tutoriel de bout en bout.

Un compte Cloudflare gratuit (le plan Free suffit pour tout ce tutoriel)
Node.js version 20 ou supérieure, avec npm installé
Un compte GitHub (ou GitLab, la procédure est équivalente)
Git installé en local et configuré avec vos identifiants
Wrangler, le CLI officiel de Cloudflare, installé via npm (nous verrons la commande à l’étape 2)
Un terminal Linux, macOS ou Windows avec WSL2
Environ 200 Mo d’espace disque libre pour les dépendances du projet

Aucune carte bancaire n’est requise pour le plan Free. Vous en aurez besoin uniquement si vous décidez plus tard de passer au plan Pro à 25 dollars par mois (20 dollars en facturation annuelle) pour dépasser les 500 builds mensuels ou obtenir plus de builds simultanés. Le détail exact de chaque palier est consultable sur la page Limits de la documentation officielle Cloudflare Pages, régulièrement mise à jour.

Étape 1 : créer le compte Cloudflare et activer la plateforme développeur

Rendez-vous sur le tableau de bord Cloudflare et créez un compte si ce n’est pas déjà fait. Activez l’authentification à deux facteurs immédiatement : c’est une recommandation officielle de Cloudflare pour tout compte qui va gérer des déploiements de production.

Une fois connecté, cherchez la section “Workers & Pages” dans le menu latéral. Depuis l’unification de 2026, les deux produits partagent un tableau de bord commun sous l’appellation “Developer Platform”. Vous verrez apparaître un bouton “Create application” avec deux onglets : Workers et Pages. Restez sur l’onglet Pages pour ce tutoriel.

Notez que le plan Free vous donne 500 builds par mois, un seul build à la fois, jusqu’à 20 000 fichiers par site et 100 domaines personnalisés par projet. C’est largement suffisant pour un blog, une documentation ou un site vitrine avec un trafic modéré.

Étape 2 : installer Wrangler et initialiser le projet local

Wrangler est le CLI qui permet de gérer vos projets Cloudflare depuis le terminal, sans passer par le tableau de bord. Installez-le globalement ou en dépendance de développement selon votre préférence.

npm install -g wrangler
wrangler --version
wrangler login

La commande wrangler login ouvre votre navigateur pour autoriser l’accès à votre compte Cloudflare. Une fois authentifié, créez le squelette du projet avec Astro, un générateur de site statique qui supporte nativement le rendu hybride (pages statiques et fonctions serveur).

npm create astro@latest mon-site-pages -- --template minimal --no-install
cd mon-site-pages
npm install
npm run dev

Vérifiez que le serveur de développement local répond bien sur http://localhost:4321 avant de continuer. Si la commande échoue, passez directement à la section dépannage en fin d’article.

Étape 3 : pousser le projet sur GitHub

Cloudflare Pages fonctionne surtout par intégration continue depuis un dépôt Git. Initialisez un dépôt local, créez un dépôt vide sur GitHub, puis poussez votre code.

git init
git add .
git commit -m "Premier commit du site Astro"
git branch -M main
git remote add origin https://github.com/VOTRE-COMPTE/mon-site-pages.git
git push -u origin main

Adaptez l’URL du dépôt distant à votre propre compte. Si vous préférez GitLab, la procédure est identique côté Git ; seule l’étape de connexion dans le tableau de bord Cloudflare diffère légèrement.

Étape 4 : connecter le dépôt et configurer le build

Retournez dans le tableau de bord Cloudflare, section Workers & Pages, et cliquez sur “Connect to Git”. Autorisez Cloudflare à accéder à votre compte GitHub via OAuth, puis sélectionnez le dépôt mon-site-pages et la branche main.

Cloudflare propose des préréglages de build (build presets) pour la plupart des frameworks modernes : Next.js, Astro, Nuxt, Remix, SvelteKit, Hugo, Eleventy, et d’autres générateurs statiques. Choisissez le préréglage Astro, qui remplit automatiquement les champs suivants :

Paramètre	Valeur pour Astro
Commande de build	`npm run build`
Répertoire de sortie	`dist`
Version de Node.js	20 ou supérieure (variable NODE_VERSION)
Répertoire racine	vide (racine du dépôt)

Cliquez sur “Save and Deploy”. Le premier build démarre immédiatement. Chaque build est limité à 20 minutes d’exécution sur tous les plans ; au-delà, il est automatiquement annulé, ce qui arrive rarement sur un site de taille normale.

Étape 5 : comprendre les déploiements de prévisualisation

C’est l’une des fonctionnalités les plus utiles de Pages. Chaque push sur une branche différente de main, ou chaque pull request, déclenche un déploiement de prévisualisation avec une URL unique du type https://a1b2c3d4.mon-site-pages.pages.dev. Vous pouvez ainsi partager un lien de test avec un collègue ou un client avant de fusionner les changements en production.

Testez ce comportement dès maintenant : créez une branche, modifiez le titre de la page d’accueil, puis poussez.

git checkout -b test-preview
echo "Modification de test" >> src/pages/index.astro
git add .
git commit -m "Test du déploiement de prévisualisation"
git push origin test-preview

Dans l’onglet “Deployments” du tableau de bord, vous verrez apparaître un nouveau déploiement marqué “Preview” avec sa propre URL, distincte de votre déploiement de production. Sur le plan Free, ces builds de prévisualisation comptent dans votre quota de 500 builds mensuels, ce qui reste large pour la plupart des équipes.

Étape 6 : ajouter des variables d’environnement et des secrets

Dans les paramètres du projet, section “Environment variables”, vous pouvez définir des valeurs séparément pour les environnements Production et Preview. C’est essentiel pour, par exemple, pointer vers une base de données de test en prévisualisation et vers la vraie base en production.

Les secrets (clés API, jetons) ne sont jamais affichés en clair après leur création et ne sont pas exposés dans le code de sortie du build : ils sont injectés au moment de l’exécution des Pages Functions. Ajoutez une variable de test :

Environnement	Nom	Valeur	Type
Production	API_MESSAGE	Bonjour depuis la prod	Texte
Preview	API_MESSAGE	Bonjour depuis la preview	Texte

Redéployez après chaque modification de variable : contrairement au code, un changement de variable d’environnement ne redéclenche pas automatiquement un build.

Étape 7 : écrire votre première Pages Function

Les Pages Functions sont en réalité des Workers exécutés à la périphérie du réseau Cloudflare, sur des centaines d’emplacements dans le monde. Elles utilisent un système de routage basé sur des fichiers, dans un dossier functions/ à la racine du projet. Créez le fichier suivant :

// functions/api/hello.js
export async function onRequest(context) {
  const message = context.env.API_MESSAGE || "Message par defaut";
  return new Response(
    JSON.stringify({ message, timestamp: Date.now() }),
    { headers: { "Content-Type": "application/json" } }
  );
}

Ce fichier crée automatiquement une route accessible sur /api/hello. Testez-le en local avec la commande suivante, qui simule l’environnement Pages Functions :

wrangler pages dev -- npm run dev

Ouvrez http://localhost:8788/api/hello (le port par défaut de wrangler pages dev) pour vérifier que la réponse JSON s’affiche correctement, avec la variable d’environnement injectée.

Sur le plan Free, les Pages Functions héritent des limites du plan Workers Free : 100 000 requêtes par jour et 10 millisecondes de temps CPU par requête. Sur le plan payant (5 dollars par mois), vous passez à 10 millions de requêtes incluses par mois et 30 millions de millisecondes CPU. Les requêtes vers des assets statiques (HTML, CSS, images) restent gratuites et illimitées sur tous les plans, seules les fonctions sont comptabilisées.

Étape 8 : connecter une base de données D1

D1 est la base de données SQL serverless de Cloudflare, basée sur SQLite et distribuée à la périphérie du réseau. Créez une base avec Wrangler.

wrangler d1 create base-mon-site
wrangler d1 execute base-mon-site --command "CREATE TABLE messages (id INTEGER PRIMARY KEY, texte TEXT)"
wrangler d1 execute base-mon-site --command "INSERT INTO messages (texte) VALUES ('Premier message stocke dans D1')"

La commande wrangler d1 create retourne un identifiant de base (database_id) à noter. Le fonctionnement complet de D1, la base SQL serverless de Cloudflare, est détaillé dans sa documentation dédiée. Dans le tableau de bord Cloudflare, section “Settings > Functions” de votre projet Pages, ajoutez un binding D1 : nom de variable DB, base sélectionnée base-mon-site. Modifiez ensuite votre fonction pour interroger la base :

// functions/api/messages.js
export async function onRequest(context) {
  const { results } = await context.env.DB
    .prepare("SELECT * FROM messages ORDER BY id DESC LIMIT 10")
    .all();
  return new Response(JSON.stringify(results), {
    headers: { "Content-Type": "application/json" },
  });
}

Redéployez (un simple git push suffit) puis testez /api/messages sur votre URL de production. Les bindings KV et R2 suivent la même logique décrite dans la documentation officielle des bindings Pages Functions : ils se configurent dans le même onglet “Settings > Functions” et sont accessibles via l’objet env passé à chaque fonction.

Étape 9 : ajouter un binding KV pour du cache rapide

KV (Key-Value) est adapté aux données qui changent peu et doivent être lues très vite, comme un cache de configuration. Créez un espace de noms KV :

wrangler kv namespace create "CACHE_SITE"

Ajoutez le binding dans le tableau de bord (nom de variable CACHE), puis utilisez-le dans une fonction :

// functions/api/compteur.js
export async function onRequest(context) {
  let compteur = await context.env.CACHE.get("visites");
  compteur = compteur ? parseInt(compteur, 10) + 1 : 1;
  await context.env.CACHE.put("visites", compteur.toString());
  return new Response(JSON.stringify({ visites: compteur }), {
    headers: { "Content-Type": "application/json" },
  });
}

Ce compteur simple illustre la logique de lecture-écriture rapide. En production, évitez ce pattern exact pour des compteurs à fort trafic à cause de la cohérence éventuelle de KV (les écritures peuvent prendre jusqu’à 60 secondes pour se propager sur tous les emplacements) : préférez D1 pour des données qui doivent rester strictement cohérentes.

Étape 10 : configurer un domaine personnalisé et le SSL

Dans l’onglet “Custom domains” de votre projet Pages, cliquez sur “Set up a custom domain” (voir la documentation officielle des domaines personnalisés pour le détail des cas particuliers). Si votre domaine est déjà géré par Cloudflare DNS, l’enregistrement CNAME se configure automatiquement. Sinon, vous devrez créer manuellement un enregistrement CNAME pointant vers mon-site-pages.pages.dev chez votre registrar actuel.

Une fois le DNS validé, Cloudflare émet automatiquement un certificat SSL/TLS pour le domaine, généralement en quelques minutes. Le plan Free autorise jusqu’à 100 domaines personnalisés par projet, ce qui couvre largement les besoins d’un site unique avec ses sous-domaines (www, blog, api).

Activez également la redirection HTTP vers HTTPS et, si votre domaine est sur Cloudflare, HSTS depuis les réglages de la zone DNS associée pour renforcer la sécurité de transport.

Étape 11 : mettre en place les règles de redirection et les en-têtes

Pages permet de définir des redirections et des en-têtes HTTP personnalisés via deux fichiers spéciaux placés dans le dossier de sortie du build (public/ pour Astro, qui sera copié dans dist/).

# public/_redirects
/ancien-blog/*  /blog/:splat  301
/admin          /login        302

# public/_headers
/*
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin

Ces deux fichiers sont lus automatiquement à chaque déploiement, sans configuration supplémentaire côté tableau de bord. C’est le moyen le plus simple d’ajouter des en-têtes de sécurité sans passer par une Pages Function dédiée.

Étape 12 : surveiller les builds et gérer la concurrence

Sur le plan Free, un seul build s’exécute à la fois par compte. Si vous poussez deux commits rapprochés sur deux branches différentes, le second build attend que le premier se termine, ce qui peut ajouter plusieurs minutes de délai en cas d’usage intensif par une équipe. Le plan Pro autorise 5 builds simultanés, le plan Business 20.

Plan	Prix mensuel	Builds/mois	Builds simultanés	Fichiers max/site
Free	0 $	500	1	20 000
Pro	25 $ (20 $ en annuel)	5 000	5	100 000
Business	250 $ (200 $ en annuel)	20 000	20	100 000

Pour suivre l’état de vos builds, l’onglet “Deployments” affiche les logs complets de chaque exécution, avec la durée, la commande exécutée et la sortie console. Consultez-les systématiquement en cas d’échec avant de chercher ailleurs.

Étape 13 : déployer manuellement sans Git avec Wrangler

Si vous ne souhaitez pas connecter de dépôt Git (pour un script généré localement, par exemple), Wrangler permet un déploiement direct depuis votre machine.

npm run build
wrangler pages deploy dist --project-name=mon-site-pages

Cette méthode est utile pour des déploiements depuis un pipeline CI externe (GitLab CI, CircleCI, Jenkins) qui ne passe pas par l’intégration Git native de Cloudflare. Dans ce cas, générez un jeton API dans votre compte Cloudflare et exposez-le en variable d’environnement CLOUDFLARE_API_TOKEN dans votre pipeline.

Exemple de sortie attendue

Voici ce que vous devriez voir dans le terminal après un déploiement réussi via Wrangler :

✨ Compiled Worker successfully
✨ Uploading... (12 files)
✨ Success! Uploaded 12 files
✨ Deployment complete!
   https://a1b2c3d4.mon-site-pages.pages.dev

Et voici la réponse attendue en interrogeant l’API de messages construite à l’étape 8 :

[
  { "id": 1, "texte": "Premier message stocke dans D1" }
]

Les 5 pièges les plus fréquents

Premier piège : oublier de redéployer après avoir modifié une variable d’environnement. Contrairement à un changement de code, une variable ne déclenche pas de nouveau build automatiquement ; il faut forcer un redéploiement depuis l’onglet Deployments.

Deuxième piège : confondre le répertoire de sortie du build. Pour Astro c’est dist, pour Next.js en mode statique c’est souvent out, pour Hugo c’est public. Une mauvaise valeur ici produit un déploiement vide ou une erreur 404 sur toutes les pages.

Troisième piège : dépasser la limite de 25 Mio par fichier statique. Les gros fichiers vidéo ou les archives doivent être stockés sur R2 et servis via une Pages Function plutôt qu’inclus directement dans le build.

Quatrième piège : placer les fichiers _redirects et _headers au mauvais endroit. Ils doivent se trouver dans le dossier source qui sera copié tel quel dans le répertoire de sortie (par exemple public/ pour Astro), pas dans dist/ directement, qui est régénéré à chaque build.

Cinquième piège : croire que les Pages Functions du plan Free ont un temps CPU illimité. La limite de 10 millisecondes de CPU par requête est stricte : une fonction qui fait un calcul lourd ou plusieurs appels réseau synchrones dépassera ce quota et sera interrompue.

Conseils avancés

Pour des projets plus ambitieux, quelques pratiques permettent d’aller plus loin. D’abord, utilisez des branches de déploiement dédiées pour un environnement de staging permanent : configurez une branche staging avec ses propres variables d’environnement, distincte des previews éphémères par pull request.

Ensuite, combinez Pages avec Cloudflare Access (la brique Zero Trust) pour protéger un environnement de staging par authentification, sans exposer de mot de passe dans le code. Cela évite qu’un moteur de recherche indexe accidentellement une URL de prévisualisation.

Enfin, si votre trafic grossit et que vous approchez des 100 000 requêtes Functions par jour du plan Free, envisagez de déplacer la logique la plus sollicitée (authentification, recherche) vers un Worker payant séparé, facturé au million de requêtes, plutôt que de migrer tout le projet vers le plan Pro à 25 dollars par mois si le reste de votre usage reste modéré.

Structure complète du projet final

À l’issue de ce tutoriel, votre dépôt doit ressembler à ceci :

mon-site-pages/
├── functions/
│   └── api/
│       ├── hello.js
│       ├── messages.js
│       └── compteur.js
├── public/
│   ├── _redirects
│   └── _headers
├── src/
│   └── pages/
│       └── index.astro
├── package.json
└── astro.config.mjs

Ce projet combine un site statique rapide (Astro), trois routes API serverless, une base SQL (D1), un cache clé-valeur (KV), un domaine personnalisé avec SSL automatique et des déploiements de prévisualisation par branche. C’est une base solide pour un blog technique, une documentation produit ou un site vitrine avec formulaire de contact dynamique.

Comparaison rapide avec Vercel et Netlify

Cloudflare Pages se distingue par une bande passante illimitée sur le plan Free et par un egress gratuit vers R2, ce qui n’est généralement pas le cas des plans gratuits concurrents, souvent limités en volume de transfert mensuel. Netlify et Vercel restent toutefois plus intégrés à certains écosystèmes spécifiques (Next.js pour Vercel notamment, puisque Vercel édite ce framework), avec parfois des fonctionnalités de prévisualisation plus poussées côté design.

Pour un projet qui utilise déjà l’écosystème Cloudflare (DNS, WAF, R2, D1), rester sur Pages simplifie la facturation et réduit la latence entre les différents services, puisque tout tourne sur le même réseau périphérique. Pour un projet fortement dépendant de fonctionnalités propriétaires Next.js avancées, Vercel garde un avantage d’intégration native.

Sur le plan tarifaire, la différence se joue surtout à partir d’un certain volume de trafic. Le plan Free de Cloudflare Pages ne facture jamais la bande passante consommée par les assets statiques, quel que soit le nombre de visiteurs. C’est un point de bascule important pour un site à fort trafic (actualité, comparateur, documentation très consultée), où d’autres plateformes facturent au-delà d’un certain volume de transfert mensuel sur leur offre gratuite. À l’inverse, si votre projet dépend surtout du nombre de builds plutôt que du trafic (une équipe qui pousse du code toute la journée), c’est cette métrique-là qu’il faut comparer en priorité entre les offres.

Performance et réseau : ce qu’apporte le CDN de Cloudflare

Un des avantages souvent sous-estimé de Cloudflare Pages tient à son réseau. Chaque asset statique est répliqué automatiquement sur l’ensemble du réseau de points de présence Cloudflare, sans configuration de cache manuelle à gérer. Pour un visiteur en France ou ailleurs en Europe, cela se traduit par un temps de premier octet nettement plus court qu’avec un hébergement mono-région classique, puisque le fichier est servi depuis le nœud le plus proche géographiquement.

Les Pages Functions bénéficient du même principe : le code s’exécute au plus près du visiteur plutôt que dans une seule région cloud, ce qui réduit la latence perçue sur les routes API légères comme celles construites aux étapes 7 à 9. Ce comportement diffère d’un déploiement serverless classique de type AWS Lambda, où la fonction reste rattachée à une région précise sauf configuration additionnelle de réplication.

Pour tirer parti au maximum de cette architecture, évitez les appels réseau synchrones vers des API tierces situées loin géographiquement depuis une Pages Function : chaque appel externe ajoute de la latence qui annule une partie du bénéfice du edge compute. Privilégiez les bindings natifs (D1, KV, R2) qui restent, eux, sur le réseau Cloudflare de bout en bout.

Dépannage : 8 problèmes courants et leurs solutions

Le build échoue avec “command not found: npm run build”. Vérifiez que votre package.json contient bien un script build et que le fichier a été poussé sur la branche connectée à Cloudflare.

Le site s’affiche en 404 après un déploiement réussi. Le répertoire de sortie configuré ne correspond probablement pas à celui réellement généré par votre framework. Vérifiez dans les logs de build le chemin exact où les fichiers sont écrits.

Les Pages Functions renvoient une erreur 500 silencieuse. Consultez les logs en temps réel avec wrangler pages deployment tail, qui affiche les erreurs d’exécution non visibles dans le tableau de bord.

Le binding D1 renvoie “env.DB is undefined”. Le binding n’a probablement été ajouté que pour l’environnement Production et pas pour Preview, ou inversement. Vérifiez les deux onglets dans les réglages du projet.

Le certificat SSL reste en attente plusieurs heures. Cela indique généralement que le DNS ne pointe pas encore correctement vers Cloudflare. Vérifiez la propagation avec un outil de résolution DNS public et patientez, la propagation peut prendre jusqu’à 24 heures dans de rares cas.

Les variables d’environnement n’apparaissent pas côté client. C’est normal et volontaire : les variables définies côté Pages Functions ne sont jamais exposées au navigateur. Pour une valeur publique côté client, utilisez le système de variables d’environnement natif de votre framework (préfixe PUBLIC_ pour Astro par exemple), injecté au moment du build.

Le build dépasse le quota de 500 par mois avant la fin du mois. Chaque push, y compris sur des branches de test, consomme un build. Limitez les pushes automatiques depuis des outils tiers ou passez au plan Pro si votre équipe pousse fréquemment.

Le déploiement manuel via Wrangler échoue avec une erreur d’authentification. Le jeton API généré doit avoir la permission “Cloudflare Pages: Edit”. Régénérez-en un avec le bon scope depuis la section “API Tokens” de votre profil Cloudflare.

Sécuriser votre déploiement Cloudflare Pages

Quelques réflexes réduisent la surface d’attaque de votre projet. Ne stockez jamais de secret directement dans le code source, même dans un fichier de configuration ignoré par Git : utilisez systématiquement les variables d’environnement chiffrées du tableau de bord. Limitez les permissions des jetons API Wrangler au strict nécessaire (édition Pages uniquement, pas d’accès compte complet).

Ajoutez les en-têtes de sécurité présentés à l’étape 11 sur l’ensemble du site, pas uniquement sur les pages sensibles. Pour un projet avec authentification, envisagez de placer les routes d’administration derrière Cloudflare Access plutôt que de coder une vérification de session personnalisée, ce qui réduit le risque d’erreur d’implémentation côté serverless.

Questions fréquentes

Cloudflare Pages est-il vraiment gratuit pour un usage personnel ?
Oui, le plan Free reste disponible sans limite de durée, avec 500 builds par mois, bande passante illimitée pour les assets statiques et jusqu’à 100 domaines personnalisés par projet.

Quelle est la différence entre Cloudflare Pages et Cloudflare Workers en 2026 ?
Depuis la convergence annoncée en 2026, les deux partagent le même moteur d’exécution et les mêmes bindings. Pages ajoute par-dessus une intégration Git native avec builds automatiques et déploiements de prévisualisation, ce que Workers seul ne propose pas nativement.

Peut-on héberger un site Next.js complet sur Cloudflare Pages ?
Oui, via le préréglage Next.js qui gère le rendu côté serveur à travers les Pages Functions, avec certaines limitations sur les fonctionnalités les plus récentes du framework qui peuvent nécessiter un adaptateur spécifique.

Combien de temps prend un build sur Cloudflare Pages ?
Cela dépend de la taille du projet et des dépendances à installer, mais chaque build est plafonné à 20 minutes maximum, au-delà duquel il est automatiquement interrompu.

Les Pages Functions supportent-elles les WebSockets ?
Le support suit celui des Workers, avec des capacités qui évoluent régulièrement ; pour un usage temps réel intensif, vérifiez la documentation officielle à jour avant de vous engager sur cette architecture.

Faut-il migrer un projet Pages existant vers Workers ?
Pas dans l’immédiat. Cloudflare ne prévoit aucun abandon de Pages ; la convergence technique se fait en coulisses sans obliger les projets existants à changer de produit.

Quelle est la limite de taille pour un fichier déployé sur Pages ?
25 Mio par fichier statique. Pour des fichiers plus lourds, utilisez R2 et servez-les via une Pages Function ou un lien direct.

Peut-on utiliser un domaine .fr ou .eu avec Cloudflare Pages ?
Oui, toute extension de domaine supportée par Cloudflare DNS fonctionne, y compris les extensions européennes, à condition de configurer correctement l’enregistrement CNAME ou de transférer la gestion DNS vers Cloudflare.

Cloudflare Pages : Déployer un Site en 13 Étapes, 75 Min [2026]