Cloudflare Pages
Cloudflare Pages transforme un dépôt en site public. C'est l'étape qui met votre travail sous les yeux du monde.
Ce que Cloudflare Pages fait
Cloudflare Pages relie un dépôt à une adresse publique : vous poussez du code, il compile et met en ligne. Gratuit pour un projet d'élève, sans serveur à administrer, avec des URL qui répondent vite partout dans le monde.
C'est l'étape qui donne un sens à tout le reste : un projet qui n'est pas en ligne n'existe que pour son auteur. Une URL, un lien partagé, et le travail devient réel — vérifiable, montrable, discutable.
Pages sert des fichiers préparés à l'avance (HTML, CSS, images). Pas de calcul côté serveur, pas de base de données. Pour une landing page, c'est exactement ce qu'il faut — et c'est ce qui rend l'hébergement gratuit et très rapide.
Comment un site arrive en ligne
Push sur GitHub
Vous envoyez vos commits vers le dépôt.
Cloudflare surveille la branche principale (main). Chaque push peut déclencher un nouveau déploiement : la mise en ligne devient une conséquence du travail, pas une corvée.
Build
Cloudflare installe les dépendances et compile le projet.
C'est ici que tout se joue : commande de build, dossier de sortie, version de Node. Le journal du build dit exactement ce qui s'est passé.
Mise en ligne
Le résultat compilé est déposé sur le réseau Cloudflare.
Ce sont les fichiers compilés (dist/) qui sont servis, jamais vos sources. Le site est répliqué sur des serveurs proches des visiteurs.
URL
Le site répond à une adresse publique.
Par défaut : https://projet.pages.dev. Un domaine personnalisé (comme workflow.nsi.xyz) peut ensuite être rattaché.
Retenez la conséquence pratique : ce n'est pas vous qui envoyez le site, c'est Cloudflare qui le reconstruit à partir du dépôt. Si un fichier n'est pas dans le dépôt, il ne peut pas apparaître en ligne.
Deux façons de déployer
| Méthode | Comment ça marche | Pour qui |
|---|---|---|
| Connexion Git (recommandée) | On autorise Cloudflare à lire un dépôt GitHub. Chaque push sur la branche principale déclenche un build et une mise en ligne automatiques. | Le cas normal : un dépôt, une URL, zéro commande à retenir. |
| Envoi direct (ligne de commande) | On compile chez soi (npm run build) puis on publie le dossier dist/ avec l'outil Cloudflare (Wrangler). | Pour les cas particuliers : publier sans dépôt, ou automatiser un déploiement. |
Quelle que soit la méthode, il faut que le build fonctionne chez vous(npm run build) avant de l'espérer en ligne. Un projet qui ne compile pas sur votre machine ne compilera pas dans le nuage.
Pas à pas : connecter le dépôt
- Créer un compte Cloudflare puis ouvrir la section Workers & Pages et choisir Create puis Pages.
- Choisir « Connect to Git » et autoriser Cloudflare à accéder à vos dépôts GitHub. Vous pouvez limiter l'accès à un seul dépôt : c'est plus propre.
- Sélectionner le dépôt du projet, puis la branche à surveiller (
mainen général). Chaque push sur cette branche mettra le site à jour. - Vérifier les réglages de build : c'est ici que 90 % des échecs se jouent. Le tableau ci-dessous donne les valeurs attendues.
- Lancer le premier déploiement et lire le journal : il se termine par une URL
*.pages.dev. Le site est en ligne. - Tester comme un visiteur : ouvrez l'URL publique depuis un autre appareil — pas depuis la machine qui a servi au développement.
Les réglages de build
| Champ | Valeur attendue | Pourquoi |
|---|---|---|
| Framework preset | Astro | Remplit automatiquement la commande de build et le dossier de sortie. Sinon, réglez-les à la main. |
| Build command | npm run build | La commande qui compile le site. Elle doit fonctionner aussi chez vous, dans un terminal, avant d'espérer qu'elle marche en ligne. |
| Build output directory | dist | Le dossier produit par le build. Astro écrit dans dist/ par défaut. |
| Root directory | la racine du dépôt | Si le projet est dans un sous-dossier du dépôt, indiquez-le ici : c'est l'oubli classique. |
| NODE_VERSION | 22 | Astro 7 exige Node ≥ 22. Sans cette variable (ou un fichier .nvmrc), le build peut échouer alors qu'il passe sur votre machine. |
Les URL : prévisualisation et production
- URL de production : celle de la branche principale (
mon-projet.pages.dev). C'est elle qu'on partage. - URL de prévisualisation : chaque branche ou chaque proposition de modification obtient sa propre adresse, avant de rejoindre la production. Pratique, mais ce n'est pas un lien à distribuer.
- Domaine personnalisé : on rattache un domaine à soi (
mon-projet.nsi.xyz) dans les réglages du projet, puis on crée l'enregistrement DNS.
Pour un projet Pages, rattacher le domaine ne suffit pas : Cloudflare ne crée pas l'enregistrement DNS tout seul. Il faut ajouter soi-même un CNAME vers mon-projet.pages.dev, en mode proxied. Le certificat HTTPS est émis ensuite automatiquement. Sans ce CNAME, le domaine reste indéfiniment en pending.
Quand le build échoue
Un échec de build n'est pas une catastrophe : c'est un message d'erreur, avec un fichier et une ligne. Encore faut-il le lire dans le bon sens — toujours la première erreur, jamais la dernière.
| Ce qu'on lit dans le journal | Cause probable | Correction |
|---|---|---|
« Build command failed » sans autre détail utile | Le build échoue pour une raison de configuration (commande, dossier de sortie) ou de code. | Rouvrez le journal du build et remontez à la première erreur — c'est toujours la première qui compte. Reproduisez la commande en local : npm run build. |
« Cannot find module … » | Une dépendance n'a pas été installée, ou le dossier racine est mal indiqué. | Vérifiez que package.json et package-lock.json sont bien dans le dossier racine défini, et que la dépendance est déclarée (pas installée « à la main »). |
Le build passe en local, échoue en ligne | Version de Node différente, ou nom de fichier avec une majuscule. | Déclarez NODE_VERSION=22 et vérifiez les majuscules : « Header.astro » et « header.astro » sont deux fichiers différents pour le serveur, mais un seul sur Windows. |
« Output directory dist not found » | Le dossier de sortie réel n'est pas celui déclaré. | Lancez le build en local et regardez le nom du dossier produit (dist/, build/, out/…), puis corrigez le réglage. |
Le site s'affiche sans style, ou une page renvoie 404 | Fichiers compilés incomplets, ou une route qui n'existe pas dans le build. | Comparez ce que vous voyez en local (npm run preview) et en ligne. Un 404 sur une route signifie souvent qu'elle n'a pas été générée au build. |
Les secrets côté plateforme
En production, il n'y a pas de fichier .env : c'est volontaire. Ce dont le site a besoin se déclare dans les réglages du projet, section variables and secrets. Elles ne sont pas lisibles depuis le dépôt, et ne partent pas sur GitHub.
| Variable | À quoi elle sert |
|---|---|
CLOUDFLARE_API_TOKEN | Pour déployer en ligne de commande (jamais nécessaire si vous passez par la connexion Git). |
CLOUDFLARE_ACCOUNT_ID | Identifiant du compte, utilisé par les outils de déploiement. |
Clés d'API et mots de passe | Tout secret utilisé par le site se déclare dans les réglages du projet, jamais dans un fichier poussé. |
Un secret ne traverse jamais le dépôt. En local, il vit dans .env (ignoré par Git) ; en ligne, il vit dans les réglages de la plateforme. Aucun des deux ne doit apparaître dans le code.
Ce qu'un site statique ne sait pas faire
Autant le savoir avant de le promettre : un site Pages « pur » ne peut pas, à lui seul, enregistrer des données, authentifier des utilisateurs, envoyer des courriels ou exposer une API. Une landing page n'en a pas besoin — et c'est précisément ce qui rend l'exercice accessible.
Pour aller plus loin (formulaire qui enregistre, espace protégé, statistiques), la marche suivante s'appelle Pages Functions : une petite API déployée avec le site, qui peut lire et écrire dans un espace de stockage. C'est un autre niveau, et un autre sujet.
La checklist avant de publier
Cinq pièges à connaître
Le .env n'existe pas en ligne
Vos variables locales ne sont pas poussées — c'est voulu. Ce dont le site a besoin en production se déclare dans les réglages Cloudflare (variables et secrets).
Le domaine personnalisé reste « pending »
Pour un projet Pages, rattacher le domaine ne suffit pas : Cloudflare ne crée pas l'enregistrement DNS. Il faut ajouter le CNAME vers projet.pages.dev, en mode proxied. Le certificat est ensuite émis automatiquement.
Déployer les sources au lieu du build
Le dossier de sortie doit être dist/ (le résultat compilé), pas la racine du dépôt avec les fichiers .astro.
Publier sans relire
Une fois en ligne, c'est public : le site, son code compilé et ses textes. La checklist de la section Sécurité s'applique avant chaque mise en production.
Croire qu'un site statique peut tout faire
Un site Pages statique ne calcule rien côté serveur : pas de base de données, pas de compte utilisateur, pas d'API. Pour cela, il faut des Pages Functions — un autre sujet, et un autre niveau.
Pour aller plus loin
Git et GitHub
Le dépôt que Cloudflare va lire, et le point de retour qui protège le travail.
À ne pas raterSécurité
Secrets, variables d'environnement, checklist avant publication.
ErreursDépannage
Traduire les messages d'erreur en actions concrètes.
SourceDocumentation Cloudflare Pages
La référence officielle : cadres, réglages, limites.