Un guide pratique de cookies de suivi inter-sites

Ce guide explique cookies de suivi inter-sites de manière pratique, avec un accent sur les décisions d'analytics respectueuses de la vie privée.

Le rapport de confidentialité de Safari rend le suivi cross-site visible pour les visiteurs ordinaires. Si votre site charge des trackers, Safari peut montrer que le suivi a été empêché. C’est bon pour les utilisateurs, mais gênant pour les propriétaires de sites qui ne réalisaient pas combien de scripts tiers leurs pages avaient accumulés.

Un rapport de confidentialité propre n’est pas seulement une vanity metric. Cela signifie généralement moins de scripts intrusifs, des pages plus rapides, une conformité plus simple et un meilleur signal de confiance.

Ce que Safari bloque

Intelligent Tracking Prevention de Safari est conçu pour limiter le suivi cross-site. WebKit documente le blocage complet des cookies tiers, les referrers tiers dégradés, les défenses contre la link-decoration, une limite de sept jours sur le stockage modifiable par script dans certains contextes de suivi et des défenses contre le CNAME cloaking (WebKit Tracking Prevention).

En langage clair, Safari essaie d’empêcher les entreprises de reconnaître la même personne sur différents sites au moyen de cookies, stockage, redirections, liens décorés ou requêtes tierces déguisées.

Pourquoi votre site peut apparaître dans le rapport de confidentialité

Un site peut déclencher des avertissements de trackers parce qu’il charge des scripts ou ressources depuis des domaines que Safari classe comme trackers. Causes courantes :

• Google Analytics ou Google Tag Manager
• Meta Pixel
• Scripts publicitaires et de retargeting
• Widgets de partage social
• Vidéos intégrées avec scripts de suivi
• Outils de marketing automation
• Session replay et heatmaps
• Systèmes de commentaires tiers
• Endpoints analytics ou publicitaires masqués par CNAME

Vous ne pensez peut-être pas que votre site suit les utilisateurs, mais Safari évalue le comportement et les domaines impliqués, pas votre intention.

Analytics et ITP

L’analytics traditionnelle s’appuie souvent sur des cookies ou du stockage modifiable par script pour reconnaître les visiteurs. Les protections de Safari peuvent raccourcir la durée de vie des cookies, bloquer l’accès tiers et réduire l’exactitude de l’attribution pour les campagnes cross-site.

C’est l’une des raisons pour lesquelles une analytics lourde en cookies peut montrer moins de visiteurs de retour ou des sessions fragmentées dans Safari. Un outil d’analytics privacy-first qui évite le suivi cross-site et les identifiants persistants est moins susceptible de se battre contre le navigateur.

Comment auditer votre site

Utilisez Safari, les dev tools du navigateur et un profil propre. Visitez votre page d’accueil et vos principales landing pages. Vérifiez :

• Quels domaines tiers se chargent
• Quels cookies sont déposés avant consentement
• Si localStorage ou IndexedDB est utilisé
• Si les tag managers injectent des scripts inattendus
• Si les médias intégrés se chargent avant interaction
• Si les paramètres d’URL contiennent des ad click IDs ou des données personnelles
• Si le refus dans votre bannière arrête réellement les scripts non essentiels

Répétez après acceptation et refus des cookies. Une bannière qui semble conforme ne suffit pas si les scripts se chargent avant le choix.

Comment nettoyer

Commencez par supprimer les tags inutilisés. De nombreux sites gardent d’anciens pixels de campagnes passées, des outils d’A/B testing abandonnés, des snippets analytics dupliqués et des scripts fournisseurs que personne ne possède.

Puis remplacez ce que vous pouvez :

• Utilisez une analytics privacy-first au lieu d’une analytics lourde en cookies
• Utilisez des liens sociaux statiques au lieu de widgets JavaScript
• Utilisez des embeds vidéo privacy-enhanced ou des placeholders click-to-load
• Auto-hébergez les polices au lieu de charger Google Fonts depuis les serveurs de Google
• Supprimez les pixels de retargeting qui ne produisent pas de valeur mesurable
• Évitez le session replay sur les pages sensibles
• Réduisez les permissions et workflows de publication du tag manager

Chaque script supprimé améliore la confidentialité, la performance et le debug.

Le consentement compte toujours

Le fait que Safari bloque un tracker ne rend pas la tentative de suivi conforme. Si votre site charge des cookies ou technologies de suivi non essentiels avant consentement, cela reste un problème au regard des règles cookies de l’UE. L’EDPB Cookie Banner Taskforce a identifié des patterns de consentement invalides courants, dont les options de refus manquantes et les cases précochées (rapport EDPB).

Votre objectif ne doit pas être « se cacher de Safari ». Il doit être « ne pas charger de suivi que les visiteurs n’ont pas accepté ».

Bénéfices business d’un rapport plus propre

Un site léger en trackers charge généralement plus vite, casse moins souvent et produit une analytics first-party plus fiable. Il réduit aussi le risque fournisseur. Si un régulateur, client ou reviewer sécurité demande quels scripts tournent sur votre site, la réponse est plus courte et plus facile à défendre.

Pour les marques axées confidentialité, le rapport de confidentialité de Safari est un point de preuve visible publiquement. Les visiteurs peuvent voir si vos déclarations correspondent à votre implémentation.

La cible pratique

Visez zéro tracker non essentiel au premier chargement de page. Si vous avez besoin de médias intégrés, chargez-les après interaction. Si vous avez besoin de pixels marketing, chargez-les uniquement après consentement valide. Si vous avez besoin d’analytics, choisissez une approche qui ne dépend pas du suivi cross-site.

Safari n’essaie pas de casser la mesure honnête. Il pousse le web loin de la surveillance invisible. Les propriétaires de sites peuvent soit combattre cette tendance avec des contournements, soit s’en servir comme raison de simplifier leur stack.

Surveiller le CNAME cloaking

Certains fournisseurs analytics et publicitaires encouragent le CNAME cloaking, où un service tiers est routé via un sous-domaine qui semble first-party, comme metrics.example.com. L’idée est de faire ressembler la requête à une requête first-party. WebKit documente explicitement des défenses contre le CNAME cloaking tiers et limite certains cookies définis par ces réponses (WebKit Tracking Prevention).

Traitez le CNAME cloaking avec prudence. Il peut créer une fausse impression de contrôle first-party tout en envoyant des données à un fournisseur externe. Il peut aussi compliquer votre notice de confidentialité parce que les visiteurs ne voient pas aussi facilement le vrai tiers dans les outils navigateur.

Construire un inventaire de scripts

Gardez un inventaire simple avec URL du script, propriétaire, finalité, catégorie de consentement, fournisseur, données collectées et date de dernière revue. Si personne ne possède un script, supprimez-le. Si un script n’est utile que pour une campagne terminée depuis des mois, supprimez-le. Si un script casse lorsqu’il est bloqué par Safari, décidez si l’entreprise en a vraiment besoin ou si la fonctionnalité doit être reconstruite avec de la logique first-party.

Le rapport Safari est un test de pression utile parce qu’il montre ce que les navigateurs soucieux de confidentialité supposent déjà : le suivi doit être exceptionnel, pas la condition par défaut de lecture d’une page.

Checklist de nettoyage Safari

Utilisez le rapport Safari comme un prompt d’audit pratique. Supprimez les scripts tiers inutiles, évitez l’enrichissement par brokers, gardez l’analytics agrégée lorsque c’est possible, raccourcissez la conservation des données brutes, publiez une utilisation des données en langage clair et rendez les sorties faciles.

Vérifiez ensuite le site à nouveau dans Safari, Firefox et Chrome avec un profil propre. Si un navigateur soucieux de confidentialité bloque quelque chose d’important, reconstruisez-le avec de la logique first-party ou décidez si l’entreprise a vraiment besoin de ce tracker.