Un client corporate appelle : « votre site ne charge pas sur le Wi-Fi du bureau ». Chez vous, tout est vert. Le NOC explique : réseau pilote IPv6-only avec NAT64 vers IPv4 — et votre domaine n'a que un enregistrement A. Ce n'est pas science-fiction ; c'est le type d'incident qui pousse à revisiter le « IPv4 suffit ».
IPv4 seul reste la majorité des stacks hébergement mutualisé. Dual stack (A + AAAA) annonce le site sur les deux protocoles. La question n'est pas idéologique : quel risque d'inaccessibilité acceptez-vous pour éviter quelques heures de configuration et de tests ?
État du terrain
| Aspect | IPv4 seul | Dual stack |
|---|---|---|
| Compatibilité aujourd'hui | Très large | Large si bien testé |
| Réseaux futurs IPv6-only | Dépend NAT64/DNS64 | Natif |
| Adressage | Pénurie, coût IP dédiée | Abondant |
| Config DNS | Enregistrement A | A + AAAA |
| Pare-feu / WAF | Une famille | v4 + v6 |
| Monitoring | Standard | Vérifier les deux chemins |
Ignorer IPv6 n'est pas une stratégie — c'est un pari que personne ne coupera IPv4 chez vos visiteurs assez tôt pour vous inquiéter.
IPv4 seul : quand c'est encore défendable
Intranet legacy, VPN IPv4. Périmètre contrôlé, pas d'enjeu public.
Application avec contraintes partenaires IPv4. Intégrations B2B anciennes — plan de migration daté.
Hébergeur sans IPv6 et migration lointaine. Acceptation explicite du risque plus monitoring des erreurs de connexion si disponible.
Mitigation temporaire : CDN dual stack devant origine IPv4-only — le CDN termine IPv6, parle IPv4 à l'origine. Fonctionne si tout le trafic passe par le CDN (pas d'API directe).
Dual stack : checklist sans angle mort
Vérifiez que l'hébergeur assigne une adresse IPv6 au serveur ou au load balancer — OVH, Hetzner, Infomaniak le proposent ; consultez l'annuaire. Publiez un AAAA cohérent avec l'enregistrement A. Le certificat TLS couvre le nom, pas le protocole — Let's Encrypt gère les deux.
Ouvrez les ports 80/443 en v6 ; bloquez l'administration SSH v6 si non surveillée. Testez avec curl -6 https://votresite depuis un réseau IPv6-only. Attention aux sous-domaines API (api.example.com) souvent oubliés.
Pièges fréquents : AAAA publié mais service n'écoutant pas sur [::] → timeout long côté client ; IPv6 ouvert sans même durcissement qu'IPv4 ; email SMTP sortant en v4 seul alors que le web est dual stack.
Le sommet : l'accessibilité est asymétrique
Décider et avancer sans angle mort
Vérifiez si votre hébergeur actuel propose l'IPv6. Si oui, déployez AAAA en staging, testez depuis un réseau v6-only, puis basculez en production. Si non, choisissez un CDN dual stack devant origine IPv4 ou planifiez une migration hébergeur — pas l'inaction par défaut. Surveillez les erreurs de connexion côté support et logs edge. Comparez les hébergeurs dual stack via le comparateur et lisez HTTP/2 ou HTTP/3 pour la couche transport.
Questions fréquentes
Mon site a-t-il besoin d'IPv6 en 2026 ?
Pas obligatoire légalement, mais de plus en plus recommandé. Sans AAAA, vous dépendez de traductions NAT64 sur les réseaux IPv6-only — avec risque de lenteur ou d'échec.
Le dual stack complique-t-il l'exploitation ?
Légèrement : AAAA, pare-feu v6, tests bout en bout. Le coût principal est la vérification, pas une licence supplémentaire chez la plupart des hébergeurs européens.
IPv6 améliore-t-il le référencement ou la vitesse ?
Pas de boost SEO direct. Accessibilité future et latence parfois meilleure en natif v6 — pas un raccourci PageSpeed magique.
Que faire si mon hébergeur ne propose pas IPv6 ?
Tunnel broker temporaire ou migration vers hébergeur dual stack. Ne restez pas sans plan de surveillance des connexions client.
Avant de reporter IPv6, demandez à votre hébergeur : l'adresse v6 est incluse ou facturée — et qui monitorera le AAAA après le déploiement ? Sans réponse claire, le risque reste le vôtre.