Décidez ce que le CDN doit délivrer
Commencez par un inventaire. Séparez les assets versionnés comme images, feuilles de style, scripts, polices et téléchargements du HTML, des APIs, des pages de compte, du checkout et de l’administration. Les CDN remplissent souvent un cache à la demande : la première requête peut atteindre l’origine, tandis que les requêtes ultérieures correspondantes peuvent être servies à la périphérie (edge). Un edge proche et un hit de cache sont deux bénéfices distincts.
Enregistrez l’hôte, l’application, le bucket de stockage ou le load balancer qui fournit chaque chemin ; il doit répondre à un miss de cache.
Commencez par les assets identiques pour tous les visiteurs qui peuvent rester disponibles en toute sécurité jusqu’à la fin de leur durée de vie indiquée.
Ne partagez pas les tableaux de bord personnalisés, les pages liées à une session ou les données clients sauf si un ingénieur qualifié a conçu et testé la séparation.
Définissez la politique de cache à partir du comportement du contenu
Les en-têtes de réponse HTTP expriment le comportement du cache. Cache-Control indique si une réponse peut être stockée et combien de temps elle reste fraîche ; un time to live, ou TTL, est cette période de fraîcheur. Un navigateur est un cache privé, tandis qu’un CDN est généralement partagé. Utilisez des en-têtes explicites. Le standard HTTP permet d’utiliser s-maxage pour définir séparément la durée de vie d’un cache partagé par rapport à max-age.
Publiez une nouvelle URL lorsque le contenu change, par exemple un nom de fichier avec hash de contenu, puis donnez à la version immuable une longue durée de vie documentée.
Choisissez une durée courte ou un comportement de validation selon le coût d’un contenu obsolète ; n’utilisez pas la règle d’un asset pour les prix, l’inventaire ou l’état des comptes.
Utilisez private pour les réponses destinées à un seul utilisateur. Un cookie seul ne rend pas une réponse sûre pour un cache partagé.
Faites de l’invalidation une exception, pas le plan de déploiement
L’invalidation, ou purge, demande à un CDN géré de supprimer des objets stockés sélectionnés avant l’expiration normale. Servez-vous-en pour les corrections, pas pour chaque déploiement. Confirmez que l’origine renvoie déjà le remplacement avant de purger ; sinon un refill peut préserver la mauvaise réponse. Les caches des navigateurs sont hors du contrôle de purge du CDN, donc le versionnement d’URL reste fiable pour les fichiers changeants.
Privilégiez un chemin spécifique, un groupe de release ou une étiquette de cache prise en charge par le fournisseur plutôt qu’une purge site-wide ; des misses larges peuvent charger soudainement l’origine.
Une purge distribuée peut ne pas atteindre chaque edge simultanément. Vérifiez les sémantiques de complétion du fournisseur et testez une URL représentative.
Enregistrez l’ancienne et la nouvelle URL, la règle de cache, l’étendue de purge, le résultat attendu et l’étape de réversion.
Placez l’origine derrière la couche de livraison
L’accès direct à l’origine peut contourner le cache du CDN et les contrôles edge. Restreignez-le pour que le CDN, et uniquement les chemins prévus, puisse y accéder. En fonction de votre stack, utilisez le contrôle d’accès d’origine cloud, des règles de pare-feu avec les plages egress documentées du CDN, un réseau privé, des requêtes signées vers l’origine ou mTLS (mutual TLS), où les deux côtés s’authentifient par certificats.
Depuis un emplacement de test autorisé, confirmez que l’origine rejette les requêtes publiques tandis que le nom d’hôte CDN fonctionne.
Ciblez les checks de santé, les outils de déploiement et les accès internes par identité et réseau plutôt que par une règle publique large.
L’authentification d’origine diffère selon le CDN et l’origine. Suivez les guides actuels du fournisseur et effectuez une revue de sécurité.
Considérez TLS comme deux connexions
Le HTTPS à l’edge protège la connexion visiteur→CDN, mais la connexion CDN→origine doit aussi être protégée. Exigez le chiffrement sur les deux tronçons, validez le certificat d’origine pour le mode CDN, et assignez la propriété de l’hôte et du renouvellement. OWASP recommande TLS 1.3 par défaut et autorise TLS 1.2 pour compatibilité ; TLS 1.0 et 1.1 doivent être désactivés. Obtenez une revue qualifiée pour les données régulées, les flux de paiement ou des compatibilités client inhabituelles.
Listez les propriétaires des certificats edge et origine, les voies de renouvellement et la réponse en cas de défaillance.
Testez les redirections HTTP→HTTPS, host canonique et les redirections profondes pour déceler boucles ou chemins perdus.
Le chiffrement ne rend pas une réponse sûre à mettre en cache ; définissez séparément les règles de cache pour les pages authentifiées, personnelles et liées au paiement.
Testez le chemin de livraison réel avant de modifier le trafic
Commencez sur un nom d’hôte de staging ou un chemin production restreint, puis testez le nom d’hôte CDN, pas seulement l’origine. Chrome DevTools Network affiche l’état de la requête, le domaine, le timing, la taille et les en-têtes. Testez un rechargement forcé (hard reload) avec cache vide pour approximer une première visite, puis une visite répétée pour inspecter la réutilisation. Comparez les en-têtes et le contenu attendus, pas seulement une page qui semble plus rapide. Répétez depuis des régions représentatives si l’audience est géographiquement répartie.
Inspectez Cache-Control et les en-têtes provider cache-status. Confirmez que les assets publics sont réutilisés et que les pages sensibles ne sont pas partagées de manière inattendue.
Exercez un miss, une correction de contenu obsolète, une erreur d’origine et le rollback d’un asset ou d’une route avant un lancement large.
Sauvegardez les URL testées, les captures d’en-têtes, la version de règle de route et les timings avant/après avec le registre de changement.
Choisissez un CDN selon vos besoins opérationnels, puis prouvez-le
Ne choisissez pas un CDN uniquement sur le nombre de points de présence ou une affirmation générique de rapidité. Les performances varient selon la géographie, l’heure, la distribution du trafic, le routage et le taux de hit du cache. Comparez les candidats sur des routes, assets et régions représentatifs. Demandez si chacun prend en charge vos besoins en contrôles de cache, invalidation ciblée, restriction d’origine, workflow de certificats, logs, rôles d’accès, tarification, support et processus de changement.
Utilisez des en-têtes de cache, un comportement d’origine et des pages identiques pour les candidats ; enregistrez séparément les résultats première visite et visite répétée.
Passez en revue les coûts de requêtes, transfert, invalidation, journalisation et support, plus un pic de miss de cache. La tarification et les contrôles varient selon le plan.
Exigez une configuration exportable, le principe du moindre privilège, un rollback testé et une propriété claire avant de couvrir des routes critiques.