Longtemps, beaucoup d'éditeurs ont rangé IPv6 dans la case « on verra plus tard ». Mais à mesure que le coût de location et d'achat des adresses IPv4 grimpe, une IPv4 dédiée ressemble de plus en plus à une ressource rare qu'il faut payer à part, tandis que les adresses IPv6 échappent presque entièrement à cette contrainte. En 2026, soigner sérieusement la prise en charge d'IPv6 est passé du perfectionnisme technique à une véritable question de coût et d'accessibilité.

Pourquoi il vaut la peine d'agir maintenant

  • La structure des coûts change : plus l'IPv4 renchérit, moins la vieille méthode consistant à « attacher plusieurs IPv4 dédiées » est rentable, alors que les adresses IPv6 abondent.
  • Côté utilisateurs, tout est prêt depuis longtemps : les réseaux mobiles et les accès résidentiels distribuent massivement de l'IPv6, et la part des clients en IPv6 seul ou en IPv6 prioritaire progresse chaque année.
  • Accessibilité et ressenti : pour les utilisateurs déjà en IPv6, la double pile permet souvent de retirer une couche de NAT opérateur, avec un chemin plus direct.

Approche recommandée : la double pile, pas la bascule brutale

La stratégie la plus sûre à ce stade est la double pile (Dual-Stack) : conserver simultanément IPv4 et IPv6, accessibles des deux côtés. Un déploiement en IPv6 seul est séduisant sur le plan des coûts, mais vous heurterez immédiatement des réalités : « impossible d'appeler une API tierce disponible uniquement en IPv4 », « certains utilisateurs sur d'anciens réseaux ne peuvent pas accéder au site », ce qui impose en général une passerelle de conversion en filet. Pour la grande majorité des activités, la double pile offre le meilleur équilibre entre bénéfice et risque.

Étapes de mise en œuvre

  • Vérifiez que le serveur dispose bien d'une IPv6 correctement configurée : l'interface a-t-elle obtenu une adresse unicast globale, la route par défaut est-elle correcte, pouvez-vous joindre une adresse IPv6 externe en ping.
  • Complétez les enregistrements DNS AAAA : c'est l'étape la plus souvent oubliée. Avec un enregistrement A seul, vos utilisateurs IPv6 passeront quand même par IPv4.
  • Faites réellement écouter vos services en IPv6 : Nginx exige d'ajouter explicitement listen [::]:443 ssl; ; beaucoup d'applications ne se lient par défaut qu'à 0.0.0.0 et n'écoutent en double pile qu'après modification.
  • Synchronisez les règles de pare-feu : c'est le piège le plus fréquent et le plus dangereux — les règles iptables ne s'appliquent pas automatiquement à IPv6. Il faut configurer ip6tables en parallèle (ou utiliser les règles double pile de nftables ou d'ufw), faute de quoi votre protection soigneusement établie est virtuellement inexistante en IPv6.
  • Revoyez la logique applicative : listes blanches d'IP, limitation de fréquence, analyse de journaux, géolocalisation — toutes les fonctions qui traitent des IP doivent savoir interpréter correctement le format IPv6.

Ne validez pas uniquement depuis votre propre réseau

Un test local réussi ne garantit pas l'accessibilité depuis l'extérieur. Utilisez un outil en ligne tiers pour contrôler la connectivité IPv6 et confirmez que la résolution AAAA, la poignée de main TLS et le chargement des pages fonctionnent dans un environnement purement IPv6 avant la mise en production.

Les instances SharkCloud, dans toutes leurs régions, prennent en charge une configuration réseau standard et l'attribution d'IP dédiées : en suivant ces étapes, vous mettez la double pile en service et préservez l'accessibilité et la souplesse de votre activité dans un cycle de hausse des coûts IPv4.