10 min de lectureConformité

Attribution sans cookie : ce qui fonctionne encore

Les cookies tiers disparaissent et ceux posés par script expirent vite. Quelles voies d'attribution tiennent, leur coût et où le consentement s'applique.

Sasha Ehrlich
Compliance · EU residency

L'attribution sans cookie fonctionne si vous cessez de demander au navigateur de mémoriser le clic. Enregistrez le clic sur un serveur, transportez un identifiant dans l'URL, stockez-le sur votre propre enregistrement de commande et envoyez la conversion de serveur à serveur. Tout le reste est dégradé ou juridiquement risqué dans l'UE. Cela comprend les cookies tiers, les cookies posés par script qui expirent en quelques jours et le fingerprinting.

La pile que la plupart des équipes ont bâtie entre 2012 et 2019 reposait sur un cookie tiers déposé sur la page d'atterrissage et sur un pixel qui le retrouvait sur la page de conversion. Pour les bases du terme, voir ce qu'est l'attribution marketing. Cet article est une carte de ce qui survit, de ce qu'Elido couvre aujourd'hui et de ce qui exige votre propre back-end.

En bref

  • Safari plafonne les cookies et le stockage écrits par script à 7 jours d'inactivité, et à 24 heures pour les cookies créés sur une page d'atterrissage dont le lien est décoré. Chrome autorise encore les cookies tiers, avec le choix de l'utilisateur. Considérez-les comme peu fiables dans les deux cas.
  • Deux voies tiennent : un identifiant de clic ou de lien transmis jusqu'à votre enregistrement de commande et envoyé de serveur à serveur, et les cookies first-party posés par le serveur.
  • Sans cookie ne veut pas dire sans consentement. L'article 5(3) d'ePrivacy atteint le fingerprinting et le stockage local, et le RGPD exige toujours une base légale pour le traitement côté serveur.
  • Elido enregistre les clics côté serveur et relie les revenus Stripe et Shopify aux liens. Il ne génère pas encore d'identifiants de clic et ne transmet pas les conversions aux plateformes publicitaires.

Ce qui a changé dans les navigateurs

Trois sources donnent le tableau actuel, toutes consultées le 2026-10-24.

La page de prévention du suivi de WebKit indique que Safari supprime les cookies créés en JavaScript, et les autres stockages inscriptibles par script, après 7 jours sans interaction de l'utilisateur avec le site. Elle précise aussi que, lorsqu'un identifiant de clic est détecté dans l'URL d'atterrissage, l'expiration des cookies créés en JavaScript sur cette page est plafonnée à 24 heures. ITP 2.3, publié le 23 septembre 2019, a étendu des limites similaires aux autres données inscriptibles par script. Les cookies définis dans un en-tête de réponse HTTP par votre propre hôte first-party ne sont pas plafonnés par ces règles. L'exception est un hôte tiers masqué, comme un sous-domaine masqué par CNAME ou par IP, pour lequel WebKit plafonne l'expiration à 7 jours.

Firefox partitionne les cookies tiers par site de premier niveau grâce à Total Cookie Protection. Un cookie posé par un traceur sur votre paiement et sur celui d'un concurrent devient deux cookies distincts.

Chrome n'a jamais mené la suppression à son terme. Le 22 avril 2025, Google a annoncé qu'il ne déploierait pas d'invite autonome pour les cookies tiers et que les utilisateurs continuent de choisir dans les paramètres. Le blog Privacy Sandbox ajoute que certaines technologies de Privacy Sandbox sont abandonnées. La question pratique n'est donc plus « quand les cookies mourront-ils » mais « quelle part de mon audience les bloque », et je ne peux pas vous donner de pourcentage honnête à l'échelle de l'UE. Vérifiez vos propres statistiques par navigateur.

Une affirmation de plus que vous verrez dans les présentations des éditeurs : la Link Tracking Protection de Safari supprimerait des identifiants de clic comme fbclid ou gclid en navigation privée et dans Mail. La page de prévention du suivi de WebKit ne la mentionnait pas quand je l'ai consultée, donc je ne reprends pas ici de liste de paramètres. Testez vos propres pages d'atterrissage dans ces contextes avant de compter sur la survie d'un identifiant de clic.

Les deux voies qui fonctionnent encore

Les deux partent du même fait : un serveur voit le clic avant que les règles de stockage du navigateur ne s'appliquent.

Voie 1 : identifiants côté serveur

Quand un utilisateur clique sur une annonce, la plateforme ajoute un identifiant de clic à l'URL d'atterrissage, par exemple fbclid pour Meta ou gclid pour Google. L'identifiant vit dans l'URL : le partitionnement des cookies n'y touche pas. Votre page d'atterrissage le lit et le stocke sur le panier ou la commande. Quand la commande est payée, votre back-end le relit sur la commande et envoie la conversion à l'API côté serveur de la plateforme, comme l'API Conversions de Meta ou le GA4 Measurement Protocol.

La déduplication compte si vous gardez aussi le pixel du navigateur. La documentation de Meta indique que l'eventID du Pixel doit correspondre à l'event_id de l'API Conversions, avec le même nom d'événement, et que les doublons reçus dans un délai de 48 heures sont écartés. Utilisez l'identifiant de commande pour les achats. Pour savoir quels champs client doivent être hachés, lisez la page des paramètres d'informations client de Meta ; je n'ai pas vérifié ces règles pour cet article.

Les points faibles sont réels. Effacer les cookies fait perdre un identifiant stocké dans un cookie. Une conversion sur un autre appareil n'a aucun lien sauf si la personne est connectée. L'identifiant de clic peut aussi disparaître avant que la page d'atterrissage ne le voie.

Voie 2 : une redirection que vous contrôlez

Une redirection sur votre propre domaine est un événement côté serveur. Quand quelqu'un clique sur un lien court de marque, l'hôte de redirection peut écrire un enregistrement de clic à cet instant, avec l'horodatage, le référent et le user agent, au lieu d'attendre le déclenchement d'une balise au chargement de page. Si vous posez aussi un cookie, faites-le dans l'en-tête Set-Cookie sur un hôte first-party. Cela évite les limites de 7 jours et de 24 heures des cookies écrits par script évoquées plus haut.

Un pixel ne peut pas reproduire cela. C'est aussi là que s'arrête le périmètre actuel d'Elido.

Deux colonnes : les mécanismes dégradés comme les cookies tiers, les cookies posés par script et le fingerprinting, face aux mécanismes qui fonctionnent encore comme les journaux de clics côté serveur, les identifiants de clic sur l'enregistrement de commande.

Ce que fait Elido aujourd'hui, vérifié dans le code

J'ai vérifié dans les services chaque affirmation que cet article faisait auparavant. Voici le résultat.

CapacitéStatut
Journal de clics côté serveur écrit quand la redirection est servieOui
Transmission des clics à GA4 (événement link_click), Mixpanel, Klaviyo, Brevo et DatadogOui, intégrations par espace de travail
Événements Meta et TikTok côté serveur au clicNon
Commandes Stripe et Shopify rattachées à un lien via elido_link_idOui
Revenus par lien, campagne, jour et plateformeOui
Identifiant elido_click ajouté à l'URL de destinationNon
Cookie first-party posé par la redirectionNon
API publique de conversions (POST /v1/conversions)Non
Transmission des conversions à Meta CAPI ou GA4 avec hachage et event_idNon

La version honnête de « un lien court comme surface d'attribution » est plus étroite que ce que cet article disait auparavant. La redirection vous donne un enregistrement de clic et des rapports par lien. Pour boucler la boucle sur les revenus, placez l'identifiant du lien dans la commande : elido_link_id dans les métadonnées Stripe, ou un attribut de note elido_link_id sur un panier Shopify. Quand le webhook de commande arrive, Elido attribue le revenu à ce lien. Tout le reste, comme hacher un e-mail et appeler l'API de Meta, est aujourd'hui du code dans votre back-end. Pour savoir comment construire cette diffusion, voir le suivi des conversions côté serveur via les liens courts, et pour l'angle propre à Safari, l'attribution des clics après Safari ITP. La page de la fonctionnalité de suivi des conversions décrit le côté tableau de bord.

Flux depuis un clic sur une annonce menant à un lien court, puis un journal de redirection côté serveur, une page d'atterrissage et un paiement, jusqu'à une commande portant l'identifiant du lien dans ses métadonnées, puis un webhook qui rapporte le revenu par lien

Rapprochement d'identités : ce qui marche et ce qui ne marche pas

Les identifiants côté serveur couvrent le cas courant. Une personne, un appareil, une session, aucun paramètre supprimé. Le reste exige un identifiant que la personne vous a donné.

La correspondance déterministe fonctionne. Si quelqu'un se connecte ou saisit un e-mail à un moment, vous pouvez envoyer un e-mail haché avec la conversion comme signal de correspondance. Le hachage doit suivre les règles de normalisation de la plateforme : lisez la page de l'éditeur avant de le construire.

Le fingerprinting probabiliste est le mauvais recours dans l'UE. Il combine taille d'écran, polices, fuseau horaire, rendu canvas et signaux similaires en un identifiant sans cookie. Savoir si cela exige un consentement est une question juridique, et l'article 5(3) de la directive ePrivacy s'applique à l'accès à des informations sur l'appareil de l'utilisateur, pas seulement aux cookies. La page EUR-Lex ne s'est pas chargée chez moi le 2026-10-24 ; je paraphrase donc d'après le champ d'application bien connu de la directive, sans la citer. Je ne nomme pas non plus ici de décisions précises d'autorités de contrôle. Les navigateurs axés sur la confidentialité continuent de réduire l'entropie sur laquelle ces méthodes reposent. La précision baisse là où vous en avez le plus besoin.

Le multi-appareil est l'écart que vous ne pouvez pas combler côté serveur. Un clic sur un téléphone et un achat sur un ordinateur portable ne se rejoignent que si la personne s'identifie sur les deux.

Le consentement s'applique toujours

« Pas de cookie, pas de consentement » est une erreur de lecture courante. L'article 5(3) concerne l'appareil : tout stockage ou accès à cet endroit exige un consentement, sauf s'il est strictement nécessaire. Un cookie posé pour l'analytique n'est pas strictement nécessaire du simple fait qu'il est first-party.

Le traitement côté serveur change le chemin des données. Les bloqueurs de publicités et le partitionnement n'y touchent pas, et vous contrôlez ce qui sort de votre back-end. Il exige toujours une base légale RGPD au titre de l'article 6, généralement l'intérêt légitime pour l'analytique au niveau de la campagne après évaluation, et c'est plus difficile pour le profilage individuel. Le guide RGPD pour les raccourcisseurs d'URL couvre les articles 6, 28 et 30, et le consentement aux cookies pour les liens courts traite de la question de la bannière.

Côté traitement de l'IP, Elido tronque l'IP du visiteur à l'edge (IPv4 à /24, IPv6 à /48) avant l'enregistrement du clic. Le pays, la région, la ville et les coordonnées approximatives sont dérivés d'abord et conservés avec le clic, et le user agent complet est stocké : traitez donc la ligne de clic comme des données personnelles. Si la minimisation compte pour votre DPA, demandez par écrit la durée de conservation et le traitement des IP actuels.

Ce à quoi vous renoncez

L'attribution côté serveur récupère l'essentiel du signal perdu, pas sa totalité.

Identité multi-appareil. Perdue, sauf si la personne se connecte.

Attribution après vue. Elle dépend de la capacité de la plateforme publicitaire à rattacher une impression à une conversion ultérieure à travers son propre graphe d'appareils. Attendez-vous à des chiffres plus bruités que dans les rapports fondés sur les clics.

Longues fenêtres de rétrospection. Chaque plateforme fixe ses propres fenêtres d'attribution, qui peuvent être plus courtes que les 28 ou 90 jours que certaines équipes utilisaient avec les cookies. Vérifiez la fenêtre actuelle de chaque plateforme sur laquelle vous reportez. Les abonnements et les cycles B2B sont les plus touchés.

Multi-touch pour les utilisateurs anonymes. Sans graphe d'identité, vous retombez sur le dernier clic. L'e-mail haché des utilisateurs connectés permet de reconstituer des séquences pour cette part de votre audience, avec les modèles à base de règles adaptés à vos données.

Une pile pratique

Pour une équipe qui achète du trafic payant vers l'UE, voici ce que je construirais avec ce qui existe aujourd'hui.

  1. Des liens courts de marque pour l'e-mail, les SMS, les QR codes et les publications organiques. Vous obtenez dès le départ un enregistrement de clic côté serveur et des rapports par lien. Gardez les publicités pointées sur l'URL de la page d'atterrissage elle-même : Elido abandonne les paramètres de requête ajoutés à un lien court, si bien que le fbclid ou le gclid d'une annonce ne survivrait pas à la redirection (la transmission est prévue, pas encore disponible).
  2. Capturer l'identifiant de clic de la plateforme à l'atterrissage (fbclid, gclid) et l'écrire dans le panier ou la commande. Testez qu'il survit dans Mail sur iOS et dans les onglets privés avant de lui faire confiance.
  3. Mettre elido_link_id dans les métadonnées Stripe ou les attributs de note Shopify pour que les revenus se rapportent par lien sans aucun cookie.
  4. Envoyer les achats de serveur à serveur depuis votre back-end vers Meta et GA4, avec l'identifiant de commande comme clé de déduplication.
  5. Hacher l'e-mail des utilisateurs connectés pour couvrir le multi-appareil et combler les trous quand l'identifiant de clic manque.
  6. Importer les conversions hors ligne par lots pour les longs cycles B2B ou d'abonnement, avec l'API hors ligne de la plateforme.

Rien de cela n'exige une CDP. Il faut un journal de clics fiable, un identifiant sur votre commande et un back-end qui dialogue avec les plateformes publicitaires.

À lire aussi sur le blog

Questions fréquentes

Qu'est-ce que l'attribution sans cookie ?

L'attribution sans cookie relie une conversion au clic ou à la campagne qui l'a provoquée, sans s'appuyer sur un cookie tiers. Concrètement : un journal de clics côté serveur, un identifiant de clic ou de lien transporté dans l'URL puis stocké sur votre propre enregistrement de commande, et des appels de serveur à serveur vers les plateformes publicitaires. Elle récupère l'essentiel de ce que les pixels du navigateur perdent, mais pas les parcours multi-appareils ni les longues fenêtres de rétrospection.

Les cookies tiers ont-ils disparu de Chrome ?

Non. Le 22 avril 2025, Google a indiqué qu'il ne déploierait pas de nouvelle invite autonome pour les cookies tiers dans Chrome, et que les utilisateurs continuent de choisir dans les paramètres de confidentialité de Chrome (blog Privacy Sandbox, consulté le 2026-10-24). Safari et Firefox les restreignent déjà par défaut : l'attribution qui repose sur eux est donc peu fiable pour une grande partie de votre trafic, quoi que fasse Chrome.

Se passer de cookies supprime-t-il le besoin de consentement dans l'UE ?

Non. L'article 5, paragraphe 3 de la directive ePrivacy couvre le stockage ou l'accès à des informations sur l'appareil de l'utilisateur, pas seulement les cookies : le fingerprinting et le stockage local sont donc concernés. Un traitement purement côté serveur sort de l'article 5(3), mais exige toujours une base légale RGPD. Demandez à votre propre conseil juridique ce qui s'applique à votre configuration.

Un cookie first-party posé par mon serveur échappe-t-il aux limites de Safari ?

En grande partie. La page de prévention du suivi de WebKit indique que les cookies et le stockage créés en JavaScript sont supprimés après 7 jours sans interaction de l'utilisateur, et qu'un cookie posé par script depuis une page d'atterrissage dont le lien est décoré dure 24 heures. Les cookies définis dans un en-tête de réponse HTTP sur votre propre hôte first-party ne sont pas plafonnés par ces règles, à l'exception des hôtes tiers masqués (cloaking), plafonnés à 7 jours.

Un raccourcisseur d'URL peut-il faire de l'attribution sans cookie ?

Il peut fournir la première moitié : un enregistrement de clic côté serveur écrit au moment où la redirection est servie, avant l'intervention de toute fonction de confidentialité du navigateur, plus des rapports par lien et par campagne. Elido rattache aussi les commandes Stripe et Shopify à un lien grâce à une valeur elido_link_id que vous placez dans les métadonnées de la commande. Il ne génère pas encore d'identifiants de clic et ne transmet pas les conversions à Meta ni à GA4 : ces étapes passent par votre propre back-end.

Que ne peut pas récupérer l'attribution sans cookie ?

Les parcours multi-appareils où la personne ne s'identifie jamais, les conversions après vue qui dépendent du graphe d'appareils propre à une plateforme publicitaire, et les clics plus anciens que la fenêtre de rétrospection de la plateforme. L'e-mail haché des utilisateurs connectés comble une partie de l'écart. Pour les visiteurs anonymes, le dernier clic est le plafond.

Essayer Elido

Collez une URL, obtenez un lien court

Sans inscription. Lien actif 30 jours. Inscrivez-vous pour le garder pour toujours.

Sans inscription. Créez un compte gratuit pour 50 liens par mois.

Essayer Elido

Raccourcisseur d'URL hébergé en UE : domaines personnalisés, analyses approfondies et API ouverte. Forfait gratuit - sans carte bancaire.

Tags
cookieless attribution
cookieless tracking
server side attribution
itp 2.3
third party cookie phase out
marketing attribution

Lire la suite