Pourquoi IPv6 revient à l'ordre du jour
IPv4 compte environ quatre milliards d'adresses et les derniers blocs libres ont été distribués dans les années 2010. Internet ne s'est pas arrêté : les opérateurs ont placé de nombreux clients derrière une adresse partagée (NAT opérateur) et traduisent entre les deux mondes. Cela fonctionne, mais ajoute un intermédiaire à chaque connexion, rend les règles par IP absurdes quand mille téléphones partagent une adresse et coûte de l'argent aux opérateurs — c'est pourquoi la plupart des réseaux mobiles font désormais de l'IPv6 natif et traitent IPv4 comme la voie héritée. Ajoutez le volet achats : appels d'offres publics et questionnaires de sécurité demandent si un service est joignable en IPv6, et un simple non est un point perdu.
Ce qui change vraiment pour un site web
Presque rien dans votre HTML ou votre application. Un site double pile a deux types d'enregistrements DNS — A pour IPv4, AAAA pour IPv6 — et une porte d'entrée qui écoute sur les deux familles. Un navigateur moderne résout les deux, les essaie presque en parallèle et garde celle qui se connecte en premier (règle Happy Eyeballs) : un chemin IPv6 cassé ne laisse pas un visiteur en plan. Une fois la connexion ouverte, HTTP est HTTP : mêmes cookies, mêmes en-têtes de cache, même certificat TLS. La différence visible est dans vos journaux, où des adresses comme 2a01:4f9:... apparaissent à côté des adresses pointées habituelles.
Ce que le CDN fait déjà pour vous
L'edge CDN.com.tr est en double pile depuis septembre 2026 : chaque nom d'hôte du CDN porte des enregistrements AAAA à côté des A et l'edge accepte les connexions sur les deux. Si votre site pointe vers nous par un CNAME — la configuration habituelle pour www et les sous-domaines — il a hérité d'IPv6 ce jour-là sans aucun changement de votre côté. Votre serveur d'origine n'intervient pas : l'edge termine la connexion du visiteur, quelle que soit sa famille, et interroge votre origine en IPv4 exactement comme avant. Le visiteur obtient un site IPv6 ; votre serveur n'a jamais besoin d'adresse IPv6.
Un CNAME hérite des deux familles du nom d'hôte CDN
$ dig +short www.example.com AAAA
www.example.com.cdn.com.tr.
2a03:35e0:9700::9
$ dig +short www.example.com A
www.example.com.cdn.com.tr.
185.70.97.9Comment vérifier votre propre site
Deux commandes répondent à la question pour n'importe quel nom d'hôte : dig pour les enregistrements, curl pour une vraie connexion. Dans le navigateur, DevTools → Network → clic droit sur les colonnes → Remote Address montre la famille utilisée. Si curl -6 échoue alors que curl -4 fonctionne, le site n'est pas joignable en IPv6 depuis là où vous êtes — ce peut être le site ou votre propre réseau — donc testez depuis un téléphone en données mobiles avant d'ouvrir un ticket.
Les enregistrements, puis une vraie connexion IPv6
$ dig +short AAAA www.example.com
2a03:35e0:9700::9
$ curl -6 -sI https://www.example.com/ | head -1
HTTP/2 200
$ curl -4 -sI https://www.example.com/ | head -1
HTTP/2 200Les choses qui cassent vraiment
IPv6 ne casse pas les pages ; il casse des hypothèses sur les adresses. D'abord, les listes d'autorisation et de blocage : une règle qui nomme des adresses IPv4 ne correspond jamais à un visiteur IPv6, donc une liste bureau pour un chemin d'administration cesse d'admettre les collègues en mobile IPv6 seul tant que vous n'ajoutez pas leur plage IPv6. Ensuite, les limites et compteurs par IP : un visiteur IPv6 peut légitimement changer d'adresse à l'intérieur d'un /64 ; comptez par /64, pas par adresse, sinon vos limites deviennent à la fois poreuses et injustes. Troisièmement, statistiques et géolocalisation : bases et tableaux de bord conçus pour les adresses pointées ont besoin de versions compatibles IPv6, et un champ IPv4 de 15 caractères tronque une adresse IPv6 de 39. Enfin, les parties de votre pile qui ne sont pas derrière le CDN — une API sur un autre hôte, un serveur de messagerie, un récepteur de webhooks — restent en IPv4 seul, et un client IPv6 seul ne peut pas les atteindre.
IPv6 et HTTP/3 vont ensemble
Le même changement d'edge qui a apporté IPv6 a aussi activé HTTP/3, et les deux partagent une raison : chacun retire un intermédiaire ou un aller-retour du chemin du visiteur, et chacun est annoncé par l'edge et adopté par le navigateur sans réglage de votre côté. Si votre objectif est la vitesse plutôt que la joignabilité, HTTP/3 est le levier visible dans les Core Web Vitals ; le guide HTTP/2 vs HTTP/3 explique ce qu'il change et comment le voir dans DevTools.
Questions fréquentes
Dois-je changer mon DNS pour avoir IPv6 ?
Si votre nom d'hôte est un CNAME vers votre nom d'hôte CDN, non : les enregistrements AAAA viennent avec. Si vous pointez un domaine apex vers des adresses IP de l'edge avec des enregistrements A chez un autre fournisseur DNS, ajoutez les enregistrements AAAA correspondants ; le support vous donnera les adresses de votre point de diffusion.
IPv6 rendra-t-il mon site plus rapide ?
Pas à lui seul. Il supprime la couche de traduction de l'opérateur pour les visiteurs en réseau IPv6 seul, ce qui aide un peu, et surtout rend votre site joignable pour eux. Le levier de vitesse sur le même edge, c'est HTTP/3.
Les visiteurs IPv6 voient-ils le même cache ?
Oui. Les clés de cache sont construites à partir de l'URL et de vos règles, pas de la famille d'adresses. Une page mise en cache par un visiteur IPv4 est servie depuis le cache à un visiteur IPv6, et inversement.
Mon pare-feu d'origine a-t-il besoin de règles IPv6 maintenant ?
Non. L'edge continue de se connecter à votre origine avec la famille d'adresses qu'il utilise aujourd'hui, généralement IPv4, depuis les mêmes adresses d'edge qu'avant. Seul le côté visiteur a changé.