La question est arrivée après qu’un client a lu un article généraliste sur l’épuisement des adresses IPv4. « Est-ce qu’on doit activer IPv6 sur notre serveur ? On ne voudrait pas qu’une partie des visiteurs ne puisse plus accéder au site. » La crainte est légitime mais mal calibrée : pour un WordPress classique, hébergé sur un serveur mutualisé ou un VPS standard, l’urgence est généralement bien moindre qu’elle n’y paraît.
IPv6 est le protocole destiné à remplacer à terme IPv4, dont l’espace d’adressage (environ 4,3 milliards d’adresses) est épuisé depuis plusieurs années côté attribution aux opérateurs. Contrairement à une idée reçue, ce changement de protocole réseau se joue presque entièrement en dehors de WordPress lui-même. Voici ce qu’il faut réellement comprendre avant de décider quoi que ce soit.
WordPress ne sait pas ce qu’est une adresse IP de son visiteur
Sur le plan applicatif, WordPress fonctionne au niveau HTTP, une couche entièrement indépendante du protocole IP utilisé pour transporter la requête. Que le visiteur arrive via IPv4 ou IPv6, WordPress reçoit une requête HTTP identique, avec les mêmes en-têtes, le même contenu de formulaire, les mêmes cookies. Aucune fonction du cœur de WordPress ne distingue les deux cas.
Il existe une exception notable, indirecte : les extensions qui utilisent l’adresse IP du visiteur à des fins de sécurité ou de statistiques, par exemple pour limiter les tentatives de connexion ou géolocaliser un commentaire. Ces extensions doivent savoir parser correctement une adresse IPv6 (au format hexadécimal avec des :), ce qui n’est pas toujours le cas des plus anciennes, écrites à une époque où IPv6 était encore marginal. C’est la seule zone de friction réellement applicative.
Le vrai enjeu se situe au niveau du serveur et du DNS
Rendre un site joignable en IPv6 est une affaire d’infrastructure, pas de code WordPress. Cela suppose que l’hébergeur attribue une adresse IPv6 au serveur, que le serveur web soit configuré pour l’écouter, et qu’un enregistrement DNS de type AAAA (l’équivalent IPv6 d’un enregistrement A) soit publié pour le domaine.
server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;
server_name exemple.fr;
...
}Sans cette configuration double (IPv4 et IPv6 explicitement déclarés dans le bloc serveur nginx, ou son équivalent Apache), un visiteur arrivant en IPv6 pur ne pourrait tout simplement pas joindre le site. Mais dans les faits, une écrasante majorité des connexions résidentielles et mobiles en France restent en mode « dual stack » : le terminal du visiteur dispose des deux protocoles et bascule automatiquement sur IPv4 si le serveur ne répond qu’en IPv4. C’est précisément ce qui explique qu’un serveur uniquement IPv4 puisse fonctionner des années sans jamais générer la moindre plainte d’accessibilité.
Le point d’attention réel : la messagerie
Si l’activation d’IPv6 pour le trafic web reste peu urgente, la question mérite plus de prudence côté email. Un serveur qui envoie des emails WordPress (confirmations de commande, notifications) via IPv6 sans DNS inverse (PTR) correctement configuré sur cette adresse IPv6 prend un risque réel de délivrabilité : les grands fournisseurs de messagerie sont particulièrement stricts sur la cohérence des enregistrements PTR en IPv6, plus encore qu’en IPv4.
- Si l’hébergeur active IPv6 sans configurer de PTR cohérent sur cette nouvelle adresse, les emails sortants risquent d’être davantage filtrés qu’auparavant, pas moins.
- Un serveur qui n’envoie jamais d’email en IPv6 (configuration explicite du relais SMTP en IPv4 uniquement) évite entièrement ce risque, sans perdre l’accessibilité web en IPv6 si elle est activée par ailleurs.
- Vérifier ce point avec l’hébergeur avant d’activer IPv6 globalement est plus important que de se soucier de l’accessibilité web, déjà couverte par le mode dual stack des visiteurs.
Faut-il l’activer en 2020 ?
Pour un WordPress institutionnel ou e-commerce classique, sans contrainte spécifique, l’activation d’IPv6 en 2020 relève davantage de l’anticipation que de l’urgence. Aucun visiteur grand public en France n’est aujourd’hui bloqué par l’absence d’IPv6 sur un site, grâce au mode dual stack généralisé chez les fournisseurs d’accès. La bascule devient en revanche pertinente dans des contextes précis : hébergement chez un fournisseur qui facture différemment ou limite les adresses IPv4 disponibles, ou contrainte contractuelle d’un client du secteur public engagé sur une feuille de route IPv6.
Notre position sur les serveurs que nous gérons : IPv6 n’est ni un risque ni une urgence, mais une case à cocher proprement le jour où l’hébergeur la propose nativement, à condition de vérifier le PTR avant de l’activer sur le flux sortant des emails.
En résumé
IPv6 ne change rien au code WordPress, tout au réseau. Un site qui tourne bien en IPv4 pur ne perd aucun visiteur aujourd’hui. La vraie vigilance à avoir, si l’hébergeur active IPv6 sur le serveur, porte sur la cohérence du DNS inverse pour l’envoi d’emails, bien plus que sur l’accessibilité web elle-même.
