Cookies propriétaires, ITP et ATT : ce que Safari limite vraiment

En bref

Safari n’efface pas automatiquement l’attribution. WebKit limite à sept jours sans interaction les stockages accessibles aux scripts ; d’autres règles visent certaines décorations de liens, les traceurs connus et les montages CNAME. Dans une application, ATT encadre le suivi entre les applications et les sites d’autres entreprises : il ne bloque pas toute mesure.

La technique ne détermine pas ce que vous avez le droit de collecter. En France, les traceurs non nécessaires relèvent d’abord de l’article 82 de la loi Informatique et Libertés, puis les informations sur les utilisateurs restent soumises aux principes du RGPD : finalité, base légale, transparence, minimisation, durée de conservation, sécurité et encadrement des sous-traitants. Le cadre RGPD et DMA du ciblage publicitaire doit donc être lu avec précision : le DMA impose des obligations à certains contrôleurs d’accès, il ne remplace pas le droit commun des traceurs ni l’information prévue dans la politique de confidentialité.

Une perte de signal ne devient pas automatiquement du trafic direct

L’effet dépend du paramètre reçu, du stockage, du consentement, de la fenêtre d’attribution et de la modélisation. Un serveur ne conserve que le signal encore transmis par le navigateur.

Commencez par reconstruire la chaîne : le paramètre de clic a-t-il atteint votre serveur, quel stockage a été écrit, quel consentement était disponible, quelle fenêtre d’attribution s’applique et la conversion finale a-t-elle été observée ou modélisée ? La part Safari et le délai d’achat ne suffisent pas à répondre.

WebKit supprime après sept jours sans interaction avec le site les cookies créés en JavaScript et les autres stockages accessibles aux scripts. Cette règle peut affecter des outils de mesure et de suivi Google Ads, mais elle ne décrit ni tous les cookies propriétaires ni toutes les visites Safari.

Une autre règle peut plafonner à vingt-quatre heures un cookie JavaScript créé sur la page d’arrivée après une navigation décorée depuis un domaine que WebKit a classé comme capable de suivi intersites. Cette condition précise ne doit pas devenir une durée universelle « post-clic ».

Quand l’identifiant n’est plus disponible à la conversion, le résultat dépend du dispositif. Google Ads peut attribuer ou modéliser certaines conversions ; Google Analytics applique ses propres règles de session et d’événement ; un outil interne peut laisser la source vide. Une hausse du canal « direct » est donc une hypothèse à tester, pas l’issue automatique d’ITP.

ITP (Intelligent Tracking Prevention)
Ensemble de protections de WebKit contre le suivi intersites. Il encadre notamment les stockages accessibles aux scripts, la décoration de liens et les montages qui masquent un tiers derrière un domaine propriétaire. Chaque règle possède ses propres conditions.

Safari 17+ et la protection contre le suivi par lien

La protection avancée contre le suivi et les empreintes est active par défaut en navigation privée et l’utilisateur peut l’étendre à toute sa navigation. Elle ajoute notamment la suppression de paramètres connus et le blocage de chargements vers des traceurs identifiés. Elle ne retire pas indistinctement tous les paramètres de campagne.

La protection contre le suivi par lien retire une liste de paramètres associés au suivi intersites avant la navigation. Le paramètre supprimé n’atteint alors ni la page ni le serveur de destination. Aucun conteneur côté serveur ne peut le « récupérer » après coup. WebKit précise en revanche qu’un paramètre servant uniquement à l’attribution d’une campagne peut rester transmis.

Si l’identifiant atteint encore le domaine, un point de collecte propriétaire, par exemple un GTM côté serveur sur GCP ou Stape, peut réduire la dépendance au JavaScript et transmettre un événement observé. Il ne recrée pas un identifiant déjà retiré et ne neutralise ni les règles du navigateur ni le consentement.

Quand une requête vers un traceur connu est bloquée

En navigation privée, Safari bloque des chargements réseau présents à la fois dans plusieurs listes de traceurs connues, y compris certains domaines masqués par CNAME. Cela ne permet pas d’affirmer que Google Tag Manager est toujours bloqué : il faut observer les requêtes réellement émises avec la version de Safari, le mode de navigation et la configuration concernés.

Protection Condition documentée Effet possible Contrôle utile
Stockages accessibles aux scripts Sept jours d’utilisation de Safari sans interaction avec le site Cookie JavaScript, stockage local et autres données de site supprimés Type de stockage, dernière interaction et continuité de l’identifiant
Décoration de lien classée Navigation depuis un domaine classé et création d’un cookie JavaScript sur l’arrivée Durée du cookie plafonnée à vingt-quatre heures Domaine source, paramètre, mode d’écriture et classification
Protection contre le suivi par lien Paramètre connu, navigation privée ou protection avancée étendue Paramètre retiré avant son envoi sur le réseau URL reçue côté serveur et URL visible côté navigateur
Traceur connu ou masquage CNAME/IP Règle de blocage ou détection d’un tiers derrière un sous-domaine Chargement bloqué ou cookie HTTP plafonné à sept jours Résolution DNS, destination réseau, réponse HTTP et journal Safari

Audiences et enchères : mesurer avant de conclure

Une perte d’identifiant peut réduire le signal observable, mais elle ne vide pas mécaniquement une audience au septième jour. Trois notions doivent rester séparées : la durée d’adhésion configurée, la capacité à reconnaître le navigateur lors d’un retour et les seuils d’éligibilité du réseau publicitaire.

Adhésion, reconnaissance et éligibilité

Un visiteur Safari peut devenir plus difficile à reconnaître lorsque son stockage local disparaît. L’effet réel dépend toutefois de l’identifiant utilisé, des nouvelles interactions, du consentement à la personnalisation, de la collecte Google et de la taille de la liste. Mesurez les utilisateurs actifs et éligibles par navigateur au lieu de déduire la taille d’audience d’une seule durée ITP.

Le Consent Mode v2 peut alimenter la modélisation de conversions lorsque les conditions sont réunies. Google précise que les requêtes sans cookie ne servent jamais à suivre individuellement les personnes, à créer leur profil ou à les ajouter à une liste de reciblage. La modélisation ne transforme donc pas un visiteur non consentant en membre observable d’une audience.

Conversions observées et modélisées

Les enchères automatiques utilisent les conversions observées et, quand Google dispose d’assez de données et de confiance, certaines conversions modélisées. Une rupture de mesure peut modifier le mélange de signaux reçu ; elle ne prouve pas à elle seule un biais de décision ni son amplitude. Comparez les résultats par navigateur, délai et source de conversion avant de toucher aux objectifs d’enchères.

Les conversions améliorées complètent une conversion éligible avec des données propriétaires fournies par l’utilisateur puis hachées, afin de rechercher une correspondance avec Google. Les imports hors ligne transmettent des événements aval lorsque l’identifiant ou les données nécessaires sont encore disponibles. Ni l’un ni l’autre ne récupère universellement une conversion Safari tardive : il faut un événement observé, des données admissibles, une correspondance et les consentements requis.

Ce que signifie vraiment l’inactivité

Le repère courant est sept jours d’utilisation de Safari sans interaction avec le site pour les stockages accessibles aux scripts. Il ne s’agit ni d’une « purge universelle à trente jours » ni d’une règle identique pour chaque cookie HTTP. Une nouvelle interaction peut aussi changer le point de départ.

Un parcours long reste plus exposé parce qu’il multiplie les occasions de perdre l’identifiant : inactivité, changement d’appareil, refus de consentement, navigation privée ou suppression manuelle. Il faut cependant vérifier lequel de ces mécanismes a réellement rompu la continuité.

Pour un cycle B2B de plusieurs semaines, un identifiant propriétaire lié au compte ou au CRM peut préserver une partie de l’historique lorsque la personne s’est authentifiée ou identifiée licitement. C’est l’intérêt des données propriétaires hors cookies : elles réduisent la dépendance au navigateur sans autoriser un suivi caché.

Diagnostiquer une perte de mesure

« Le direct monte » et « les campagnes d’amont sous-performent » sont des symptômes compatibles avec une rupture d’identifiant, mais aussi avec une campagne non balisée, une redirection, une application, un changement de consentement ou un vrai changement de comportement. Aucun rapport isolé ne permet d’attribuer l’écart à Safari.

Dans Google Ads, le rapport d’attribution consacré aux métriques de parcours indique le délai observé depuis la première ou la dernière interaction publicitaire. Dans Google Analytics, segmentez les utilisateurs, le trafic et les campagnes publicitaires avec une exploration ou l’export brut adapté à votre implémentation, sans supposer qu’un menu universel « Délai de conversion » existe encore. Rapprochez ensuite ces délais des conversions et ventes confirmées pour chaque type de client dans le CRM.

Le faux calcul
Multiplier la part Safari par la durée moyenne du cycle ne donne pas une perte d’attribution : les unités ne correspondent pas. Estimez plutôt, par cohorte et par navigateur, la part des conversions dont le délai dépasse la persistance effectivement observée, puis confrontez-la aux identifiants encore disponibles.

Dans une application, ATT s’applique lorsqu’une entreprise collecte des données et les partage avec d’autres entreprises pour suivre l’utilisateur ou l’appareil entre leurs applications et leurs sites. L’autorisation conditionne notamment l’accès à l’identifiant publicitaire. Elle n’interdit pas toute mesure inter-applications : les données internes, les cadres d’attribution respectueux de la confidentialité et les cas non qualifiés de suivi restent à distinguer.

Le diagnostic croise donc quatre traces issues de vos outils : URL reçue par le serveur, requêtes réseau du navigateur, conversions observées ou modélisées par la plateforme, et ventes confirmées en aval. Pour chaque utilisateur test, conservez les mêmes informations de contexte. L’écart localise la rupture ; il ne la répare pas automatiquement.

À côté des protections Safari, une autre famille de pertes vient des bloqueurs et du routage : elle doit être testée séparément pour ne pas attribuer toutes les requêtes absentes à ITP.

Un stockage propriétaire écrit en JavaScript entre dans le plafond général de sept jours sans interaction. Un cookie posé par une réponse HTTP réellement propriétaire n’entre pas automatiquement dans cette même règle, mais il n’est pas immunisé : WebKit plafonne aussi certains cookies de réponse lorsque le sous-domaine masque un tiers par CNAME ou par adresse IP.

Un GTM côté serveur hébergé sur GCP ou Stape peut centraliser la collecte, appliquer une déduplication et réduire des dépendances au navigateur si son domaine, son routage et ses en-têtes sont correctement configurés. Il ne peut traiter que les informations reçues et n’empêche pas Safari de bloquer une requête ou de limiter un montage assimilé à un masquage de domaine.

Le rapprochement par identité complète cette architecture. Le principe des conversions améliorées consiste à transmettre à Google des données propriétaires hachées issues d’une conversion observée. Un import CRM peut relier une vente au clic ou à une personne lorsque l’identifiant admissible a été conservé. Ces mécanismes améliorent certains appariements ; ils ne remplacent pas un signal jamais transmis.

Pourquoi un CNAME n’accorde aucune immunité

Un sous-domaine tel que analytics.mondomaine.com peut résoudre vers un prestataire tiers. WebKit documente la détection de ce masquage par CNAME ou par adresse IP ; les cookies reçus dans ces réponses peuvent être plafonnés à sept jours. Le nom visible dans l’URL ne suffit donc pas à qualifier l’infrastructure de propriétaire.

Examinez la résolution DNS, l’hébergement final, les accès du prestataire, les données transmises et le rôle contractuel de chaque acteur. Une collecte techniquement maîtrisée peut être plus robuste et plus auditable, mais elle ne contourne aucune obligation légale.

Quatre vérifications avant d’investir
Testez l’URL reçue côté serveur, le stockage effectivement écrit, la conversion encore appariable et la part de ventes confirmées hors mesure. La solution se choisit sur la rupture observée : point de collecte propriétaire, conversion améliorée, import aval ou correction du consentement.

Le calendrier de Chrome sur les cookies tiers ne change pas ces règles WebKit. Traitez chaque navigateur et chaque architecture selon son comportement actuel plutôt que d’attendre une date de bascule commune.

Le cadre légal du ciblage publicitaire reste indépendant de cette robustesse technique. Un cookie plus persistant ou un envoi serveur ne fournit ni base légale, ni information, ni minimisation à votre place.

Consentement et protections Safari répondent à deux questions

Le navigateur décide ce qu’il conserve ou transmet ; l’organisation doit déterminer ce qu’elle peut licitement déposer, lire et traiter. Un consentement valide ne désactive pas ITP. À l’inverse, une architecture côté serveur ne dispense pas du consentement lorsque le traceur n’est pas strictement nécessaire.

Consent Mode adapte le comportement des balises aux choix reçus et peut permettre une modélisation agrégée. Ce n’est pas, à lui seul, une preuve de conformité. Pour les usages publicitaires, documentez les finalités, les paramètres de consentement, les destinataires, la conservation et les transferts éventuels.

La bonne optimisation d’une bannière n’est pas la maximisation de l’acceptation. Le choix doit être libre, informé, spécifique et non ambigu ; la CNIL demande que refuser soit aussi simple qu’accepter et écarte les interfaces qui poussent visuellement vers l’accord.

Pour chaque site ou application Apple, tenez une fiche courte : outil ou balise, finalité, mode d’écriture, domaine destinataire, informations collectées, durée, choix de l’utilisateur, sous-traitant et mécanisme de suppression. Cette cartographie relie la réalité technique à la politique de confidentialité et facilite les tests Safari sur plusieurs sites.

Cette limite est-elle propre à Google Ads, ou touche-t-elle toute plateforme publicitaire ?

La limite touche toute plateforme qui dépend d’un identifiant ou d’une requête que Safari supprime. Les API de conversion peuvent recevoir un événement depuis votre serveur, mais seulement si cet événement et les données nécessaires ont été observés licitement. Elles réduisent une dépendance au pixel ; elles ne voient pas ce que votre système n’a jamais reçu.

Pour comparer Google Ads à une autre plateforme, utilisez la même définition de conversion, la même période, la même déduplication et le même statut de consentement. Un écart peut venir de la fenêtre d’attribution ou du taux d’appariement autant que de la performance publicitaire.

Lorsque navigateur et serveur envoient le même événement, transmettez un identifiant commun et vérifiez la déduplication. Sans ce contrôle, une architecture censée combler un manque peut au contraire compter deux conversions.

Repères d’arbitrage
  • Sept jours concernent les stockages accessibles aux scripts après une période sans interaction, pas tous les cookies propriétaires.
  • Une protection par lien peut retirer un paramètre avant son envoi : aucun serveur ne peut alors le reconstituer.
  • La modélisation de conversions ne crée pas de membre observable dans une audience de reciblage.
  • Serveur, CNAME et conversions améliorées ne remplacent ni consentement, ni minimisation, ni contrôle des destinataires.
  1. Rejouez un clic test dans Safari normal, privé et avec la protection avancée : consignez l’URL reçue par le serveur, les requêtes et le stockage créé.
  2. Mesurez le délai observable dans les métriques de parcours Google Ads, puis dans votre CRM ou votre export analytique pour les ventes confirmées.
  3. Construisez des cohortes par navigateur, consentement et type d’identifiant ; comparez conversions observées, modélisées, importées et ventes dédupliquées.
  4. Corrigez la rupture prouvée : balisage, point de collecte propriétaire, conversion améliorée, import aval ou gouvernance du consentement. Rejouez ensuite le même test.

Décider à partir de faits observables

Ne classez pas l’exposition avec une multiplication théorique. Documentez la part des parcours réellement touchés, la valeur commerciale manquante et la capacité de chaque solution à restaurer un signal autorisé. Un correctif serveur peut être prioritaire pour une requête bloquée côté client, inutile pour un paramètre retiré avant le réseau, ou insuffisant lorsqu’aucune identité n’existe à la conversion.

La décision finale tient sur une ligne : rupture observée, population concernée, valeur perdue, correctif testé et limite résiduelle. C’est assez précis pour piloter le budget sans transformer Safari en explication universelle.

Sources officielles consultées le 16 juillet 2026 : règles de prévention du suivi dans WebKit, protection des liens et blocage des traceurs dans Safari, cadre App Tracking Transparency d’Apple, modélisation avec Consent Mode, conversions améliorées, métriques des parcours d’attribution Google Ads et règles CNIL sur le consentement aux traceurs.

Questions fréquentes

ITP s’applique-t-il aussi aux cookies propriétaires ?
Oui, selon leur mode d’écriture et leur contexte. WebKit limite les cookies JavaScript et les autres stockages accessibles aux scripts après sept jours sans interaction. Un cookie HTTP réellement propriétaire suit une autre logique, mais un masquage par CNAME ou adresse IP peut aussi déclencher un plafond.
Qu’est-ce que l’ATT d’Apple change concrètement pour Google Ads ?
ATT exige une autorisation lorsqu’une application partage des données avec d’autres entreprises pour suivre une personne ou son appareil entre leurs applications et leurs sites, et conditionne notamment l’accès à l’identifiant publicitaire. Il n’interdit pas toute mesure dans une application.
Comment savoir si mon attribution est affectée par ITP ?
Rejouez le parcours sur Safari, vérifiez le paramètre reçu, le stockage écrit et l’identifiant disponible à la conversion. Comparez ensuite les cohortes Safari aux ventes dédupliquées du CRM. La part Safari multipliée par le délai moyen ne mesure pas une perte.
GTM côté serveur résout-il le problème ITP ?
Il peut conserver et transmettre un signal encore reçu, réduire la dépendance aux scripts et mieux dédupliquer. Il ne récupère pas un paramètre supprimé avant la requête, n’empêche pas tous les blocages et ne dispense jamais du consentement ou de la minimisation.
Les visites organiques et payantes subissent-elles les mêmes limites ?
La règle dépend du stockage, de la décoration du lien, du domaine source et du mode Safari, pas de l’étiquette organique ou payante. Un clic publicitaire peut être plus exposé à certains paramètres connus, mais le comportement doit être testé.
Le calendrier de Chrome rend-il ITP moins urgent ?
Non. ITP est un mécanisme WebKit indépendant. Les décisions de Chrome sur les cookies tiers ne modifient ni les plafonds Safari, ni la protection contre le suivi par lien, ni les obligations de consentement.
Vincent Duquesne, consultant Google Ads
Vincent Duquesne
Expert Google Ads Certifié depuis 2011 : j’ai audité et restructuré des centaines de comptes dans des dizaines de thématiques différentes. +20M€ gérés.
Google Partner Premier 2026

Attribution Safari à mesurer ?

On chiffre l’exposition réelle.

Réserver un appel