Configuration CDN Cloudflare et Fastly : les premiers réglages à effectuer

Publié le

14 juil. 2026

Temps de lecture

9 min de lecture

Cloudflare et Fastly peuvent tous deux accélérer un site web, protéger une origine et exposer des contrôles fins de diffusion. Aucun n'est un interrupteur magique de vitesse. La première configuration détermine si l'edge sert du contenu utile, si les réponses privées restent privées et si votre équipe peut récupérer lorsqu'une règle est incorrecte.

L'approche fiable est neutre vis-à-vis des fournisseurs : définissez le contrat d'origine, établissez le DNS et TLS sans risque, classez les réponses cachables, contrôlez la clé de cache, ajoutez des politiques de purge et de contenu périmé, puis vérifiez avec de vraies requêtes. Cloudflare exprime habituellement ces décisions au moyen des paramètres de zone et règles de cache. Fastly combine habituellement la configuration du service, les en-têtes cache-control, VCL et les clés surrogate. Les concepts se transfèrent, mais pas la priorité exacte, les valeurs par défaut, limites et l'interface.

1. Définir le contrat d'origine

Consignez les origines de production et préproduction, l'en-tête d'hôte attendu, les noms de certificat TLS, les protocoles pris en charge, l'endpoint de santé, le délai de connexion, le délai jusqu'au premier octet et les codes de statut acceptables. Faites accepter à l'origine le trafic des plages de sortie du CDN ou de la connexion privée, mais ne la laissez pas largement exposée si le CDN doit être le point d'entrée public.

Confirmez que l'origine émet des en-têtes explicites. Au minimum, décidez comment elle définit Cache-Control, ETag ou Last-Modified, Vary, Content-Type et Content-Encoding. Le comportement de cache HTTP est standardisé dans la RFC 9111. Les règles CDN doivent affiner ce contrat, pas le contredire silencieusement.

Séparez les noms d'hôte lorsque c'est possible : le site public, les ressources statiques, les API et les transformations d'images ont souvent des politiques de cache et sécurité différentes. Une règle unique et large pour tous les chemins est simple à créer et difficile à rendre correcte.

2. Connecter DNS et TLS avec un chemin de retour arrière

Commencez avec un nom d'hôte de préproduction ou un sous-domaine à faible risque. Provisionnez le certificat CDN pour chaque nom d'hôte qui sera servi, confirmez le mode TLS et testez la chaîne complète de certificats. Pointez ensuite le nom d'hôte vers le CDN à l'aide de la cible DNS ou du CNAME requis par le fournisseur. Conservez la cible DNS précédente documentée et utilisable jusqu'à ce que le nouveau chemin ait passé les contrôles de production.

Réduisez le TTL DNS avant une bascule planifiée uniquement si vous comprenez les caches de résolveurs existants. Un TTL plus faible améliore l'agilité des changements futurs mais ne peut pas évincer les réponses déjà mises en cache avec l'ancien TTL. Ne modifiez pas les serveurs de noms, DNSSEC, TLS et le routage CDN dans une même étape non testée.

Le guide CDN d'Optimi explique le rôle de la diffusion edge, tandis que le guide de performance DNS couvre la partie résolution et migration de ce changement.

3. Configurer le comportement de cache par classe de contenu

Commencez par des listes d'autorisation explicites plutôt que de mettre en cache chaque réponse réussie :

Pour les ressources statiques, publiez un nouveau nom de fichier lorsque les octets changent. Pour les URL stables, utilisez une purge ciblée ou la validation. Définissez délibérément les durées navigateur et cache partagé ; max-age navigateur et s-maxage edge ne doivent pas être identiques. Évitez de dépendre des TTL de fallback du fournisseur lorsque l'origine peut envoyer la bonne politique.

Différences Cloudflare et Fastly à vérifier

Sur Cloudflare, examinez le comportement de cache par défaut, les règles de cache, les paramètres de clé de cache et l'éligibilité d'une réponse au cache. Sur Fastly, examinez la configuration du service, la sélection du backend, les branches VCL et la priorité de Surrogate-Control, s-maxage, max-age et Expires. Les conseils Fastly sur le cache recommandent les en-têtes d'origine, les clés surrogate et les politiques de contenu périmé plutôt que des TTL inutilement courts.

Ne copiez pas une règle Cloudflare dans Fastly, ou inversement, en supposant une priorité équivalente. Consignez le comportement voulu, puis implémentez-le dans les contrôles natifs du fournisseur.

4. Rendre la clé de cache intentionnelle

La clé minimale comprend généralement la méthode de requête et l'URI cible, mais les réponses négociées peuvent varier selon les en-têtes de requête. Décidez quels paramètres de requête sont significatifs. Ne supprimez les paramètres de suivi que si cela ne peut pas modifier la réponse. Conservez la devise, la locale, les filtres produit et les paramètres signés lorsqu'ils affectent le contenu.

Soyez prudent avec les cookies et l'autorisation. Une clé de cache qui ignore un cookie de personnalisation peut servir la réponse d'un acheteur à un autre. Une clé qui inclut chaque cookie peut détruire le taux de succès du cache. Préférez contourner les chemins personnalisés, ou rendez explicites les représentations publiques et privées.

Si la négociation de format utilise Accept, utilisez un mécanisme de variante pris en charge par le fournisseur ou émettez le comportement Vary: Accept correct. Testez chaque format pris en charge. Le même principe s'applique à la langue, la classe d'appareil et la compression.

5. Ajouter invalidation, résilience et observabilité

Donnez aux éditeurs et à l'automatisation de déploiement un chemin de purge limité : URL pour un objet, tag ou clé surrogate pour une entité logique, préfixe pour une collection contrôlée, et purge complète uniquement pour un incident documenté. Cloudflare documente les purges par URL, tag, nom d'hôte, préfixe et complètes. Fastly prend en charge les purges par URL et clé surrogate et peut effectuer une soft purge dans les cas appropriés. Vérifiez les limites de débit du fournisseur avant de créer un hook de version.

Définissez si les pages publiques peuvent utiliser stale-while-revalidate ou stale-if-error. Le contenu périmé peut masquer une indisponibilité de l'origine, mais ne convient pas aux stocks, prix, comptes ou autres données où une ancienne réponse pourrait nuire. Ajoutez des en-têtes de statut de cache ou diagnostics du fournisseur que les opérateurs peuvent inspecter, et collectez le statut de l'origine, le taux de succès du cache, l'âge de réponse, les résultats de purge et la latence régionale.

6. Déployer par étapes contrôlées

1. Testez l'origine directement et validez les en-têtes.
2. Déployez la configuration CDN en préproduction ou sur un nom d'hôte non critique.
3. Exercez les requêtes anonymes, authentifiées, mobiles, ordinateur, dans une langue alternative et API.
4. Envoyez des requêtes répétées depuis plusieurs régions et confirmez le comportement attendu de HIT, MISS, Age et des validateurs.
5. Transférez une petite part observable du trafic de production si votre routage le permet.
6. Comparez le taux d'erreur, la charge d'origine, le TTFB, le taux de succès du cache et les flux métier avant d'augmenter le trafic.

Conservez une capture de requête avant et après. Un changement CDN n'est pas réussi simplement parce qu'une page s'affiche ; elle doit afficher la bonne représentation et réduire le travail sans affaiblir la sécurité.

Vérification et retour arrière

Utilisez curl -I pour les en-têtes, curl -w pour le timing, les DevTools du navigateur pour le comportement de cache et de service worker, et un outil terrain ou synthétique pour la couverture régionale. Vérifiez le corps de la réponse avec un marqueur de déploiement, pas seulement un en-tête de statut de cache. Inspectez aussi les redirections, cookies, compression, requêtes de plage et réponses d'erreur.

Si des erreurs, mélanges de données ou une surcharge de l'origine apparaissent, redirigez le trafic vers la cible précédente ou désactivez la règle modifiée via la procédure d'urgence. Gardez la version ou configuration CDN précédente active jusqu'à ce que la nouvelle soit stable. Ne purgez que les objets créés par la mauvaise règle et évitez une purge complète sauf si la mauvaise réponse pourrait être largement mise en cache ou empoisonnée. Réexécutez la matrice de vérification après le retour arrière.

Erreurs courantes

• Activer une règle de cache large avant d'identifier les chemins privés.
• Ignorer l'en-tête Host de l'origine ou le nom de certificat pendant la configuration du backend.
• Supposer que les changements de TTL DNS sont instantanés partout.
• Ajouter chaque en-tête de requête ou cookie à la clé, fragmentant le cache.
• Supprimer tous les paramètres de requête, y compris ceux qui modifient les prix ou résultats.
• Considérer les valeurs par défaut Cloudflare et Fastly comme interchangeables.
• Omettre les autorisations de purge, limites de débit et un test de retour arrière d'urgence.

Poursuivez avec le guide contenu statique ou dynamique pour concevoir la politique de cache, le processus de purge du cache pour des versions plus sûres et la page CDN managé d'Optimi pour le modèle plus large de diffusion edge. Les équipes e-commerce peuvent aussi consulter la solution e-commerce.

Il n'y a que deux choses difficiles en informatique : l'invalidation du cache et le choix des noms.