Configurer le cache Cloudflare sans exposer les pages privées

La mise en cache est la plus sûre lorsqu’elle est ennuyeuse. Les feuilles de style, images et scripts statiques gagnent généralement à être réutilisés ; les écrans de connexion, paniers, pages de compte et aperçus ne peuvent souvent pas être traités de la même façon. Une seule règle générale du type « tout mettre en cache » peut produire une page rapide tout en servant à un visiteur une réponse destinée à quelqu’un d’autre. Avant d’optimiser la vitesse, tracez la frontière entre contenu public et contenu personnalisé.

La documentation de Cloudflare sur le comportement de cache par défaut indique que le service met généralement en cache certaines extensions de fichiers et ne met pas en cache le HTML ni le JSON par défaut. Elle explique aussi comment les en-têtes de cache de l’origine et les caractéristiques de la réponse HTTP influent sur l’éligibilité. Une règle personnalisée peut modifier ces hypothèses. C’est pourquoi copier une règle agressive trouvée dans un tutoriel est risqué.

Classer les routes selon l’audience et l’état

Répartissez les URL entre ressources statiques publiques, HTML public anonyme, pages qui varient selon les cookies ou l’état de connexion, administration, API et points d’accès imprévisibles. Signalez explicitement les liens d’aperçu, les étapes de paiement, les actions liées aux commentaires et les contenus protégés par mot de passe. Si une page dépend de l’identité du visiteur, la décision initiale la plus sûre est de contourner le cache partagé jusqu’à ce que l’application ait été conçue pour cela.

Examinez la manière dont l’origine envoie les en-têtes Cache-Control, Set-Cookie et Vary. Une page anonyme peut tout de même définir un cookie inoffensif, tandis qu’une page personnalisée peut omettre un en-tête protecteur. Tester la réponse réelle est plus fiable que de déduire un comportement à partir du seul chemin de l’URL.

Créer des règles étroites avant les règles larges

Dans le tableau de bord de Cloudflare, les Cache Rules vous permettent de choisir une expression de correspondance, puis soit de contourner le cache, soit de rendre les requêtes correspondantes éligibles à la mise en cache. Le guide de création de règles détaille l’ordre des règles et leur déploiement. Commencez par un test restrictif ciblant le contenu public plutôt que toutes les requêtes adressées au nom d’hôte.

Tenez compte de l’ordre des règles et de leurs chevauchements. Un contournement couvrant les chemins de connexion ne doit pas être involontairement supplanté par une correspondance large placée plus loin. Testez les variantes de paramètres, les chemins linguistiques, les contenus propres à certains appareils et les états des cookies. Si vous modifiez les clés de cache, vérifiez que les variantes de contenu produisent réellement des clés distinctes.

Se méfier des remplacements de TTL en périphérie

Un Edge Cache TTL peut modifier la durée pendant laquelle Cloudflare conserve une réponse et, selon les réglages, prendre le pas sur les instructions de l’origine. La documentation des réglages disponibles explique les options et avertit que le comportement interagit avec les en-têtes et le reste de la configuration. Ne définissez pas de TTL partagé long pour du HTML que vous ne pouvez pas invalider en toute sécurité.

Choisissez une procédure de purge avant le déploiement. Les éditeurs ont besoin que les mises à jour et les corrections apparaissent rapidement. Un titre d’article erroné conservé en périphérie peut rester visible après sa correction dans le CMS, sauf si l’invalidation du cache atteint les variantes concernées.

Comparer une visite anonyme et une visite authentifiée

Consultez un article public sans cookies, puis avec une session authentifiée normale. Examinez la réponse réseau et les éventuels en-têtes de statut du cache. Recommencez avec des comptes de test distincts dans un environnement sûr. Vérifiez que les noms privés, jetons, paniers et éléments de navigation propres à un utilisateur ne passent jamais d’un compte à l’autre. Testez aussi les redirections et les pages d’erreur. Un HIT ne prouve pas qu’une règle de cache est correcte ; l’exactitude passe en premier.

Tenez un bref inventaire des règles indiquant la raison de chaque exception, la personne qui l’a approuvée et une URL de test réputée sûre. Une règle inexpliquée héritée d’un déploiement antérieur ne doit pas rester indéfiniment en place simplement parce que personne ne sait ce qu’elle fait. Examinez les modifications du cache en même temps que les mises en production touchant l’authentification et le paiement.

Après le déploiement, surveillez la charge de l’origine, les taux de réussite du cache, les contenus périmés et les taux d’erreur. Gardez les règles antérieures à la modification prêtes pour un retour arrière. Lorsque l’exactitude est incertaine, contournez le cache et corrigez le contrat de l’application avant de tenter une autre optimisation.

Une route peut sembler publique tout en variant de manière invisible selon les en-têtes de requête, le pays, l’appareil ou un test A/B. Si vous mettez en cache une seule représentation pour tout le monde, la mauvaise langue ou la mauvaise variante peut parvenir à la mauvaise personne. Avant de concevoir une clé de cache personnalisée, identifiez précisément quelle donnée d’entrée modifie la réponse HTML. Cloudflare documente des options pour les chaînes de requête, les en-têtes et les cookies, mais ajouter tous les en-têtes à une clé peut anéantir l’efficacité du cache et créer des combinaisons imprévisibles.

Testez trois états différents pour chaque route importante : première visite sans cookies, nouvelle visite anonyme et visite authentifiée. Notez le code de statut de la réponse, Cache-Control, Set-Cookie, CF-Cache-Status lorsqu’il est disponible, ainsi qu’une courte empreinte du contenu visible. Recommencez après une correction éditoriale et une purge ciblée. Il s’agit d’une méthode de contrôle qualité hypothétique, et non d’une affirmation sur la configuration d’un site précis.

Soyez particulièrement prudent avec les pages d’erreur et les redirections. Mettre en cache de manière trop large une réponse de maintenance temporaire, une redirection d’authentification ou une destination localisée peut ressembler à une panne du site alors même que l’origine fonctionne correctement. Déployez d’abord les règles sur un petit motif de chemin et testez-les sur un nom d’hôte sûr lorsque c’est possible. Si les symptômes sont ambigus, revenez au comportement par défaut et analysez la situation avant d’élargir l’éligibilité.

Préserver la vitesse sans perdre la confiance

La mise en cache des ressources statiques apporte souvent des gains utiles sans toucher au HTML personnalisé. Procédez par catégorie de routes, une à la fois, consignez les exceptions et vérifiez de nouveau après les mises à jour du CMS ou de l’authentification. Notre article sur la mise à jour de sécurité de Cloudflare traite d’un autre enjeu de protection ; le guide sur la préproduction WordPress porte sur le test des modifications avant la production. Des pages rapides n’ont de valeur que si elles affichent le bon contenu.