Defaults.Exposed › Corrections › Prise en charge de l'IPv6

Comment corriger Prise en charge de l'IPv6

L'IPv6 est la version plus récente et bien plus vaste du système d'adressage d'internet, introduite parce que l'ancien (IPv4) a épuisé sa réserve. Ajouter la prise en charge de l'IPv6 signifie que votre site et votre messagerie peuvent être joints sur le réseau moderne aussi bien que sur l'ancien. Dans notre notation, c'est informatif — ne pas l'avoir ne baisse pas votre note — mais c'est un véritable enjeu de portée : une part croissante de clients mobiles et étrangers se connectent sur des réseaux IPv6 uniquement, et ils vous joignent sans accroc seulement si vous le prenez en charge. Le correctif est gratuit et réside dans votre configuration DNS et d'hébergement.

En clair, pour votre entreprise : Une part montante d'internautes — surtout sur les opérateurs mobiles et dans les marchés à forte croissance d'Asie et de certaines régions d'Europe — se connectent désormais en IPv6. Si votre site est en IPv4 uniquement, ces visiteurs passent quand même en général (leur opérateur traduit la connexion pour eux), mais cette traduction ajoute un saut, peut être légèrement plus lente, et est une chose de plus susceptible d'échouer ou d'être bridée aux heures de pointe. Prendre en charge l'IPv6 signifie une connexion plus propre et plus directe pour les clients modernes, un petit gain de pérennité, et un signal soigné aux acheteurs techniques que votre infrastructure est à jour. Cela ne change rien à votre note — voyez-y du peaufinage tourné vers l'avenir, pas une urgence — mais c'est gratuit à ajouter et vous aligne sur la direction que prend internet.

Ce que cela peut vous coûter

Un client sur un opérateur mobile qui fonctionne en IPv6 uniquement doit atteindre votre site IPv4 via la couche de traduction de son opérateur. Cela marche presque toujours — mais cela ajoute de la latence et est une dépendance de plus susceptible de hoqueter aux heures de pointe, rendant votre site marginalement plus lent qu'un concurrent joignable directement.
L'équipe sécurité/infra d'un acheteur ou partenaire technique lance un scan rapide avant de signer et note que vous êtes en IPv4 uniquement. Cela ne vous recale pas, mais un concurrent qui affiche du dual-stack (IPv4 + IPv6) atterrit dans la colonne « moderne, bien géré » tandis que vous restez dans « correct, un peu en retard ».
Vous vous développez sur un marché — certaines régions d'Asie, l'Inde, certains réseaux mobiles européens — où l'IPv6 est déjà dominant. Y être joignable directement, plutôt que toujours via traduction, supprime une source petite mais réelle de connexions lentes ou capricieuses pour vos clients les plus récents.
Votre hébergement ou votre CDN prend déjà en charge l'IPv6 gratuitement, mais personne ne l'a jamais activé, donc vous passez à côté d'une amélioration facile et sans coût que vos concurrents ont récupérée par défaut.
Une liste de contrôle des achats publics ou d'entreprise demande si vos services sont prêts pour l'IPv6 (beaucoup de mandats du secteur public le font désormais). « Non » est une ligne embarrassante à expliquer alors que le correctif était gratuit depuis le début.

Pourquoi c'est important. Dans notre méthodologie, la prise en charge de l'IPv6 est informative — le contrôle est enregistré avec zéro point et ne fait jamais bouger votre note. Nous en rendons compte parce que c'est un véritable signal de portée et de modernité tourné vers l'avenir : internet a épuisé les adresses à l'ancienne (IPv4) il y a des années, et la part d'utilisateurs se connectant sur des réseaux IPv6 uniquement ne cesse de grimper, en particulier sur mobile et dans les régions à dominante IPv6. Prendre en charge l'IPv6 donne à ces utilisateurs un chemin plus propre et plus direct vers votre site et votre messagerie, et signale une infrastructure à jour à quiconque vérifie. C'est gratuit à ajouter et casse rarement quoi que ce soit — ce qui est précisément pourquoi cela vaut la peine même si cela n'affecte pas votre score.

La prise en charge de l’IPv6, en clair

Internet identifie chaque serveur par une adresse numérique. Le système d’origine, l’IPv4, a une réserve d’adresses fixe et plutôt petite — et le monde a épuisé les adresses neuves il y a des années. Son remplaçant, l’IPv6, a une réserve pratiquement illimitée, et internet migre tranquillement vers lui depuis.

La prise en charge de l’IPv6 signifie que votre site (et votre messagerie) peuvent être joints sur ce réseau plus récent aussi bien que sur l’ancien. En pratique, cela se résume à une chose dans votre DNS : aux côtés de l’enregistrement qui liste votre adresse à l’ancienne (un enregistrement A), vous publiez aussi un enregistrement qui liste votre adresse IPv6 (un enregistrement AAAA — quatre A). Faire tourner les deux côte à côte s’appelle le dual-stack, et c’est la façon normale et sûre de procéder.

Ce contrôle est informatif. Il ne change pas votre note. Nous recherchons si votre domaine publie des enregistrements AAAA et indiquons simplement ce que nous trouvons — présent, ou absent. Nous le signalons parce que c’est un véritable signal de portée et de modernité, gratuit à corriger, pas parce que c’est un échec.

Ce que cela peut vous coûter

Cela provoque rarement une panne franche — c’est exactement pourquoi c’est informatif plutôt que noté. Mais un « coût invisible » reste un coût. Voici les façons réalistes dont une configuration IPv4 uniquement joue discrètement contre vous :

Une expérience légèrement plus lente pour les clients mobiles. Beaucoup d’opérateurs mobiles fonctionnent désormais en IPv6 uniquement en interne. Un client sur un tel réseau atteignant votre site IPv4 uniquement passe par la couche de traduction de son opérateur — un saut supplémentaire qui ajoute de la latence et peut se congestionner aux heures de pointe. Votre concurrent avec l’IPv6 donne à ce même client une connexion directe et plus propre. Sur une page de paiement, de petites lenteurs s’additionnent en paniers abandonnés.
Une impression plus faible auprès des acheteurs techniques. Avant qu’un contrat soit signé, l’équipe informatique ou sécurité d’un acheteur lance souvent un scan rapide d’infrastructure. L’IPv4 uniquement ne vous recale pas — mais le dual-stack se lit comme « moderne et bien géré », et son absence se lit comme « un peu en retard ». Quand vous êtes au coude à coude sur tout le reste, ces petits signaux font pencher les décisions.
De la friction sur les marchés à dominante IPv6. Si vous vous développez dans des régions où l’IPv6 est déjà la norme — certaines régions d’Asie, l’Inde, plusieurs réseaux mobiles européens — y être joignable directement supprime une vraie source de connexions lentes ou capricieuses pour vos clients les plus récents et les plus durement gagnés.
Une case d’achat ratée. Un nombre croissant de processus d’achat du secteur public et d’entreprise demandent désormais explicitement si vos services sont prêts pour l’IPv6. « Non » est une réponse embarrassante à donner alors que le correctif était gratuit.
Laisser une amélioration gratuite sur la table. Très souvent, votre hébergeur ou votre CDN prend déjà en charge l’IPv6 sans coût supplémentaire — il n’a simplement jamais été activé. C’est un gain facile et sans coût que vos concurrents ont récupéré par défaut et pas vous.

Ce que c’est vraiment

Chaque appareil sur internet a besoin d’une adresse. Les adresses IPv4 ressemblent à 203.0.113.10 — quatre nombres, une réserve d’environ 4,3 milliards, épuisée depuis longtemps. Les adresses IPv6 ressemblent à 2001:db8::1 — plus longues, hexadécimales, avec une réserve si vaste qu’elle est pratiquement illimitée.

Dans votre DNS — le carnet d’adresses d’internet — ils existent sous forme de deux types d’enregistrements :

Enregistrement A → votre adresse IPv4 (l’ancien réseau).
Enregistrement AAAA → votre adresse IPv6 (le nouveau réseau).

Notre contrôle fait l’équivalent de lancer dig AAAA votredomaine.com et indique si des enregistrements AAAA reviennent.

À quoi ressemble une situation « correcte » : une configuration dual-stack — vos enregistrements A existants intacts, avec des enregistrements AAAA publiés à côté, les deux pointant vers un serveur (ou répartiteur de charge, ou CDN) qui répond réellement sur les deux réseaux et sert le même site. Les utilisateurs IPv4 continuent exactement comme avant ; les utilisateurs IPv6 obtiennent un chemin direct. Vous ne supprimez pas l’IPv4 — vous ajoutez l’IPv6 à côté.

Ce que signifie « absent » : aucun enregistrement AAAA. Les utilisateurs IPv6 uniquement peuvent encore généralement vous joindre via la traduction de leur opérateur, mais jamais directement. Ce n’est pas cassé — c’est juste une modernisation manquée, c’est pourquoi cela ne vous coûte pas de points.

Comment corriger (gratuit, ~15–30 minutes)

Transmettez ceci à votre informaticien ou à la personne qui gère votre site — le correctif est gratuit. C’est un changement DNS-et-hébergement, pas un achat. La règle d’or : ajoutez l’IPv6 aux côtés de l’IPv4, jamais à sa place (dual-stack), et confirmez que la cible répond réellement en IPv6 avant de publier.

1. Déterminez si votre hébergement/CDN prend du tout en charge l’IPv6. C’est le verrou. Si votre hébergeur n’a aucune adresse IPv6 à offrir, il n’y a rien de plus à faire et aucune pénalité pour cela. La plupart des plateformes et CDN modernes le prennent en charge — souvent déjà activé.

2. Appliquez-le sur votre plateforme :

Cloudflare : l’IPv6 est généralement activé par défaut. Quand votre site est mandaté par Cloudflare (nuage orange), Cloudflare répond en IPv6 pour vous automatiquement — vous n’ajoutez généralement pas d’enregistrements AAAA vous-même du tout. Vérifiez que Network → IPv6 Compatibility est activé. C’est la voie la plus facile de loin.
Google Workspace / Microsoft 365 (côté messagerie) : le côté réception de courrier est généralement déjà compatible IPv6 sur l’infrastructure du fournisseur — vous ne le gérez pas. Les enregistrements AAAA du site web de cette page concernent votre site, pas leurs serveurs de courrier ; aucune action nécessaire pour le fournisseur de messagerie lui-même.
AWS : activez le dual-stack sur votre répartiteur de charge (ALB/NLB) ou votre instance, puis ajoutez un enregistrement alias AAAA dans Route 53 pointant vers lui. Pour CloudFront, l’IPv6 est un interrupteur dans les réglages de la distribution.
Google Cloud / Azure : activez l’IPv6 (dual-stack) sur le répartiteur de charge ou l’instance, obtenez l’adresse IPv6, et publiez l’enregistrement AAAA dans votre DNS.
Auto-hébergé / VPS géré : demandez à votre fournisseur une adresse IPv6, configurez votre serveur web pour écouter en IPv6 (et confirmez qu’il y sert le même site), puis ajoutez l’enregistrement DNS :
```
votredomaine.com.      AAAA   2001:db8::1
www.votredomaine.com.  AAAA   2001:db8::1
```
(Remplacez par votre vraie adresse IPv6. Gardez vos enregistrements A existants exactement tels quels.)

3. Testez avant de vous y fier. Après la publication, vérifiez depuis un outil compatible IPv6 que l’enregistrement AAAA résout et que le site se charge réellement en IPv6 (un « test IPv6 » en ligne, ou curl -6 https://votredomaine.com depuis une machine compatible IPv6). Un enregistrement AAAA publié qui ne pointe nulle part est pire que pas d’enregistrement du tout.

4. Relancez le scan. Une fois les enregistrements AAAA actifs et répondant, ce contrôle signalera l’IPv6 comme activé. (Cela ne changera pas votre note — c’était informatif depuis le début — mais vous aurez comblé la lacune.)

Erreurs courantes

Publier un enregistrement AAAA qui pointe vers un serveur n’écoutant pas en IPv6. C’est la blessure auto-infligée classique : les utilisateurs IPv6 sont envoyés vers une adresse morte et votre site paraît cassé pour eux seulement — difficile à remarquer, puisqu’il fonctionne très bien pour vous en IPv4. Confirmez toujours que la cible répond en IPv6 avant de publier.
Remplacer l’IPv4 au lieu d’ajouter l’IPv6. Vous ne supprimez jamais vos enregistrements A. Le dual-stack garde les deux ; abandonner l’IPv4 couperait la majorité des utilisateurs du jour au lendemain.
Ajouter le domaine apex mais oublier www (ou l’inverse), ou couvrir le site mais pas les sous-domaines de courrier qui vous tiennent à cœur. Soyez cohérent sur les noms d’hôte qui comptent.
Supposer que c’est fait parce que l’hébergeur « prend en charge » l’IPv6. Prise en charge et activé sont différents. Sur Cloudflare c’est généralement automatique ; sur un VPS brut, vous devez le configurer et le publier vous-même.
Le traiter comme urgent. Ça ne l’est pas. C’est informatif. Faites vos contrôles de sécurité notés (HTTPS, DMARC, DNSSEC, les en-têtes de sécurité) d’abord ; ajoutez l’IPv6 comme du peaufinage tourné vers l’avenir quand c’est commode.

FAQ

Si mon site IPv4 uniquement se charge encore pour tout le monde, pourquoi l'IPv6 importe-t-il ?

Parce que « se charge encore » fait beaucoup de travail. Les utilisateurs sur des réseaux IPv6 uniquement — courants sur les opérateurs mobiles et de plus en plus ailleurs — atteignent un site IPv4 uniquement via la couche de traduction de leur opérateur (NAT64/464XLAT). Cela marche généralement, mais c'est un saut supplémentaire qui ajoute un peu de latence et est une pièce d'infrastructure partagée de plus susceptible d'être lente ou congestionnée aux heures de pointe. Prendre en charge l'IPv6 donne à ces utilisateurs une connexion directe. C'est une amélioration de fluidité et de pérennité, pas un interrupteur « cassé contre fonctionnel » — c'est pourquoi c'est informatif et non noté.

Cela n'affecte pas ma note — devrais-je m'en préoccuper ?

C'est réellement optionnel, mais c'est aussi gratuit et à faible risque, donc cela vaut la peine la prochaine fois que votre informaticien est dans la console DNS ou d'hébergement. Beaucoup de fournisseurs (Cloudflare, les grandes plateformes cloud, de nombreux hébergeurs) prennent en charge l'IPv6 d'office — parfois c'est juste un interrupteur. Si le vôtre ne le prend pas du tout en charge, c'est une bonne raison de le laisser pour l'instant ; rien de fâcheux n'arrive à votre score dans tous les cas. Voyez-y un rangement, pas un exercice d'alerte.

Je ne suis pas technique — que dois-je faire concrètement ?

Transmettez la section « Comment corriger » à la personne qui gère votre site ou votre DNS et demandez : « Peut-on ajouter l'IPv6 (enregistrements AAAA) pour notre site ? C'est gratuit et ça ne devrait rien casser. » Si vous êtes sur Cloudflare, c'est généralement déjà activé. Si vous êtes sur un hébergement géré ou une grande plateforme cloud, c'est souvent un réglage unique. Si votre hébergeur ne prend pas du tout en charge l'IPv6, il n'y a rien à faire — et aucune pénalité pour cela.

Qu'est-ce qu'un enregistrement AAAA, en clair ?

Votre DNS est le carnet d'adresses d'internet. Un « enregistrement A » liste l'adresse à l'ancienne (IPv4) de votre site ; un « enregistrement AAAA » (quatre A) liste son adresse IPv6 plus récente. Ajouter la prise en charge de l'IPv6 signifie publier des enregistrements AAAA aux côtés de vos enregistrements A existants, pour que les appareils sur le nouveau réseau vous trouvent directement. Notre contrôle recherche simplement vos enregistrements AAAA (l'équivalent technique de lancer « dig AAAA votredomaine.com ») et indique s'il en existe.

Ajouter l'IPv6 pourrait-il casser mon site ou ma messagerie ?

C'est à faible risque quand c'est bien fait, mais pas à risque nul, c'est pourquoi on teste. Le schéma sûr est le « dual-stack » — vous gardez tous vos enregistrements IPv4 (A) existants exactement tels quels et ajoutez des enregistrements IPv6 (AAAA) à côté. Les utilisateurs IPv4 continuent sans changement ; les utilisateurs IPv6 obtiennent un nouveau chemin direct. Ce qu'il faut vérifier, c'est que ce vers quoi pointe l'enregistrement AAAA (votre serveur ou répartiteur de charge) écoute réellement en IPv6 et sert le même site — un enregistrement AAAA périmé ou erroné peut envoyer les utilisateurs IPv6 vers une adresse morte. Sur les plateformes gérées et les CDN, c'est pris en charge pour vous ; sur les configurations auto-hébergées, confirmez que le serveur répond en IPv6 avant de publier.

L'IPv6 rend-il mon site plus sécurisé ?

Pas en soi — c'est avant tout une amélioration de portée et de modernité, pas un contrôle de sécurité, ce qui explique en partie pourquoi cela ne compte pas dans le score. C'est référencé dans des cadres de gestion des risques plus larges (par exemple les obligations générales de gestion des risques de cybersécurité de NIS2) comme faisant partie d'une infrastructure à jour et résiliente, mais ajouter un enregistrement AAAA ne vous durcit pas comme le font HTTPS, DMARC ou DNSSEC. Faites d'abord les contrôles de sécurité notés ; voyez l'IPv6 comme de l'hygiène d'infrastructure tournée vers l'avenir, par-dessus.