Table des matières de l'article :
Dans le monde du e-commerce, on parle couramment de taux de conversion, de campagnes Meta Ads, de Google Ads, de pixels, de suivi côté serveur, de cookies propriétaires et d'API de conversion. En revanche, on s'interroge beaucoup moins souvent sur ce qui se passe à un niveau inférieur, au sein du réseau qui achemine physiquement les requêtes entre les smartphones, les plateformes publicitaires, les CDN et les serveurs e-commerce.
L'une des questions les plus intéressantes concerne l'IPv6.
Aujourd'hui, une part importante des internautes, notamment mobiles, utilise déjà l'IPv6. Facebook, Instagram, Google et les principales plateformes mondiales sont pleinement accessibles via IPv6. Cependant, de nombreux sites web restent exclusivement publiés via IPv4.
Cela crée une situation particulière : un utilisateur peut naviguer sur Facebook via une adresse IPv6, cliquer sur une publicité et accéder immédiatement à un site de commerce électronique accessible uniquement en IPv4. Le serveur de commerce électronique pourrait alors observer une adresse IP totalement différente de celle utilisée par le même appareil quelques instants avant de communiquer avec Meta.
Votre achat fonctionnera normalement. Le produit sera ajouté à votre panier, vous pourrez accéder à la page de paiement et effectuer le règlement.
La question intéressante est une autre :
Cette discontinuité entre IPv6 et IPv4 pourrait-elle rendre le suivi et donc l'attribution des conversions moins précis ?
La réponse est oui, du moins potentiellement. Mais il nous faut comprendre dans quelle mesure et, surtout, éviter la conclusion simpliste selon laquelle un site fonctionnant exclusivement en IPv4 « perd automatiquement ses conversions Facebook ».
Le problème est plus subtil et concerne la qualité des signaux utilisés pour reconnaître un utilisateur et associer une conversion à une interaction publicitaire antérieure.
Pourquoi le suivi est si important pour le commerce électronique
Une plateforme de commerce électronique ne doit pas se contenter de vendre. Elle doit également être capable de comprendre, dans la mesure du possible sur les plans technique et légal, d'où proviennent ces ventes.
Si une boutique en ligne investit 20 000 € par mois en publicité, il ne suffit pas de savoir que 500 commandes ont été reçues. Il est essentiel de déterminer quelles campagnes, quelles publicités, quelles audiences et quelles sources de trafic ont contribué à les générer.
C’est là qu’entrent en jeu des systèmes comme Meta Pixel, Meta Conversions API, Google Ads Conversion Tracking, Google Analytics et les nombreuses plateformes d’analyse et de publicité utilisées quotidiennement par les entreprises de commerce électronique.
Lorsqu'un utilisateur clique sur une publicité Facebook ou Instagram et effectue ensuite un achat, Meta tente de corréler les deux événements.
Dans un monde idéal, nous aurions une séquence parfaitement reconnaissable :
Facebook affiche une publicité, l'utilisateur clique dessus, arrive sur le site de commerce électronique, consulte un produit, l'ajoute au panier, entame la procédure de paiement et finalise la commande.
Plus Meta pourra associer clairement ces événements au même utilisateur ou parcours publicitaire, meilleure sera l'attribution.
Ceci est important non seulement pour produire des statistiques plus attrayantes dans le panneau Gestionnaire de publicités.
Les données de conversion sont également utilisées par les systèmes automatisés des plateformes publicitaires pour optimiser la diffusion des campagnes . Si le système reçoit des signaux de conversion incomplets ou de faible qualité, il risque de disposer de moins d'informations sur les caractéristiques des utilisateurs qui effectuent réellement un achat.
C’est pourquoi, ces dernières années, l’écosystème du commerce électronique est progressivement passé du simple Pixel exécuté dans le navigateur à des implémentations plus complexes qui incluent également l’envoi d’événements côté serveur via des outils tels que l’ API Meta Conversions , communément appelée CAPI.
Et c'est précisément dans le cadre du suivi côté serveur que l'adresse IP du visiteur redevient un paramètre particulièrement intéressant.
Explication succincte d'IPv4 et d'IPv6
Tout appareil communiquant via Internet utilise le protocole IP.
Pendant de nombreuses années, Internet a été construit presque entièrement autour d'IPv4 , un protocole qui utilise des adresses 32 bits telles que :
192.0.2.123
L'espace théorique disponible est d'environ 4,3 milliards d'adresses. Ce nombre pouvait paraître énorme aux débuts d'Internet, mais il est devenu insuffisant avec les milliards d'ordinateurs, de smartphones, de routeurs, de serveurs, d'objets connectés et d'infrastructures interconnectées.
Le problème n'est pas théorique. En Europe, le RIPE NCC a épuisé son stock d'adresses IPv4 disponibles en novembre 2019. Depuis, la croissance s'est poursuivie grâce à la récupération et au déplacement d'adresses existantes, au NAT, au NAT de niveau opérateur et à d'autres techniques permettant le partage de l'espace IPv4 limité.
L'IPv6 a été créée précisément pour surmonter cette limitation.
Utilisez des adresses de 128 bits, par exemple :
2001:db8:85a3::8a2e:370:7334
L'espace d'adressage devient tellement vaste qu'il élimine pratiquement le problème de rareté qui caractérise IPv4.
L'IPv6 n'est donc pas simplement une nouvelle notation pour indiquer une adresse IP : elle représente une évolution fondamentale de l'infrastructure Internet.
Cette migration ne s'est toutefois pas faite du jour au lendemain par le remplacement d'IPv4. Les deux protocoles ont coexisté pendant des décennies.
Et c'est cette coexistence qui rend le problème du suivi intéressant.
L'IPv6 n'est plus une technologie marginale
Pendant de nombreuses années, l'IPv6 a été perçu par les administrateurs de sites web comme quelque chose qui pourrait être mis en œuvre « plus tard ».
Aujourd'hui, cette position est beaucoup plus difficile à maintenir.
Google mesure en permanence le pourcentage de ses utilisateurs qui accèdent aux services Google via IPv6. Au 13 juin 2026, il avait déjà détecté 50,29 % des accès via IPv6 natif.
Les méthodologies de mesure peuvent donner des pourcentages différents. APNIC, par exemple, utilise ses propres systèmes de mesure et estime que la capacité mondiale d'IPv6 dépassera les 40 % d'ici septembre 2026.
Il est donc inutile de s'attarder sur un seul chiffre. L'important est l'ordre de grandeur : l'IPv6 couvre désormais des centaines de millions d'utilisateurs et une part considérable du trafic Internet mondial.
Ceci est particulièrement important dans le monde mobile, où les technologies IPv6 uniquement, NAT64 et 464XLAT permettent aux opérateurs de limiter le besoin d'adresses IPv4 publiques.
Facebook, Instagram, Google et bien d'autres plateformes majeures sont bien sûr accessibles via IPv6.
Le Web dans son ensemble, cependant, présente une situation très différente.
Les utilisateurs privilégient de plus en plus l'IPv6, mais de nombreux sites fonctionnent encore exclusivement en IPv4.
En septembre 2026, W3Techs détecte la prise en charge d'IPv6 sur environ 31,5 % des sites Web analysés .
La situation s'améliore considérablement lorsqu'on regarde les sites les plus importants : l'IPv6 est présent sur 44,2 % des 1 million de sites les plus visités, sur 52,9 % des 100 000 premiers et sur 56,6 % des 10 000 premiers.
Ces données révèlent un phénomène intéressant.
La disponibilité d'IPv6 augmente avec la taille et la pertinence du site.
Les principales plateformes ont investi depuis longtemps dans une infrastructure à double pile, tandis qu'une part importante du web traditionnel continue de fonctionner exclusivement sur IPv4.
D'après W3Techs, en juillet 2026, seuls 13,7 % des sites détectés avec cPanel et 19,1 % de ceux avec Plesk utilisaient IPv6. Ces statistiques ne doivent pas être interprétées comme une limitation intrinsèque de ces deux plateformes, mais elles illustrent clairement à quel point l'écosystème d'hébergement traditionnel reste fortement axé sur IPv4.
WordPress, pris dans son ensemble, affichait également une présence IPv6 d'environ 32,9 % en juin 2026.
Il est donc parfaitement plausible qu'un smartphone moderne utilise l'IPv6 pour Facebook, Instagram ou Google, et soit immédiatement contraint d'utiliser l'IPv4 lorsqu'il ouvre le site de l'annonceur.
Pourquoi de nombreux fournisseurs d'hébergement sont-ils encore exclusivement compatibles IPv4 ?
Le problème vient rarement du noyau Linux ou du serveur web.
Linux, NGINX, Apache, HAProxy, Varnish, PHP et les principales bases de données prennent en charge IPv6 depuis très longtemps.
La limitation réside souvent dans l'architecture d'hébergement globale.
De nombreuses plateformes d'hébergement mutualisé ont vu le jour à une époque où l'IPv4 était encore considérée comme la norme absolue. Les configurations des hôtes virtuels, les systèmes DNS, les pare-feu, les logiciels de provisionnement, les panneaux de contrôle, les statistiques, les systèmes antifraude, les applications existantes et les procédures opérationnelles étaient conçus autour de l'adresse IPv4.
L'ajout d'IPv6 ne signifie donc pas simplement attribuer une adresse au serveur.
Cela signifie s'assurer que votre DNS, votre pare-feu, votre système de surveillance, votre journalisation, votre limitation de débit, votre proxy inverse, vos applications et vos logiciels de sécurité gèrent correctement cette situation.
L'hébergement moderne devrait être conçu pour considérer IPv4 et IPv6 comme deux modes d'accès standard à un même service. Or, dans de nombreuses infrastructures plus anciennes, IPv6 est encore considéré comme une option supplémentaire.
Pendant des années, cette lacune n'a eu que peu de conséquences évidentes pour le propriétaire du site : grâce aux technologies de transition, un utilisateur IPv6 pouvait toujours ouvrir pratiquement n'importe quel site IPv4.
Aujourd'hui, cependant, d'autres raisons justifient cet intérêt. L'une d'elles est la continuité des données utilisées dans le suivi côté serveur.
Que se passe-t-il lorsque Facebook détecte l'IPv6 mais que le commerce électronique n'utilise que l'IPv4 ?
Prenons l'exemple d'un utilisateur qui utilise Facebook via l'application installée sur son smartphone.
Le réseau mobile assure une connectivité IPv6 et Facebook est donc accessible directement via IPv6.
On peut imaginer que, durant cette phase, l'appareil est identifiable sur le réseau par une adresse du type :
2a01:xxxx:xxxx:xxxx::1234
L'utilisateur voit une campagne publicitaire, clique dessus et est redirigé vers :
https://www.ecommerce.it/
Cependant, le DNS du commerce électronique ne comporte qu'un seul enregistrement A :
[www.ecommerce.it](http://www.ecommerce.it) → 192.0.2.50
Il n'existe aucun enregistrement AAAA.
À ce stade, l'appareil doit accéder à une ressource disponible uniquement en IPv4.
Sur de nombreux réseaux mobiles modernes, cela se fait via des systèmes tels que le 464XLAT , normalisé par l'IETF dans la RFC 6877.
La norme 464XLAT combine une traduction côté client, appelée CLAT, avec une traduction côté opérateur, appelée PLAT. Cette dernière peut effectuer une traduction N:1, permettant ainsi à un plus grand nombre de sources IPv6 d'apparaître à travers un nombre beaucoup plus limité d'adresses IPv4 publiques.
Le résultat pratique est simple.
Facebook a peut-être communiqué avec :
2a01:xxxx:xxxx:xxxx::1234
tandis que le serveur web de commerce électronique enregistre :
93.45.120.38
Les deux adresses ne présentent aucune similitude évidente.
Et surtout, cette adresse IPv4 pouvait être partagée, via l'infrastructure de l'opérateur, avec de nombreux autres utilisateurs.
Cela signifie-t-il que Meta perd automatiquement des conversions ?
Non.
C'est probablement le point le plus important de tout l'article.
L'adresse IP n'est pas la seule donnée qui puisse être utilisée pour corréler les clics, les sessions et les événements de conversion.
Si l'infrastructure de suivi est correctement mise en place, Meta peut recevoir différents signaux.
Parmi ceux-ci, on trouve des identifiants dérivés des clics publicitaires, des cookies tels que _fbc e _fbp, l'agent utilisateur du navigateur, l'URL de l'événement, les identifiants de première partie, toutes les données client correctement normalisées et hachées le cas échéant, ainsi que l'adresse IP.
Dans le cas de l'API Conversions, une event_id partagé entre le pixel côté navigateur et l'événement côté serveur pour permettre la déduplication du même événement.
Un changement d'adresse IP entre la navigation sur Facebook et l'arrivée sur le site n'entraîne donc pas automatiquement une perte d'attribution.
Un utilisateur peut se connecter à Facebook depuis un réseau mobile, ouvrir le site via Wi-Fi, changer de réseau lors du paiement ou utiliser des technologies de confidentialité qui modifient l'adresse observable.
Un système publicitaire mondial ne peut raisonnablement reposer sur l'hypothèse que la propriété intellectuelle est immuable.
L'adresse IP doit être considérée comme l'un des signaux de correspondance , et non comme une clé primaire universellement stable.
Le problème survient lorsque, parallèlement à la discontinuité de l'adresse IP, d'autres signaux sont également perdus.
Pourquoi une adresse IPv4 partagée peut encore présenter un signal plus faible
Il existe toutefois une différence substantielle entre affirmer que l'adresse IP n'est pas le seul identifiant et soutenir que toute adresse IP possède la même qualité d'information.
Meta propose elle-même un guide extrêmement intéressant au sein de son projet officiel CAPI Parameter Builder.
En ce qui concerne la collecte des adresses IP des clients, la documentation recommande :
« Privilégiez IPv6 (plus précis qu'IPv4) ; utilisez IPv4 si IPv6 n'est pas disponible. »
En d'autres termes : privilégiez IPv6, car il est plus précis, en utilisant IPv4 comme solution de repli.
La raison technique est facilement compréhensible.
Une adresse IPv4 peut se trouver derrière un NAT de niveau opérateur et représenter simultanément plusieurs abonnés.
Une adresse IPv6 offre généralement une plus grande granularité du point de vue de la source réseau, tout en n'étant pas conçue comme un identifiant personnel permanent : les adresses IPv6 peuvent changer, il existe des extensions de confidentialité, des préfixes dynamiques et de nombreuses autres variables.
La recommandation de Meta est toutefois importante car elle démontre que, pour les besoins de leur système de collecte de métriques CAPI, l'IPv6 est considéré comme un signal préférable à l'IPv4 lorsqu'il est disponible.
Et cela rend moins négligeable le fait que l'hébergement exclusivement IPv4 puisse transformer un utilisateur initialement joignable via IPv6 en un visiteur observable par le site uniquement via une adresse IPv4 partagée.
L'API Pixel et Conversions peut même identifier deux familles d'adresses IP différentes.
Il existe un autre scénario qui rend la question encore plus intéressante.
Supposons que le commerce électronique utilise uniquement le protocole IPv4.
Le navigateur atteint :
www.ecommerce.it
via IPv4.
Une fois la page chargée, Meta Pixel est exécuté.
Le navigateur doit alors communiquer directement avec les infrastructures Meta, qui prennent en charge IPv6.
Rien n'empêche une telle situation de se produire :
Pour une même conversion, différentes observations de réseau peuvent donc exister simultanément.
Cela ne signifie pas forcément que quelque chose ne fonctionne pas. Meta possède les autres paramètres d'événement et, notamment avec une configuration Pixel + CAPI appropriée, la possibilité de dédupliquer et de corréler les informations.
Mais cela montre à quel point il est erroné de considérer le suivi moderne comme quelque chose qui dépend d'une seule adresse IP.
Le véritable problème se pose lorsque plusieurs signaux sont perdus simultanément.
Une infrastructure exclusivement IPv4 devient plus problématique lorsqu'elle est associée à d'autres erreurs d'implémentation.
Imaginons un utilisateur se connectant depuis Facebook via IPv6.
Vous cliquez sur l'annonce, mais une redirection mal configurée supprime les paramètres utilisés pour enregistrer la source du clic. Le système ne stocke pas correctement ces informations. _fbc. _fbp n'est ni collectée ni transmise au composant côté serveur. Il n'y en a pas external_idL'utilisateur n'étant pas encore authentifié, aucun autre identifiant déterministe n'est disponible pour l'intégration. Enfin, CAPI transmet uniquement l'agent utilisateur et une adresse IPv4 partagée provenant du CGNAT de l'opérateur.
À ce stade, la qualité de l'appariement peut être bien inférieure.
Non pas parce que l'IPv4 empêche techniquement le suivi, mais parce qu'il reste très peu de choses à faire correspondre.
La question pertinente à poser n'est donc pas :
« Un site sans IPv6 perd-il des conversions Facebook ? »
La question la plus correcte d'un point de vue technique est :
« Un site fonctionnant exclusivement en IPv4 peut-il éliminer ou rendre moins précis l'un des signaux qui contribuent à une attribution correcte des conversions ? »
La réponse à cette question est oui.
Attention aux redirections : perdre votre identifiant de clic est probablement pire que de changer d’adresse IP.
D'après notre expérience d'ingénieurs système, il est fréquent de se concentrer sur des outils complexes tout en oubliant des problèmes d'infrastructure beaucoup plus triviaux.
Un exemple est celui des redirections.
L'utilisateur accède à l'application depuis une campagne via une URL contenant les paramètres nécessaires à l'attribution. Avant d'y parvenir, il peut effectuer plusieurs étapes :
- HTTP → HTTPS ;
- domaine sans
www→ domaine avecwww; - page d'accueil → URL canonique ;
- système de suivi → commerce électronique ;
- Redirection d'application ou de plugin WordPress/WooCommerce.
Si l'un de ces composants construit mal l'URL et supprime la chaîne de requête, un signal extrêmement précieux peut disparaître avant même que le système de suivi ait eu la possibilité de le préserver.
Concrètement, un site e-commerce parfaitement à double pile avec une chaîne de redirection défectueuse peut avoir un suivi pire qu'un site e-commerce IPv4 uniquement avec une implémentation CAPI correcte.
L'IPv6 doit donc être considéré comme un élément d'une architecture correcte , et non comme une solution miracle.
Double pile : la solution la plus naturelle sur le plan technique
La configuration idéale pour un service web public moderne reste à double pile.
L'enregistrement A IPv4 et l'enregistrement AAAA IPv6 sont tous deux publiés dans le DNS.
Par exemple:
[www.example.com](http://www.example.com). A 192.0.2.10 [www.example.com](http://www.example.com). AAAA 2001:db8::10
Un client disposant d'une adresse IPv6 pourra se connecter en utilisant IPv6, tandis qu'un client ne disposant que d'une adresse IPv4 continuera d'utiliser IPv4 normalement.
Les systèmes d'exploitation et les navigateurs modernes implémentent des algorithmes appartenant à la famille Happy Eyeballs , formalisés dans la RFC 8305, qui interrogent A et AAAA et gèrent les tentatives de connexion à travers les différentes familles IP en essayant d'éviter les délais perceptibles par l'utilisateur et en privilégiant IPv6 lorsque cela est approprié.
Il n'est donc pas nécessaire de choisir entre les utilisateurs IPv4 et les utilisateurs IPv6.
Les deux sont proposés.
Pour un site de commerce électronique, cela signifie permettre à un smartphone qui communiquait déjà nativement en IPv6 avec Facebook ou Instagram de continuer à accéder à la boutique via IPv6, au lieu de l'obliger à passer par un mécanisme de compatibilité IPv4.
Il n'est pas nécessaire de disposer d'une adresse IPv6 à l'origine pour proposer une adresse IPv6 aux utilisateurs.
Ce point est particulièrement important car il permet de résoudre le problème même en présence d'infrastructures existantes.
Un site de commerce électronique peut être accessible publiquement via IPv6 même si le serveur d'origine reste exclusivement IPv4.
Il suffit d'un proxy inverse ou d'un CDN à double pile devant le serveur d'origine.
Cloudflare en est un exemple très populaire.
Lorsque la compatibilité IPv6 est activée, Cloudflare génère automatiquement une connectivité AAAA pour les enregistrements proxy, permettant ainsi aux clients IPv6 de se connecter à son réseau périphérique. Les connexions ultérieures entre Cloudflare et le serveur d'origine peuvent continuer à utiliser IPv4.
L'architecture devient alors :
Utente IPv6 → Cloudflare IPv6 → origin IPv4
Du point de vue de l'infrastructure interne, il n'est pas nécessaire de migrer immédiatement chaque serveur vers IPv6.
L'interface Internet devient à double pile tandis que le serveur peut continuer, au moins temporairement, à fonctionner sur IPv4.
Il s'agit d'une stratégie extrêmement utile lors d'une migration progressive.
Toutefois, le proxy inverse doit conserver la véritable adresse IP du visiteur.
Placer un CDN devant votre site e-commerce et oublier de configurer correctement l'adresse IP réelle peut entraîner un problème encore plus grave.
Le système dorsal pourrait en fait commencer à considérer l'adresse du proxy inverse comme l'adresse du visiteur.
En présence de Cloudflare, l'en-tête CF-Connecting-IP Elle contient généralement l'adresse du client qui s'est connecté au serveur Cloudflare. Si le client s'est connecté via IPv6, cette valeur peut être IPv6.
Le serveur web doit être configuré de manière à ce que les adresses provenant de proxys autorisés soient correctement traitées et que l'adresse IP d'origine soit rétablie.
Avec NGINX, cela se fait généralement via le module Real IP et une configuration conceptuellement similaire à :
real_ip_header CF-Connecting-IP; set_real_ip_from RETE_CLOUDFLARE; set_real_ip_from ALTRA_RETE_CLOUDFLARE;
Naturellement, les réseaux considérés comme fiables doivent être exclusivement les réseaux officiels du proxy utilisé et doivent être tenus à jour.
Une fois l'adresse IP réelle rétablie avec succès, l'application, PHP, la journalisation et le composant CAPI peuvent fonctionner sur l'adresse réelle du visiteur au lieu de l'adresse du CDN.
Il s'agit d'un détail d'infrastructure qui peut avoir des conséquences sur le suivi, la limitation du débit, les systèmes anti-fraude, la géolocalisation, la sécurité et l'analyse des journaux.
Attention également aux pseudo-IPv4
Cloudflare propose une fonctionnalité appelée Pseudo IPv4 , destinée aux applications anciennes qui ne peuvent pas traiter les adresses IPv6.
Il s'agit d'une fonctionnalité utile pour la maintenance de logiciels conçus exclusivement pour IPv4, mais elle doit être bien comprise.
Avec le mode Overwrite HeadersCloudflare peut remplacer CF-Connecting-IP e X-Forwarded-For avec une adresse pseudo-IPv4, en conservant la véritable adresse IPv6 dans l'en-tête CF-Connecting-IPv6.
Si l'application prend correctement en charge IPv6 et que l'objectif est de préserver au mieux les données sur le client, la transformation inutile de l'adresse IPv6 en une pseudo-adresse IPv4 n'offre aucun avantage.
Il est donc important de connaître toute la chaîne :
client → CDN → reverse proxy → web server → applicazione → tracking server-side
Un seul composant qui normalise ou remplace incorrectement l'adresse peut modifier les données envoyées ultérieurement aux plateformes publicitaires.
Meilleures pratiques pour le commerce électronique moderne
Une bonne architecture ne devrait pas s'appuyer sur un seul signal pour l'attribution.
Le site e-commerce doit être accessible en mode double pile, soit directement, soit via un CDN ou un proxy inverse double pile. L'adresse IP d'origine du visiteur doit être correctement préservée tout au long de la chaîne de proxys. Les paramètres des campagnes ne doivent pas être supprimés accidentellement lors des redirections et des canonisations.
_fbc e _fbpLorsque la configuration et le régime de consentement associé le prévoient, les données doivent être collectées et transmises correctement au composant côté serveur. Pixel et CAPI doivent utiliser une stratégie cohérente. event_id et la déduplication. Toutes les données de première partie utilisées pour la mise en correspondance doivent être gérées conformément aux spécifications de la plateforme et aux réglementations applicables.
Enfin, il est essentiel de vérifier que l'API CAPI reçoit bien l'adresse IP du client et non celle de NGINX, Varnish, HAProxy, Cloudflare, d'un équilibreur de charge interne ou du serveur d'application lui-même.
La qualité du suivi résulte de la combinaison de tous ces éléments.
Comment vérifier si votre site e-commerce est compatible IPv6
Le test le plus élémentaire consiste à vérifier le DNS.
Sous Linux :
dig A [www.example.com](http://www.example.com) dig AAAA [www.example.com](http://www.example.com)
Si la première commande renvoie une adresse IPv4 et que la seconde ne renvoie aucune adresse IPv6, le site est vraisemblablement accessible uniquement via IPv4.
Vous pouvez également effectuer un véritable contrôle HTTP :
curl -4 -I https://www.example.com/ curl -6 -I https://www.example.com/
Les deux devraient fonctionner sur une architecture frontale véritablement à double pile.
Au niveau de NGINX, sur un serveur directement exposé à Internet, on peut trouver par exemple des écouteurs IPv4 et IPv6 :
listen 443 ssl; listen [::]:443 ssl;
Bien sûr, avoir le listen L'IPv6 ne suffit pas : les serveurs, le routage, les pare-feu et le DNS doivent être correctement configurés.
Sur une infrastructure reposant sur un CDN, la vérification doit toutefois tenir compte du fait que l'interface publique et le serveur d'origine sont deux éléments distincts. Il est tout à fait normal que le site soit accessible publiquement en IPv6 tandis que le serveur d'origine n'accepte que les connexions IPv4 provenant du CDN.
L'IPv6 améliore-t-il directement les taux de conversion ?
La plus grande prudence est de mise ici.
Il n'existe aucune donnée fiable, du moins dans l'état de la documentation publique que nous avons analysée, qui nous permette d'étayer une telle hypothèse :
« L’activation d’IPv6 augmentera les conversions de 5 %. »
Ce serait une conclusion commercialement séduisante, mais techniquement infondée.
L'activation d'IPv6 ne convainc pas un client d'acheter un produit qu'il ne désire pas, et elle ne modifie pas directement le processus de vente.
Il existe toutefois une distinction fondamentale entre la conversion et la conversion attribuée.
Si dix personnes effectuent un achat, le magasin a réalisé dix conversions, indépendamment de ce qui apparaît dans Meta Ads Manager.
Si Meta ne peut en attribuer correctement que huit, du point de vue du système publicitaire, cela fait huit.
Les revenus réels n'ont pas disparu, mais l'ensemble de données utilisé pour mesurer et optimiser la campagne est devenu moins complet.
C’est dans ce second aspect que l’IPv6 peut jouer un rôle.
Le maintien d'une connectivité IPv6 native évite les traductions inutiles et préserve un signal que Meta elle-même affirme préférer à l'IPv4 lorsqu'il est disponible.
Cela ne signifie pas que l'IPv6 est indispensable pour les méta-annonces.
Cela signifie qu’une infrastructure moderne doit éviter de dégrader les informations disponibles sans raison technique valable de le faire.
L'IPv6 comme élément de la performance Web et pas seulement comme élément de réseau
Chez Managed Server, nous avons toujours considéré que les performances d'un site étaient le résultat de l'ensemble de l'infrastructure, et non pas simplement de la puissance du processeur ou de la quantité de RAM installée.
DNS, TCP, TLS, HTTP/2, HTTP/3, QUIC, CDN, mise en cache, serveur web, PHP, base de données et application contribuent tous à l'expérience finale.
IPv6 appartient à la même couche d'infrastructure.
Longtemps considérée comme un sujet réservé aux ingénieurs réseau, la question concerne aujourd'hui également les responsables de systèmes de commerce électronique, de publicité, d'analyse de données et de lutte contre la fraude.
Dans une architecture web moderne, nous ne devrions plus nous contenter de nous demander :
« Le site fonctionne-t-il ? »
Nous devrions nous poser la question suivante :
« Le site fonctionne-t-il correctement avec toutes les méthodes de connexion habituellement utilisées par ses utilisateurs ? »
Si une part importante des clients potentiels provient de smartphones dotés d'une connectivité IPv6 et que les principales plateformes publicitaires communiquent nativement via IPv6, il devient de plus en plus difficile de justifier le maintien d'une interface utilisateur exclusivement IPv4.
Un problème qui deviendra de plus en plus pertinent
L'IPv4 ne disparaîtra pas demain.
Une quantité considérable d'infrastructures, de logiciels et d'appareils continuera de l'utiliser pendant de nombreuses années encore.
La tendance est toutefois claire.
Les adresses IPv4 sont une ressource rare. Les réseaux des opérateurs utilisent de plus en plus l'IPv6 et les technologies de transition. Les principales plateformes Internet fonctionnent en double protocole depuis des années. Une part croissante d'utilisateurs est parfaitement capable de communiquer directement en IPv6.
Dans le même temps, selon W3Techs, en septembre 2026, moins d'un site sur trois dans l'ensemble de l'échantillon prenait encore en charge l'IPv6, tandis que parmi les sites les plus fréquentés, le pourcentage était nettement plus élevé.
C'est une photographie très claire de la phase de transition dans laquelle nous nous trouvons.
Les utilisateurs sont en avance sur certains aspects de l'infrastructure web.
Pour un petit site web institutionnel, cela peut paraître anodin. En revanche, pour un site de commerce électronique qui investit chaque mois des milliers, voire des dizaines de milliers d'euros en publicité, tout élément susceptible d'améliorer la qualité et la cohérence des données doit être évalué.
Conclusions
Le fait qu'un utilisateur navigue sur Facebook ou Instagram via IPv6 et accède ensuite à un site de commerce électronique fonctionnant uniquement en IPv4 n'empêche pas l'achat et n'entraîne pas automatiquement la perte de la conversion.
Le système d'exploitation et le réseau de l'opérateur vous permettent généralement d'atteindre le serveur IPv4 sans problème grâce à des mécanismes ou technologies à double pile tels que NAT64 et 464XLAT.
Cependant, le serveur de commerce électronique peut observer une adresse IPv4 différente de l'adresse IPv6 qu'il utilisait quelques instants auparavant pour communiquer avec Meta. Cette adresse IPv4 peut également être partagée avec de nombreux autres utilisateurs via un NAT de niveau opérateur.
Cela rend le signal réseau potentiellement moins précis.
Meta ne se base pas uniquement sur l'adresse IP et utilise une combinaison de signaux, c'est pourquoi une implémentation correcte de Pixel, de l'API Conversions, _fbc, _fbp, event_idL’agent utilisateur et les identifiants de première partie restent bien plus importants que la simple présence d’IPv6.
Mais la documentation technique officielle de Meta recommande elle-même de privilégier IPv6 car il est plus précis qu'IPv4 , en utilisant IPv4 comme solution de repli.
C’est pourquoi nous considérons également le dual-stack comme une bonne pratique pour le commerce électronique.
Dans la mesure du possible, l'interface publique doit accepter à la fois IPv4 et IPv6. Lorsque l'infrastructure d'origine est encore exclusivement IPv4, un CDN ou un proxy inverse double pile peut proposer l'IPv6 aux utilisateurs tout en communiquant avec le serveur via IPv4.
L'adresse IP réelle du visiteur doit alors être correctement préservée tout au long de la chaîne d'infrastructure et transmise au composant applicatif et aux systèmes côté serveur qui en ont légitimement besoin.
Il ne s'agit pas d'une astuce pour augmenter comme par magie les taux de conversion.
Nous parlons de la qualité des infrastructures, de la qualité des données et de la réduction des perturbations au sein d'un écosystème publicitaire de plus en plus complexe.
Et lorsqu'un site de commerce électronique investit des sommes importantes pour acquérir du trafic, disposer d'une infrastructure capable de préserver aussi fidèlement que possible les signaux générés par ce trafic ne doit pas être considéré comme un détail mineur.
Sources et références techniques
- Google, Statistiques d'adoption d'IPv6Google mesure en permanence la part de ses utilisateurs accédant à ses services via IPv6 ; en juin 2026, ce chiffre avait dépassé 50 %.
- Laboratoires APNIC, Mesure IPv6Statistiques mondiales et nationales sur la capacité et la préférence pour l'IPv6.
- W3Techs, Statistiques d'utilisation du protocole IPv6 pour les sites webStatistiques sur l'adoption de l'IPv6 par les sites web et leur répartition selon leur popularité, les CMS et les panneaux web.
- Moitié, Générateur de paramètres CAPI: Implémentation de référence qui recommande de privilégier l'adresse IPv6 du client par rapport à l'adresse IPv4 lorsqu'elle est disponible.
- IETF RFC 6877, 464XLAT : Combinaison de traduction avec et sans état: Décrit l'architecture utilisée pour fournir un accès aux ressources IPv4 sur les réseaux IPv6.
- IETF RFC 8305, Yeux Heureux Version 2: Décrit les algorithmes utilisés par les clients à double pile pour gérer les connexions IPv4 et IPv6 tout en réduisant les délais et les problèmes d'accessibilité.
- RIPE NCC, Expiration des adresses IPv4: Documentation de l'épuisement du pool IPv4 disponible dans la région RIPE en novembre 2019.
- Nuageux, Compatibilité IPv6, En-têtes HTTP, Pseudo IPv4 e Restauration des adresses IP d'origine des visiteurs: Documentation du frontend IPv6,
CF-Connecting-IP,CF-Connecting-IPv6et la gestion de l'origine IPv4.
