Seul le domaine tranche entre cookies first-party vs third-party

Quelle est la différence entre cookies first-party vs third-party ?

Les navigateurs trient les cookies first-party vs third-party avec un seul test, en comparant le domaine qui a posé le cookie au domaine affiché dans la barre d'adresse : le cookie est first-party, donc du domaine de la page consultée, quand les deux correspondent, et third-party, donc d'un domaine tiers, quand ils diffèrent. Rien de ce que contient le cookie n'entre dans ce test, ni le nom, ni la valeur, ni le propriétaire. Le guide MDN sur les cookies third-party énonce la règle sans détour : "If the cookie domain and scheme match the current page the user is looking at (the URL shown in the browser's address bar), the cookie is considered to be from the same site as the page, and is referred to as a first-party cookie." En français : si le domaine et le schéma du cookie correspondent à la page que l'utilisateur consulte (l'URL affichée dans la barre d'adresse du navigateur), le cookie est considéré comme venant du même site que la page et il est appelé cookie first-party. Domaine ou schéma différent, cookie third-party.

Presque toutes les pages en ligne décrivent la séparation comme votre cookie contre le cookie d'un annonceur. Ce cadrage est faux. Le cookie d'une régie publicitaire, lu sur le site de la régie elle-même, est first-party ; votre propre cookie de connexion, lu dans une iframe sur le site d'un partenaire, est third-party.

Pourquoi le même cookie est-il tantôt first-party, tantôt third-party ?

La catégorie appartient à la lecture, pas au cookie. Un cookie stocké porte un domaine, et le navigateur refait la comparaison à chaque requête, donc déplacer la lecture vers un autre site de premier niveau inverse la réponse.

Prenez un widget de support qui pose un cookie sur widget.example. Un visiteur installé sur https://widget.example envoie ce cookie comme cookie first-party, parce que le domaine du cookie correspond à la barre d'adresse. Le même visiteur ouvre https://shop.example, où le même widget se charge dans une iframe. Le navigateur compare widget.example à shop.example, ne trouve aucune correspondance, et le cookie identique voyage comme cookie third-party sous chacune des restrictions que le navigateur applique à cette catégorie. Un cookie en stockage, deux catégories, tranchées requête par requête.

Qu'a réellement fait Chrome au sujet de la suppression des cookies third-party ?

Chrome l'a annulée. Anthony Chavez, VP of Privacy Sandbox, a écrit le 22 avril 2025 que Google avait "made the decision to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies." En français : pris la décision de maintenir son approche actuelle consistant à laisser aux utilisateurs le choix sur les cookies third-party dans Chrome, et ne déploiera pas de nouvelle invite dédiée aux cookies third-party. Les cookies third-party restent activés par défaut dans le mode de navigation normal de Chrome, et le réglage reste dans les paramètres Confidentialité et sécurité. La documentation d'aide de Chrome indique que les cookies third-party sont bloqués par défaut en navigation privée, donc le blocage vise un mode de navigation et non le navigateur.

Tout article qui cite encore une date d'abandon cite un plan que Google a retiré. Construisez contre ce qui est livré : Safari bloque, Firefox partitionne, Chrome autorise hors navigation privée.

Que font Safari et Firefox aux cookies third-party ?

Safari supprime la catégorie et Firefox la découpe. John Wilander a annoncé le blocage complet sur le blog WebKit le 24 mars 2020 en une phrase : "Cookies for cross-site resources are now blocked by default across the board." En français : les cookies des ressources intersites sont désormais bloqués par défaut dans tous les cas. La politique de prévention du pistage de WebKit confirme qu'Intelligent Tracking Prevention "blocks all third-party cookies", donc bloque tous les cookies third-party, et laisse une seule voie de retour, la Storage Access API, qui interroge d'abord l'utilisateur.

Firefox a pris l'autre chemin. Mozilla a déployé Total Cookie Protection pour tous les utilisateurs dans le monde le 14 juin 2022, et cette protection garde les cookies third-party vivants à l'intérieur d'une frontière : "any time a website, or third-party content embedded in a website, deposits a cookie in your browser, that cookie is confined to the cookie jar assigned to only that website." En français : chaque fois qu'un site web, ou un contenu third-party intégré dans un site web, dépose un cookie dans votre navigateur, ce cookie reste confiné au pot à cookies attribué à ce seul site web. Un traceur intégré obtient toujours un cookie sur chaque site où il apparaît, et il en obtient un différent à chaque fois, ce qui tue le rapprochement intersites sans tuer le widget.

Cookies first-party vs third-party comparés

La dernière ligne explique pourquoi le blocage est tombé d'un seul côté. Bloquer les cookies third-party casse la tuyauterie intersites des autres ; bloquer les cookies first-party casserait le web.

Qu'est-ce qui casse quand les cookies third-party sont bloqués ?

L'état intersites casse, et seulement l'état intersites. L'authentification unique via un fournisseur d'identité dans une iframe cesse de reconnaître l'utilisateur, un paiement ou un widget de chat intégré perd le client qui revient, et une plateforme publicitaire perd l'attribution des conversions et le plafonnement de répétition, parce que chacun a besoin d'un identifiant lu sur deux sites de premier niveau différents.

Deux remplacements couvrent les parties qui valent la peine d'être gardées. La Storage Access API permet à un cadre intégré de demander à l'utilisateur ses cookies non partitionnés. Les cookies partitionnés font le reste.

Comment les cookies partitionnés changent-ils la donne ?

Les cookies partitionnés gardent le cookie third-party et suppriment le rapprochement intersites en ajoutant le site de premier niveau à la clé de stockage. MDN documente le mécanisme sous le nom CHIPS, Cookies Having Independent Partitioned State, et l'enregistre comme Baseline newly available depuis décembre 2025. Le changement tient en une ligne de structure de clé :

storage key = (top-level site, cookie domain) au lieu de storage key = (cookie domain)

Déroulez un exemple avec les valeurs de MDN elle-même. Un widget sur 3rd-party.example envoie Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned; alors qu'il est intégré sur site-a.example, et le navigateur le stocke sous {("https://site-a.example"), ("3rd-party.example")}. Sur site-b.example le widget demande le cookie, le navigateur cherche {("https://site-b.example"), ("3rd-party.example")} et ne trouve rien. Le widget fonctionne sur les deux sites et n'en relie aucun à l'autre.

Les cookies first-party survivent-ils à tout ?

Non, et l'exception frappe l'analytique en premier. La politique de prévention du pistage de WebKit engage l'ITP à "deleting all cookies created in JavaScript and all other script-writeable storage after 7 days of no user interaction", en français : supprimer tous les cookies créés en JavaScript et tout autre stockage inscriptible par script après 7 jours sans interaction utilisateur, ce qui couvre un cookie first-party écrit par un script d'analytique sur votre propre domaine. La règle porte sur la façon dont le cookie a été écrit, pas sur le domaine où il se trouve, donc la limite de 7 jours des cookies Safari raccourcit tout identifiant côté client.

L'effet visible est un comptage gonflé de nouveaux visiteurs, parce qu'un visiteur qui revient après la limite arrive sans identifiant et démarre une nouvelle session. Posez les identifiants depuis le serveur dans un en-tête de réponse Set-Cookie si vous voulez qu'ils survivent à la limite.

Qu'est-ce que cela change pour mesurer votre propre site ?

Une analytique qui s'appuie sur un cookie third-party mesure le mode de navigation normal de Chrome et pas grand-chose d'autre. Déplacer l'identifiant vers un cookie first-party élargit la couverture et heurte le plafond de l'ITP, et c'est pourquoi la mesure continue de dériver vers le serveur : lisez les arguments pour le tracking côté serveur avant de reconstruire un identifiant côté client pour la troisième fois.

Aucune des deux catégories n'échappe au droit du consentement. L'article 5(3) de la directive ePrivacy demande si une information est stockée sur l'appareil ou lue depuis celui-ci, donc un cookie d'analytique first-party le déclenche exactement comme un cookie third-party, ce à quoi une bannière de consentement sert à répondre. Ne stocker aucun identifiant supprime le déclencheur, et l'analytique sans cookies couvre ce que cela vous coûte.

Flowsery est construit ainsi. Son analytique privacy-first fonctionne sans cookies, est hébergée dans l'UE et GDPR by design, se livre en un seul script de moins de 10 KB et n'applique aucun échantillonnage de données, donc elle ne tombe jamais d'un côté ou de l'autre de la séparation entre first-party et third-party.

Questions fréquentes

Un cookie first-party est-il toujours à l'abri du blocage par le navigateur ?

Non. L'ITP de Safari supprime les cookies créés en JavaScript, ainsi que les autres stockages inscriptibles par script, après 7 jours sans interaction utilisateur, et cela s'applique sur votre propre domaine. Un cookie first-party posé par le serveur dans un en-tête de réponse Set-Cookie sort de cette règle. Ce qui compte, c'est la façon dont le cookie a été écrit, pas qui possède le domaine.

Le navigateur regarde-t-il qui possède le domaine ?

Non. Le navigateur compare le domaine et le schéma du cookie à la page de premier niveau affichée dans la barre d'adresse, et rien d'autre. La propriété, l'entreprise et la finalité n'entrent jamais dans la comparaison, c'est pourquoi le cookie d'un annonceur est first-party sur le site de cet annonceur.

Un même cookie peut-il être à la fois first-party et third-party ?

Oui, et le même cookie stocké bascule entre les deux à chaque requête. Lu sur le domaine qui l'a posé, le cookie est first-party. Lu depuis une iframe sur un autre site de premier niveau, le cookie identique est third-party et hérite de chaque restriction third-party.

Pourquoi un cookie third-party a-t-il besoin de SameSite=None et Secure ?

Les requêtes intersites transportent un cookie seulement quand il est marqué SameSite=None, puisque la valeur par défaut du navigateur est SameSite=Lax. MDN précise que "if SameSite=None is set then the Secure attribute must also be set", en français : si SameSite=None est défini, l'attribut Secure doit l'être aussi, ce qui le limite à HTTPS. Sans les deux attributs, un navigateur moderne n'envoie jamais le cookie en intersites.

Google a-t-il déjà retiré les cookies third-party de Chrome ?

Non. Anthony Chavez a écrit le 22 avril 2025 que Google allait "maintain our current approach to offering users third-party cookie choice in Chrome", donc maintenir son approche actuelle consistant à laisser aux utilisateurs le choix sur les cookies third-party dans Chrome, et ne déploierait pas d'invite dédiée. Chrome autorise les cookies third-party par défaut en navigation normale et les bloque par défaut en navigation privée, selon la documentation d'aide de Chrome.

Firefox supprime-t-il les cookies third-party comme Safari ?

Non, Firefox les isole à la place. Total Cookie Protection, activée par défaut dans le monde entier depuis le 14 juin 2022, confine chaque cookie à "the cookie jar assigned to only that website", le pot à cookies attribué à ce seul site web, donc un traceur intégré obtient un cookie distinct sur chaque site où il apparaît. L'intégration continue de fonctionner, et le profil intersites ne se constitue jamais.

Que signifie CHIPS ?

CHIPS signifie Cookies Having Independent Partitioned State, le mécanisme que MDN documente derrière les cookies partitionnés. Il ajoute le site de premier niveau à la clé de stockage du cookie, si bien que le même domaine de cookie obtient une valeur distincte sur chaque site qui l'intègre. MDN classe CHIPS comme Baseline newly available depuis décembre 2025.

Qu'est-ce que la Storage Access API ?

La Storage Access API permet à une iframe intégrée de demander au navigateur l'accès à ses cookies non partitionnés, avec une invite envoyée à l'utilisateur au préalable. La politique de prévention du tracking de WebKit chez Safari la désigne comme l'unique voie de retour après le blocage de tous les cookies third-party. Les cookies partitionnés couvrent le reste de ce dont l'état inter-sites a besoin pour continuer à fonctionner.

Les cookies first-party ont-ils aussi besoin d'un consentement ?

L'article 5(3) de la directive ePrivacy demande si une information est stockée sur l'appareil ou lue depuis celui-ci, pas à qui appartient le domaine, donc un cookie first-party d'analytics déclenche la même obligation de consentement qu'un cookie third-party. Une bannière de consentement existe justement pour répondre à cette obligation, quelle que soit la catégorie du cookie. Ne stocker aucun identifiant supprime entièrement le déclencheur.

Pourquoi un visiteur récurrent est-il parfois compté comme nouveau dans les analytics ?

Un visiteur qui revient après la limite de 7 jours de l'ITP de Safari arrive sans identifiant, si bien que l'outil d'analytics démarre une nouvelle session et le compte comme nouveau. Cette règle s'applique à tout cookie écrit côté client via JavaScript, y compris les scripts d'analytics first-party sur votre propre domaine. Définir les identifiants depuis le serveur dans un en-tête de réponse Set-Cookie évite entièrement cette limite.