Pages CMS, Cloudflare Pages et GitHub : la stack gratuite pour un site statique rapide et éditable

Oui, un site statique gratuit et éditable est possible, à condition de connaître les limites de chaque brique avant de se lancer. GitHub stocke le code et les contenus, Cloudflare Pages construit et publie le site, Pages CMS permet à vos rédacteurs de modifier les textes sans toucher au code. Cette stack gratuite convient bien à un site vitrine, un blog ou une documentation qui n'a pas besoin de base de données.

Quelques termes à poser d'emblée. Un site statique est un ensemble de pages HTML générées à l'avance et servies telles quelles, ce qui les rend rapides et sans base de données à protéger. Un CDN les distribue depuis des serveurs proches du visiteur. Un CMS Git enregistre chaque modification dans le dépôt sous forme de commit, et une preview est une version de test du site, consultable avant publication.

Ce guide détaille chaque étape, de la création du dépôt à la mise en ligne, puis les quotas gratuits à vérifier et les limites d'un site statique.

1. Choisir un générateur et créer le dépôt GitHub

Un dépôt GitHub pour site statique ne sert pas d'hébergement direct ici, mais de source de vérité pour stocker votre code et vos contenus.

Pages CMS (édition) ➔ GitHub (stockage & commit) ➔ Cloudflare Pages (build SSG) ➔ CDN (diffusion)

Étape 1 : choisir un générateur de site statique

Le générateur transforme vos gabarits et vos fichiers Markdown en pages HTML lors de la compilation. Trois options se démarquent selon vos besoins :

  • Astro : pensé pour une approche par composants, idéal si vous prévoyez une interface modulaire avec React. Les composants Astro sont décrits dans la documentation officielle.
  • Eleventy (11ty) : une fois la compilation terminée, le dossier _site contient les fichiers statiques du projet, que vous pouvez téléverser sur n'importe quel hébergeur.
  • Hugo : compilé en Go, il traite d'importants volumes de pages avec une grande rapidité, selon la documentation officielle de Hugo.

Pour des besoins spécifiques ou une refonte sur mesure, faire appel à une équipe de spécialistes du développement web permet de cadrer l'architecture dès le départ.

Étape 2 : initialiser le dépôt GitHub

Créez un nouveau dépôt sur GitHub et poussez-y votre projet local. La plateforme intervient ici uniquement pour gérer les versions :

  • Elle enregistre chaque ajout ou correction sous la forme d'un commit horodaté.
  • Elle conserve l'historique complet des modifications pour faciliter les retours en arrière.

Étape 3 : organiser l'arborescence du contenu

Isolez strictement les textes des templates pour sécuriser l'édition par des profils non techniques :

├── content/          # Articles et pages en Markdown
├── public/           # Images et médias
├── src/              # Templates et composants HTML
├── .pages.yml        # Configuration de Pages CMS
└── package.json      # Dépendances du projet

Cette structure sépare le contenu du code : les droits GitHub et la configuration de Pages CMS déterminent les fichiers que les rédacteurs peuvent modifier.

2. Choisir entre GitHub Pages et Cloudflare Pages selon ses besoins

Le choix entre GitHub Pages ou Cloudflare Pages dépend de votre chaîne de publication : simplicité brute d'un côté, pipeline d'intégration continue complet de l'autre.

Critère GitHub Pages Cloudflare Pages
Publication statique Directe via branche ou GitHub Actions Automatisée via Git ou Direct Upload
Previews par branche Non natives (workflows requis) Générées à chaque pull request
Automatisation Écosystème GitHub CLI C3, API et intégrations Git

GitHub Pages pour la documentation interne

Pour un portfolio, un dépôt simple ou une documentation avec Jekyll, GitHub Pages suffit : vos fichiers HTML, CSS et JavaScript sont servis sans infrastructure externe.

Cloudflare Pages pour la collaboration éditoriale

Dès que plusieurs personnes rédigent, Cloudflare Pages s'impose grâce aux previews par branche : chaque pull request dispose d'une URL isolée. Cette mécanique rejoint les principes des environnements de développement, de préproduction et de production pour valider les contenus avant publication.

3. Déployer le site sur Cloudflare Pages

Le déploiement continu signifie que chaque push sur votre dépôt déclenche automatiquement un nouveau build et une mise en ligne. Avec Cloudflare Pages, ce pipeline distribue vos fichiers HTML statiques sur son réseau mondial sans gestion de serveur.

Schéma des quatre étapes de déploiement sur Cloudflare Pages : connecter le dépôt GitHub, renseigner la commande de build et le dossier de sortie, vérifier la preview, rattacher le domaine personnalisé

Étape 1 : connecter le dépôt GitHub à Cloudflare Pages

Dans votre tableau de bord Cloudflare Pages, créez une nouvelle application puis sélectionnez l'option Git. Autorisez l'accès à votre compte GitHub en restreignant les autorisations au seul dépôt du projet, puis validez la sélection.

Étape 2 : renseigner la commande de build et le dossier de sortie

Indiquez la commande d'exécution et le répertoire de sortie correspondant à votre générateur de site statique :

  • Astro : commande npm run build et répertoire de sortie dist.
  • Hugo : commande hugo et répertoire de sortie public.
  • Fichiers sans compilation : commande exit 0 en ciblant le dossier contenant vos fichiers prêts.

Vérifiez systématiquement ces paramètres dans la documentation officielle de votre générateur avant de lancer le premier traitement.

Étape 3 : lancer le premier déploiement et vérifier les previews

Validez la configuration pour déclencher le premier build. Cloudflare vous fournit une adresse temporaire en .pages.dev pour contrôler le rendu, les liens et les médias. Chaque future pull request générera sa propre URL d'aperçu isolée : vous pouvez relire les modifications éditoriales sans affecter le site public.

Étape 4 : ajouter un domaine personnalisé

Rattachez votre nom de domaine dans les paramètres du projet. La configuration DNS active automatiquement la distribution globale et le certificat HTTPS pour chiffrer les échanges, tandis que vos commits sur la branche principale actualisent le site en production.

Si vous hésitez sur la configuration technique de votre futur site, échangeons pour évaluer honnêtement la faisabilité de votre projet.

4. Connecter Pages CMS au dépôt GitHub

Un Git-based CMS fonctionne sans base de données séparée : l'interface d'édition écrit directement des commits dans votre dépôt Git. Pages CMS applique cette architecture pour offrir un espace de rédaction visuel aux équipes non techniques, tout en stockant le contenu sous forme de fichiers texte dans votre code source.

Étape 1 : autoriser l'accès GitHub à Pages CMS

Connectez-vous sur la plateforme Pages CMS avec vos identifiants GitHub. Lors de l'installation de l'application GitHub associée, appliquez le principe de moindre privilège : sélectionnez uniquement le dépôt du site concerné au lieu d'ouvrir l'ensemble de votre compte. L'application demande un accès en lecture et écriture pour modifier vos fichiers.

Étape 2 : créer le fichier .pages.yml

La structure de l'interface repose sur le fichier .pages.yml, placé à la racine du dépôt. Rédigé au format YAML, ce document constitue l'unique source de vérité de l'outil et liste précisément les sections éditables.

Étape 3 : déclarer une collection d'articles et un dossier de médias

Déclarez le répertoire des images puis votre collection de publication :

media: media

content:
  - name: posts
    label: Articles
    type: collection
    path: content/posts
    fields:
      - name: title
        label: Titre
        type: string
      - name: body
        label: Contenu
        type: rich-text

Chaque sauvegarde effectuée dans Pages CMS enregistre alors un commit dans le dossier correspondant du dépôt.

Étape 4 : limiter les droits des contributeurs

Gérez les accès directement depuis les permissions de votre organisation GitHub, en accordant l'accès au dépôt aux seuls collaborateurs habilités. Puisque l'interface n'affiche que les collections définies dans la configuration, les rédacteurs travaillent en autonomie sans risquer d'altérer les fichiers du thème ou la logique applicative.

5. Tester la publication et dépanner une erreur 404 sur pages.dev

Appliquez une modification concrète dans Pages CMS puis suivez son déploiement jusqu'à la mise en ligne pour valider votre chaîne de publication.

Étape 1 : modifier un article dans Pages CMS

Modifiez un titre ou un paragraphe dans Pages CMS, puis enregistrez. L'outil crée automatiquement un commit dans votre dépôt GitHub.

Étape 2 : repérer le commit dans GitHub

Consultez l'historique du dépôt. Ce commit confirme que le CMS écrit directement dans vos fichiers, sans base de données.

Étape 3 : suivre le build dans Cloudflare Pages

Ouvrez l'onglet Déploiements dans Cloudflare Pages. En cas d'échec, consultez les logs de build : un code d'erreur signale une commande invalide ou une dépendance manquante.

Étape 4 : vérifier la page publiée et la preview de branche

Ouvrez votre URL en pages.dev pour vérifier le rendu. Sur une branche secondaire, Cloudflare génère une URL de prévisualisation dédiée, idéale pour relire sans impacter la production.

Étape 5 : dépanner un 404 ou un build en erreur

Une erreur 404 sur pages.dev provient généralement d'un dossier de sortie mal renseigné dans les paramètres de build ou de l'absence d'un fichier index.html à la racine. Contrôlez aussi la syntaxe de votre fichier _redirects si vos routes personnalisées échouent.

6. Vérifier les quotas gratuits et les limites avant le lancement

Avant d'ouvrir votre site au public, validez les plafonds des offres sans frais pour prévenir tout blocage de build ou interruption de service. Les limites documentées par Cloudflare fixent par exemple une taille maximale de 25 MiB par fichier de site. Un fichier média qui dépasse ce seuil doit donc être compressé ou hébergé ailleurs avant la mise en ligne.

Quotas gratuits : les seuils d'hébergement

Les offres sans frais imposent des règles strictes sur les volumes et les durées de traitement. Les seuils ci-dessous ne sont pas tous de même nature : certains sont des limites fermes, d'autres des seuils indicatifs.

  • Cloudflare Pages : d'après la documentation des limites de la plateforme, un build est interrompu au bout de 20 minutes, un site peut contenir jusqu'à 20 000 fichiers sur l'offre gratuite, et un fichier individuel ne peut pas dépasser 25 MiB.
  • GitHub Pages : selon la documentation de GitHub Pages, un site publié ne peut pas dépasser 1 Go. Les deux autres seuils sont des limites souples : 100 Go de bande passante mensuelle et 10 builds par heure, qui ne s'appliquent pas lorsque le site est construit et publié par un workflow GitHub Actions personnalisé.

Un fichier média de plus de 25 MiB dépasse la taille maximale autorisée pour un élément de site sur Cloudflare Pages : il faut le compresser ou l'héberger ailleurs.

Limites de la stack et dépendances externes

Adopter cette architecture implique d'accepter les limites de la stack :

  • Dépendance totale envers GitHub pour l'authentification et l'écriture des contenus
  • Absence de support technique dédié sur les formules gratuites
  • Nécessité de former les contributeurs aux bases de Git (commits, gestion des conflits)

Notre astuce

Configurez un miroir automatique de votre dépôt Git vers un second service d'hébergement de code pour sécuriser vos contenus en cas d'indisponibilité de GitHub.

Checklist technique avant mise en ligne

Validez ces cinq points essentiels avant le lancement :

  1. Désigner au moins deux administrateurs sur le compte GitHub
  2. Optimiser les images pour qu'aucun fichier ne dépasse la limite de 25 MiB par fichier que fixe la documentation de Cloudflare Pages
  3. Configurer le nom de domaine personnalisé et les enregistrements DNS
  4. Tester la procédure complète de restauration locale à partir d'un clone vierge
  5. Renseigner les pages légales obligatoires, comme vos mentions légales

7. Contourner l'absence de dynamique d'un site statique

Des services tiers, des fonctions serverless et des scripts côté client comblent l'absence de base de données traditionnelle pour enrichir un site statique sans héberger de serveur applicatif.

Formulaires et fonctions serverless

Pour intégrer un formulaire sur un site statique, deux approches s'offrent à vous : déléguer la réception des messages à un service tiers spécialisé ou déployer du code serverless via Cloudflare Pages Functions. Ces fonctions exécutent des scripts légers à la demande dans un dossier dédié, sans serveur à administrer.

En revanche, ce mode de fonctionnement ne suffit pas à lui seul pour un espace membres complet. La gestion des comptes, des sessions et des droits peut être confiée à un service externe d'authentification, qui prend en charge une partie de cette complexité. Lorsque les règles d'accès ou les fonctionnalités dépassent ce que proposent ces services, un développement spécifique devient nécessaire, avec un niveau de contrôle qui dépend des besoins fonctionnels. Pour un projet de ce type, un développement web sur mesure permet d'arbitrer ces choix au cas par cas.

Recherche côté client et gestion des médias

L'exploration des articles repose sur la recherche côté client : un index textuel est généré au moment du build, puis interrogé directement dans le navigateur du visiteur par un script JavaScript.

Pour maintenir un affichage rapide et respecter les quotas de votre hébergeur, optimisez vos images avant chaque commit et conservez les vidéos volumineuses en dehors du dépôt Git.

Pour aller plus loin

Créer votre site statique et performant avec Les Yétis

Un site statique couplé à un gestionnaire de contenu Git peut répondre à certains besoins de performance ; le résultat dépend aussi de l'implémentation et des ressources du site. Certains projets nécessitent toutefois des fonctionnalités sur mesure, une indexation technique plus poussée ou une gestion éditoriale avancée. Les Yétis conçoivent, développent et maintiennent votre site avec une seule et même équipe : WordPress, Next.js ou Payload CMS selon le besoin, avec la performance et le SEO pensés dès le cadrage. Parlez-nous de votre projet ou de votre site actuel, nous vous disons honnêtement ce qui est faisable.

FAQ : déployer et éditer sans code sur cette stack

Comment fonctionne le déploiement automatique à chaque push ?

Le déploiement se déclenche dès qu'un nouveau commit arrive sur la branche connectée de votre dépôt GitHub. Cloudflare Pages détecte l'événement, lance la commande de build et met à jour le site statique en ligne en quelques secondes. Ce déploiement automatique à chaque push s'applique autant aux commits d'un développeur qu'aux publications rédigées depuis Pages CMS.

Une équipe peut-elle modifier le contenu sans coder ?

Oui, Pages CMS permet à des collaborateurs non techniques de modifier le contenu sans coder grâce à une interface épurée. L'outil enregistre les modifications directement dans le dépôt sous forme de fichiers Markdown ou JSON, mettant à jour les articles et les images existants. L'ajout de nouveaux composants ou la refonte de gabarits requièrent en revanche l'intervention d'un développeur.