Un CDN auto-hébergé avec Varnish couvre trois continents pour moins de 15 $ par mois
Vos utilisateurs sont à Tokyo, votre serveur à Paris — un CDN place vos pages à 10 ms d’eux. Avec Varnish ou Apache Traffic Server sur trois VPS à 5 $, vous obtenez la même latence que BunnyCDN ou Cloudflare, sans facture qui explose avec le trafic.
Juin 2026, votre SaaS décolle au Japon. 10 000 visiteurs quotidiens depuis Tokyo, Osaka, Séoul. Votre serveur est chez Hetzner à Nuremberg — 260 ms de latence par requête. Un fichier CSS de 80 Ko met une demi-seconde à arriver. Votre taux de conversion s’effondre parce qu’un client qui attend plus de trois secondes est un client perdu.
La solution classique : activer Cloudflare ou BunnyCDN. Deux clics, vos assets statiques passent de 260 ms à 10 ms. Facture : 0,01 $/Go en Europe, jusqu’à 0,06 $/Go en Afrique. À 10 To/mois, vous payez 100 $ — acceptable. À 100 To/mois, la facture dépasse le salaire d’un ingénieur.
Ce qu’on vous vend rarement : la brique logicielle derrière Cloudflare et Fastly est open source. Elle s’appelle Varnish Cache, et vous pouvez la déployer vous-même sur trois VPS à 5 $ pour couvrir l’Europe, l’Amérique du Nord et l’Asie. Voici comment.
Pourquoi un CDN change tout — les chiffres
Un CDN (Content Delivery Network) est un réseau de serveurs répartis géographiquement qui mettent en cache vos fichiers statiques (CSS, JS, images, polices) et les servent depuis le nœud le plus proche de l’utilisateur. Le principe est simple : au lieu de traverser l’Atlantique pour chaque requête, l’utilisateur tape à la porte d’un serveur situé dans sa ville.
Les gains mesurés sont massifs :
- Cloudflare rapporte une réduction moyenne de 65 % de la bande passante origine sur les déploiements CDN standard (source).
- Docker Hub est passé d’un hit ratio de 97 % à 99 %+ en activant le Tiered Caching et le Cache Reserve de Cloudflare — divisant par trois sa facture S3 (source).
- BunnyCDN affiche une latence médiane globale de 24 ms sur son réseau de 119 PoPs (source).
- Fastly documente un ROI de 189 % sur trois ans pour ses clients Network Services selon Forrester (source).
Le problème ? Ces chiffres concernent des CDN SaaS. Vous payez au Go, et plus vous avez de succès, plus la facture grimpe.
Le marché des CDN SaaS — trois profils, trois prix
Voici ce que coûte la livraison de 5 To/mois en Europe et Amérique du Nord, selon les grilles publiques de mars 2026 :
Cloudflare est imbattable en gratuit. BunnyCDN est le meilleur rapport qualité/prix pour un usage modéré. Fastly domine chez les éditeurs de presse et les plates-formes de streaming qui ont besoin de purger leur cache en moins de 150 ms. CloudFront est un piège tarifaire — l’egress AWS se cumule avec le transfert CDN.
Mais aucun ne vous laisse le contrôle de l’infrastructure. Si Cloudflare décide de bloquer votre site (ça arrive, cf. le blocage de Kiwi Farms en 2022), vous n’avez aucun recours. Si BunnyCDN n’a pas de PoP en Afrique du Sud, vous ne pouvez pas en ajouter un.
Construire son propre CDN — l’architecture en trois nœuds
Un CDN auto-hébergé minimal tient en trois VPS chez trois fournisseurs différents, dans trois zones géographiques distinctes. Chaque VPS fait tourner un reverse proxy cache qui intercepte les requêtes, vérifie s’il a le fichier en cache, et le renvoie sans toucher à l’origine.
[Utilisateur Tokyo] ── 10 ms ──▶ [VPS Tokyo] ──▶ [Cache HIT ?]
│
├── OUI : réponse immédiate (< 10 ms)
│
└── NON : fetch origine Paris (260 ms)
puis cache pour la prochaine requêteLe hit ratio typique d’un site statique bien configuré dépasse 95 %. Autrement dit, 19 requêtes sur 20 ne touchent jamais votre serveur d’origine.
Choix du moteur de cache — Varnish vs Apache Traffic Server
Deux projets open source dominent le cache HTTP en production :
Varnish Cache 9.0.3 (publié le 18 mai 2026, EOL le 16 mars 2027) est le standard de fait. Il équipe Wikipedia, Facebook (historiquement), Twitter et des milliers de sites à fort trafic. Sa force : le VCL (Varnish Configuration Language), un DSL compilé en C qui permet d’écrire des règles de cache extrêmement fines sans jamais toucher au code du serveur applicatif.
sub vcl_recv {
# Purge rapide : une requête PURGE vide le cache
if (req.method == "PURGE") {
return (purge);
}
# Ne pas cacher les pages admin
if (req.url ~ "^/admin") {
return (pass);
}
}
sub vcl_backend_response {
# TTL par type de contenu
if (beresp.http.Content-Type ~ "image") {
set beresp.ttl = 7d;
} elsif (beresp.http.Content-Type ~ "text/html") {
set beresp.ttl = 10m;
}
}Apache Traffic Server (ATS) est l’alternative carrier-grade. Utilisé par Yahoo, Comcast et le CDN Apple, il gère plusieurs térabits par seconde en production. ATS supporte HTTP/1.1 et HTTP/2 nativement, s’administre via une API REST (traffic_ctl), et s’étend en C via des plugins. Sa dernière version stable (10.1.3, juillet 2026) inclut des correctifs pour 34 CVE. La courbe d’apprentissage est plus raide que Varnish, mais la scalabilité horizontale est supérieure.
Verdict rapide : Varnish si vous avez moins de 50 000 requêtes/seconde et voulez configurer en 30 minutes. ATS si vous prévoyez de dépasser le Gbps et avez une équipe à l’aise avec le tuning noyau Linux.
Déploiement — trois VPS, 15 $/mois
Voici une configuration réelle, tarifée en juillet 2026 :
Sur chaque VPS, l’installation tient en cinq commandes :
# Installation de Varnish 9.0 sur Debian 12
curl -s https://packagecloud.io/install/repositories/varnishcache/varnish90/script.deb.sh | bash
apt install varnish -y
# Configuration minimale — écouter sur le port 80, origine vers Paris
cat > /etc/varnish/default.vcl << 'VCL'
vcl 4.1;
backend origin {
.host = "51.15.x.x"; # IP de votre serveur d'origine
.port = "8080";
.connect_timeout = 5s;
.first_byte_timeout = 30s;
}
sub vcl_recv {
if (req.method == "PURGE") {
return (purge);
}
# Normaliser les requêtes pour maximiser le hit ratio
unset req.http.Cookie;
}
sub vcl_backend_response {
set beresp.ttl = 1h;
set beresp.grace = 24h; # Servir du contenu stale si l'origine est down
unset beresp.http.Set-Cookie;
}
VCL
systemctl enable --now varnishLe grace mode est critique : si votre serveur d’origine tombe, Varnish continue de servir le contenu expiré pendant 24 heures. Vos utilisateurs ne voient rien.
Routage — le chaînon manquant
Une fois les trois nœuds déployés, il faut router les utilisateurs vers le plus proche. Deux approches :
DNS GeoIP — le plus simple. Un service comme NS1 (payant, ~50 $/mois) ou bunny.net DNS (gratuit jusqu’à 50 M requêtes/mois) répond avec l’IP du nœud le plus proche en fonction de la localisation du résolveur DNS. C’est ce que font la plupart des CDN commerciaux.
Anycast BGP — le standard telco. Vous annoncez la même IP depuis vos trois datacenters, et le routage Internet (BGP) dirige naturellement le trafic vers le nœud le plus proche. Nécessite un ASN et un préfixe IP, donc irréaliste sous 200 $/mois.
Pour un budget serré, le DNS GeoIP avec bunny.net DNS (gratuit) est le choix pragmatique. Configuration en cinq minutes :
# Exemple avec l'API BunnyDNS
curl -X PUT "https://api.bunny.net/dnszone/12345/records/1" \
-H "AccessKey: $BUNNY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"Type": 1,
"Name": "cdn",
"Value": "",
"SmartRoutingType": 3
}'Inconvénients assumés — ce que le SaaS fait que vous ne ferez pas
Un CDN auto-hébergé n’est pas un remplacement universel. Voici ce que vous perdez par rapport à Cloudflare ou BunnyCDN :
- DDoS protection. Cloudflare absorbe des attaques de 2,3 Tbps (record 2025). Vos trois VPS à 5 $ tombent à 10 Gbps.
- Optimisation d’images à la volée. BunnyCDN et Cloudflare redimensionnent vos images en temps réel (WebP, AVIF) sans toucher à l’origine. Avec Varnish, vous devez pré-générer les variantes.
- WAF et règles de sécurité. Cloudflare bloque les injections SQL, les XSS et les bots malveillants au niveau de la couche CDN. Varnish ne fait pas ça — il faut ajouter ModSecurity ou un WAF externe.
- Purge instantanée globale. Fastly vide son cache mondial en 150 ms. Varnish nécessite un script qui appelle
PURGEsur chaque nœud, soit 2-3 secondes si vous avez trois PoPs.
La parade : vous pouvez combiner les deux. Un CDN SaaS en frontal pour l’anti-DDoS et le WAF, et vos propres nœuds Varnish en origine secondaire pour absorber la charge statique sans payer l’egress SaaS. C’est ce que fait le New York Times avec Fastly + Varnish en interne.
Verdict — dans quel cas construire le vôtre
Prenez BunnyCDN ou Cloudflare si :
- Votre trafic est inférieur à 5 To/mois — la facture SaaS est inférieure au coût d’un ingénieur qui configure Varnish.
- Vous n’avez pas d’équipe ops — un CDN SaaS se configure en 10 minutes, un Varnish en production demande une astreinte.
- Vous subissez des attaques DDoS régulières — le filtrage edge de Cloudflare est irremplaçable à petit budget.
Construisez votre CDN si :
- Vous dépassez 20 To/mois — à ce volume, 15 $ de VPS battent n’importe quelle grille SaaS.
- Vous avez des contraintes de souveraineté — vos données ne doivent pas quitter l’UE, et vous ne voulez pas dépendre d’une entreprise américaine.
- Vous avez besoin de règles de cache impossibles à exprimer dans l’UI d’un SaaS — le VCL est Turing-complet, le dashboard Cloudflare ne l’est pas.
Le CDN auto-hébergé n’est pas une mode self-hoster. C’est un calcul économique qui bascule vers 15 $ par mois dès que votre trafic justifie trois VPS. Et avec Varnish 9.0 et ATS 10.1, la brique logicielle est plus fiable que jamais — c’est la même qui tourne chez les plus gros du web.