Cookies first-party, ITP et ATT : pourquoi la durée de vie efface votre attribution

L’arithmétique que personne ne fait

Posez deux chiffres côte à côte : votre cycle d’achat moyen entre le premier clic et la conversion, et la part de votre trafic sur Safari et iOS.

Maintenant la mécanique : sur Safari, un cookie first-party posé en JavaScript, ce que font la plupart des outils de mesure et de tracking Google Ads, vit 7 jours maximum.

Et si le visiteur est arrivé par un lien décoré d’un tracker connu, un clic publicitaire typiquement, ce plafond tombe à 24 heures (à jour au 12/06/2026).

Croisez : un cycle de trois semaines, une part Safari significative, et une fraction entière de vos conversions arrive après la mort du cookie qui aurait dû la relier au clic. Ces conversions existent, elles sont comptées... en « trafic direct ».

Sur Safari, votre attribution a une date de péremption : sept jours. Vingt-quatre heures après un clic payé.

Le symptôme que vous avez déjà vu sans le nommer

Cette mécanique a deux visages en réunion, et ils passent presque toujours pour des faits de marché. « Le direct monte », célébré comme un signe de notoriété, alors qu’une part en est l’artefact : des parcours payés dont le fil s’est rompu en route. « Les campagnes d’amont sous-performent », et on les coupe, alors qu’elles initient des conversions que la péremption attribue au néant.

Vous reconnaissez la logique de la page attribution : on ampute l’amont sur la foi du seul récit disponible, sauf qu’ici le récit n’est même pas une convention de modèle, c’est un trou technique. Avant toute conclusion stratégique sur « le direct qui monte », la question d’hygiène : quelle part vient de Safari, sur des cycles longs ?

Côté applications, l’ATT joue la partition voisine depuis iOS 14.5 : le suivi inter-apps exige un opt-in explicite, que la majorité décline (à jour au 12/06/2026). Si votre acquisition passe par l’app, la mesure y est structurellement partielle, même famille de trous, autre terrain.

À côté de ces plafonds navigateur, une autre famille de pertes vient des bloqueurs et du routage : la donnée n’est plus tronquée par péremption, elle est interceptée avant même d’arriver.

Ce qui résiste, et pourquoi c’est toujours la même réponse

Le mythe à corriger d’abord : « le first-party est épargné ». Non, le first-party posé en JavaScript est plafonné comme on vient de le voir. Ce qui résiste, c’est le first-party posé côté serveur (en-tête HTTP) : largement épargné par les plafonds JS .

Relisez le bloc server-side de cette branche avec cette donnée : poser le cookie en HTTP suppose une mécanique serveur, et c’est précisément le rôle d’un GTM server-side hébergé sur GCP ou Stape.

L’allongement de durée de vie n’est pas un bénéfice abstrait : pour les cycles longs sur Safari, c’est la différence entre une attribution et un trou.

Les deux autres réponses, vous les connaissez : le rapprochement par identité, où le principe des enhanced conversions tient à ce que l’e-mail survit là où le cookie meurt, et l’aval importé (le CRM ignore les navigateurs).

La branche entière converge : quand le fil technique casse, on attache la mesure à quelque chose de plus durable que lui.

Quant à Chrome : la déprécation des cookies tiers y a été abandonnée en 2024, sans prompt dédié depuis avril 2025, en modèle « choix utilisateur » (à jour au 12/06/2026).

Pas de falaise côté Chrome, une érosion continue partout, que le cadre légal du ciblage, RGPD et DMA en tête, prolonge sur le terrain du droit plutôt que sur celui du navigateur.

La décision

Votre exposition se calcule en dix minutes : part Safari/iOS dans vos rapports × cycle d’achat moyen. Exposition faible, classez, relisez dans un an.

Exposition réelle, la priorité est déjà écrite dans la branche : pose serveur, enhanced conversions, imports d’aval, dans l’ordre d’effort croissant. Et dès demain, en réunion : la prochaine fois qu’on célèbre « le direct qui monte », posez la question de la péremption.

Questions fréquentes