Comment les cookies partitionnés CHIPS donnent à chaque site son propre pot

Que sont les cookies partitionnés CHIPS ?

Les navigateurs rangent les cookies partitionnés CHIPS dans un pot séparé pour chaque site de premier niveau, si bien que le cookie posé par un widget de support intégré sur retail.example reste illisible pour ce même widget intégré sur news.example. CHIPS signifie Cookies Having Independent Partitioned State et repose sur un seul attribut à activer volontairement : ajoutez Partitioned à l'en-tête Set-Cookie et le navigateur stocke le cookie sous deux clés au lieu d'une, l'hôte qui l'a posé et le site de premier niveau sous lequel il a été posé. Ajoutez-le à tout cookie intersite limité à un seul site de premier niveau, comme une session de chat, une indication de répartition de charge d'un CDN ou une position enregistrée sur une carte.

La double clé est ce qui sépare CHIPS du cookie third-party classique, qui suit le service intégré partout et alimente le suivi intersite. Un cookie partitionné ne peut pas quitter le site où il est né, donc un service intégré reçoit un identifiant neuf par site de premier niveau et rien à relier entre eux. Si les deux catégories se confondent pour vous, commencez par les cookies first-party et third-party.

Qu'exige l'attribut Partitioned ?

L'attribut Partitioned exige Secure, et les navigateurs jettent tout cookie partitionné qui arrive sans lui. L'explainer CHIPS du W3C Privacy Community Group donne cette consigne aux implémenteurs : "User agent must reject any cookie set with Partitioned that does not also include the Secure." En français : l'agent utilisateur doit rejeter tout cookie posé avec Partitioned qui n'inclut pas aussi Secure. La documentation Privacy Sandbox de Google le répète pour les développeurs : "Partitioned cookies must be set with Secure.", autrement dit les cookies partitionnés doivent être posés avec Secure. Le brouillon de l'IETF draft-cutler-httpbis-partitioned-cookies-01 du 10 novembre 2022 en donne la raison dans ses considérations de sécurité : "This proposal takes the opportunity of defining the semantics of a new cookie attribute in order to require the Secure attribute, restricting this feature to secure protocols." En français : cette proposition profite de la définition de la sémantique d'un nouvel attribut de cookie pour exiger l'attribut Secure, ce qui réserve cette fonctionnalité aux protocoles sécurisés.

Le Path=/ présent dans chaque exemple officiel vient d'une deuxième règle, portée par le préfixe de nom __Host- et non par Partitioned lui-même. La RFC 6265bis, brouillon 22 de décembre 2025, section 4.1.3.2, la définit : "If a cookie's name begins with a case-sensitive match for the string __Host-, then the cookie will have been set with a Secure attribute, a Path attribute with a value of /, and no Domain attribute." En français : si le nom d'un cookie commence par la chaîne __Host-, casse comprise, alors le cookie a été posé avec un attribut Secure, un attribut Path de valeur / et aucun attribut Domain. Nommez le cookie __Host-something et le navigateur impose Path=/ à votre place en rejetant tout le reste. L'explainer CHIPS recommande le préfixe sans l'exiger : "Although it is not required, it is still recommended to still include the __Host- prefix." Les navigateurs qui ignorent Partitioned appliquent quand même __Host-, donc le préfixe apporte la liaison à l'hôte sur des clients qui n'ont jamais entendu parler de CHIPS.

SameSite est la troisième pièce. L'explainer indique que les agents utilisateurs peuvent n'accepter Partitioned que lorsque SameSite vaut None, et un cookie conçu pour fonctionner dans un cadre intersite a de toute façon besoin de SameSite=None. Consultez le guide des cookies du navigateur pour débutants pour voir comment les attributs interagissent.

Qu'est-ce que la clé de partition, exactement ?

La clé de partition est le site de la page affichée dans la barre d'adresse, pas le site du service intégré. L'explainer CHIPS la définit avec précision : "A cookie's partition key is the site (i.e. scheme and registrable domain) of the top-level URL the browser was visiting at the start of the request to the endpoint that set the cookie." En français : la clé de partition d'un cookie est le site, c'est-à-dire le schéma et le domaine enregistrable, de l'URL de premier niveau que le navigateur visitait au début de la requête vers l'endpoint qui a posé le cookie. Deux mots y font un vrai travail. "Site" désigne le domaine enregistrable, donc support.shoppy.example et checkout.shoppy.example partagent une partition. "Scheme" fait entrer le protocole dans la clé, donc http://shoppy.example et https://shoppy.example n'en partagent pas.

Chrome ajoute un champ de plus. Chrome Platform Status consigne le changement : "Chrome 128 adds a cross-site ancestor bit to the keying of the partitioned cookie's CookiePartitionKey." En français : Chrome 128 ajoute un bit d'ancêtre intersite à la construction de la clé CookiePartitionKey du cookie partitionné. Ce bit indique si un cadre intersite se trouve entre le document de premier niveau et le cadre qui envoie la requête, ce qui empêche un service intégré d'atteindre les propres cookies partitionnés du site de premier niveau via une iframe imbriquée. Depuis Chrome 128, la clé est un triplet : schéma, domaine enregistrable, bit d'ancêtre.

À quoi ressemble un vrai en-tête Set-Cookie ?

Un cookie partitionné est un en-tête Set-Cookie ordinaire qui porte quatre attributs. Voici l'exemple que publient la documentation Privacy Sandbox de Google et MDN, caractère pour caractère :

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

Cette réponse doit arriver en HTTPS, puisque Secure et __Host- exigent tous deux une origine sécurisée. Lors d'une requête ultérieure vers le même service intégré sous le même site de premier niveau, le navigateur renvoie le cookie tel quel :

Cookie: __Host-example=34d8g

Passez sur un autre site de premier niveau et ce second en-tête disparaît. Le service intégré ne voit aucun cookie et génère une nouvelle valeur, ce qui est tout l'intérêt.

Quels navigateurs acceptent l'attribut Partitioned ?

Trois moteurs l'acceptent. Ces versions proviennent des données de compatibilité des navigateurs de MDN pour Partitioned.

MDN classe les cookies partitionnés comme Baseline newly available depuis décembre 2025. Les clients qui ne reconnaissent pas l'attribut l'ignorent et traitent le cookie comme un cookie SameSite=None ordinaire, donc votre solution de repli est ce que ce navigateur fait des cookies third-party. Dans Safari, le repli est nul, car Intelligent Tracking Prevention les bloque purement et simplement et plafonne les cookies posés par script avec la limite de 7 jours des cookies Safari.

Combien un service intégré peut-il stocker dans une seule partition ?

Chrome plafonne une partition à 180 cookies et 10 KB par site intégré. Sa documentation CHIPS le dit directement : "Chrome has a limit of maximum 180 cookies per partition that cannot exceed 10 KB per-embedded-site." En français : Chrome impose une limite de 180 cookies au maximum par partition, qui ne peuvent pas dépasser 10 KB par site intégré. Le plafond en octets est atteint en premier pour la plupart des services intégrés, donc le chiffre à vérifier est :

octets de partition utilisés = nombre de cookies x octets moyens par cookie

Un service intégré qui stocke 20 cookies de 500 octets en moyenne chacun utilise 20 x 500 = 10 000 octets et touche le plafond de 10 KB avec 160 des 180 places encore libres. Au-delà du budget en octets, le navigateur supprime des cookies, donc budgétez par taille, pas par nombre.

Chrome supprime-t-il toujours les cookies third-party ?

Non. La dernière annonce de Google sur Privacy Sandbox, "Update on Plans for Privacy Sandbox Technologies" d'Anthony Chavez, VP of Privacy Sandbox, datée du 17 octobre 2025, renvoie à la décision antérieure "that Chrome will maintain our current approach to offering users third-party cookie choice in Chrome.", soit que Chrome conserve son approche actuelle, qui laisse aux utilisateurs le choix sur les cookies third-party. Aucune suppression à l'échelle du navigateur n'est prévue et aucune nouvelle invite n'arrive. Chrome autorise les cookies third-party en navigation normale et les bloque en navigation privée.

C'est cette même annonce qui justifie de construire sur CHIPS. Elle a mis à la retraite l'Attribution Reporting API, Protected Audience, Topics, Private Aggregation et Related Website Sets, puis a désigné CHIPS pour le traitement inverse : "CHIPS and FedCM, which improve cookie privacy and security and streamline identity flows respectively, have seen broad adoption, including support from other browsers. We'll continue to support those APIs and evaluate opportunities for future enhancements." En français : CHIPS et FedCM, qui améliorent respectivement la confidentialité et la sécurité des cookies et simplifient les flux d'identité, ont été largement adoptés, y compris par d'autres navigateurs. Nous continuerons à prendre en charge ces API et à étudier des améliorations futures. Related Website Sets figure sur la liste des retraits. CHIPS non.

Qu'est-ce que cela change pour vos analytics ?

Des analytics qui ne posent aucun cookie échappent à la question. Le partitionnement résout un problème que vous n'avez que lorsqu'un script mémorise un visiteur via le stockage du navigateur, donc le suivi sans cookies supprime le mode de défaillance au lieu de l'isoler. Les analytics sans cookies hébergées dans l'UE de Flowsery enregistrent les sessions et les replays sans cookies, il n'y a donc aucune clé de partition à mal configurer.

Le calcul s'inverse si votre produit fournit un widget que d'autres entreprises intègrent. Ce widget a besoin d'un état, le site de premier niveau ne vous appartient pas, et CHIPS le fait fonctionner. Ajoutez Partitioned, utilisez le préfixe __Host-, gardez SameSite=None; Secure et testez la première requête dans une partition vierge, car ce chemin s'exécute désormais sur chaque nouveau site client.

Questions fréquentes

L'attribut Partitioned a-t-il besoin de Path=/ ?

Pas du fait de Partitioned lui-même. L'explainer CHIPS, le brouillon de l'IETF et la documentation CHIPS de Google omettent tous Path=/ des exigences de l'attribut. Il apparaît dans chaque exemple officiel parce que ces exemples utilisent le préfixe __Host-, et la RFC 6265bis impose aux cookies __Host- un Path de / et aucun attribut Domain.

Le préfixe __Host- est-il obligatoire pour les cookies partitionnés ?

Non. L'explainer CHIPS dit que le préfixe "is not required" mais reste "still recommended", c'est-à-dire qu'il n'est pas obligatoire mais reste recommandé, donc un cookie partitionné sans préfixe est accepté. Utilisez-le quand même : les navigateurs qui ignorent Partitioned appliquent toujours le préfixe et lient votre cookie à l'hôte exact.

Les cookies partitionnés nécessitent-ils toujours un consentement au titre du GDPR ?

Oui. Le partitionnement change qui peut lire un cookie, pas le fait qu'il atterrisse sur l'appareil. L'exigence de consentement de la directive ePrivacy s'applique au stockage d'informations dans l'équipement terminal d'un utilisateur ou à l'accès à ces informations, et un cookie partitionné fait les deux. Les cookies strictement nécessaires restent exemptés dans les deux cas.

Un site de premier niveau peut-il effacer les cookies partitionnés d'un service intégré ?

Non. L'explainer CHIPS précise que les sites de premier niveau ne doivent pas pouvoir effacer les cookies des tiers dans leur partition, car un site hôte pourrait alors interférer avec le code des cadres intégrés. Un service intégré efface sa propre partition en envoyant Clear-Site-Data, qui ne touche que la partition du site de premier niveau actuel.

En quoi CHIPS diffère-t-il du partitionnement d'état de Firefox ?

Firefox partitionne par défaut le stockage des cookies third-party, sans action de la part du site. CHIPS est un attribut qu'un service ajoute délibérément, et il s'applique aussi bien en contexte first-party qu'en contexte third-party. MDN recommande l'activation de CHIPS plutôt que le partitionnement d'état, parce que l'attribut explicite est le plus compatible d'un navigateur à l'autre.

Qu'est-ce qui remplace CHIPS si un service intégré a besoin d'un seul cookie sur plusieurs sites ?

La Storage Access API. Related Website Sets couvrait ce cas en déclarant un groupe de domaines liés, et l'annonce de Google du 17 octobre 2025 l'a rangé parmi les technologies retirées. La Storage Access API demande à l'utilisateur la permission d'utiliser un stockage non partitionné dans un cadre intersite, et c'est la voie prise en charge qui reste pour un état partagé.

Partitioned fonctionne-t-il avec SameSite=Lax ou SameSite=Strict ?

L'explainer de CHIPS autorise les navigateurs à n'accepter Partitioned que lorsque SameSite vaut None, donc un cookie en Lax ou Strict peut rester non partitionné malgré l'attribut. Cette association correspond à l'usage, car un cookie partitionné compte dans un embed intersite, et un embed a besoin de SameSite=None pour recevoir un cookie. Définissez SameSite=None; Secure avec Partitioned et la question ne se pose plus.

Que se passe-t-il quand une partition dépasse la limite de 10 Ko de Chrome ?

Chrome impose une limite de 180 cookies et 10 Ko par partition pour chaque site intégré, et dès que le stockage franchit l'une des deux limites, le navigateur évince des cookies de cette partition. La limite en octets se déclenche généralement en premier : une poignée de cookies de quelques centaines d'octets chacun peut remplir 10 Ko pendant que des dizaines des 180 emplacements restent libres. Calculez votre budget sur le total d'octets stockés par site de premier niveau, pas sur le nombre de cookies posés.

Peut-on poser un cookie partitionné en HTTP simple ?

Secure l'en empêche. L'attribut Partitioned exige Secure, et le brouillon de l'IETF cite justement cette association comme la raison de définir ce nouvel attribut, restreignant la fonctionnalité aux protocoles sécurisés. Un en-tête Set-Cookie envoyé en HTTP simple perd à la fois Partitioned et le cookie qui le porte.

Qu'est-ce que le bit d'ancêtre cross-site dans la clé de partition de Chrome ?

Depuis Chrome 128, la clé de partition gagne un troisième champ, en plus du schéma et du domaine enregistrable, qui indique si un frame cross-site se trouve entre le document de premier niveau et le frame à l'origine de la requête. Ce bit d'ancêtre empêche un service intégré d'atteindre les propres cookies partitionnés du site de premier niveau via un iframe imbriqué. Les versions plus anciennes de Chrome et les autres navigateurs ne clés les partitions que sur le schéma et le domaine enregistrable.