Pourquoi votre server-side GTM a besoin d'IPv6 (impact Meta CAPI)

Le problème que personne ne voit venir

Vous avez investi dans un GTM server-side. Vous avez connecté Meta CAPI. Votre Event Match Quality affiche un score correct dans le gestionnaire d'événements. Et pourtant, Meta peine à attribuer vos conversions correctement.

Le coupable est invisible : votre endpoint server-side ne parle qu'IPv4, alors qu'une part croissante de vos visiteurs arrive en IPv6.

Ce n'est pas une erreur technique spectaculaire. Aucune alarme ne se déclenche dans GTM, aucun message d'erreur dans Meta Events Manager. C'est une fuite silencieuse qui dégrade progressivement la qualité de vos données publicitaires, et donc le ROAS de vos campagnes Meta.

Pourquoi IPv6 est devenu critique en 2026

Le protocole IPv4 (les adresses du type 192.168.1.1) tire sur ses dernières réserves. Les opérateurs mobiles et les FAI basculent massivement vers IPv6, un format 128 bits capable d'adresser 340 undécillions d'appareils. En pratique, une part significative de vos visiteurs — particulièrement sur mobile — arrive déjà avec une adresse IPv6.

Ce basculement crée un problème précis pour votre infrastructure de tracking.

Quand un utilisateur sur un réseau IPv6 déclenche le pixel Meta sur votre site, Meta enregistre l'événement avec son adresse IPv6. Votre tag CAPI côté serveur est censé envoyer la version serveur de ce même événement, avec le paramètre client_ip_address correspondant, pour que Meta puisse dédupliquer les deux et améliorer la qualité de correspondance.

Le problème : si votre load balancer GTM server-side n'a qu'un frontend IPv4, la requête de cet utilisateur IPv6 passe par une translation d'adresse NAT64 avant d'atteindre votre conteneur sGTM. L'adresse IP que sGTM lit dans la requête entrante est une adresse IPv4 traduite. Votre tag CAPI la transmet fidèlement à Meta. Meta compare alors cette adresse IPv4 avec l'adresse IPv6 enregistrée par le pixel. Elles ne correspondent pas. La déduplication est dégradée, le score de correspondance chute.

Les symptômes à surveiller

Comment savoir si vous êtes affecté ? Plusieurs signaux :

• Score EMQ (Event Match Quality) en dessous de 7/10 dans Meta Events Manager, sans raison apparente côté données client
• Taux de déduplication faible : Meta reçoit des événements en double (pixel + CAPI) mais n'arrive pas à les fusionner
• Warnings sur le paramètre client_ip_address : Meta indique que les adresses IP reçues ne correspondent pas au format attendu
• Attribution instable entre vos campagnes Meta et vos données de vente réelles, sans explication côté budget ou créatif

Si vous cochez plusieurs de ces points, l'absence d'IPv6 sur votre endpoint sGTM est probablement en cause.

Comprendre la mécanique de l'échec

Voici ce qui se passe, étape par étape, quand un utilisateur IPv6 visite votre site avec un endpoint sGTM uniquement IPv4 :

1. L'appareil de l'utilisateur a l'adresse 2001:db8::1 (IPv6).
2. Le pixel Meta côté client se déclenche. Meta enregistre l'événement avec client_ip_address: 2001:db8::1.
3. Le navigateur envoie une requête à votre endpoint sGTM pour déclencher l'événement CAPI.
4. Votre endpoint sGTM n'a pas de frontend IPv6. L'appareil de l'utilisateur se connecte via NAT64, qui traduit l'adresse source en quelque chose comme 192.0.2.1.
5. sGTM lit 192.0.2.1 depuis le header X-Forwarded-For.
6. Le tag CAPI envoie client_ip_address: 192.0.2.1 à Meta.
7. Meta compare 192.0.2.1 avec 2001:db8::1. Pas de correspondance. La déduplication est incomplète.

Avec un load balancer dual-stack (IPv4 + IPv6), l'étape 4 change radicalement : l'utilisateur se connecte nativement en IPv6, l'adresse arrive dans sGTM sans traduction, et le tag CAPI envoie la valeur correcte. Meta fait correspondre les événements proprement.

La solution : activer le dual-stack sur votre infrastructure server-side

La bonne nouvelle : corriger ce problème est moins complexe qu'il n'y paraît. La solution consiste à donner à votre load balancer un frontend dual-stack — une adresse IPv4 (déjà en place) et une adresse IPv6. Le serveur Cloud Run lui-même n'a pas besoin d'être modifié : la terminaison IPv6 se fait au niveau du load balancer, qui continue de transmettre le trafic à Cloud Run en IPv4 en interne.

Pour les déploiements sur Google Cloud (self-hosted)

Si vous gérez votre propre infrastructure GTM server-side sur Google Cloud Run, le processus se décompose en cinq étapes clés selon la documentation de Simo Ahava :

Réserver une adresse IPv6 statique externe dans la console GCP (VPC Network > IP addresses). Choisir le type Global et la version IPv6.

Ajouter un enregistrement DNS AAAA chez votre fournisseur DNS pour votre sous-domaine sGTM (ex: sst.votredomaine.com), pointant vers l'adresse IPv6 réservée. Conserver l'enregistrement A existant — l'objectif est le dual-stack, pas de remplacer l'IPv4.

Créer un Certificate Map dans Google Cloud Certificate Manager et une nouvelle entrée liant votre certificat SSL au sous-domaine concerné. Google Cloud a migré vers ce système pour la gestion des certificats multi-frontends.

Ajouter un frontend IPv6 sur le load balancer existant (Network Services > Load balancing), en sélectionnant l'adresse IPv6 réservée et le certificate map créé. Le backend et les règles de routage n'ont pas besoin d'être dupliqués.

Vérifier via dig AAAA que les deux types d'enregistrements resolvent correctement, et que les connexions IPv6 arrivent bien à votre container.

Pour les déploiements via Addingwell ou Stape

Si vous passez par un hébergeur managé pour votre GTM server-side, la démarche est différente — et souvent plus simple.

Addingwell est notre recommandation principale pour les PME françaises qui veulent un GTM server-side sans gestion d'infrastructure. Hébergeur français, support en français, interface pensée pour des équipes sans DevOps. La configuration IPv6 est gérée au niveau de leur plateforme.

Stape supporte nativement IPv6 sur l'ensemble de ses serveurs (Stape Global et Stape Europe). L'adresse IPv6 est transmise automatiquement via le Stape GTM Data Tag, sans configuration manuelle côté client. Si vous êtes déjà sur Stape, vérifiez que votre Data Tag est activé et correctement configuré.

Dans les deux cas, contactez le support de votre hébergeur pour confirmer que le passage des adresses IPv6 vers vos tags CAPI est bien activé sur votre compte.

Configurer Meta CAPI pour exploiter l'IPv6

Activer IPv6 sur le load balancer ne suffit pas si votre implémentation CAPI ne transmet pas correctement le paramètre client_ip_address. Voici les points à vérifier dans votre conteneur server-side :

Le tag Facebook Conversions API (template officiel disponible dans la galerie GTM) lit automatiquement l'adresse IP depuis le header X-Forwarded-For. Si votre load balancer transmet correctement l'adresse IPv6 dans ce header, le tag l'enverra à Meta sans configuration supplémentaire.

Si vous avez une implémentation personnalisée ou un forwarding configuré manuellement, vérifiez que le paramètre client_ip_address contient bien l'adresse IP de l'utilisateur final — et non une adresse interne ou traduite.

Pour les cas où l'adresse IP ne remonte pas automatiquement, la documentation de TagDataTrust recommande une approche complémentaire : pousser l'adresse IP dans le dataLayer côté application (idéalement déjà au format IPv6), la récupérer via une variable Event Data dans GTM server-side, et l'injecter via une Transformation de type Augment Event avec la clé ip_override.

Ce que ça change concrètement sur vos campagnes

Un meilleur score EMQ n'est pas qu'un indicateur technique. Il a des effets directs sur vos performances publicitaires :

• Meilleure déduplication : Meta évite de compter deux fois la même conversion (pixel + CAPI), ce qui donne une image plus précise de votre CPA réel
• Attribution plus fiable : les événements bien matchés améliorent la capacité de Meta à optimiser la diffusion vers les profils les plus susceptibles de convertir
• Signal plus fort pour l'apprentissage de l'algorithme : Meta Advantage+ et les stratégies d'enchères automatiques performent mieux avec des données d'événements cohérentes
• Réduction des avertissements dans Meta Events Manager, qui signalent aux annonceurs des problèmes de qualité de données pouvant affecter la confiance dans les résultats rapportés

En d'autres termes : corriger l'IPv6 sur votre endpoint sGTM, c'est directement améliorer la qualité du signal que vous donnez à Meta pour optimiser vos budgets publicitaires.

Votre checklist de mise en conformité IPv6

Avant de clore ce sujet, passez en revue ces points :

• Mon endpoint GTM server-side répond-il aux requêtes IPv6 ? (test via dig AAAA votre-sous-domaine.com)
• Mon load balancer a-t-il un frontend dual-stack (A + AAAA en DNS) ?
• Mon hébergeur sGTM (Addingwell, Stape) confirme-t-il le support IPv6 ?
• Mon tag Meta CAPI transmet-il bien le paramètre client_ip_address avec la vraie IP de l'utilisateur ?
• Mon score EMQ dans Meta Events Manager est-il supérieur à 7/10 ?
• Le taux de déduplication pixel/CAPI est-il supérieur à 80% dans mon gestionnaire d'événements ?

Si vous répondez non à l'un de ces points, une partie de votre signal publicitaire est aujourd'hui perdue.

Conclusion

L'IPv6 n'est pas un sujet d'infrastructure purement technique. C'est un levier direct sur la qualité de votre tracking Meta et, par extension, sur l'efficacité de vos investissements publicitaires. En 2026, avec la croissance continue du trafic IPv6 — notamment mobile — ignorer ce paramètre revient à laisser Meta travailler avec des données partielles.

La correction est accessible : si vous utilisez Addingwell ou Stape, commencez par contacter leur support pour vérifier la configuration. Si vous gérez votre propre infrastructure Cloud Run, le processus décrit par Simo Ahava vous guidera étape par étape sans toucher à votre conteneur sGTM.

Chez Data Detective, on audite régulièrement des stacks server-side où ce problème passe sous le radar depuis des mois. Si vous avez un doute sur la qualité de votre signal CAPI, c'est le premier point à vérifier.

Sources et ressources complémentaires

• Add IPv6 Support To Your Server-side GTM Load Balancer — Simo Ahava (mars 2026)
• Update to IPv6 for Facebook events with Stape — Stape Blog
• Implement Facebook CAPI Tracking with Google Tag Manager — TagDataTrust
• Documentation officielle Meta CAPI — Customer Information Parameters
• Guide officiel Google Tag Manager Server-side Setup — Google Developers
• Facebook Event Match Quality — Stape Blog