Un CDN est un réseau de serveurs distribués qui met le contenu en cache près des utilisateurs, pour que pages et fichiers se chargent vite partout. Le problème qu’il résout est physique : une requête partie de São Paulo vers un serveur à Francfort paie l’aller-retour en latence, à chaque fois. Un CDN répond depuis São Paulo — et une précision évite des confusions sans fin : il complète votre hébergement, il ne le remplace jamais.
Points clés
| Question | Réponse |
|---|---|
| Ce que c’est | Des serveurs edge distribués qui détiennent des copies en cache de votre contenu |
| Le problème résolu | La distance — la latence croît avec l’aller-retour jusqu’à votre origine |
| Le mécanisme | Routage vers l’edge le plus proche → un cache hit répond aussitôt ; un miss va chercher à l’origine une seule fois |
| Les leviers | En-têtes Cache-Control, TTL, purge ou noms de fichiers versionnés |
| Ce qu’il n’est pas | Un hébergeur web, ni de l’edge computing — de la distribution, pas du stockage ni de la logique |
Les leviers qui le font fonctionner
Tout le contrat de mise en cache tient dans un seul en-tête HTTP — et c’est la pièce la moins bien expliquée de toutes les présentations des CDN :
# L'instruction de l'origine à chaque cache entre elle et l'utilisateur :
Cache-Control: public, max-age=300, s-maxage=86400, stale-while-revalidate=3600
public → n'importe quel cache peut stocker ceci
max-age=300 → navigateurs : frais pendant 5 minutes
s-maxage=86400 → edges du CDN : frais pendant 24 heures
stale-while-revalidate → servir le périmé tout de suite, rafraîchir en arrière-plan
# L'autre stratégie : ne jamais expirer, ne jamais purger — versionner le nom du fichier
/_assets/app.3f9c1b.css → en cache "pour toujours" ; un nouveau build = une nouvelle URLLa provenance des fichiers dans une app compte aussi — sur un backend géré, un envoi renvoie une URL prête pour la distribution, avec une stratégie de cache déjà saine :
// JavaScript / Node.js — Back4app JS SDK
// Upload once; the returned URL serves from edge cache worldwide
const file = new Parse.File('hero.webp', { base64: imageData });
await file.save();
console.log(file.url()); // CDN-backed, cache-friendly URL// Flutter / Dart — Back4app Flutter SDK
final file = ParseFile(File('hero.webp'));
await file.save();
print(file.url); // CDN-backed, cache-friendly URL// iOS / Swift — Back4app Swift SDK
let file = ParseFile(name: "hero.webp", data: imageData)
file.save { result in
if case .success(let saved) = result {
print(saved.url ?? "") // CDN-backed, cache-friendly URL
}
}// Android / Kotlin — Back4app Android SDK
val file = ParseFile("hero.webp", imageBytes)
file.saveInBackground { e ->
if (e == null) Log.d("CDN", file.url) // CDN-backed, cache-friendly URL
}Anatomie d’une requête
Le vocabulaire en un passage : l’origine est votre vrai serveur — la source de vérité. Un PoP (point de présence) est un emplacement de data center du CDN ; les serveurs edge sont les machines de cache qu’il abrite. Le taux de cache hit — la part des requêtes servies sans solliciter l’origine — est la métrique que tout l’exercice optimise, et les leviers sont les en-têtes ci-dessus. Ce qui s’améliore pour les utilisateurs, c’est le TTFB (time to first byte) et, quand des pages entières sont en cache en périphérie, les métriques de chargement qui en découlent.
CDN vs. hébergement web vs. edge computing
| Dimension | Hébergement web (origine) | CDN | Edge computing |
|---|---|---|---|
| Rôle | Stocke le contenu de référence | Distribue des copies en cache | Exécute de la logique près des utilisateurs |
| Répond à | ”Où vit mon site ?" | "Pourquoi est-il rapide à Tokyo ?" | "Puis-je calculer à Tokyo ?” |
| État | Permanent | Temporaire, borné par le TTL | Généralement sans état |
| Sans lui | Pas de site | Site lent, origine exposée | Un aller-retour pour chaque décision |
| Contenu typique | Tout, une seule fois | Ressources statiques, médias, pages entières en cache | Personnalisation, contrôles d’auth, réécritures |
La définition du MDN ajoute la mise en garde que les pages des fournisseurs omettent : les scripts servis par un CDN tiers sont une dépendance de la chaîne d’approvisionnement (les attributs d’intégrité existent pour une raison), et une résolution DNS supplémentaire vers un CDN peut même coûter du temps lors d’une première visite — un levier, pas de la magie.
Cas d’usage courants
- Ressources statiques à grande échelle. CSS, JavaScript, polices, images — des noms de fichiers à empreinte et des TTL longs transforment les visites répétées en trafic purement edge.
- Médias et téléchargements. Segments vidéo et fichiers volumineux, là où la bande passante de l’origine serait à la fois la facture et le goulot d’étranglement.
- Audiences mondiales. La même page servie en moins de 100 ms sur quatre continents, sans faire tourner de serveurs sur quatre continents.
- Pics de trafic et lancements. L’edge absorbe la vague ; l’origine n’en voit qu’une fraction.
- Posture de sécurité. Origine masquée derrière un reverse proxy, TLS terminé en périphérie, attaques volumétriques dissipées sur l’ensemble du réseau.
Avez-vous besoin d’un CDN ? Matrice de décision
| Un CDN est rentable quand… | Passez-vous-en (ou reportez-le) quand… |
|---|---|
| Les utilisateurs sont loin de votre origine | Votre audience est dans la région de votre serveur |
| Ressources et médias dominent votre trafic | L’app est petite, dynamique et centrée sur l’API |
| Les pics de trafic font partie du métier | Le trafic est trop faible pour que les caches restent chauds |
| La bande passante de l’origine coûte vraiment | La pièce mobile de plus pèse plus que les ms gagnées |
| Vous voulez absorber les DDoS devant l’origine | Vous mettriez en cache des réponses personnalisées (impossible) |
La ligne honnête que personne n’imprime : sur un site à faible trafic, les copies en cache expirent entre deux visiteurs, chaque requête est un miss, et le CDN ajoute un saut pour rien. La distance et le volume sont les données d’entrée ; sans l’un ni l’autre, réglez d’abord autre chose.
Limites et trade-offs
- Le contenu périmé est la panne par défaut. Des TTL longs signifient que le fichier d’hier est servi avec aplomb aujourd’hui ; le remède est la purge (lente, propre à chaque CDN) ou les noms de fichiers versionnés (mieux).
- L’invalidation de cache est réellement difficile. Ce n’est pas pour rien qu’elle figure parmi les deux fameux problèmes difficiles de l’informatique — concevez vos URL pour en avoir rarement besoin.
- Le contenu dynamique résiste à la mise en cache. Les réponses propres à chaque utilisateur ne se partagent pas ; l’accélération et la logique edge aident, mais c’est toujours l’origine qui fait le travail.
- Une dépendance sur le chemin critique. Les pannes de CDN sont des événements météo d’internet ; quand l’edge tombe, “votre” site tombe.
- Le débogage gagne une couche. Quel cache a servi ceci ? Avec quels en-têtes ? Les en-têtes de statut de cache et le comportement propre à chaque edge font désormais partie de votre surface d’observabilité.
Les CDN sur Back4app
Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. La distribution par CDN est intégrée à la couche fichiers : envoyez un fichier via n’importe quel SDK (les onglets ci-dessus) et l’URL renvoyée est prête pour la distribution — stable, cacheable et indépendante du trafic dynamique de votre API, ce qui sépare proprement les moitiés cacheable et non cacheable de votre app. Les frontends web hébergés sur Back4app Containers se placent naturellement derrière n’importe quel CDN, avec le pattern classique — ressources à empreinte de longue durée, HTML de courte durée — configuré en un seul en-tête.
Questions fréquentes
Qu'est-ce qu'un CDN, en termes simples ?
Un réseau de serveurs répartis géographiquement qui conserve des copies en cache de votre contenu près de vos utilisateurs. Au lieu que chaque requête voyage jusqu'à votre serveur d'origine — parfois de l'autre côté d'un océan — la plupart reçoivent leur réponse en quelques millisecondes d'un serveur edge proche. La majorité du trafic web des grands sites est servie de cette façon.
Comment fonctionne un CDN ?
Routage plus mise en cache. La requête d'un utilisateur est dirigée vers le point de présence le plus proche ; si ce serveur edge détient une copie fraîche en cache (un cache hit), il répond immédiatement. Sinon (un cache miss), l'edge va chercher le contenu à l'origine, en stocke une copie pendant la durée de vie (TTL) que vous avez configurée et sert depuis le cache tous les utilisateurs proches jusqu'à expiration.
Un CDN, est-ce la même chose qu'un hébergement web ?
Non — un CDN complète l'hébergement, il ne le remplace jamais. Votre hébergeur (l'origine) stocke le contenu de référence ; le CDN en détient des copies temporaires en périphérie. Si l'origine disparaît, le CDN finit par n'avoir plus rien à servir. La répartition des rôles : l'origine est la source de vérité, le CDN est la couche de distribution.
Que sont un cache hit, un cache miss et le TTL ?
Un hit signifie que l'edge a servi sa copie en cache — rapide, et l'origine n'a rien vu passer. Un miss signifie que l'edge n'avait pas de copie fraîche et est allé la chercher à l'origine — plus lent, une seule fois, pour le premier visiteur de la zone. Le TTL (time to live) est la durée pendant laquelle une copie en cache est considérée comme fraîche, définie via les en-têtes Cache-Control. Concevoir un cache, c'est surtout l'art de maximiser les hits sans servir de contenu périmé.
Un CDN peut-il servir du contenu dynamique ?
Pas depuis le cache au sens classique — une réponse d'API personnalisée diffère d'un utilisateur à l'autre. Mais les CDN accélèrent tout de même le trafic dynamique grâce à des routes optimisées, des connexions persistantes et une terminaison TLS proche de l'utilisateur ; et les plateformes modernes exécutent de la logique directement en périphérie. Le partage pragmatique : mettez agressivement en cache les ressources statiques, accélérez les réponses dynamiques et calculez en périphérie là où c'est rentable.
Comment un CDN protège-t-il contre les attaques DDoS ?
En étant énorme et en se trouvant sur le chemin. En tant que reverse proxy, le CDN masque l'adresse de votre origine, et sa capacité distribuée absorbe les attaques volumétriques sur de nombreux points de présence — un trafic qui écraserait un serveur isolé se dissipe sur un réseau mondial, avec un filtrage appliqué en périphérie avant que quoi que ce soit ne vous atteigne.
Quand n'avez-vous PAS besoin d'un CDN ?
Quand votre audience se trouve dans la région de votre serveur, un saut supplémentaire par un edge éloigné peut même ajouter de la latence ; quand le trafic est si faible que les caches expirent entre deux visiteurs (des miss perpétuels ne servent à rien) ; et quand une petite app dynamique n'est tout simplement pas limitée par la distribution. Un CDN est un levier sur la distance et le volume — sans l'un ni l'autre, c'est de la configuration sans bénéfice.
Quelle est la différence entre un CDN et l'edge computing ?
Un CDN rapproche le contenu des utilisateurs ; l'edge computing rapproche le calcul. Distribution contre décisions : un CDN répond à "servir ce fichier vite partout", les fonctions edge répondent à "exécuter cette logique près de l'utilisateur". Les deux convergent en pratique — les plateformes CDN modernes exécutent du code dans leurs points de présence — mais le modèle mental tient.