J’ai mis beaucoup de sites en ligne sur Cloudflare Pages, y compris celui que vous lisez en ce moment. La raison pour laquelle j’y reviens toujours est ennuyeuse dans le bon sens : c’est rapide, l’offre gratuite est généreuse, et une fois configuré je n’y pense plus. Voici ma méthode.
Connectez d’abord le dépôt
Pages fonctionne le mieux quand il construit à partir d’un dépôt Git. Connectez-vous au tableau de bord Cloudflare, ouvrez Workers and Pages, puis choisissez « Create application » et « Pages ». Autorisez GitHub ou GitLab, sélectionnez votre dépôt, et vous arrivez sur l’écran de configuration du build. C’est l’étape que les gens ratent, alors prenez votre temps ici.
Il vous faut trois choses : le préréglage du framework (ou « None » pour un build maison), la commande de build, et le répertoire de sortie. Pour mon propre générateur, la commande est node build.js et le répertoire de sortie est dist. Si vous utilisez un outil connu, les préréglages les remplissent pour vous. Si votre « build » se résume à copier des fichiers, mettez une commande inoffensive comme echo done et pointez la sortie vers votre dossier.
Alignez la version de Node sur la vôtre
Un nombre surprenant de premiers déploiements échouent à cause d’un décalage de version Node. Pages utilise une version récente par défaut, mais votre code suppose peut-être autre chose. Je la fixe explicitement avec une variable d’environnement pour éviter les surprises :
NODE_VERSION = 20.11.0Ajoutez cela dans Settings, Environment variables, pour la Production et les Preview. Pendant que vous y êtes, ajoutez les autres secrets dont votre build a besoin, comme les jetons d’API pour récupérer du contenu. Tout ce qui est sensible va ici, jamais dans le dépôt.
Lancez le premier build
Cliquez sur « Save and Deploy » et regardez le journal défiler. Le premier build est le plus honnête. S’il manque une dépendance ou si votre répertoire de sortie est faux, vous le verrez immédiatement. Un build propre se termine par l’envoi de vos fichiers vers le réseau de périphérie de Cloudflare, et vous obtenez une URL en *.pages.dev pour tester. Ouvrez-la, naviguez, et vérifiez que les ressources se chargent vraiment. Les chemins relatifs cassés sont le problème le plus courant, souvent à cause d’un site qui se croyait dans un sous-chemin.
Ajoutez votre domaine personnalisé
Une fois la preview correcte, attachez un vrai domaine. Allez dans l’onglet Custom domains du projet et ajoutez votre nom d’hôte. Si le domaine est déjà sur Cloudflare, l’enregistrement DNS est créé pour vous en un clic. S’il est ailleurs, vous obtiendrez un CNAME à ajouter chez votre registraire. La propagation prend généralement des minutes, pas des heures. Cloudflare provisionne le certificat TLS automatiquement, donc le HTTPS fonctionne sans toucher à certbot.
Configurez redirections et en-têtes
Les sites statiques ont quand même besoin de règles. Pages lit deux fichiers spéciaux dans votre répertoire de sortie. Un fichier _redirects gère les réécritures d’URL et les anciens liens, et un fichier _headers permet de définir les en-têtes de cache et de sécurité. Voici un petit exemple qui verrouille l’affichage en iframe et met les ressources en cache agressif :
/*
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
/assets/*
Cache-Control: public, max-age=31536000, immutablePlacez-les dans le dossier que vous publiez, pas à la racine du projet, sauf si votre build les recopie. Un cache agressif sur des noms de fichiers hachés est l’un des gains de performance les moins chers que vous obtiendrez.
Automatisez les redéploiements
Chaque push sur votre branche de production déclenche un nouveau build, et les pull requests reçoivent automatiquement leurs propres URL de preview. Cela couvre déjà la plupart des flux. Mais si votre contenu vit hors du dépôt, dans un CMS par exemple, vous voudrez un build hook. Créez-en un dans Settings, Builds and deployments, et vous obtenez une URL à laquelle envoyer un POST depuis n’importe où pour lancer un déploiement. Je relie le mien à un webhook pour que les rédacteurs ne touchent jamais à Git.
Si vous voulez plus de contrôle sur le pipeline de build, vous pouvez ignorer le build du tableau de bord et le lancer vous-même. J’aborde cette approche dans la configuration du CI/CD avec GitHub Actions, qui permet de déployer avec le CLI Wrangler une fois vos propres étapes de test et de lint passées.
Ce que je vérifie avant de dire que c’est fini
Avant de faire confiance à un déploiement, je passe une courte liste. Le domaine personnalisé répond-il en HTTPS sans avertissement de contenu mixte ? Les redirections se déclenchent-elles vraiment ? Les grandes images sont-elles raisonnables, ou est-ce que j’envoie des photos de 4 Mo ? Ce dernier point compte plus qu’on ne le croit, et j’ai détaillé toute mon approche dans l’optimisation des images pour le web.
C’est vraiment tout. Cloudflare Pages récompense une configuration simple, et le réseau de périphérie fait que vos visiteurs à Sydney ont un chargement aussi vif que ceux d’à côté. Une fois le pipeline en place, déployer devient un non-événement, ce qui est exactement le but.