Comment le cookie syncing associe les ID publicitaires d'un site à l'autre

Qu'est-ce que le cookie syncing ?

Les entreprises ad tech utilisent le cookie syncing pour faire correspondre l'ID qu'une entreprise conserve dans votre navigateur avec l'ID qu'une seconde entreprise conserve pour ce même navigateur, afin que les deux puissent traiter leurs deux fiches comme une seule personne. Chaque entreprise dépose son propre cookie tiers depuis son propre domaine, et le navigateur ne laisse pas un domaine lire le cookie d'un autre domaine. Le cookie syncing contourne cette règle en transmettant l'ID dans une URL au lieu de lire directement le cookie.

Google en donne la raison dans son guide Authorized Buyers : "the security model of internet browsers restricts one from reading a cookie set by another domain." Son service de cookie matching existe pour qu'un enchérisseur puisse associer son propre cookie à "a corresponding bidder-specific Google User ID", que Google décrit comme "an encrypted form of the doubleclick.net cookie." Le secteur appelle la même chose cookie matching, ID syncing ou user matching.

Si vous gérez un site web, le cookie syncing se produit sur vos pages dès que vous chargez un tag publicitaire, un pixel de retargeting ou un conteneur de tag manager qui charge l'un ou l'autre. Votre propre analytics ne voit jamais les ID associés. Les entreprises publicitaires, si.

Comment fonctionne le cookie syncing, étape par étape ?

Le cookie syncing fonctionne par une chaîne de requêtes HTTP qu'un pixel déclenche et qu'une redirection termine, avec l'ID utilisateur d'une entreprise inscrit dans l'URL que suit le navigateur. Le guide de cookie matching de Google documente ce flux pour ses partenaires Real-Time Bidding, et les autres réseaux publicitaires appliquent le même schéma :

1. Un tag de correspondance se charge. Une page ouverte par le visiteur contient un pixel d'un enchérisseur qui envoie le navigateur vers le Cookie Matching Service de Google. Le navigateur transmet à Google son cookie doubleclick.net avec cette requête.
2. Google redirige. Google répond par une redirection HTTP 302 vers l'URL de cookie matching de l'enchérisseur et place le Google User ID propre à cet enchérisseur dans un paramètre google_gid.
3. L'enchérisseur lit les deux ID. Le navigateur suit la redirection vers le domaine de l'enchérisseur, qui reçoit son propre cookie dans les en-têtes de la requête et l'ID de Google dans l'URL.
4. La paire entre dans une table de correspondance. L'enchérisseur stocke l'association dans sa propre table de correspondance, ou envoie son propre ID à Google dans un paramètre google_hm pour que Google héberge la table.
5. Les requêtes d'enchère portent la correspondance. Les requêtes d'enchère suivantes pour ce navigateur incluent les données associées de l'enchérisseur, qui sait ainsi que l'impression appartient à un utilisateur dont il possède un profil.

Google exécute aussi le flux en sens inverse avec un paramètre google_push : Google place le tag et l'enchérisseur redirige vers Google pour terminer la correspondance. Le visiteur ne voit rien de tout cela. Le pixel est une image 1x1 ou une requête invisible, la même brique de base que celle décrite dans le guide sur les spy pixels.

Pourquoi les entreprises ad tech ont-elles besoin du cookie syncing ?

Les entreprises ad tech ont besoin du cookie syncing parce que chacune ne reconnaît un navigateur que par son propre cookie, et qu'une enchère en temps réel exige que l'acheteur et le vendeur s'accordent sur l'identité du visiteur en quelques millisecondes. Imaginons qu'un data broker connaisse un navigateur sous a91f, une plateforme d'échange sous 7c2e et un enchérisseur sous 55d0. Sans table de correspondance, l'enchérisseur ne peut pas savoir que l'impression proposée appartient à la personne qui a abandonné un panier sur un autre site la veille.

Chaque synchronisation ajoute une entreprise de plus qui détient un ID pour le même navigateur. C'est pourquoi le cookie syncing est au cœur du suivi intersites, et pourquoi le guide sur la façon dont les data brokers collectent des informations personnelles le cite aux côtés des pixels et des SDK comme source de données de comportement en ligne. Un tag de synchronisation sur une page d'actualité se propage à tous les partenaires avec lesquels le propriétaire du tag se synchronise, et chacun d'eux connaît désormais le même navigateur sous la même clé.

Qu'ont fait Safari et Firefox contre le cookie syncing ?

Safari et Firefox ont cassé le cookie syncing à la base en coupant le cookie tiers dont dépend chaque étape de la chaîne de redirections. La correspondance ne fonctionne que si le propre cookie de l'enchérisseur arrive avec la requête redirigée, et les deux navigateurs l'empêchent par défaut.

WebKit appelle ce schéma de redirection "tracker collusion." Dès qu'un domaine est classé comme traqueur, "a check is made to see which other domains have previously redirected to" lui, "and all of them get classified too." Un domaine classé avec lequel l'utilisateur n'a pas interagi en tant que first party au cours des 30 derniers jours d'utilisation du navigateur voit toutes ses données de site supprimées.

Mozilla décrit l'approche de Firefox plus simplement : tout cookie déposé par un site web ou un contenu intégré "is confined to the cookie jar assigned to only that website." Un enchérisseur obtient toujours un cookie, mais c'est un cookie différent sur chaque site, soit l'inverse de ce dont une synchronisation a besoin. Le guide des cookies partitionnés CHIPS explique comment Chrome propose le même modèle partitionné aux sites qui l'activent.

Le cookie syncing fonctionne-t-il encore dans Chrome ?

Le cookie syncing fonctionne encore dans Chrome pour tout utilisateur qui n'a pas bloqué les cookies tiers, parce que Google a choisi de garder les cookies tiers comme réglage utilisateur. Dans un billet du 22 avril 2025, le responsable de la Privacy Sandbox chez Google, Anthony Chavez, a écrit que Chrome allait "maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies." Les utilisateurs choisissent une option dans les paramètres Privacy and Security de Chrome, et la page d'aide de Chrome indique "by default, third-party cookies are blocked in Incognito mode."

Google a ensuite retiré l'essentiel de la technologie de remplacement. Une mise à jour du 17 octobre 2025 a listé les API Privacy Sandbox retirées, dont Topics, Protected Audience, l'Attribution Reporting API et les Related Website Sets, en invoquant "their low levels of adoption." CHIPS et FedCM restent.

Pour un propriétaire de site, tout tag publicitaire ou de retargeting que vous chargez dans Chrome peut toujours synchroniser des ID avec ses partenaires. Retirer le tag est le seul moyen d'arrêter cela sur vos pages.

Comment un propriétaire de site peut-il voir le cookie syncing sur ses propres pages ?

Un propriétaire de site voit le cookie syncing en ouvrant le panneau réseau du navigateur sur sa propre page et en cherchant des chaînes de redirections entre domaines publicitaires qui portent des ID dans la query string. Chargez une page avec des tags publicitaires ou de retargeting dans Chrome avec les cookies tiers autorisés, ouvrez DevTools, filtrez sur "Img" ou "Doc" et triez par domaine.

Les signes d'une synchronisation :

• Une requête vers un domaine publicitaire qui renvoie un statut 302 avec un en-tête Location pointant vers un autre domaine publicitaire.
• Des paramètres de requête nommés comme uid, gid, buyeruid, partner_uid ou google_gid qui contiennent une longue valeur aléatoire.
• Un GIF 1x1 ou une réponse vide au bout de la chaîne.
• La même chaîne qui se déclenche à chaque page vue, et non une fois par visite.

Refaites ensuite la vérification dans Safari. Le Privacy Report de Safari liste les traqueurs connus qu'il a empêchés de profiler le visiteur, et le guide du rapport de confidentialité de Safari explique comment le lire. L'écart entre les deux navigateurs vous montre combien de partenaires vos tags font entrer.

Pourquoi l'analytics first-party n'a-t-il pas besoin du cookie syncing ?

L'analytics first-party n'a pas besoin du cookie syncing parce qu'il ne compte que les visites du site sur lequel il est installé, il n'y a donc aucune seconde entreprise dont il devrait associer l'ID. Une page vue, un référent, un objectif et un achat appartiennent tous à un seul site web. L'outil d'analytics doit distinguer une session d'une autre sur ce site, pas reconnaître le même navigateur sur un blog de recettes et dans un magasin de chaussures.

Flowsery est conçu pour cette mission plus étroite. Le script de suivi Flowsery fonctionne sans cookies avec un hash de visiteur renouvelé chaque jour et ne collecte aucune donnée personnelle, et en mode sans cookies les ID de visiteur changent chaque jour, donc Flowsery ne relie pas un visiteur anonyme d'un jour à l'autre ni d'un appareil à l'autre. Flowsery affirme ne jamais vendre ni partager les données d'analytics et ne collecter aucune empreinte de navigateur. Pour les utilisateurs connectés, l'appel identify() de Flowsery rattache l'ID utilisateur que vous détenez déjà, et l'attribution des revenus relie un paiement Stripe, Paddle, Polar, Lemon Squeezy ou Shopify à la session qui a converti. Aucune de ces étapes ne fait intervenir l'ID d'un partenaire publicitaire. La page sur le suivi sans cookies montre comment les sessions sont regroupées à l'aide de hashs salés.

Questions fréquentes

Le cookie syncing est-il la même chose que le cookie matching ?

Oui. La documentation Authorized Buyers de Google l'appelle cookie matching, et le secteur parle aussi d'ID syncing et de user matching. Ces quatre noms décrivent le même échange d'ID par redirection entre deux domaines ad tech.

Le cookie syncing a-t-il besoin des cookies tiers ?

Oui, le flux classique par redirection a besoin que le cookie tiers de l'enchérisseur arrive avec la requête redirigée. Safari bloque tous les cookies tiers et Firefox les cloisonne par site, donc l'enchérisseur n'obtient soit aucun cookie, soit un cookie propre au site. Chrome envoie toujours les cookies tiers pour les utilisateurs qui ne les ont pas bloqués.

Puis-je arrêter le cookie syncing sur mon site ?

Vous arrêtez le cookie syncing sur vos propres pages en retirant les tags publicitaires, de retargeting et de data brokers qui le déclenchent. Une bannière de consentement qui bloque ces tags jusqu'à ce que le visiteur accepte arrête aussi les synchronisations pour les visiteurs qui refusent. Votre outil d'analytics n'a aucun réglage qui désactive la synchronisation pour des tags qu'il ne contrôle pas.

Le cookie syncing relève-t-il des données personnelles au sens du RGPD ?

Un ID synchronisé est un identifiant en ligne qui isole un navigateur d'un site à l'autre, ce qui en fait une donnée personnelle au sens du RGPD. Dans l'UE, déposer et lire les cookies qui le sous-tendent exige un consentement en vertu des règles ePrivacy. Le partager avec des partenaires exige aussi une base légale pour chaque destinataire.

Chrome a-t-il bloqué les cookies tiers ?

Non. Le billet de Google du 22 avril 2025 indique que Chrome continuera de proposer le choix des cookies tiers dans ses paramètres et ne déploiera pas d'invite autonome. Chrome ne bloque les cookies tiers par défaut qu'en mode Incognito.

Flowsery synchronise-t-il des cookies avec des réseaux publicitaires ?

Non. Flowsery mesure le trafic de votre propre site, affirme ne jamais vendre ni partager les données d'analytics, et son mode sans cookies utilise un hash de visiteur renouvelé chaque jour, sans donnée personnelle. Flowsery n'a aucun ID de partenaire publicitaire à associer.

Qu'est-ce qu'une table de correspondance dans le cookie syncing ?

Une table de correspondance est la liste où une entreprise ad tech enregistre quel identifiant à elle va avec quel identifiant d'un partenaire. Le bidder la construit après la redirection, quand il a vu son propre cookie et l'identifiant du partenaire dans la même requête. Dans le flux de Google, le bidder peut aussi renvoyer son identifiant dans un paramètre google_hm pour que Google héberge la table.

Comment vérifier si mon site fait du cookie syncing ?

Ouvrez les DevTools de Chrome avec les cookies tiers autorisés, chargez une page avec des balises publicitaires ou de retargeting et filtrez sur "Img" ou "Doc". Cherchez une réponse 302 dont l'en-tête Location pointe vers un autre domaine publicitaire, et des paramètres comme uid, gid ou google_gid avec une longue valeur aléatoire. Un GIF de 1x1 au bout de la chaîne est un autre signe de synchronisation.

Safari bloque-t-il le cookie syncing ?

Safari bloque le cookie dont dépend la synchronisation. L'ITP de WebKit bloque tous les cookies tiers sans exception, donc la redirection arrive chez le bidder sans son cookie et il n'y a rien à faire correspondre. Safari classe aussi les domaines qui redirigent entre trackers, ce qui range chaque domaine de la chaîne dans la classification.

Le cookie syncing fonctionne-t-il en navigation privée ?

L'aide de Chrome indique que les cookies tiers sont bloqués par défaut en navigation privée. Le cookie du bidder n'arrive alors pas avec la requête redirigée, et la synchronisation classique n'a rien à faire correspondre tant que l'utilisateur ne change pas ce réglage.