HTTP/2 et HTTP/3 : ce qu'on active et pourquoi (ou pas)

HTTP/1.1 a tenu la toile pendant quinze ans. HTTP/2 l'a remplacé côté serveurs web à partir de 2015, HTTP/3 arrive depuis 2022. Chaque saut change la plomberie du transport, pas le langage HTTP lui-même. Voici ce qui est réellement activé chez Datacampus, pourquoi, et quand il faut demander plus.

Ce qui change sous le capot

• HTTP/1.1 : une requête à la fois par connexion TCP. Pour paralléliser, les navigateurs ouvrent jusqu'à 6 connexions par domaine, d'où la vieille pratique du domain sharding (servir les assets depuis static1.mondomaine.fr, static2...).
• HTTP/2 : une seule connexion TCP, des flux multiplexés. Les headers sont compressés (HPACK). Le texte devient binaire.
• HTTP/3 : on abandonne TCP pour QUIC, un protocole sur UDP qui intègre TLS 1.3, gère le multiplexage et survit aux pertes de paquets sans pénaliser tous les flux.

HTTP/2 : les bénéfices concrets

• Multiplexage. Plus besoin de domain sharding, plus de tête-de-ligne au niveau applicatif. Tous les assets passent dans le même tuyau, en parallèle.
• Compression des headers (HPACK). Sur des pages modernes où chaque requête traîne 2 à 4 Ko de cookies et d'en-têtes, le gain cumulé est réel.
• 10 à 30 % de mieux sur le LCP pour un site chargé en assets (WordPress avec beaucoup de plugins, e-commerce avec galerie produit).
• Support navigateur quasi universel : 97 %+ depuis 2018. Aucun souci de compatibilité en 2026.

Les risques en prod standard

Aucun, à une exception historique près : HTTP/2 est incompatible avec la combinaison Apache prefork + mod_php. Il faut Apache en MPM event et PHP en FPM. C'est la config moderne, et c'est celle que nous utilisons par défaut sur tous nos hébergements Plesk et serveurs gérés.

Server Push (pousser un CSS avant que le navigateur ne le demande) a été déprécié côté Chrome en 2022. On l'ignore, il ne sert plus à rien.

curl -sI --http2 https://votresite.fr/ | head -1

HTTP/3 et QUIC : ce que ça apporte

• Connexion plus rapide. Handshake TLS 1.3 fondu dans le transport. En reprise de session, un 0-RTT permet d'envoyer la première requête avec le tout premier paquet.
• Résilience aux pertes de paquets. Un flux bloqué par un paquet perdu ne bloque plus les autres, contrairement à TCP. Utile en 4G dégradée, wifi saturé, train.
• Pas de head-of-line blocking au niveau transport. C'était la limite que HTTP/2 sur TCP ne pouvait pas dépasser.
• Migration de connexion. Le passage wifi → 4G ne coupe plus la session : QUIC suit le client par son connection ID, pas par son IP.

Les risques, eux, sont bien réels

• UDP 443 filtré en entreprise. Beaucoup de firewalls d'entreprise, IDS et proxys corporate bloquent ou limitent UDP 443. Les navigateurs retombent alors sur HTTP/2 via l'en-tête Alt-Svc, mais la toute première visite paie le timeout avant bascule.
• Monitoring réseau dégradé. QUIC est chiffré bout en bout, y compris les métadonnées que les APM, WAF et log analyzers lisaient tranquillement sur TCP. Moins de visibilité côté opérations.
• Apache et HTTP/3. Le module mod_http3 reste expérimental en 2026. Plesk ne l'active pas par défaut. LiteSpeed Enterprise, lui, embarque QUIC nativement depuis longtemps.
• Vecteur DDoS UDP. UDP est amplifiable. Chez Datacampus, Cloudflare Magic Transit filtre en périmètre avant d'atteindre nos serveurs, donc le risque reste maîtrisé côté infra.
• Prérequis TLS 1.3. QUIC n'existe pas en TLS 1.2. Ce n'est plus un problème en 2026, mais c'est à noter pour les stacks très anciennes.

Le gain mesurable, sans enrober

Soyons honnêtes sur les chiffres. HTTP/3 apporte :

• 5 à 15 % de mieux sur mobile en réseau dégradé.
• Environ 0 % sur desktop fibre avec peu de pertes de paquets.
• ~3 % de TTFB moyen selon les chiffres publiés par Google et Cloudflare sur leur trafic agrégé.

Ce n'est ni négligeable ni spectaculaire. C'est une optimisation à considérer quand votre audience le justifie, pas un impératif universel.

Notre config par défaut

Sur l'ensemble de nos offres d'hébergement mutualisé et serveurs gérés :

• Apache MPM event + PHP-FPM.
• HTTP/2 activé sur tous les vhosts HTTPS.
• TLS 1.3 et HSTS préchargé.
• HTTP/3 non activé par défaut. Reste en opt-in, sur ticket motivé.

Quand activer HTTP/3

• Site e-commerce ou media à forte audience mobile, où les 5 à 15 % de gain sur connexion dégradée se traduisent en conversions ou en temps de lecture.
• Clients derrière Cloudflare. Cloudflare fait tout le boulot côté edge, l'origine reste en HTTP/2, zéro risque côté serveur. Voir la doc cloudflare-devant-plesk.
• PWA et apps à connexions fréquentes, où le 0-RTT et la migration de connexion changent vraiment l'expérience.

Quand ne pas l'activer

• Site B2B corporate dont les visiteurs sont majoritairement derrière firewalls d'entreprise stricts. Le fallback Alt-Svc ajoute plus de latence qu'il n'en retire.
• Besoin fort de monitoring réseau fin, NetFlow, inspection WAF au niveau transport.
• Applications legacy à supervision sensible, où perdre la visibilité sur les sessions TCP est un problème opérationnel.

Comment l'activer chez Datacampus

1. Ouvrir un ticket sur le ServiceDesk avec votre contexte : part de trafic mobile estimée, présence ou non d'un CDN devant, contraintes de monitoring.
2. Sur LiteSpeed Enterprise (certaines de nos offres mutualisées) : activation simple, QUIC est natif, pas de module expérimental.
3. Sur Apache : activation en opt-in. Nous validons le filtrage UDP côté Cloudflare Magic Transit avant d'ouvrir le port.
4. Sur Cloudflare Free ou Business devant votre site : un toggle dans leur UI suffit. Gratuit, sans toucher à l'origine.

En résumé

HTTP/2 est un acquis de prod, déjà actif partout chez nous. HTTP/3 est une optimisation ciblée : puissante pour du mobile à grande audience, neutre voire gênante pour du B2B corporate. Notre politique reste simple : HTTP/2 par défaut pour tout le monde, HTTP/3 à la demande quand votre profil de trafic le justifie.