« Si mon serveur reçoit le cookie, j’ai le droit de le garder ? » La question revient dès qu’on parle de Safari. Non : la technique ne décide pas de ce que vous pouvez collecter. En France, un traceur non nécessaire relève d’abord de l’article 82 de la loi Informatique et Libertés. Ensuite, vos données visiteurs restent soumises aux principes du RGPD : finalité, base légale, transparence, minimisation, durée de conservation, sécurité et encadrement des sous-traitants. Lisez le cadre RGPD et DMA du ciblage publicitaire avec précision : le DMA impose des obligations à certains contrôleurs d’accès, il ne remplace ni le droit commun des traceurs ni l’information due dans votre politique de confidentialité.
Une perte de signal ne devient pas automatiquement du trafic direct
Tout dépend du paramètre reçu, du stockage écrit et du consentement. Puis de la fenêtre d’attribution et de la modélisation. Un serveur ne garde que ce que le navigateur lui envoie encore.
C’est par là que je commence : remonter la chaîne. Le paramètre de clic a-t-il atteint votre serveur ? Quel stockage a été écrit, avec quel consentement ? Quelle fenêtre d’attribution s’applique, et la conversion a-t-elle été observée ou modélisée ? Votre part de trafic Safari et votre délai d’achat n’y répondent pas.
Sept jours d’utilisation de Safari sans interaction avec votre site, et WebKit supprime les cookies créés en JavaScript et les autres stockages accessibles aux scripts. Vos outils de mesure Google Ads sont concernés s’ils écrivent ainsi. Mais la règle ne couvre ni tous les cookies propriétaires ni toutes les visites Safari.
Autre règle, plus étroite : un cookie JavaScript créé sur la page d’arrivée, après un lien décoré depuis un domaine que WebKit a classé comme capable de suivi intersites, tombe à vingt-quatre heures. Toutes ces conditions à la fois. Ce cas précis n’est pas une durée universelle « post-clic ».
Quand l’identifiant a disparu à la conversion, chaque outil réagit à sa façon. Google Ads attribue ou modélise une partie des conversions, si ses conditions sont réunies. Google Analytics applique ses règles de session et d’événement. Votre outil interne laisse parfois la source vide. Une hausse du « direct » est donc une hypothèse à tester, pas la conséquence automatique d’ITP.
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. Un réglage l’étend à toute la navigation. Elle ajoute, entre autres, la suppression de paramètres connus et le blocage des chargements vers des traceurs identifiés. Elle ne rase pas tous les paramètres de campagne au passage.
Quand le paramètre disparaît avant la requête
La protection contre le suivi par lien retire, avant la navigation, une liste de paramètres associés au suivi intersites. Le paramètre supprimé n’arrive ni sur la page ni sur votre serveur. Aucun conteneur côté serveur ne le « récupère » après coup. WebKit précise en revanche qu’un paramètre qui sert uniquement à l’attribution d’une campagne peut rester transmis.
Si l’identifiant arrive encore sur votre domaine, un point de collecte propriétaire (un GTM côté serveur sur GCP ou Stape, par exemple) réduit votre dépendance au JavaScript et transmet un événement observé. C’est tout ce qu’il fait. 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 les chargements réseau présents à la fois dans plusieurs listes de traceurs connues, y compris certains domaines masqués par CNAME. Ça ne veut pas dire que Google Tag Manager est bloqué partout. Ouvrez l’inspecteur web de Safari et regardez les requêtes vraiment émises, avec la version de Safari, le mode de navigation et votre configuration.
| Protection | Condition documentée par WebKit | Ce qui se passe | Ce que vous vérifiez |
|---|---|---|---|
| Stockages accessibles aux scripts | Sept jours d’utilisation de Safari sans interaction avec votre site | Cookie JavaScript, stockage local et autres données de site supprimés | Type de stockage, dernière interaction, continuité de l’identifiant |
| Décoration de lien classée | Arrivée depuis un domaine classé, puis cookie JavaScript créé sur la page d’arrivée | Cookie plafonné à vingt-quatre heures | Domaine source, paramètre, mode d’écriture, classification |
| Protection contre le suivi par lien | Paramètre connu, en navigation privée ou protection avancée étendue | Paramètre retiré avant même l’envoi sur le réseau | URL reçue par votre serveur face à l’URL affichée dans le navigateur |
| Traceur connu ou masquage CNAME/IP | Règle de blocage, ou détection d’un tiers derrière votre sous-domaine | Chargement bloqué, ou cookie HTTP plafonné à sept jours | Résolution DNS, destination réseau, réponse HTTP, journal Safari |
Audiences et enchères : mesurer avant de conclure
Perdre un identifiant réduit le signal que vous observez. Ça ne vide pas mécaniquement votre audience le septième jour. Gardez trois notions séparées : la durée d’adhésion configurée, la capacité de Google à reconnaître le navigateur quand il revient, et les seuils d’éligibilité du réseau publicitaire.
Adhésion, reconnaissance et éligibilité
Quand son stockage local disparaît, un visiteur Safari devient plus dur à reconnaître. Mais l’effet réel dépend de l’identifiant utilisé, de ses nouvelles interactions et de son consentement à la personnalisation. De la collecte Google et de la taille de la liste, aussi. Comptez les membres actifs et éligibles, navigateur par navigateur, au lieu de déduire une taille d’audience d’une seule durée ITP.
Le Consent Mode v2 alimente la modélisation des conversions, si ses conditions sont réunies. Google précise que les requêtes sans cookie ne servent jamais à suivre une personne, à dresser son profil ou à l’ajouter à une liste de reciblage. La modélisation ne transforme donc pas un visiteur qui a refusé en membre observable d’une audience.
Conversions observées et modélisées
Les enchères automatiques apprennent sur les conversions observées et, quand Google a assez de données et de confiance, sur une partie des conversions modélisées. Une rupture de mesure change le mélange de signaux reçu. Seule, elle ne prouve pas un biais de décision, encore moins son ampleur. Comparez vos 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 le client, hachées, puis rapprochées de celles de Google. Les imports hors ligne remontent des événements aval quand l’identifiant ou les données nécessaires sont encore là. Aucun des deux ne rattrape à coup sûr 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 à retenir : sept jours d’utilisation de Safari sans interaction avec votre site, pour les stockages accessibles aux scripts. Pas une « purge universelle à trente jours », et pas la même règle pour chaque cookie HTTP. Une nouvelle interaction avec le site relance aussi le décompte.
Un cycle d’achat 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. Cinq causes possibles, parmi d’autres. Cherchez laquelle a vraiment rompu le fil avant d’accuser Safari.
Sur un cycle B2B de plusieurs semaines, un identifiant propriétaire lié au compte ou au CRM conserve une partie de l’historique, à condition que le prospect se soit connecté ou identifié licitement. C’est tout l’intérêt des données propriétaires hors cookies : elles réduisent votre dépendance au navigateur, sans autoriser un suivi caché.
Diagnostiquer une perte de mesure
« Le direct monte. » « Mes campagnes d’amont sous-performent. » Ces deux symptômes collent avec une rupture d’identifiant. Ils collent aussi avec une campagne non balisée, une redirection, une application, un changement de consentement ou un vrai changement de comportement. Un rapport isolé ne vous dira jamais lequel.
Dans Google Ads, le rapport d’attribution consacré aux métriques de parcours vous donne le délai observé depuis la première ou la dernière interaction publicitaire. Dans Google Analytics, segmentez visiteurs, trafic et campagnes avec une exploration ou l’export brut adapté à votre installation, sans chercher un menu universel « Délai de conversion » qui n’existe plus forcément. Rapprochez ensuite ces délais des conversions et ventes confirmées dans votre CRM, type de client par type de client.
Dans une application, ATT (l’autorisation de suivi d’Apple) s’applique quand une entreprise collecte des données et les partage avec d’autres entreprises pour suivre une personne ou son appareil entre leurs applications et leurs sites. L’autorisation conditionne entre autres l’accès à l’identifiant publicitaire. Elle n’interdit pas toute mesure entre applications : données internes, cadres d’attribution respectueux de la confidentialité et cas qu’Apple ne qualifie pas de suivi restent à distinguer.
Le diagnostic croise donc quatre traces : l’URL reçue par le serveur, les requêtes réseau du navigateur, les conversions observées ou modélisées par la plateforme, et les ventes confirmées en aval. Pour chaque test, notez le même contexte. L’écart vous dit où le fil casse. Il ne le répare pas.
À côté des protections Safari, une autre famille de pertes vient des bloqueurs et du routage. Testez-la à part, sinon vous mettrez toutes les requêtes absentes sur le dos d’ITP.
Cookie HTTP, serveur et limites du CNAME
Un stockage propriétaire écrit en JavaScript tombe sous le plafond général de sept jours sans interaction. Un cookie posé par une réponse HTTP vraiment propriétaire n’y entre pas d’office. Il n’est pas immunisé pour autant : WebKit plafonne aussi certains cookies de réponse quand le sous-domaine masque un tiers par CNAME ou par adresse IP.
Un GTM côté serveur hébergé sur GCP ou Stape centralise la collecte, déduplique et réduit vos dépendances au navigateur, si son domaine, son routage et ses en-têtes sont bien configurés. Il ne traite que ce qu’il reçoit. Il n’empêche pas Safari de bloquer une requête, ni de brider un montage qu’il assimile à un masquage de domaine.
Le rapprochement par identité complète cette architecture. Les conversions améliorées envoient à Google des données propriétaires hachées, tirées d’une conversion observée. Un import CRM relie une vente au clic ou à une personne, à condition d’avoir conservé l’identifiant admissible. Ces mécanismes améliorent une partie des appariements. Ils ne remplacent pas un signal jamais transmis.
Pourquoi un CNAME n’accorde aucune immunité
Un sous-domaine comme analytics.mondomaine.com résout parfois vers un prestataire tiers. WebKit documente la détection de ce masquage par CNAME ou par adresse IP, et peut alors plafonner à sept jours les cookies reçus dans ces réponses. Le nom affiché dans l’URL ne rend donc pas votre infrastructure propriétaire.
Regardez 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 que vous maîtrisez est plus robuste et plus facile à auditer. Elle ne vous dispense d’aucune obligation légale.
Le calendrier de Chrome sur les cookies tiers ne change rien à ces règles WebKit. Traitez chaque navigateur et chaque architecture d’après son comportement d’aujourd’hui, au lieu d’attendre une date de bascule commune.
Le cadre légal du ciblage publicitaire, lui, ne bouge pas avec votre robustesse technique. Un cookie qui dure plus longtemps ou un envoi serveur ne vous fournit ni base légale, ni information, ni minimisation.
Consentement et protections Safari répondent à deux questions
Le navigateur décide ce qu’il garde et transmet. Vous, vous devez établir ce que vous avez le droit de déposer, lire et traiter. Un consentement valide ne désactive pas ITP. À l’inverse, une architecture serveur ne vous dispense pas du consentement quand le traceur n’est pas strictement nécessaire.
Consent Mode adapte vos balises au choix du visiteur et ouvre la porte à une modélisation agrégée, si Google en réunit les conditions. Ce n’est pas une preuve de conformité en soi. Pour l’usage publicitaire, documentez à quoi sert chaque traceur, ses paramètres de consentement, ses destinataires, sa durée de conservation et les transferts éventuels.
Optimiser sa bannière, ce n’est pas faire grimper le taux d’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 le « oui ».
Pour chaque site ou application Apple, tenez une fiche courte par balise : à quoi elle sert, comment elle écrit, vers quel domaine, quelles données, combien de temps, quel choix du visiteur, quel sous-traitant, comment on la supprime. Cette carte relie la technique à votre politique de confidentialité et rend vos tests Safari reproductibles d’un site à l’autre.
Cette limite est-elle propre à Google Ads, ou touche-t-elle toute plateforme publicitaire ?
Toute plateforme qui dépend d’un identifiant ou d’une requête que Safari supprime est touchée. Les API de conversion reçoivent un événement depuis votre serveur, à une condition : que cet événement et les données nécessaires aient été observés licitement. Elles réduisent votre 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, prenez 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, pas seulement de la performance publicitaire.
Quand navigateur et serveur envoient le même événement, transmettez un identifiant commun et vérifiez la déduplication. Sans ce contrôle, l’architecture censée combler un trou compte la même conversion deux fois.
- Les sept jours visent les stockages accessibles aux scripts, après une période sans interaction. Pas tous les cookies propriétaires.
- Quand la protection par lien retire un paramètre avant l’envoi, aucun serveur ne le reconstitue derrière.
- La modélisation des conversions n’ajoute personne à une audience de reciblage.
- Serveur, CNAME et conversions améliorées ne remplacent ni le consentement, ni la minimisation, ni le contrôle des destinataires.
- Rejouez un clic test dans Safari normal, en navigation privée, puis avec la protection avancée. Notez l’URL reçue par le serveur, les requêtes émises et le stockage créé.
- Mesurez le délai observable dans les métriques de parcours Google Ads, puis dans votre CRM ou votre export analytique, côté ventes confirmées.
- Construisez des segments par navigateur, consentement et type d’identifiant. Comparez conversions observées, modélisées, importées et ventes dédupliquées.
- Corrigez la rupture prouvée : balisage, point de collecte propriétaire, conversion améliorée, import aval ou gouvernance du consentement. Puis rejouez le même test.
Décider à partir de faits observables
Selon moi, une multiplication théorique est la pire base pour classer votre exposition. Documentez la part des parcours vraiment touchés, la valeur commerciale qui manque et la capacité de chaque solution à restaurer un signal autorisé. Un correctif serveur est prioritaire pour une requête bloquée côté client, inutile pour un paramètre retiré avant le réseau, insuffisant quand 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 qui reste. Assez précis pour piloter votre budget sans faire de Safari l’explication de tout.
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.
