L'IPv6 a dépassé 50 % du trafic Google pendant un jour. Voici ce qui compte vraiment.
L'IPv6 a atteint 50 % du trafic Google en mars 2026, un jour seulement. Cloudflare et APNIC mesurent moins. La vraie question : dual-stack ou tout-IPv6 ?
Le 28 mars 2026, Google a annoncé que l’IPv6, le plus récent des deux systèmes d’adressage dont chaque appareil a besoin pour se connecter à internet, avait porté pour la première fois plus de la moitié du trafic vers ses propres services. Exactement 50,1 %, contre 46,33 % un an plus tôt. La presse tech a parlé d’un jalon historique. La même semaine, deux autres organisations qui mesurent la même chose sont arrivées à des chiffres dix points plus bas. Peu importe lequel de ces chiffres vous croyez : cela ne change presque rien à la seule décision qui compte vraiment pour qui gère un serveur en 2026, à savoir si vous pouvez abandonner l’ancien protocole, l’IPv4, et faire tourner votre infrastructure uniquement en IPv6.
L’IPv6 a franchi les 50 % du trafic Google pendant un jour, et personne d’autre n’est d’accord sur le chiffre
L’explication de Google est précise sur ce qu’elle mesure réellement. L’entreprise suit la part des visiteurs qui accèdent à Google Search et à YouTube en IPv6 plutôt qu’en IPv4, à partir des données de ses propres services, pas de l’ensemble d’internet. Le 28 mars, cette part a atteint 50,1 %, et Google précise avoir déjà franchi 49,5 % plusieurs autres jours au cours de l’année précédente. Un jour au-dessus de la moitié n’est pas la même chose qu’une majorité installée.
La même semaine, deux mesures indépendantes racontent une histoire moins nette. Cloudflare a relevé 40,1 % des requêtes HTTP en IPv6, et APNIC Labs, le service de recherche du registre qui attribue les adresses IP dans la région Asie-Pacifique, a mesuré 43,13 % des réseaux observables comme capables d’IPv6. Trois organisations, trois méthodes différentes, et un écart de dix points sur ce qui devait pourtant être la même question. The Register, le média spécialisé qui a mis les trois chiffres côte à côte, a écrit que le chiffre de Google était « notable, and nice, but not solid proof that IPv6 has finally become dominant » (notable et appréciable, mais pas la preuve que l’IPv6 a fini par s’imposer).
L’écart s’explique simplement. Chaque entreprise ne voit que sa propre tranche d’internet. Google voit ceux qui visitent Google Search et YouTube, deux des sites les plus fréquentés au monde, ce qui oriente son chiffre vers les pays et les appareils qui consultent justement ces services-là. Cloudflare voit le trafic qui transite par son propre réseau de diffusion de contenu (un CDN, l’infrastructure qui sert les pages depuis des serveurs proches de l’internaute). APNIC applique une pondération statistique pour corriger le fait que le support IPv6 n’est pas annoncé de façon homogène selon les réseaux. Aucune des trois mesures n’a tort. Elles mesurent chacune une tranche différente d’internet et présentent l’écart comme un seul et même jalon.
Pourquoi l’IPv4 continue de tourner malgré tout
L’IPv4 ne s’efface pas parce qu’il a manqué de place. Il a cessé d’avoir de nouvelles adresses à distribuer il y a des années : les registres régionaux chargés de les attribuer ont épuisé leurs réserves entre 2011, pour la zone Asie-Pacifique, et 2019, pour l’Europe et le Moyen-Orient. Internet a continué de fonctionner malgré tout grâce à une astuce appelée traduction d’adresse réseau, ou NAT, qui permet à de nombreux appareils de partager une seule adresse IPv4 publique, un peu comme un immeuble de bureaux partage une seule adresse postale pour des dizaines d’entreprises. Le NAT à l’échelle d’un opérateur téléphonique, ou CGNAT, fait la même chose à l’échelle d’un réseau mobile entier, en laissant des millions de téléphones se partager un petit pool d’adresses. Cette astuce explique pourquoi l’épuisement de 2011 à 2019 n’a jamais vraiment cassé quoi que ce soit, et pourquoi l’IPv4 garde une utilité quinze ans après la fin officielle des stocks.
Un exemple concret illustre mieux le propos qu’un pourcentage de trafic. GitHub, l’une des plateformes de développeurs les plus utilisées au monde, fait encore tourner ses services cœur, le site, l’API et le clonage de dépôts Git, exclusivement en IPv4 en 2026. Il n’existe aucune feuille de route publique pour ajouter le support IPv6, et des développeurs le demandent dans les forums communautaires de GitHub depuis des années sans réponse officielle. La seule partie de GitHub qui répond bien en IPv6 est GitHub Pages, et uniquement parce qu’elle est servie par le réseau de Cloudflare plutôt que par l’infrastructure propre de GitHub. Un chiffre de part de trafic décrit une moyenne sur l’ensemble d’internet. Il ne dit rien sur le fait que le service précis dont dépend votre chaîne de déploiement ait basculé ou non.
La vraie décision de 2026 : dual-stack ou tout-IPv6
Pour la plupart des personnes qui gèrent un serveur aujourd’hui, la question n’est plus de savoir s’il faut supporter l’IPv6, c’est déjà tranché. Activer l’IPv6 en plus de l’IPv4, une configuration appelée dual-stack où le serveur répond sur les deux protocoles à la fois et laisse chaque appareil visiteur choisir celui qu’il préfère, coûte quasiment rien et reste la pratique standard depuis des années. La vraie question de 2026 est plus étroite et plus précise : peut-on couper l’IPv4 complètement et faire tourner un serveur uniquement en IPv6.
Cela devient déjà possible pour un nombre croissant de cas. Une infrastructure interne qui ne dialogue qu’avec d’autres systèmes que vous contrôlez aussi, une API privée entre deux services que vous exploitez tous les deux, un déploiement neuf sans base de clients historiques à ménager : tout cela peut passer en IPv6 seul sans que personne ne le remarque. Un serveur public accessible à n’importe qui, y compris depuis un vieux routeur domestique ou un réseau mobile encore coincé derrière du CGNAT en IPv4, est un cas différent, et y couper l’IPv4 risque d’exclure de vrais visiteurs.
Le dual-stack a lui aussi un coût discret, ce qui explique pourquoi certaines équipes l’évitent plutôt que de l’adopter d’emblée. Chaque règle de pare-feu, chaque répartiteur de charge, chaque sonde de supervision doit désormais couvrir deux protocoles au lieu d’un, et une règle écrite uniquement pour l’IPv4 échouera silencieusement à protéger le versant IPv6 du même serveur. Cet écart, pas un manque d’adresses, est la vraie raison pour laquelle certaines pannes sont mises sur le compte de l’IPv6 alors que le vrai coupable est une règle de pare-feu que personne n’a mise à jour.
Le coût commence aussi à faire pencher la balance. OVHcloud a relevé le prix d’une adresse IPv4 supplémentaire de 1,50 euro à 2 euros par mois à partir d’avril 2026, en citant la pression sur l’approvisionnement en mémoire, pas la rareté de l’IPv4 elle-même, comme raison. L’IPv6 reste gratuite chez tous les grands hébergeurs. Cela ne justifie pas de couper l’IPv4 sur un service qui en a réellement besoin, mais c’est une incitation réelle et croissante à arrêter de provisionner par défaut plus d’adresses IPv4 que ce que vous utilisez vraiment, le même réflexe qui paie sur n’importe quelle autre facture cloud à optimiser.
Comment vérifier avant de couper l’IPv4
Une liste générique des secteurs encore dépendants de l’IPv4 est moins utile qu’un audit de sa propre infrastructure, parce que la bonne réponse dépend de ce à quoi votre serveur parle réellement, pas d’une moyenne. Deux listes valent la peine d’être construites avant de basculer quoi que ce soit en IPv6 seul.
La première est sortante : chaque API tierce, chaque registre de paquets logiciels, chaque service que votre application ou votre chaîne de déploiement appelle. GitHub est l’exemple à tester en premier, tant d’outils de déploiement le sollicitent, mais ce sera rarement le seul. Si une dépendance sur laquelle vous comptez ne parle qu’IPv4, un serveur en IPv6 seul a besoin d’une couche de traduction, généralement appelée NAT64, juste pour l’atteindre, et c’est une pièce mobile de plus à maintenir.
La seconde est entrante : qui se connecte vraiment à vous. Un serveur utilisé uniquement par d’autres systèmes sous votre propre contrôle n’a aucun problème de client historique à gérer. Un serveur ouvert au grand public doit encore compter sur le fait qu’une partie des visiteurs se trouve derrière un routeur domestique ou un opérateur mobile IPv4 seul, même dans un pays où l’adoption de l’IPv6 paraît forte sur le papier.
Les deux listes se construisent vite. Lancer dig AAAA sur un domaine, une commande d’une ligne qui demande son enregistrement d’adresse IPv6, montre en quelques secondes s’il en publie une, et quelques minutes passées à relire ses propres enregistrements DNS et ses appels API sortants en disent plus sur son exposition réelle que n’importe quelle statistique d’adoption. Le chiffre digne de confiance est celui que vous avez mesuré sur votre propre infrastructure, pas celui qu’un titre a rapporté sur celle de quelqu’un d’autre.
La façon la plus sûre de trouver la vraie réponse est de tester d’abord sur un environnement non critique, un serveur de préproduction ou un outil interne, plutôt que de basculer directement un système en production vers l’IPv6 seul et de découvrir ce qui casse via le service support.
FAQ
L’IPv6 est-il désormais majoritaire sur internet ? Pas de façon établie. Le chiffre de Google a touché 50,1 % pendant une seule journée en mars 2026, mais Cloudflare et APNIC, en mesurant la même période avec des méthodes différentes, ont relevé 40,1 % et 43,13 %. Il faut traiter tout titre du type « l’IPv6 a franchi les 50 % » comme la lecture d’une seule entreprise sur son propre trafic, pas comme un verdict sur l’ensemble d’internet.
Puis-je simplement désactiver l’IPv4 sur mon serveur aujourd’hui ? Seulement après avoir vérifié ce dont il dépend réellement. Commencez par auditer les services que vous appelez en sortant et le type de visiteurs qui vous atteignent en entrant. Un serveur qui n’a que des dépendants internes est un cas bien plus simple qu’un site public.
Pourquoi GitHub ne supporte-t-il toujours pas l’IPv6 ? GitHub n’a publié aucune explication officielle ni aucune feuille de route, malgré des années de demandes dans ses propres forums communautaires. La seule partie de GitHub qui fonctionne en IPv6, GitHub Pages, le fait parce que le réseau de Cloudflare la sert, pas parce que l’infrastructure propre de GitHub a changé.
Qu’est-ce que le CGNAT, et pourquoi est-ce important ici ? C’est le mécanisme que les opérateurs télécoms utilisent pour faire partager à un grand nombre de clients, parfois un réseau mobile entier, un petit pool d’adresses IPv4 publiques. C’est la principale raison pour laquelle l’épuisement des nouvelles adresses IPv4 entre 2011 et 2019 n’a jamais vraiment cassé quoi que ce soit, et c’est pourquoi certains visiteurs de votre serveur resteront peut-être IPv4 seul pendant encore des années.
L’IPv4 va-t-il continuer à coûter plus cher ? Au moins un grand hébergeur, OVHcloud, a déjà relevé ses tarifs IPv4 en 2026, en invoquant la pression sur l’approvisionnement en mémoire. L’IPv6 reste gratuite partout. Que cette tendance se généralise à tous les hébergeurs n’est pas encore établi, mais la direction plaide pour réduire les adresses IPv4 qu’on n’utilise plus, pas pour se précipiter à migrer un service qui en a encore besoin.
Le chiffre de part de trafic qui a fait les gros titres en mars 2026 mérite d’être retenu pour ce qu’il est réellement : la lecture d’une seule entreprise sur ses propres visiteurs, contredite de dix points selon qui d’autre fait le calcul. La décision qui compte n’a rien à voir avec ce chiffre. C’est un audit tout simple de ce à quoi votre serveur parle et de qui lui parle, mené une bonne fois, avant de couper le moindre protocole.
