On vante souvent les mérites du CDN (Content Delivery Network) : rapidité de diffusion, résilience, mise en cache efficace, réduction de charge sur les serveurs d’origine. Pour beaucoup, ça va jusqu'à héberger l’intégralité d’une application front sur un CDN, parfois même sans backend côté serveur. Vue comme un progrès : zéro infra, zéro maintenance. Simple. Efficace. Moderne.
Mais posons-nous une vraie question :
Que se passe-t-il quand le CDN tombe ?
- Application indisponible.
- Erreur 403, 502 ou carrément un écran blanc.
- Plus de support client, plus de tunnel de vente, plus rien.
Et c’est là que la réalité frappe : externaliser totalement son application vers un CDN, c’est introduire une dépendance technique critique, sans plan de repli. Car non, un CDN n’est pas un hébergement, et il n’est pas infaillible. Même les plus grands tombent (Fastly, Cloudflare, Akamai, jsDelivr, etc.).
Quelques cas vécus récemment :
- Applications React/Angular servies exclusivement via un CDN public.
- Sites "jamstack" statiques sans fallback local ou sans miroir.
- Aucune supervision côté client — on découvre la panne… via les utilisateurs.
Ce qu’on oublie souvent :
- Un CDN ne garantit pas une haute disponibilité à 100 %.
- En cas de faille ou de suspension (compte bloqué, attaque, maintenance imprévue), vous êtes aveugle et impuissant.
- Une simple dépendance à une ressource statique hébergée en externe peut faire planter tout votre front (ex. un fichier main.js inaccessible = écran blanc).
Recommandations de base :
- Hébergez une copie locale minimale (fallback de secours).
- Mettez en place un plan de contingence (redirection temporaire, mode dégradé)
- Ne centralisez pas 100 % de votre logique métier sur un CDN.
- Surveillez activement vos assets critiques.
- Si possible : auto-hébergez vos fichiers statiques sensibles.
Le confort du tout-CDN est séduisant. Mais en architecture, ce n’est pas la vitesse seule qui compte — c’est la capacité à tenir quand tout tombe.
Priorisez la résilience avant de chercher la performance.