Hébergement CDN

En résumé : un CDN (Content Delivery Network, ou réseau de diffusion de contenu) place vos fichiers statiques — images, vidéos, CSS, JavaScript, polices — sur des serveurs répartis géographiquement, pour que chaque visiteur les reçoive depuis le point le plus proche de lui. Résultat : des pages qui s’affichent plus vite, un serveur d’origine soulagé et des pics de trafic absorbés sans ralentissement. Chez DEMARCQ.NET, le CDN s’intègre à l’hébergement et à l’infogérance, avec la purge du cache et la supervision comprises.

Comment fonctionne un CDN ?

Un site classique fonctionne en étoile : tous les visiteurs, où qu’ils soient, demandent leurs fichiers à une seule machine. Un visiteur situé à l’autre bout du monde attend donc que chaque image traverse l’océan, en plus du temps de traitement du serveur.

Un CDN intercale un réseau de serveurs en bordure d’Internet — les points de présence — entre vos visiteurs et votre serveur d’origine. Le principe tient en trois temps :

1. Un visiteur demande une image. La requête est dirigée vers le point de présence le plus proche de lui.
2. Si ce point possède déjà l’image en cache, il la sert immédiatement, sans aller plus loin.
3. Sinon, il la récupère une fois auprès de votre serveur d’origine, la conserve selon les règles de cache définies, puis la sert à tous les visiteurs suivants.

Votre serveur n’est donc plus sollicité pour chaque image, mais une seule fois par fichier et par point de présence. Sur un site riche en photos ou en vidéos, c’est la majeure partie de la charge qui disparaît.

Ce que le CDN change concrètement

Le temps d’affichage pour vos visiteurs

La latence réseau est le facteur le plus visible : un fichier servi depuis un point de présence à 200 km arrive plus vite qu’un fichier servi depuis un serveur à 8 000 km. Sur une page qui charge quarante ressources, ces millisecondes s’additionnent.

Les pics de trafic

Une campagne, une mention sur les réseaux sociaux, une newsletter : le CDN encaisse la rafale à la place de votre serveur. Les fichiers statiques — de loin les plus nombreux — sont servis par le réseau, votre machine ne traite que les pages dynamiques.

La bande passante du serveur d’origine

Les images et les vidéos sont les plus gros transferts d’un site. En les déportant, vous réduisez la bande passante consommée sur votre hébergement, donc le risque de saturation et, souvent, le coût du forfait.

Les Core Web Vitals et le référencement

Les indicateurs de vitesse mesurés par Google — LCP, INP, CLS — dépendent directement du temps de chargement des ressources. Un CDN ne remplace pas l’optimisation d’une page, mais il enlève la part réseau du problème. Voir plus bas la section consacrée au SEO.

CDN « push » ou CDN « pull » : deux modèles à ne pas confondre

	CDN Push	CDN Pull
Principe	Les fichiers sont envoyés au CDN à l’avance, puis répliqués sur le réseau.	Le CDN se sert lui-même chez votre serveur, à la première demande.
Mise en place	Les liens des fichiers statiques sont réécrits vers un sous-domaine dédié.	Un simple changement de DNS ou de règle de proxy suffit.
Mises à jour	Nécessite un envoi ou une purge explicite.	Se met à jour selon le TTL de cache configuré.
Pour qui	Sites à contenus stables, vidéos, téléchargements volumineux.	Sites éditoriaux et e-commerce, contenus qui changent souvent.

L’offre historique de DEMARCQ.NET est de type push : le contenu est injecté dans le réseau, répliqué sur les nœuds de bordure, et servi depuis un sous-domaine dédié. C’est le modèle le plus simple à intégrer côté développement, et le plus prévisible en performance. Une API de purge permet de retirer un fichier du cache dès qu’il est mis à jour.

CDN OVH : ce que change l’option CDN d’OVHcloud

« OVH CDN » et « CDN OVH » désignent la même chose : l’option de diffusion que propose OVHcloud devant un serveur ou un hébergement. Elle s’active depuis l’espace client, se place devant le domaine ou le sous-domaine concerné, et met en cache les fichiers statiques sur le réseau de points de présence de l’opérateur.

Trois précisions qui évitent les malentendus :

• L’option ne remplace pas un réglage applicatif. Si votre CMS envoie des en-têtes de cache interdisant la mise en cache, le CDN OVH respectera ces en-têtes et ne servira rien depuis la bordure.
• Le certificat TLS se gère au niveau du CDN. Une erreur de certificat sur le domaine en CDN rend le site inaccessible, même si le serveur d’origine est sain.
• La purge n’est pas instantanée partout. Comptez de quelques secondes à quelques minutes selon les points de présence.

Le modèle retenu par OVHcloud est un CDN de type pull : le réseau se sert chez vous à la première demande, puis conserve selon le TTL. C’est différent d’un CDN push, où les fichiers sont injectés à l’avance — voir le tableau comparatif plus haut sur cette page.

Nous configurons et supervisons cette option dans le cadre de l’infogérance de serveurs OVH : en-têtes de cache, purge après déploiement, contrôle du certificat et mesure du taux de cache réellement atteint. Sans mesure, « le CDN est activé » ne veut rien dire.

Ce que le CDN ne fait pas

• Il ne corrige pas un site lent par nature. Une requête SQL mal indexée ou un code PHP inefficace restent lents : le CDN ne met pas les pages dynamiques en cache par défaut.
• Il ne remplace pas un pare-feu applicatif. Certains réseaux intègrent une protection contre les attaques, d’autres non. Si la sécurité est l’objectif, c’est un sujet distinct.
• Il ne dispense pas de haute disponibilité. Le CDN sert les fichiers statiques depuis son cache ; si votre serveur d’origine tombe, les pages dynamiques restent indisponibles. Pour cela, voir l’hébergement haute disponibilité.
• Il n’est pas magique sur le cache applicatif. Redis, OPcache et cache de pages répondent à un autre besoin : celui du contenu généré.

Comment se passe la mise en place

1. Inventaire des ressources : quels fichiers passent par le CDN (images, CSS, JS, médias), et lesquels doivent rester sur le serveur (API, formulaires, pages personnalisées).
2. Création du sous-domaine dédié, certificat TLS valide — un CDN en HTTP sur un site en HTTPS provoque des avertissements de contenu mixte.
3. Réécriture des liens dans les gabarits ou le CMS, avec les règles de cache adaptées à chaque type de fichier.
4. Purge et versionnement : les fichiers modifiés sont purgés ou servis avec un nouveau nom, pour éviter qu’un ancien visuel reste en cache des semaines.
5. Mesure : temps de réponse avant et après, taux de cache atteint, erreurs 4xx/5xx sur le sous-domaine.

Côté développement, l’intégration se limite souvent à une variable de configuration pour le préfixe des ressources — c’est justement l’intérêt du modèle push. Nous fournissons l’accès à l’API de purge pour automatiser l’invalidation lors des déploiements.

CDN et référencement : ce qu’il faut savoir

Trois idées fausses circulent sur le CDN et Google.

• « Un CDN crée du contenu dupliqué. » Non : les fichiers servis depuis un sous-domaine du même site ne constituent pas une duplication de pages. Un CDN tiers correctement configuré n’a aucun effet négatif.
• « Il suffit d’un CDN pour être rapide. » Non : Google mesure l’expérience réelle des visiteurs. Un CDN améliore la part réseau, pas la part serveur ni le rendu.
• « Le CDN améliore le classement à lui seul. » Non : la vitesse est un facteur parmi d’autres. Le CDN aide à passer les seuils des Core Web Vitals, ce qui reste un avantage réel, en particulier sur mobile.

Un point technique compte davantage que le reste : le TTL de cache. Trop court, le CDN ne sert à rien ; trop long, vos mises à jour n’arrivent jamais chez les visiteurs. La bonne pratique est un cache long sur les fichiers versionnés (noms qui changent à chaque déploiement) et un cache court sur le reste, avec purge à la publication.

Les erreurs fréquentes

• Mettre les pages HTML en cache par défaut sans réfléchir : les visiteurs voient une version figée, les paniers et les formulaires se comportent bizarrement.
• Oublier les en-têtes de cache sur les fichiers versionnés : le CDN redemande le fichier à chaque visite.
• Servir des polices ou des scripts depuis un domaine sans CORS : le navigateur bloque la ressource.
• Laisser un certificat expiré sur le sous-domaine : tout le site paraît cassé alors que seul le CDN est en cause.
• Croire qu’une purge est instantanée partout : la propagation sur l’ensemble des points de présence prend quelques secondes à quelques minutes.

Pour quels sites le CDN est-il rentable ?

• E-commerce : images produits nombreuses, pics saisonniers, mobile majoritaire. C’est le cas d’usage le plus évident.
• Sites médias et blogs à forte audience : beaucoup d’images, peu de pages différentes.
• Sites vitrines internationaux : visiteurs répartis sur plusieurs continents.
• Plateformes avec vidéos ou téléchargements : le gain en bande passante se voit sur la facture.

À l’inverse, un site de dix pages, avec une audience locale et un serveur déjà bien réglé, n’a pas besoin d’un CDN : le gain serait marginal au regard de la complexité ajoutée.

Questions fréquentes

Quelle différence entre CDN et cache serveur ?

Le cache serveur (Redis, OPcache, cache de pages) évite de recalculer le contenu sur votre machine. Le CDN évite de le transporter jusqu’au visiteur. Les deux se complètent : voir notre article sur les systèmes de cache.

Le CDN fonctionne-t-il avec WordPress, Magento ou WooCommerce ?

Oui. Sur WordPress, un greffon ou une règle de configuration réécrit les URL des médias et des assets. Sur Magento et WooCommerce, la purge est déclenchée à l’enregistrement d’un produit ou d’une page. La vigilance porte sur les pages de panier et de compte, qui ne doivent jamais être mises en cache.

Faut-il changer d’hébergeur pour avoir un CDN ?

Non. Le CDN est indépendant de l’hébergement : il s’intercale entre vos visiteurs et votre serveur actuel. C’est même la façon la plus rapide de gagner en performance sans migrer.

Que se passe-t-il si un fichier est mis à jour ?

Deux méthodes : purge explicite via l’API ou le panneau, ou versionnement du nom de fichier. La seconde est plus robuste, car elle ne dépend d’aucune propagation de purge.

Le CDN protège-t-il contre les attaques ?

Il absorbe une partie du trafic malveillant en le servant depuis son cache, et certains réseaux ajoutent un filtrage. Ce n’est pas une protection complète : pour cela, voir nos solutions de sécurité et la protection contre les attaques DDoS.

Chiffrer votre besoin

Indiquez-nous le volume de trafic, le poids moyen d’une page et vos pics attendus : nous répondons avec une architecture et un prix. Si votre site est déjà hébergé chez nous, le CDN s’active sans migration.

Pour aller plus loin : hébergement haute disponibilité, hébergement Magento et WooCommerce, infogérance serveur et l’ensemble de nos services.