Ce que HTTP/3 change pour un visiteur
HTTP/2 a fait transporter de nombreuses requêtes par une seule connexion TCP, mais il a hérité de la règle de TCP : un paquet perdu retient tout ce qui suit. HTTP/3 remplace TCP par QUIC, un transport sur UDP avec TLS 1.3 intégré : chaque flux se remet seul d'une perte, la négociation demande moins d'allers-retours, et un téléphone qui passe du Wi-Fi aux données mobiles garde sa connexion au lieu de la rouvrir. Sur une bonne connexion filaire, le gain est faible ; sur un Wi-Fi avec pertes et les réseaux mobiles — là où sont la plupart de vos visiteurs — c'est la différence qui apparaît dans les Core Web Vitals.
Comment l'edge fait basculer les navigateurs, et revenir
Chaque réponse HTTPS de l'edge porte Alt-Svc: h3=":443". Un navigateur qui le comprend ouvre sa connexion suivante en QUIC sur le port UDP 443 ; un autre ignore simplement l'en-tête. Si l'UDP 443 est bloqué quelque part sur le chemin — pare-feu d'entreprise, box stricte — le navigateur voit l'essai QUIC échouer et reste en HTTP/2 sans aucune erreur. C'est pourquoi HTTP/3 peut être actif pour tout le monde : le pire cas est exactement ce que vous aviez avant.
IPv6 sans toucher à votre origine
Les noms d'hôte du CDN portent des enregistrements AAAA à côté des A et l'edge écoute sur les deux familles d'adresses. Un visiteur sur un réseau IPv6 seul — courant chez les opérateurs mobiles — se connecte directement à l'edge au lieu de passer par la couche de traduction de l'opérateur, et un appel d'offres ou une liste de conformité qui exige IPv6 obtient un oui. Votre serveur d'origine est contacté comme aujourd'hui, généralement en IPv4 : rien n'y change pour que votre site soit joignable en IPv6.
Le même WAF sur chaque protocole
Le pare-feu applicatif, les limites de débit, les règles par pays et ASN et la protection contre les bots inspectent une requête HTTP/3 exactement comme une requête HTTP/2 ; le protocole est un détail de transport en dessous d'eux. Une requête bloquée en HTTP/3 reçoit la même page de blocage avec le même Reference ID, donc le support et les audits fonctionnent sans changement. La seule règle qui demande votre attention est celle écrite contre des adresses IPv4 : les visiteurs IPv6 ne la déclenchent pas tant que vous n'ajoutez pas la forme IPv6.
Ce que cela vous coûte
Rien. Il n'y a ni forfait, ni option, ni réglage pour l'une ou l'autre fonction, la bande passante et les requêtes sont comptées comme avant, et la capacité de l'edge derrière est notre affaire — nous avons mesuré la bascule sur tout le réseau sans voir de variation de charge. Les deux sont de la configuration partagée de l'edge et ne peuvent pas être désactivées pour un seul site ; ce n'est pas nécessaire, car les clients qui ne peuvent pas les utiliser ne perdent rien.
Rien à configurer — voici comment le confirmer
Ouvrez DevTools et activez la colonne Protocol
Dans Chrome, Edge ou Firefox, ouvrez DevTools → Network, clic droit sur un en-tête de colonne et cochez Protocol. Chargez votre site une fois, puis rechargez : le premier chargement affiche h2, le rechargement affiche h3 sur vos propres requêtes.
Demandez avec curl
curl 8 compilé avec HTTP/3 peut forcer le protocole : curl --http3 -sI https://www.example.com/ renvoie HTTP/3 200. Sans l'option, curl -sI montre l'en-tête Alt-Svc qui annonce h3 aux navigateurs.
Vérifiez les enregistrements IPv6
dig +short AAAA www.example.com liste les adresses IPv6 de l'edge ; curl -6 -sI https://www.example.com/ récupère la page en IPv6. Si votre DNS est un CNAME vers nous, les deux sont hérités automatiquement.
Lisez vos journaux
Les requêtes HTTP/3 sont journalisées avec le protocole HTTP/3.0 et les visiteurs IPv6 avec leur adresse IPv6. La part dépend de votre audience ; le premier jour, elle allait de 6 % à 27 % des requêtes par site.
Où cela se voit
La majorité d'une audience d'actualité lit sur téléphone en données mobiles, où la perte de paquets est normale. Les pages d'articles chargées d'images cessent de bloquer sur un paquet perdu, et les lecteurs qui passent du Wi-Fi à la 4G gardent leur connexion.
Les questionnaires du secteur public et des entreprises demandent de plus en plus la joignabilité IPv6 et un transport moderne. Les deux se répondent par un oui et une commande curl, pour chaque nom d'hôte derrière le CDN, sans projet de votre côté.
Plusieurs opérateurs mobiles n'attribuent que de l'IPv6 et traduisent l'IPv4 dans le cœur de réseau. Votre site répond désormais à ces visiteurs nativement à l'edge, ce qui retire un intermédiaire partagé du chemin et ses modes de panne.
Questions fréquentes
Dois-je activer HTTP/3 ou IPv6 pour mon compte ?
Non. Les deux sont actifs pour chaque nom d'hôte servi par l'edge depuis septembre 2026. Il n'y a pas d'interrupteur dans le panneau, et rien dans votre DNS ou votre origine ne change si vous pointez déjà vers nous avec un CNAME.
Mon navigateur affiche h2, pas h3. HTTP/3 ne fonctionne pas ?
La première requête d'une session est toujours en HTTP/2 — c'est là que le navigateur découvre h3. Rechargez la page. Si toutes les requêtes restent en h2, quelque chose sur votre réseau bloque le port UDP 443 ; les navigateurs restent alors en HTTP/2 sans bruit. Testez depuis un téléphone en données mobiles pour confirmer.
Mon serveur d'origine a-t-il besoin d'IPv6 ?
Non. L'edge termine la connexion du visiteur, quelle que soit sa famille d'adresses, et interroge votre origine avec la famille qu'elle a aujourd'hui. Seul le côté visiteur est passé en double pile.
Le WAF est-il plus faible en HTTP/3 ?
Non. Les mêmes règles s'exécutent sur chaque requête quel que soit le transport, et une requête HTTP/3 bloquée reçoit la même page de blocage et le même Reference ID qu'en HTTP/2.
Peut-on désactiver HTTP/3 pour un site ?
Non, et ce n'est pas nécessaire : un client qui ne peut pas utiliser QUIC continue automatiquement en HTTP/2. Couper l'annonce retirerait seulement le gain aux clients qui le peuvent.