Réseau de diffusion de contenu : ce qu'un CDN change pour un site

Un CDN de site web assure la distribution de contenu dans le monde entier, un service de cloud computing que vendent Amazon CloudFront ou Google Cloud : la mise en cache du contenu statique près de l’utilisateur réduit le temps de chargement, épargne la bande passante du serveur d'origine et absorbe les pics de trafic.

Qu'est-ce qu'un CDN, ou réseau de diffusion de contenu ?

Un CDN, pour content delivery network ou réseau de diffusion de contenu, est une infrastructure de serveurs interconnectés répartis dans des dizaines, voire des centaines de villes, qui conservent une copie des fichiers d'un site web et les livrent depuis l'emplacement le plus proche de l'utilisateur. Chaque emplacement s'appelle un point de présence, abrégé PoP. Un PoP regroupe des serveurs de cache, des équipements réseau et une connexion directe aux grands opérateurs d'internet.

Le CDN ne remplace pas l'hébergeur. Le site reste installé sur son serveur d'origine, mutualisé, VPS ou dédié, avec ses fichiers, sa base de données et son CMS. Le fournisseur de CDN se place devant lui, comme un intermédiaire qui répond à sa place chaque fois qu'il dispose d'une copie valable de la ressource demandée. L'hébergement fabrique le contenu ; le réseau de diffusion le distribue.

Akamai, fondée en 1998 par des chercheurs du MIT, a ouvert ce marché à l'époque où les grands sites saturaient sous l'afflux des connexions. Amazon a lancé CloudFront en 2008, Cloudflare s'est fait connaître en 2010 avec une formule gratuite qui a mis le CDN à la portée des petits sites. Fastly, Bunny, Gcore ou les services de cloud de Google et de Microsoft complètent aujourd'hui le paysage. Les grands hébergeurs français intègrent souvent un CDN à leurs formules, parfois activable d'un clic depuis l'espace client.

Comment un CDN sert les fichiers d'un site web

Le fonctionnement d'un CDN repose sur la mise en cache : à la première demande d'une ressource, le serveur CDN la récupère auprès du serveur d'origine, la stocke, puis la sert directement aux utilisateurs suivants de la même région. Tant que la copie reste valable, l'origine n'est plus sollicitée pour ce fichier.

Le trajet d'une requête, étape par étape

1. Le navigateur de l'utilisateur interroge le DNS du domaine, qui renvoie l'adresse du réseau du fournisseur plutôt que celle de l'hébergement.
2. La requête arrive au PoP le plus proche. La plupart des grands réseaux utilisent l'anycast : la même adresse IP est annoncée depuis tous les points de présence, et le routage d'internet dirige chaque visiteur vers le plus accessible.
3. Le serveur cache vérifie s'il détient une copie fraîche du fichier. Si oui (un « hit »), il répond aussitôt.
4. Sinon (un « miss »), il interroge le serveur d'origine, transmet la réponse au visiteur et la conserve pour les demandes suivantes, selon les consignes reçues.

Deux gains se cumulent dans ce trajet. La distance d'abord : la lumière parcourt environ 200 000 kilomètres par seconde dans la fibre, et un aller-retour Paris-Montréal d'environ 11 000 kilomètres coûte au moins 55 millisecondes avant tout traitement. L'établissement de la connexion ensuite : une connexion TCP puis une négociation TLS demandent plusieurs allers-retours avant le premier octet utile. Quand ces échanges se font avec un serveur situé à quelques dizaines de kilomètres, le temps de réponse s'effondre pour chaque ressource.

Cache à plusieurs niveaux et bouclier d'origine

Un réseau mondial compte des centaines de PoP ; si chacun interrogeait l'origine pour remplir son cache, le serveur web recevrait encore beaucoup de requêtes. Les fournisseurs proposent donc un cache hiérarchisé, appelé tiered cache ou origin shield : les PoP de périphérie s'adressent d'abord à un nombre restreint de serveurs intermédiaires, et seuls ces derniers contactent l'hébergement. Pour un site sur une petite formule mutualisée, cette option réduit fortement le nombre de connexions reçues par l'origine.

La part des requêtes servies depuis le cache se mesure par le taux de hit (cache hit ratio), affiché dans le tableau de bord de chaque fournisseur. Un site vitrine bien réglé dépasse largement la moitié de ses ressources servies en cache ; un taux faible signale presque toujours des en-têtes mal envoyés par l'origine ou des cookies qui empêchent la mise en cache.

Quels contenus un CDN peut-il diffuser ?

Un CDN diffuse avant tout le contenu statique d'un site web, c'est-à-dire les fichiers identiques pour tous les utilisateurs : images, feuilles de style CSS, fichiers JavaScript, polices, documents PDF, archives à télécharger. Ces ressources pèsent l'essentiel d'une page et changent rarement, ce qui en fait les meilleures candidates au cache long.

Images et vidéos

Les images représentent souvent la plus grosse part du poids transféré. Plusieurs fournisseurs les optimisent à la volée : redimensionnement selon l'écran, conversion en WebP ou AVIF quand le navigateur les accepte, compression ajustée. La vidéo passe aujourd'hui par le streaming adaptatif (HLS ou DASH), qui découpe le flux en petits segments de quelques secondes ; un CDN met ces segments en cache comme n'importe quel fichier, et c'est cette distribution de contenu à grande échelle qui permet aux plateformes de diffuser un direct à des milliers de spectateurs sans saturer leur serveur.

Pages HTML et contenu dynamique

Le contenu dynamique, produit à chaque demande par le CMS ou l'application (page d'accueil d'un blog, résultat de recherche interne, fiche produit avec stock), se met aussi en cache, mais avec prudence. Une page publique identique pour tous peut rester quelques minutes ou quelques heures dans le cache, à condition d'être purgée à chaque publication. Les réponses personnalisées, en revanche, ne doivent jamais entrer dans un cache partagé.

Pour ce qui ne peut pas être mis en cache, le CDN garde un intérêt : il maintient des connexions ouvertes et optimisées vers l'origine, choisit les routes les moins encombrées et termine la négociation TLS près de l'utilisateur. Le gain est plus modeste que pour un fichier statique, mais mesurable sur les sites dont l'audience est lointaine.

Ce qu'un CDN apporte au-delà de la vitesse

Un CDN apporte d'abord de la résistance : le serveur d'origine reçoit beaucoup moins de requêtes, puisque les images et les fichiers statiques sont servis par le réseau. Une formule d'hébergement modeste supporte ainsi des pics de trafic qu'elle n'aurait pas tenus seule, par exemple après un passage à la télévision ou un article repris sur les réseaux sociaux. Lorsque l'origine tombe en panne, certains fournisseurs continuent de servir la dernière copie connue des pages (fonction « always online » ou stale-if-error), ce qui masque une coupure courte aux visiteurs.

Sécurité : filtrage et chiffrement

La sécurité est le deuxième apport. Placé en première ligne, le réseau absorbe les attaques par déni de service distribué (DDoS) qui visent à saturer la connexion, grâce à une capacité totale sans commune mesure avec celle d'un hébergement isolé. La plupart des CDN ajoutent un pare-feu applicatif (WAF) qui bloque les requêtes aux formes suspectes, des règles contre les robots qui testent des mots de passe, et une limitation du nombre de requêtes par adresse.

Le CDN gère aussi le chiffrement côté visiteur : il présente un certificat SSL valide pour le HTTPS, souvent fourni sans frais, et propose des protocoles récents comme HTTP/3, normalisé par l'IETF en juin 2022 (RFC 9114), sans rien modifier sur le serveur. Un point mérite l'attention : le lien entre le CDN et l'origine doit rester chiffré lui aussi. Chez Cloudflare, le mode « Flexible » laisse ce trajet en clair ; le mode « Full (strict) », qui exige un certificat valide sur l'hébergement, est celui qui protège réellement les données.

Bande passante et coût d'hébergement

La bande passante consommée chez l'hébergeur baisse dans la proportion des ressources servies en cache. Pour un site hébergé sur une formule facturée au volume transféré, ou sur un serveur cloud où la sortie de données se paie, l'économie compense souvent l'abonnement au CDN. Sur une formule mutualisée à trafic illimité, l'intérêt tient plutôt à la stabilité : moins de requêtes, moins de risque d'atteindre les limites de processus fixées par l'hébergeur.

Pourquoi un CDN n'accélère pas tous les sites

Un CDN n'accélère pas un site dont le serveur met plusieurs secondes à générer chaque page HTML. Le temps passé à exécuter PHP, interroger la base de données et assembler la page se produit avant que le moindre octet parte vers l'utilisateur ; si cette page n'est pas mise en cache, le réseau ne fait que transmettre une réponse tardive. Le premier chantier reste alors l'hébergement lui-même : version de PHP, cache objet, requêtes lourdes, extensions superflues.

Le temps de réponse du premier octet (TTFB) sert d'indicateur. Les recommandations de web.dev, le site de documentation de Google sur la performance, situent un bon TTFB à 0,8 seconde ou moins. Au-delà, ajouter un CDN sans mettre le HTML en cache n'améliore presque rien pour le document principal, même si les images arrivent plus vite.

Un site local tire aussi un bénéfice plus limité. Une boulangerie de Lyon hébergée en France, dont les clients habitent la région, ne gagne que quelques millisecondes de trajet. Le CDN reste utile pour la protection et la compression, mais la vitesse perçue dépend davantage du poids des images et du nombre de scripts tiers. À l'inverse, un site marchand qui livre en Europe et au Canada, une application consultée sur plusieurs continents ou un média avec un fort trafic de vidéos y trouvent un gain net.

Les réglages de cache qui font la différence

Le comportement d'un CDN dépend des en-têtes HTTP envoyés par le serveur d'origine, au premier rang desquels Cache-Control, qui indique si une réponse peut être conservée et pendant combien de temps. Un CDN mal réglé sert des pages périmées ou, à l'inverse, ne met presque rien en cache : la configuration compte plus que le choix du fournisseur.

Les directives les plus utiles sont peu nombreuses. max-age fixe la durée de conservation pour tous les caches, navigateur compris ; s-maxage s'applique aux seuls caches partagés comme le CDN, ce qui permet de garder une page dix minutes au bord du réseau sans que le navigateur la conserve ; private et no-store interdisent le cache partagé ; stale-while-revalidate autorise à servir une copie légèrement ancienne pendant que la nouvelle se récupère en arrière-plan. Chaque type de contenu demande un traitement différent.

Cookies et en-tête Vary

Les cookies sont la première cause d'un cache inefficace. La plupart des CDN refusent par défaut de conserver une réponse qui pose un cookie (Set-Cookie), et beaucoup contournent le cache dès que la requête en porte un. Un CMS qui dépose un cookie de session à chaque visiteur, même anonyme, rend ainsi toutes ses pages impossibles à cacher. L'en-tête Vary pose un problème voisin : un Vary: User-Agent multiplie les copies d'une même adresse par le nombre de navigateurs et vide presque le cache de son utilité.

La purge après une modification

Prévoir la purge est indispensable : après une modification, il faut pouvoir vider le cache d'une adresse, d'un groupe de fichiers ou de tout le site. Les fournisseurs proposent la purge par URL, par préfixe, par étiquette (cache tags ou surrogate keys, qui invalident toutes les pages liées à un article en une seule commande) ou totale. Les extensions de cache des CMS, sous WordPress notamment, déclenchent cette purge à chaque publication par l'API du fournisseur ; c'est la condition pour garder un cache HTML long sans afficher d'informations dépassées.

Mettre en place un CDN devant son hébergement

La mise en place d'un CDN passe presque toujours par le DNS du domaine, selon l'une ou l'autre de deux méthodes. Dans la première, le domaine délègue ses serveurs de noms au fournisseur, qui gère alors toute la zone et place son réseau devant les sous-domaines choisis. Dans la seconde, la zone reste chez le registraire ou l'hébergeur, et seul un enregistrement CNAME, par exemple pour www, pointe vers l'adresse fournie par le CDN. Le choix touche aussi la messagerie et les autres services du domaine : avant toute bascule, il vaut mieux relever chaque enregistrement de la zone DNS, MX et TXT compris, pour qu'aucun ne disparaisse.

Une troisième voie, plus rare sur les petits sites, consiste à servir les seuls fichiers statiques depuis un sous-domaine dédié (static.exemple.fr ou une adresse fournie par le CDN), réécrite par une extension du CMS. Le HTML continue alors de partir de l'hébergement, et le CDN ne livre que les images, les scripts et les feuilles de style.

Les vérifications après la bascule

• Lire les en-têtes de réponse : cf-cache-status: HIT chez Cloudflare, X-Cache: Hit from cloudfront chez Amazon, X-Cache: HIT chez Fastly, et l'en-tête Age, qui indique depuis combien de secondes la copie est en cache.
• Tester une page connectée (compte, panier) depuis deux navigateurs différents pour s'assurer qu'aucune donnée personnelle n'est servie à un autre utilisateur.
• Mesurer le temps de chargement depuis plusieurs régions avec un outil comme WebPageTest, avant et après, plutôt que depuis son seul poste.
• Vérifier que les formulaires, les paiements et l'administration fonctionnent, car un pare-feu trop strict bloque parfois des requêtes légitimes.
• Contrôler que l'hébergement n'accepte plus de connexions directes que du CDN, si l'on veut que la protection ne soit pas contournée par l'adresse IP d'origine.

Mesurer ce que le CDN change pour l'utilisateur

Mesurer l'effet d'un CDN sur un site web suppose de comparer des chiffres pris dans les mêmes conditions, avant et après son utilisation. Les données de terrain du rapport Chrome UX (CrUX), visibles dans PageSpeed Insights et dans la Search Console, reflètent l'expérience réelle des internautes sur 28 jours glissants : elles évoluent lentement, mais elles ne dépendent pas de la connexion de la personne qui teste. Les mesures de laboratoire, plus simples à répéter, servent à vérifier un réglage précis.

Trois indicateurs suffisent également à juger le résultat : le temps de chargement complet vu depuis plusieurs pays, le TTFB des pages HTML et la part des requêtes servies par le cache. Un CDN qui fonctionne bien doit améliorer les deux premiers et faire monter le troisième. Si le temps de chargement ne bouge pas, la cause se trouve presque toujours ailleurs : images trop lourdes, scripts publicitaires, polices chargées depuis plusieurs domaines.

L'utilisation d'un CDN s'accompagne aussi d'un suivi des erreurs. Les tableaux de bord des fournisseurs distinguent les erreurs renvoyées par le réseau de celles qui viennent de l'hébergement ; une hausse soudaine des codes 5xx signale souvent un serveur saturé derrière le cache, et permet d'améliorer la configuration avant que les utilisateurs ne s'en plaignent. Comparer les offres sur ce point aide à choisir une solution dont les statistiques restent lisibles sans compétence de développeur.

Une infrastructure web plus rapide profite enfin à l'ensemble des visiteurs, pas seulement aux plus lointains : sur mobile, chaque connexion épargnée compte. La solution consiste rarement à empiler les outils ; il s'agit plutôt de réduire le poids de chaque page, puis de laisser le CDN distribuer également ce qui reste, au plus près de chaque utilisateur. Les offres d'entrée de gamme couvrent ce besoin pour la plupart des sites web, et la configuration reste simple tant que le HTML n'entre pas dans le cache.

Un CDN améliore-t-il le référencement ?

Un CDN améliore le référencement de façon indirecte, par la vitesse : Google intègre l'expérience de page, et notamment les Core Web Vitals, parmi les signaux qu'il prend en compte. Les seuils publiés par Google qualifient de bon un LCP (affichage du plus grand élément) de 2,5 secondes ou moins, un INP (réactivité, qui a remplacé le FID en mars 2024) de 200 millisecondes ou moins, et un CLS (stabilité visuelle) de 0,1 ou moins. Un CDN agit surtout sur le LCP, en livrant plus vite l'image principale et les ressources qui bloquent l'affichage.

Le moteur ne pénalise pas l'usage d'un CDN : l'adresse IP partagée avec d'autres sites n'a pas d'effet sur le classement, et le réseau ne crée pas de contenu en double tant que le site reste servi sous un seul nom de domaine. Le risque vient plutôt des protections anti-robots trop agressives, qui peuvent bloquer Googlebot ou les robots d'autres moteurs de recherche ; le rapport « Statistiques sur l'exploration » de la Search Console permet de repérer une hausse des erreurs après la mise en place. Le lien entre serveur et visibilité dépasse d'ailleurs la vitesse, comme le montre l'importance de l'hébergement pour le référencement : localisation, disponibilité et temps de réponse s'y combinent.

Le gain de vitesse sert aussi la conversion et l'expérience utilisateur, indépendamment de Google : une page qui s'affiche vite retient davantage les visiteurs mobiles, souvent sur des connexions moins stables. Un CDN ne compense toutefois pas une page trop lourde ; réduire le poids des images et le nombre de scripts tiers reste la base de toute optimisation de performance.

Comment choisir un fournisseur de CDN

Le choix d'un fournisseur de CDN se fait sur des critères de sélection mesurables plutôt que sur la taille du réseau annoncée. La présence de points de présence là où se trouvent les visiteurs compte davantage que leur nombre total : un site francophone a besoin d'une bonne couverture en France, en Belgique, en Suisse et au Québec, pas forcément en Asie du Sud-Est.

• Couverture et performances : emplacement des PoP proches de l'audience, résultats de mesures indépendantes, qualité des interconnexions avec les opérateurs français.
• Fonctions de cache : cache du HTML, purge rapide par URL et par étiquette, cache hiérarchisé, règles par chemin.
• Sécurité : protection DDoS incluse, pare-feu applicatif, gestion des robots, certificats automatiques.
• Tarification : formule gratuite, forfait mensuel ou facturation au volume transféré et au nombre de requêtes ; ce dernier modèle convient aux sites au trafic irrégulier mais rend la facture moins prévisible.
• Support technique : langue, délai de réponse, assistance incluse ou réservée aux formules supérieures.
• Intégration : extension pour le CMS utilisé, API, compatibilité avec l'hébergeur actuel.

Pour un blog ou un site vitrine, une formule gratuite suffit souvent : elle couvre la mise en cache des fichiers statiques, le certificat et une protection de base. Les formules payantes ajoutent des règles de pare-feu avancées, l'optimisation des images, des statistiques détaillées, le cache HTML intelligent ou une assistance réactive. Les grands sites combinent parfois plusieurs fournisseurs (multi-CDN) pour répartir la charge et ne pas dépendre d'un seul réseau en cas de panne.

CDN, données personnelles et RGPD

Un CDN traite des données personnelles : chaque requête transmet l'adresse IP du visiteur, que le RGPD considère comme une donnée à caractère personnel. Le fournisseur agit en sous-traitant de l'éditeur du site, ce qui suppose un contrat de traitement des données, généralement intégré aux conditions générales. Les journaux de connexion conservés par le CDN entrent dans le même cadre.

Quand le fournisseur est établi aux États-Unis, la décision d'adéquation de la Commission européenne sur le cadre de protection des données UE-États-Unis, adoptée le 10 juillet 2023, couvre les entreprises qui y ont adhéré. Certains fournisseurs proposent aussi de cantonner le traitement et le stockage des journaux à l'Union européenne, et des acteurs européens offrent une solution hébergée sur le continent. Les obligations de l'éditeur vis-à-vis de ses prestataires sont détaillées avec les obligations d'un responsable de traitement envers son hébergeur.

Au-delà du cache : le calcul en périphérie

Les grands réseaux ne se limitent plus à stocker des fichiers : l'edge computing permet d'exécuter du code directement sur les serveurs du CDN, au plus près de l'utilisateur. Cloudflare Workers, Fastly Compute ou Lambda@Edge chez Amazon servent à réécrire des adresses, rediriger selon le pays, tester deux versions d'une page, assembler une réponse à partir de fragments en cache ou vérifier une authentification sans solliciter l'origine.

Pour un site classique, ces fonctions restent optionnelles. Elles deviennent intéressantes quand l'application a besoin de logique rapide pour chaque requête : redirections nombreuses, personnalisation légère, sites statiques générés à l'avance et servis intégralement depuis le réseau. Cette architecture, où le serveur d'origine se réduit à un espace de stockage, montre jusqu'où la diffusion de contenu peut remplacer une partie du rôle de l'hébergement traditionnel. Les autres articles du blog sur l'hébergement présentent les formules qui se combinent avec ce type de service.

Hébergeur, formule gratuite, audience française et en-têtes HIT

Un CDN remplace-t-il un hébergeur ?

Un CDN ne remplace pas l'hébergeur dans la grande majorité des cas : il distribue des copies de fichiers produits ailleurs, et le site a toujours besoin d'un serveur d'origine pour son CMS, sa base de données et ses fichiers. Seul un site entièrement statique peut se passer d'hébergement classique, en stockant ses pages directement chez certains fournisseurs.

Un CDN gratuit suffit-il pour un petit site ?

Une formule gratuite suffit pour la plupart des blogs et sites vitrines : elle met en cache les images et les fichiers statiques, fournit un certificat et absorbe les attaques courantes. Les formules payantes deviennent utiles pour un site marchand qui veut mettre son HTML en cache, optimiser ses images automatiquement ou obtenir une assistance rapide.

Faut-il un CDN pour un site visité uniquement en France ?

Un site visité uniquement en France gagne peu en distance, puisque son hébergement est déjà proche de son audience. Le CDN garde un intérêt pour la protection contre les attaques, la tenue face aux pics de trafic et la compression des ressources, mais la priorité reste un serveur rapide et des pages légères.

Comment savoir si une page est servie par le cache du CDN ?

Les en-têtes de réponse indiquent si une ressource vient du cache : cf-cache-status chez Cloudflare, X-Cache chez Amazon CloudFront ou Fastly, et l'en-tête Age. Ils se lisent dans l'onglet Réseau des outils de développement du navigateur ; une valeur HIT signale une réponse servie sans passer par l'origine.