Cours Cloudflare — DNS et proxy, CDN, HTTPS, Pages, Workers, R2, D1, Tunnel et Access

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. expliquer ce qu'un enregistrement DNS proxifié change par rapport à un enregistrement « DNS seul » ;
2. décrire le chemin d'une requête : DNS, bordure Cloudflare, cache, origine ;
3. lire les modes de chiffrement SSL/TLS et dire pourquoi éviter « Flexible » ;
4. publier un site statique sur Cloudflare Pages (envoi direct ou via Git) et rattacher un domaine personnalisé sans casser la résolution ;
5. situer Workers, R2 et D1 et dire pour quel besoin choisir chacun ;
6. exposer un service privé avec Tunnel et le protéger avec Access, sans ouvrir de port entrant ;
7. citer le rôle du WAF, des règles personnalisées et de la limitation de débit ;
8. manipuler wrangler en lecture et traiter un jeton d'API comme un secret ;
9. appliquer la règle de l'Orchestrator avant toute publication : données personnelles, secrets, noindex, puis /publier-pages et gardien-confidentialite.

Prérequis

• Savoir ouvrir Terminal et lire une commande avant de la valider (cours « Terminal macOS »).
• Notions de DNS, d'IP et de HTTP (cours « Réseau »).
• Notions de Git (cours « Git ») pour le déploiement par dépôt.
• Aucun compte Cloudflare n'est requis pour lire ce cours ; pour pratiquer, créer un compte de test et un site jetable sans contenu personnel.

Parcours et chapitres

1. Ce que fait Cloudflare, et la règle d'or avant de publier

Cloudflare propose, sur un même compte, un réseau de bordure (DNS, proxy, cache, protection) et une plateforme de développement (Pages, Workers, R2, D1). Le réseau de bordure se place entre le visiteur et le serveur d'origine.

Règle de l'Orchestrator (non négociable) : toute publication passe par /publier-pages, qui lance l'agent gardien-confidentialite (bloquant) avant le push, et cyberagent pour les secrets et le réseau. Une page publique ne contient ni nom, ni initiale, ni adresse, ni donnée de santé d'une personne réelle, et garde robots: noindex,nofollow. Les données privées ou les secrets restent en local (arbre de décision de l'ADR 0001).

2. DNS et proxy

Un enregistrement DNS Cloudflare est soit proxifié, soit « DNS seul ». D'après la page « Proxy status » (état consulté le 2026-10-17) :

Deux pièges relevés dans la page : si plusieurs enregistrements A/AAAA portent le même nom et qu'un seul est proxifié, Cloudflare les traite tous comme proxifiés ; et les types MX, TXT, etc. sont toujours « DNS seul ».

dig example.com A +shortdig example.com NS +short

• Contexte : Terminal macOS ; example.com est un nom de documentation, à remplacer par un domaine qui est le sien.
• Droits : utilisateur.
• Effet : deux requêtes DNS ; lecture seule, aucun compte nécessaire.
• Vérification : pour un nom proxifié, les adresses renvoyées sont celles de Cloudflare, non celles de l'origine (la plage exacte n'est pas à mémoriser : non vérifié ici) ; pour un domaine géré par Cloudflare, les serveurs de noms (NS) sont ceux de Cloudflare.
• Retour arrière : sans objet.

3. CDN et cache

Le cache stocke des copies du contenu dans les centres de données de Cloudflare, près des visiteurs. Comportement par défaut (page « Default cache behavior », état consulté le 2026-10-17) :

• le cache se décide d'après l'extension du fichier, pas le type MIME : images, vidéos, polices, archives, JavaScript et CSS sont mis en cache ; HTML et JSON ne le sont pas par défaut ;
• pas de mise en cache si Cache-Control contient private, no-store, no-cache ou max-age=0, si une réponse porte Set-Cookie, ou si la méthode n'est pas GET ;
• durées par défaut selon le code HTTP (par exemple 120 minutes pour 200 et 301, 3 minutes pour 404) ; des Cache Rules adaptent le comportement par URL.

curl -sI --max-time 10 https://example.com/ | grep -i -E 'cf-cache-status|cache-control|server'

• Contexte : Terminal macOS ; domaine de documentation à remplacer par le sien. L'en-tête cf-cache-status (valeurs comme HIT, MISS, DYNAMIC) est connu par usage ; sa description n'a pas été relue dans la page consultée : non vérifié.
• Droits : utilisateur.
• Effet : une requête HTTPS, en-têtes seulement ; lecture seule.
• Vérification : présence des en-têtes ; deux appels successifs sur une ressource statique montrent si elle est servie depuis le cache.
• Retour arrière : sans objet.

4. Certificats HTTPS et modes SSL/TLS

Deux liaisons sont chiffrées indépendamment : visiteur → Cloudflare et Cloudflare → origine.

• Certificat visiteur (Universal SSL) : d'après la page consultée, Cloudflare émet et renouvelle automatiquement des certificats gratuits, publiquement reconnus, de validation de domaine (DV), pour les domaines actifs sur Cloudflare ; ils couvrent le domaine racine et les sous-domaines de premier niveau. Pour des niveaux plus profonds, il faut Total TLS ou Advanced Certificate Manager (offres non détaillées ici).
• Modes de chiffrement vers l'origine :

La documentation « recommande vivement » Full ou Full (strict). Elle indique aussi que le mode automatique (« Automatic SSL/TLS ») est maintenant celui par défaut, qu'il choisit le mode le plus sûr selon l'origine et qu'il ne rétrograde jamais ; son déploiement a été progressif, donc l'état d'un compte donné est non vérifié.

Cas de Pages : pour un site Pages, l'origine est Cloudflare lui-même ; le choix du mode vers une origine externe ne concerne pas un site statique Pages (point à confirmer en pratique, non vérifié).

5. Cloudflare Pages : publier un site statique

Cloudflare Pages héberge des fichiers statiques (HTML, CSS, images…) sur un sous-domaine <NOM-PROJET>.pages.dev. Deux façons de déployer (état consulté le 2026-10-17) :

1. Envoi direct (Direct Upload) : on construit le site localement, puis on envoie le dossier de sortie, par glisser-déposer dans le tableau de bord (maximum 1 000 fichiers, 25 MiB par fichier) ou avec wrangler (maximum 20 000 fichiers, 25 MiB par fichier).
2. Intégration Git : Cloudflare se connecte à un dépôt GitHub ou GitLab (pas d'instance auto-hébergée), construit et déploie à chaque push, et crée des aperçus pour les autres branches et les demandes de fusion.

Limites de Pages (état consulté le 2026-10-17, plan gratuit) : 500 constructions par mois, 1 construction à la fois, 20 000 fichiers par site, 25 MiB par fichier, 100 projets par compte, 100 domaines personnalisés par projet, 100 règles dans _headers, 2 100 redirections maximum. Les plans payants ont des plafonds plus hauts. Non garantis dans le temps.

Pages ou Workers pour un projet neuf ? La page « Migrate from Pages » (consultée le 2026-10-17) indique que Workers offre un ensemble de fonctions plus large et oriente les nouveaux projets vers Workers avec des ressources statiques ; elle ne dit rien de l'avenir ou de l'arrêt de Pages. Pour un site statique simple, Pages reste décrit comme possible ; le choix définitif est à confirmer par Stéphane avant tout projet réel.

Déploiement direct avec wrangler (modèle d'après la documentation) :

Attention, effet notable. Cette commande peut créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

npx wrangler pages project createnpx wrangler pages deploy <DOSSIER-DE-SORTIE>

• Contexte : Terminal macOS ; Node.js et wrangler installés (versions inconnues). <DOSSIER-DE-SORTIE> contient uniquement ce qui doit être public. À lancer seulement après /publier-pages et le feu vert de gardien-confidentialite.
• Droits : un jeton d'API ou une connexion wrangler avec droit de modifier Pages sur le compte (voir chapitre 12).
• Effet : crée un projet puis publie les fichiers à une adresse *.pages.dev : visible de tous et pouvant être mis en cache.
• Vérification : ouvrir l'adresse publique, vérifier les en-têtes (voir noindex ci-dessous) et la liste des fichiers servis.
• Retour arrière : supprimer le déploiement ou le projet dans le tableau de bord (ou par wrangler, syntaxe non vérifiée) ; les copies en cache et les historiques peuvent subsister un temps. Pour les secrets exposés : révoquer le secret, pas seulement retirer la page.

Garder noindex : la page « Headers » donne le moyen de demander aux moteurs de ne pas indexer, avec un fichier _headers placé dans le dossier publié :

https://:project.pages.dev/*
  X-Robots-Tag: noindex

La même page précise que ce fichier s'applique aux ressources statiques et pas aux réponses de Pages Functions ; qu'il est limité à 100 règles. Conserver aussi la balise <meta name="robots" content="noindex,nofollow"> dans chaque page, comme l'exige l'Orchestrator.

Via Git : pousser vers un dépôt connecté déclenche une construction et un déploiement. Les aperçus de branche sont des URL publiques elles aussi : ne rien y mettre qu'on ne publierait pas en production. On peut désactiver les déploiements automatiques dans « Branch control » et déployer à la main avec wrangler. Les détails de configuration de construction n'ont pas été relus : non vérifiés.

Domaine personnalisé. D'après la page « Custom domains » (état consulté le 2026-10-17) :

• un sous-domaine (www.example.com) demande seulement un enregistrement CNAME vers <NOM-PROJET>.pages.dev ;
• un domaine racine (example.com) exige que la zone soit gérée par Cloudflare (serveurs de noms pointés vers Cloudflare) ;
• ajouter le domaine dans le tableau de bord de Pages d'abord, puis le DNS : créer le CNAME à la main avant provoque une erreur 522 ;
• un enregistrement CAA trop restrictif peut empêcher l'émission du certificat.

6. Workers : du code sans serveur

Un Worker est du code (JavaScript, TypeScript…) exécuté par Cloudflare près du visiteur, sans serveur à administrer. Il répond à des requêtes HTTP, peut modifier une réponse, appeler d'autres services et accéder à R2 ou D1 par des liaisons (bindings) déclarées dans sa configuration.

Limites relevées (page « Limits », état consulté le 2026-10-17) :

Sur le plan gratuit, dépasser le quota quotidien renvoie une erreur. Non garanti dans le temps.

7. R2 : stockage d'objets

R2 stocke des objets (fichiers) dans des buckets, avec une API compatible S3 et une API Workers. Selon la page « Pricing » (état consulté le 2026-10-17) :

• palier gratuit, stockage Standard : 10 GB-mois, 1 million d'opérations de classe A (écritures, listes) et 10 millions de classe B (lectures) par mois ;
• pas de frais de sortie de données (egress) pour la lecture directe depuis R2 ;
• au-delà du palier, facturation au Go et au million d'opérations ; une classe « Infrequent Access » existe, avec durée minimale de 30 jours. Les montants exacts changent : ne pas les retenir.

8. D1 : base SQL gérée

D1 est la base de données SQL de Cloudflare, utilisée depuis un Worker. La page des limites (état consulté le 2026-10-17) indique : plan gratuit, 10 bases par compte, 500 MB par base, 5 GB au total ; plan payant, 50 000 bases, 10 GB par base (limite non extensible), 1 TB au total ; 30 secondes maximum par requête ; 2 MB maximum par ligne ou valeur. Que D1 repose sur SQLite est connu par ailleurs mais n'a pas été confirmé par la page lue : non vérifié.

9. Tunnel : exposer un service sans ouvrir de port

Cloudflare Tunnel relie un service privé à Cloudflare par un démon, cloudflared, qui ouvre des connexions sortantes vers le réseau Cloudflare (page « Tunnel », mise à jour du 2026-08-04, consultée le 2026-10-17). L'origine n'écoute pas sur Internet : aucun port entrant n'est à ouvrir sur la box ou le pare-feu. Un tunnel est identifié par un UUID ; plusieurs processus cloudflared (connecteurs) peuvent servir le même tunnel. Il peut relayer du HTTP, du SSH, du bureau à distance, etc.

Les commandes de création et de lancement de cloudflared (installation, tunnel create, tunnel run, service launchd) n'ont pas été relues pour ce cours : elles sont non vérifiées et, comme tout service qui tourne en permanence sur le Mac, relèvent de ops-macos puis de cyberagent (niveau « Obligatoire » du workflow de l'Orchestrator). Se reporter à la page officielle « Cloudflare Tunnel » au moment de l'utiliser.

10. Access : protéger une application

Cloudflare Access place une authentification devant une application (page « Self-hosted public app », mise à jour du 2026-04-17, consultée le 2026-10-17). Elle se crée dans Zero Trust > Access controls > Applications, en choisissant une application « auto-hébergée ». Principes relevés :

• refus par défaut : un utilisateur doit correspondre à une stratégie « Allow » pour entrer ; il existe aussi « Block » et « Bypass » ;
• des fournisseurs d'identité sont configurés pour l'authentification ;
• une durée de session règle la fréquence de réauthentification ;
• l'origine doit valider le jeton d'application, pour rejeter les requêtes qui contourneraient Cloudflare.

Les conditions tarifaires d'Access (nombre d'utilisateurs gratuits) n'ont pas été trouvées sur la page lue : non vérifié.

11. WAF, règles et limitation de débit

Le pare-feu applicatif (WAF) filtre les requêtes web avant qu'elles n'atteignent l'origine.

• Règles personnalisées (état consulté le 2026-10-17) : une expression décrit le trafic visé, une action le traite (Block, Managed Challenge, Skip, Log ; Log est limité sur les plans bas). Les règles sont évaluées dans l'ordre, et Block arrête l'évaluation. Plafond par plan : 5 règles (Free), 20 (Pro), 100 (Business), 1 000 (Enterprise).
• Limitation de débit (état consulté le 2026-10-17) : une règle définit une expression, une période de comptage, un seuil de requêtes et une durée de blocage ; utile contre l'essai répété de mots de passe. Sur le plan gratuit : correspondance sur le chemin seulement, comptage par IP, une seule règle ; Pro : deux règles ; Business : cinq ; Enterprise : jusqu'à 100.

12. wrangler en lecture et jetons d'API

wrangler est la ligne de commande de la plateforme de développement (npx wrangler <COMMANDE> <SOUS-COMMANDE>). La page « Commands » (mise à jour du 2026-04-23, aucune version de wrangler indiquée) range en lecture des commandes comme whoami, la liste des projets Pages et de leurs déploiements, la liste des buckets R2, des bases D1 et des espaces KV, deployments list, versions list et tail. Les syntaxes exactes ci-dessous sont à confirmer avec npx wrangler --help (version inconnue : non vérifié).

npx wrangler whoaminpx wrangler pages project listnpx wrangler pages deployment list --project-name <NOM-PROJET>

• Contexte : Terminal macOS ; connexion préalable à un compte (par wrangler login ou par jeton). Cette connexion n'est pas faite dans ce cours : lire les sorties sur un compte de test.
• Droits : ceux du jeton ou de la session ; un jeton « lecture seule » suffit pour ces commandes.
• Effet : requêtes de lecture vers l'API Cloudflare ; rien n'est modifié. Les sorties contiennent des noms de projets et parfois l'ID de compte : ne pas les coller dans le dépôt ni dans une capture.
• Vérification : la liste correspond à ce que montre le tableau de bord.
• Retour arrière : sans objet (pour se déconnecter : wrangler logout, non vérifié).

Jetons d'API : encadré de sécurité.

Les variables d'environnement reconnues par wrangler pour le jeton et l'identifiant de compte, et la différence avec l'ancienne « clé API globale », n'ont pas été relues : non vérifiées. Ne jamais utiliser une clé globale quand un jeton à portée limitée suffit.

13. Bonnes pratiques de publication

Avant de publier quoi que ce soit sur Cloudflare :

1. Choisir la bonne cible avec l'arbre de décision de l'ADR 0001 : données privées ou secrets, donc local ; site public statique, donc cloudflare-pages ou github-pages (sans préférence pour le moment).
2. Inspecter le dossier de sortie, fichier par fichier : noms, adresses, numéros, données de santé, chemins personnels, métadonnées d'images, clés, jetons, fichiers .env, sauvegardes, cartes de sources (source maps).
3. Garder noindex,nofollow : balise robots dans chaque page et en-tête X-Robots-Tag via _headers.
4. Passer /publier-pages : gardien-confidentialite (bloquant) et cyberagent rendent leur verdict avant tout envoi ; pas de publication sans feu vert.
5. Jeton à portée minimale, hors dépôt, avec expiration.
6. Prévoir la sortie : le site/ statique est versionné et peut être republié ailleurs en moins d'une heure (ADR 0001).
7. Vérifier après publication depuis une navigation privée : contenu, en-têtes, absence de ressources inattendues.

Exercices et vérifications de fin de cours

Tous sont sur papier ou en lecture seule, sans connexion à un compte réel.

1. Chemin. Dessiner de mémoire le trajet d'une requête vers un site Pages et un service derrière Tunnel + Access, en nommant le rôle de chaque étape.
2. Proxy. Expliquer la différence entre un enregistrement proxifié et un enregistrement « DNS seul », et ce que chacun révèle de l'origine.
3. Cache. Pour un site avec une page HTML, une feuille de style et une image, dire ce que Cloudflare met en cache par défaut et pourquoi.
4. HTTPS. Classer les modes Off, Flexible, Full et Full (strict) du moins sûr au plus sûr, avec une phrase de justification.
5. Pages. Écrire la liste de contrôle à passer avant de lancer un déploiement direct (chapitre 13), puis la commande sans l'exécuter.
6. Domaine. Dans quel ordre créer le CNAME et ajouter le domaine à Pages, et que se passe-t-il dans l'autre sens ?
7. Choix. Pour chacun de ces besoins, dire Pages, Worker, R2, D1 ou Tunnel : page de présentation, API qui renvoie du JSON, dépôt de fichiers volumineux, petite base de comptes, tableau de bord privé tournant sur le Mac.
8. Jeton. Rédiger la portée minimale d'un jeton qui ne sert qu'à déployer un projet Pages, et dire où il sera stocké.
9. Incident. Un jeton est collé par erreur dans une page publiée : ordre des actions (révoquer, retirer, purger, consigner).