D'un CDN mutualisé à HTTP/3 : dix ans d'accélération web
En novembre 2016, je publiais sur mon blog un billet enthousiaste : « Les CDN sont désormais compatibles SSL chez OVH ». Les hébergements mutualisés Pro et Performance venaient de gagner le droit de cumuler leur CDN, 3 à 19 points de présence selon l'offre, avec un certificat Let's Encrypt gratuit. Jusque-là il fallait choisir : le cache au plus près des visiteurs, ou le cadenas vert. Certains avaient même dû résilier leur option CDN pour activer le HTTPS. Mon propre site tournait alors sur un de ces mutualisés OVH, cette annonce me concernait directement. Dix ans plus tard, le site que vous lisez est servi en HTTP/3 via CloudFront, devant un Nginx que je règle moi-même sur EC2, chez AWS. Entre les deux, tout le transport du web a été reconstruit. Voici le chemin, sans jargon inutile.
Un CDN, c'est quoi au juste
Ma définition de 2016 tient toujours : un CDN (Content Delivery Network) stocke et met en cache des ressources sur d'autres serveurs que le vôtre, automatiquement, pour les servir depuis un point plus proche de vos visiteurs. La lumière dans une fibre a beau être rapide, un aller-retour Bruxelles-Sydney reste incompressible. Rapprocher les fichiers, c'est le gain le plus bête et le plus efficace qui existe.
Ce qui a changé, c'est l'échelle. En 2016, 19 points de présence était un argument commercial. Les grands réseaux actuels en alignent des centaines, et le CDN n'est plus une option à cocher dans un panneau d'hébergement mutualisé : c'est la porte d'entrée du site, celle qui termine le HTTPS et qui parle le protocole le plus récent avec le navigateur.
HTTP/1.1, l'époque des files d'attente
Pour comprendre l'intérêt de HTTP/3, il faut voir de quoi on vient. Avec HTTP/1.1, une connexion ne transporte qu'une requête à la fois. Une page qui charge cinquante fichiers, c'est cinquante tours de file d'attente, à peine atténués par les six connexions parallèles qu'ouvrent les navigateurs. On compensait avec des bricolages : coller toutes les icônes dans une seule image, concaténer les scripts, éparpiller les ressources sur des sous-domaines. J'ai fait tout ça.
HTTP/2, standardisé en 2015, a réglé ce problème sur le papier : une seule connexion, des dizaines de requêtes multiplexées dedans, des en-têtes compressés. Sauf qu'en dessous, tout circule encore sur TCP, qui garantit l'ordre des paquets. Un seul paquet perdu et TCP bloque toute la connexion en attendant sa retransmission, y compris les fichiers qui n'ont rien à voir. C'est le fameux head-of-line blocking : la caisse rapide du supermarché, figée parce qu'un article du premier client ne passe pas.
HTTP/3 et QUIC, reconstruire sous la route
HTTP/3 ne retouche pas HTTP, il change la route en dessous. Le protocole QUIC, standardisé en 2021, roule sur UDP et réimplémente lui-même la fiabilité, flux par flux. Concrètement :
Des flux vraiment indépendants. Un paquet perdu ne bloque que le fichier auquel il appartient. Le CSS n'attend plus la retransmission d'une image.
Moins d'allers-retours au démarrage. TCP puis TLS, c'était deux allers-retours avant le premier octet utile. QUIC intègre le chiffrement TLS 1.3 dans sa poignée de main : un seul aller-retour, et zéro pour un visiteur qui revient (le fameux 0-RTT).
La migration de connexion. Une connexion QUIC est identifiée par un jeton, pas par une adresse IP. Votre visiteur quitte le Wi-Fi du bureau, bascule sur la 4G dans l'ascenseur : la connexion survit au lieu de tout renégocier. Sur mobile, c'est le gain le plus tangible.
Et le chiffrement n'est plus une option qu'on coche après coup, comme chez OVH en 2016 : QUIC est chiffré par conception, il n'existe pas de HTTP/3 en clair.
Ce que ça change pour un site de PME
Soyons honnêtes : sur une fibre stable à 10 ms du serveur, la différence se mesure en millisecondes. HTTP/3 brille exactement là où sont vos clients réels : un smartphone en 4G moyenne, un train, une zone mal couverte, un Wi-Fi d'hôtel. Moins de latence au premier chargement, moins de blocages quand le réseau perd des paquets, pas de reconnexion en changeant de réseau.
En 2016, j'écrivais qu'un CDN « vous permet d'être mieux référencé ». J'y allais un peu vite. La version 2026, plus prudente : la vitesse ne propulse pas un site en première position, mais elle pèse sur les Core Web Vitals, sur le taux de rebond et sur les conversions. Un formulaire de devis qui répond au quart de tour est rempli plus souvent, c'est aussi simple que ça.
La bonne nouvelle : vous n'avez rien à développer. HTTP/3 se joue au niveau de l'hébergement ou du CDN, pas dans votre code. C'est un critère de choix de prestataire, pas un chantier.
Vérifier votre propre site en deux minutes
Ouvrez votre site dans Chrome ou Firefox, puis les outils de développement (F12), onglet Réseau. Faites un clic droit sur les en-têtes de colonnes et activez la colonne « Protocole ». Rechargez la page deux fois : la découverte de HTTP/3 passe par un en-tête envoyé lors de la première visite, le protocole ne bascule souvent qu'au second chargement. Si vous lisez « h3 », c'est gagné. « h2 » reste correct, « http/1.1 » sur tout le trafic mérite une conversation avec votre hébergeur. Des testeurs en ligne font le même diagnostic si vous préférez coller une URL.
Dix ans plus tard, la même obsession
Le billet de 2016 se terminait sur une illustration SVG à survoler, avec et sans CDN. La technologie a changé trois fois depuis, l'idée derrière n'a pas bougé : rapprocher le contenu des visiteurs, chiffrer tout, éliminer les attentes inutiles. J'ai migré plusieurs employeurs de l'hébergement mutualisé vers ce genre d'infrastructure, et j'en ai mieux dormi.
Aujourd'hui, ce réglage fait partie de mon hébergement géré, au même titre que les sauvegardes et les mises à jour. Et si votre site est encore sur un mutualisé qui plafonne en HTTP/1.1, la migration vers chez moi est offerte : le diagnostic aussi, il tient dans une colonne d'outils de développement.
