WebKit détaille le blocage par Safari du suivi fondé sur les adresses e-mail
Le 19 octobre 2026, l’équipe WebKit d’Apple a publié une explication technique de la protection de Safari contre le suivi par résolution d’identité (en anglais). Celle-ci bloque l’accès réseau à certaines infrastructures tierces pour éviter que l’adresse e-mail d’une personne devienne un identifiant persistant reliant son activité sur des sites sans rapport entre eux.
Le problème diffère de celui des cookies tiers classiques. Dans le modèle décrit par WebKit, un tiers reçoit une adresse e-mail lors d’une connexion ou d’une inscription à une newsletter, l’associe à un identifiant de suivi, puis renvoie cet identifiant aux sites participants. Au fil du temps, ce tiers peut rapprocher des interactions que les internautes ne s’attendaient pas à voir reliées.
Ce que WebKit a annoncé
Selon WebKit, Safari et WebKit dans les versions 27 d’iOS, d’iPadOS, de macOS et de visionOS bloquent l’accès réseau aux infrastructures de résolution d’identité. Le blocage s’applique au domaine, plutôt que de dépendre uniquement d’un chemin d’URL ou du format du corps d’une requête.
WebKit distingue explicitement cette pratique de la personnalisation propre à un site. Mémoriser les choix d’une personne sur un site n’équivaut pas à envoyer des informations identifiantes à un service distinct pour la reconnaître sur plusieurs sites. WebKit distingue aussi ces traceurs des fournisseurs de connexion et des services de newsletter. L’annonce ne dresse pas la liste des fournisseurs bloqués et n’établit pas que toutes les requêtes liées à l’analyse d’audience ou à l’identité sont bloquées.
Ce que les équipes de développement devraient vérifier
Pour une équipe web, une prochaine étape utile consiste à vérifier si les parcours d’inscription, de newsletter, de connexion ou de personnalisation dépendent d’un suivi tiers non essentiel. Des prestataires légitimes peuvent rester nécessaires à ces tâches ; identifiez ce que fait réellement chaque dépendance.
Ouvrez la page dans Safari sur une version couverte par l’annonce, utilisez une adresse e-mail de test jetable et observez le panneau Réseau pendant un parcours normal. Comparez les destinations des requêtes et les messages d’échec de chargement. Vérifiez que la tâche aboutit et que la page se comporte correctement lorsque des scripts tiers non essentiels sont indisponibles. Une requête en échec ne suffit pas à désigner cette protection précise comme cause.
N’utilisez pas les adresses e-mail de véritables clients et ne partagez pas de capture réseau sans l’expurger. Le guide de vérification des requêtes réseau dans Chrome, Firefox, Edge et Safari explique comment examiner les requêtes sans confondre les téléchargements de ressources ordinaires avec la transmission des données saisies.
Si la console signale plutôt un échec de pré-vérification CORS, consultez l’article sur le diagnostic des pré-vérifications CORS pour examiner l’échange OPTIONS. Les contrôles de permission CORS et les protections contre le suivi sont des mécanismes distincts ; modifier les en-têtes CORS n’est pas une solution générale au blocage d’une infrastructure de suivi.
Si un parcours cesse de fonctionner, examinez la dépendance et sa finalité légitime avant de changer de point d’accès ou d’ajouter un proxy. Supprimez les partages de données inutiles et évitez de faire dépendre une tâche essentielle d’un rapprochement d’identité dissimulé entre sites.
Ce que cela implique pour le reste du web
Pour les équipes de développement, la conséquence pratique est d’intégrer les protections de la vie privée aux tests de compatibilité. Les réponses du serveur, les cookies, les intégrations JavaScript et les API tierces peuvent se comporter différemment sous l’effet de ces contrôles.
Notre actualité sur Firefox Enterprise soulève une question de test voisine : des politiques de navigateur administrées de manière centralisée peuvent elles aussi modifier les conditions d’exécution d’un site. Testez les environnements de vos visiteurs, y compris le comportement du site lorsqu’une intégration facultative échoue.
La distinction entre l’état conservé dans le navigateur et les informations d’identité transmises à distance compte également. L’article localStorage, sessionStorage ou cookies : où stocker les données d’une application web ? explique quels mécanismes accompagnent automatiquement les requêtes et pourquoi aucun ne dispense de réfléchir au traitement des données.
Pour un premier examen des dépendances de votre site, suivez le guide d’inspection du panneau Réseau avec des données fictives. Relevez la destination et le rôle de chaque requête, puis vérifiez que la tâche prévue aboutit lorsque les intégrations facultatives sont indisponibles.