Cookies tiers : ce que le revirement de Chrome a réellement changé et quelles API Privacy Sandbox disparaissent

En 2026, cette description n'est déjà plus d'actualité.

Chrome n'a pas mis en place une désactivation générale et obligatoire des cookies tiers conformément à l'ancien calendrier. Google a décidé de conserver le modèle actuel, dans lequel les utilisateurs peuvent gérer l'accès à ces cookies dans les paramètres de Chrome. L'entreprise a également renoncé au projet d'introduire une nouvelle invite distincte concernant les cookies tiers.

Cela ne signifie toutefois pas un retour à la situation antérieure à Privacy Sandbox.

Les cookies tiers peuvent toujours être indisponibles en raison :

• d'une décision de l'utilisateur,
• du mode Incognito,
• des règles organisationnelles de Chrome Enterprise,
• des limitations d'un navigateur spécifique,
• des paramètres du site,
• du groupe expérimental de Chrome,
• des mécanismes de partitionnement et de protection contre le pistage.

Parallèlement, Google a décidé de retirer une grande partie des API de Privacy Sandbox, notamment Topics, Protected Audience, Attribution Reporting, Shared Storage et Related Website Sets. En revanche, les solutions utiles pour des cas d'usage fonctionnels subsistent, telles que CHIPS, Storage Access API, FedCM, le partitionnement du stockage et Private State Tokens.

Conclusion la plus importante : le revirement de Chrome ne signifie pas que l'on peut de nouveau concevoir l'authentification, les widgets intégrés, l'analytique et les paiements en partant du principe que les cookies tiers non partitionnés seront toujours disponibles. En 2026, une architecture correcte doit gérer les deux états : cookie disponible et cookie bloqué.

Statut et documentation vérifiés le 23 juillet 2026.

TL;DR

Question	Réponse pour 2026
Chrome a-t-il désactivé les cookies tiers pour tous les utilisateurs ?	Non
Chrome prévoit-il encore une nouvelle invite distincte ?	Non
L'utilisateur peut-il les bloquer ?	Oui
Sont-ils bloqués par défaut en mode Incognito ?	Oui
Une application doit-elle présumer de leur disponibilité ?	Non
L'ensemble de Privacy Sandbox disparaît-il ?	Non
Les API publicitaires telles que Topics et Protected Audience sont-elles retirées ?	Oui
CHIPS reste-t-il pris en charge ?	Oui
Storage Access API subsiste-t-il ?	Oui
FedCM subsiste-t-il ?	Oui
SameSite=None; Secure garantit-il le fonctionnement d'un cookie ?	Non
Une seule date de suppression s'applique-t-elle à toutes les API ?	Non

1. Qu'est-ce qu'un cookie tiers ?

Un cookie est une valeur enregistrée par le navigateur et transmise selon les règles du domaine, du chemin, du protocole, de la durée de vie et de l'attribut SameSite.

Un cookie est considéré comme tiers lorsqu'il est utilisé dans un contexte de site différent de celui du site affiché en haut de l'onglet du navigateur.

Exemple :

Użytkownik otwiera:
https://shop.example

Strona osadza:
https://chat.vendor.example/widget

Si un widget intégré tente d'utiliser un cookie non partitionné du domaine chat.vendor.example, il le fait dans un contexte tiers.

Une configuration typique permettant d'envoyer un cookie dans un contexte cross-site se présente ainsi :

Set-Cookie: widget_session=abc123;
  SameSite=None;
  Secure;
  HttpOnly;
  Path=/

SameSite=None autorise l'envoi du cookie dans les requêtes cross-site, et Secure est requis pour les cookies avec SameSite=None dans les navigateurs modernes.

Ce n'est toutefois qu'une condition technique. Ce n'est pas une garantie que le navigateur autorisera le cookie tiers. Un paramètre de l'utilisateur ou une politique du navigateur peut toujours le bloquer.

2. Comment le plan de Chrome a-t-il évolué ?

Étape 1 : l'annonce d'un monde sans cookies tiers

Privacy Sandbox a vu le jour comme un ensemble de propositions visant à limiter le pistage entre sites, tout en fournissant des solutions pour la publicité, la mesure, la prévention des abus et l'identité.

En janvier 2024, Chrome a commencé à restreindre les cookies tiers pour 1% des utilisateurs dans le cadre du test Tracking Protection.

Étape 2 : l'abandon du phase-out généralisé

En juillet 2024, Google a annoncé un changement de cap : au lieu d'une désactivation générale des cookies, une approche fondée sur le choix de l'utilisateur a été proposée.

Le 22 avril 2025, Google a précisé sa décision :

• Chrome conserve son approche actuelle fondée sur le choix de l'utilisateur,
• la nouvelle invite distincte ne sera pas mise en place,
• les utilisateurs continuent de gérer les cookies dans les paramètres Privacy and Security,
• le mode Incognito continue de bloquer les cookies tiers par défaut.

C'est précisément là le principal « revirement de Chrome ».

Étape 3 : la réduction de Privacy Sandbox

Le 17 octobre 2025, Google a annoncé qu'après avoir analysé l'adoption et les retours de l'écosystème, il retirerait une part importante des technologies de Privacy Sandbox.

En janvier 2026, les release notes de Chrome 144 ont mentionné la dépréciation et le retrait prévu de Private Aggregation, Shared Storage et Protected Audience.

Il ne faut cependant pas réduire l'ensemble du changement à Chrome 144. Le statut officiel couvre davantage de technologies, et le processus de leur retrait est étalé dans le temps et mené conformément aux procédures de Chrome et d'Android.

3. Que signifie « Chrome conserve son approche actuelle » ?

Cela ne signifie pas :

• une garantie de disponibilité des cookies dans chaque installation,
• un retour au pistage cross-site illimité,
• l'annulation du partitionnement du stockage,
• un comportement identique de Chrome, Safari et Firefox,
• une garantie que l'intégration SSO ou iframe existante fonctionnera.

Cela signifie que Chrome n'a pas remplacé le modèle actuel par une désactivation globale unique et une nouvelle invite couvrant l'ensemble de sa base d'utilisateurs.

La documentation officielle de Chrome décrit toujours plusieurs raisons de blocage des cookies :

• les paramètres de l'utilisateur,
• les limitations du navigateur,
• les flags de test,
• les règles de Chrome Enterprise.

La même documentation, mise à jour le 18 décembre 2025, mentionne toujours un groupe de 1% des utilisateurs pour lequel les cookies tiers sont restreints par défaut à des fins de test.

Pour un développeur, la conclusion pratique est simple :

third-party cookie availability = stan runtime,
a nie właściwość gwarantowana przez nazwę przeglądarki

4. Quelles technologies de Privacy Sandbox sont retirées ?

Le statut officiel utilise plusieurs catégories différentes :

• Deprecate and remove - l'API est destinée à être dépréciée et supprimée.
• Discontinue - le projet est arrêté ou en cours de retrait.
• Do not launch - la technologie ne sera pas lancée.
• Scheduled for phaseout - un retrait progressif est prévu.

Il ne faut pas les présenter comme une unique « désactivation de Privacy Sandbox » simultanée.

Principales technologies web destinées à la dépréciation et à la suppression

Technologie	Usage initial	Statut
Attribution Reporting API	mesure d'attribution sans identifiant cross-site	deprecate and remove
Aggregation Service	agrégation des rapports pour Attribution Reporting	scheduled for phaseout
Topics API	centres d'intérêt de l'utilisateur pour la publicité	deprecate and remove
Protected Audience API	remarketing et enchères interest-group dans le navigateur	deprecate and remove
Private Aggregation API	mesures agrégées cross-site	deprecate and remove
Shared Storage API	stockage cross-site avec des opérations contrôlées	deprecate and remove
SelectURL	choix d'une variante d'URL à partir de Shared Storage	retiré en même temps que Shared Storage
Related Website Sets	déclaration de domaines associés	deprecate and remove
requestStorageAccessFor()	demande d'accès au nom d'une ressource d'un site associé	deprecate and remove
Related Website Partition	partition partagée pour les sites associés	discontinue

Technologies arrêtées ou non lancées

Technologie	Statut
IP Protection	discontinue / scheduled for phaseout
Partitioned Popins	discontinue
Fenced Storage Read	do not launch
Private Proofs	do not launch
Probabilistic Reveal Tokens	do not launch
Script Blocking	do not launch

Android Privacy Sandbox

Google retire également :

• Attribution Reporting,
• On-Device Personalization,
• Protected App Signals,
• Protected Audience,
• SDK Runtime,
• Topics.

5. Qu'est-ce qui disparaissait exactement dans Chrome 144 ?

Chrome 144, publié en version stable en janvier 2026, comportait des entrées formelles de dépréciation pour :

• Private Aggregation API,
• Shared Storage API,
• Protected Audience API.

Les release notes évoquent un plan de dépréciation et de suppression, non une garantie que tous les éléments ont immédiatement cessé de fonctionner dans chaque installation.

C'est important lors d'une migration. Les signaux peuvent apparaître par étapes :

1. le message Intent to Deprecate,
2. des avertissements dans la console ou la documentation,
3. le changement de l'état par défaut,
4. la suppression du code,
5. un éventuel deprecation trial ou une période de transition.

L'équipe devrait suivre Chrome Platform Status et les release notes, plutôt que de se fier à une seule date tirée d'un article.

6. Qu'est-ce qui reste pris en charge ?

Privacy Sandbox ne disparaît pas comme un ensemble unique. Le statut officiel indique les technologies qui restent prises en charge.

CHIPS

CHIPS permet de marquer un cookie avec l'attribut Partitioned. Le navigateur crée un « bocal » de cookies distinct pour chaque site de premier niveau.

Set-Cookie: __Host-widget_session=abc123;
  Secure;
  HttpOnly;
  Path=/;
  SameSite=None;
  Partitioned

Si chat.vendor.example est intégré sur :

shop-a.example
shop-b.example

il obtient alors deux partitions distinctes. Un cookie défini dans le contexte de shop-a.example n'est pas accessible dans l'intégration sur shop-b.example.

CHIPS convient entre autres à :

• des widgets de chat,
• des cartes,
• des paiements intégrés,
• de l'état d'un composant par site,
• des ressources nécessitant une session limitée à un seul embedder.

CHIPS n'est pas un substitut lorsque le même identifiant doit être partagé entre des sites indépendants. C'est précisément cette impossibilité qui constitue le mécanisme de protection de la vie privée.

Storage Access API

Storage Access API permet à un document intégré de vérifier s'il a accès aux cookies non partitionnés et de demander cet accès au navigateur.

async function ensureStorageAccess() {
  if (await document.hasStorageAccess()) {
    return true;
  }

  try {
    await document.requestStorageAccess();
    return true;
  } catch {
    return false;
  }
}

L'accès :

• peut nécessiter une interaction de l'utilisateur,
• peut déclencher une invite,
• est soumis aux politiques du navigateur,
• peut être refusé,
• requiert un contexte sécurisé,
• peut être bloqué par Permissions Policy.

Il ne faut pas considérer requestStorageAccess() comme un contournement automatique de la confidentialité.

FedCM

Federated Credential Management API est destinée aux flux d'identité fédérée sans dépendance aux cookies tiers ni aux redirections de navigation classiques.

FedCM a du sens pour :

• « Se connecter via un fournisseur d'identité »,
• One Tap,
• la création de comptes fédérée,
• les flux où le navigateur sert d'intermédiaire entre le RP et l'IdP.

Ce n'est pas un substitut universel à tous les cookies. Il ne résout ni l'état d'un widget, ni l'analytique, ni chaque fonctionnalité d'OpenID Connect.

Partitionnement du stockage et de l'état réseau

Chrome continue de prendre en charge le partitionnement du stockage et de l'état réseau. L'objectif est de limiter la possibilité de relier l'activité d'un utilisateur entre différents sites de premier niveau.

Private State Tokens

Private State Tokens restent maintenus comme un mécanisme aidant à transmettre des signaux de confiance limités sans pistage classique de l'utilisateur entre les sites.

Autres éléments pris en charge

Le statut mentionne également :

• les bounce tracking mitigations,
• Fenced Frames,
• frame-ancestors,
• User-Agent Client Hints et la réduction de User-Agent.

Ils ne sont pas tous des substituts aux cookies tiers. Ce sont des mécanismes distincts de la plateforme de confidentialité et de sécurité.

7. SameSite=None; Secure suffit-il ?

Non.

C'est l'un des mythes les plus répandus.

Set-Cookie: session=abc;
  SameSite=None;
  Secure

signifie que le cookie peut être envoyé dans un contexte cross-site, si le navigateur autorise les cookies tiers non partitionnés.

Cela ne signifie pas que :

• l'utilisateur ne les a pas bloqués,
• le mode Incognito les autorisera,
• Safari ou Firefox se comporteront comme Chrome,
• Chrome Enterprise n'appliquera pas de politique,
• l'iframe dispose de Storage Access,
• un mécanisme de protection contre le pistage ne limitera pas l'accès.

Le code doit détecter la disponibilité réelle.

8. Comment détecter la disponibilité des cookies dans une intégration ?

Chrome décrit deux méthodes principales.

document.hasStorageAccess()

const hasAccess = await document.hasStorageAccess();

Cette méthode permet à un document intégré de vérifier s'il a accès aux cookies non partitionnés.

Sec-Fetch-Storage-Access

Depuis Chrome 133, les credentialed requests peuvent inclure l'en-tête :

Sec-Fetch-Storage-Access: active

Valeurs possibles :

• none,
• inactive,
• active.

Exemple côté serveur :

const storageAccess =
  request.headers.get("sec-fetch-storage-access");

if (storageAccess !== "active") {
  // Nie zakładaj dostępu do unpartitioned third-party cookies.
}

Que ne pas utiliser comme unique test ?

navigator.cookieEnabled

Cette propriété n'indique pas de manière fiable si un iframe donné a accès à un cookie tiers donné. Elle ne peut que signaler la prise en charge générale des cookies.

9. Qu'en est-il de requestStorageAccessFor() ?

Ce n'est pas la même chose que :

document.requestStorageAccess()

requestStorageAccessFor() était une extension liée à Related Website Sets, permettant à un site de premier niveau de demander l'accès au nom d'une ressource issue d'un site associé.

Comme Related Website Sets est en cours de retrait, requestStorageAccessFor() a lui aussi le statut deprecate and remove.

MDN indique que cette méthode est deprecated et non-standard.

La méthode requestStorageAccess() classique reste une voie prise en charge et internavigateurs pour les documents intégrés nécessitant un état non partitionné.

10. Conséquences pour l'authentification

Les flux les plus exposés sont ceux qui supposent qu'un IdP intégré dans un iframe lira toujours son propre cookie.

Directions possibles :

Cas	Meilleure solution
authentification fédérée	FedCM ou un flux OAuth/OIDC top-level bien conçu
session de sa propre application	cookie first-party sur le domaine de l'application
intégration nécessitant l'accès à un compte existant	Storage Access API avec une UX claire
état indépendant du widget	CHIPS
communication parent ↔ iframe	postMessage() avec validation de l'origin
backend entre ses propres services	jetons et sessions côté serveur, et non des cookies de pistage cross-site

Il ne faut pas déplacer automatiquement les jetons vers localStorage. Un tel changement ne résout pas tous les problèmes et peut aggraver les conséquences d'une attaque XSS.

11. Conséquences pour l'analytique

Le revirement de Chrome signifie que les cookies tiers n'ont pas été globalement supprimés, mais qu'ils restent une base de mesure instable.

Les données peuvent différer entre :

• les utilisateurs qui bloquent les cookies,
• le mode normal et le mode privé,
• Chrome, Safari et Firefox,
• les appareils gérés par une organisation,
• les utilisateurs disposant d'extensions de blocage,
• les déploiements avec et sans consentement.

Attribution Reporting API, qui devait être l'un des mécanismes de mesure de Privacy Sandbox, est en cours de retrait. Google déclare toutefois poursuivre ses travaux sur un standard d'attribution interopérable dans le cadre du processus de standardisation du web.

Ce n'est pas la garantie d'un substitut prêt à l'emploi.

Une approche pratique comprend :

• la mesure first-party,
• un consentement explicite là où il est requis,
• la modélisation des données manquantes,
• l'agrégation,
• la collecte server-side avec contrôle de la confidentialité,
• la mesure des limites et de la couverture des données,
• éviter de promettre un pistage complet de l'utilisateur entre les sites.

12. Conséquences pour la publicité

Trois piliers centraux de la partie publicitaire de Privacy Sandbox sont retirés :

• Topics,
• Protected Audience,
• Attribution Reporting.

À cela s'ajoutent Shared Storage, SelectURL, Private Aggregation et Aggregation Service.

Cela signifie qu'il ne faut pas démarrer une nouvelle implémentation stratégique reposant uniquement sur ces API sans vérifier le statut actuel et le plan de migration.

Cela ne signifie pas automatiquement que le secteur revient à un modèle unique et stable de publicité basée sur les cookies tiers. La disponibilité des cookies reste fragmentaire, et les autres navigateurs appliquent leurs propres mécanismes de protection.

13. Conséquences pour les widgets et les services intégrés

Un widget typique :

<iframe src="https://support.vendor.example/widget"></iframe>

peut avoir besoin :

• de reconnaître une session,
• de mémoriser des paramètres,
• d'accéder au compte de l'utilisateur,
• de communiquer avec la page parente.

Le choix de la solution doit dépendre de l'objectif :

État réservé à un seul embedder

Utilisez CHIPS.

Accès à une session existante non partitionnée

Utilisez Storage Access API, avec un fallback et un message clair.

Authentification fédérée

Envisagez FedCM.

État transmissible explicitement

Transmettez des données minimales du parent vers l'iframe via postMessage() après une validation stricte de l'origin.

14. Audit des cookies tiers

Chrome recommande un audit avec les DevTools et le Privacy Sandbox Analysis Tool.

Étape 1 : inventoriez les cookies

Pour chaque cookie, notez :

Champ	Exemple
nom	widget_session
setter	chat.vendor.example
contexte	iframe
objectif	état de la conversation
requis en cross-site ?	oui
partage entre sites requis ?	non
alternative	CHIPS

Étape 2 : recherchez SameSite=None

grep -R "SameSite=None" .

Cela ne détectera pas les cookies créés par des scripts externes, il faut donc également utiliser les DevTools et les journaux réseau.

Étape 3 : testez avec le blocage

Chrome documente le flag :

chrome://flags/#test-third-party-cookie-phaseout

ainsi que le lancement :

google-chrome --test-third-party-cookie-phaseout

La documentation recommande toujours ce mode pour tester les défaillances lorsque les cookies sont restreints.

Étape 4 : testez les parcours réels

• connexion,
• déconnexion,
• rafraîchissement du jeton,
• paiement,
• chat,
• carte,
• médias intégrés,
• consentement,
• analytique,
• paiement cross-domain,
• récupération de compte.

Étape 5 : testez différents navigateurs

Ne limitez pas les tests à Chrome. Le revirement de Chrome n'a pas modifié les politiques de Safari et Firefox.

15. Exemple de stratégie progressive pour un widget

async function initializeWidget() {
  if ("hasStorageAccess" in document) {
    const hasAccess = await document.hasStorageAccess();

    if (hasAccess) {
      return startWithUnpartitionedSession();
    }
  }

  const partitionedSession = await tryPartitionedSession();

  if (partitionedSession) {
    return startWithPartitionedSession();
  }

  return startAnonymousMode();
}

Après une action délibérée de l'utilisateur, on peut proposer l'accès :

button.addEventListener("click", async () => {
  try {
    await document.requestStorageAccess();
    location.reload();
  } catch {
    showManualLoginFallback();
  }
});

La logique doit tenir compte d'un refus. L'invite n'est pas une obligation pour l'utilisateur.

16. Que ne pas faire ?

Ne partez pas du principe que le revirement de Chrome a réglé le problème

Les cookies tiers ne constituent toujours pas une dépendance prévisible.

Ne migrez pas tout vers le fingerprinting

Remplacer les cookies par une collecte agressive des signaux de l'appareil n'est pas une solution privacy-first.

Ne déplacez pas automatiquement les sessions vers localStorage

Cela peut accroître le risque en cas de XSS et n'offre pas automatiquement la possibilité de partager des données cross-site.

N'utilisez pas CHIPS pour l'identité cross-site

CHIPS isole délibérément le cookie par top-level site.

N'utilisez pas Storage Access API sans fallback

L'accès peut être refusé.

Ne démarrez pas un nouveau projet sur une API en cours de retrait

Vérifiez le statut de Topics, Protected Audience, Attribution Reporting, Shared Storage et RWS avant tout investissement.

N'assimilez pas « deprecated » à « ne fonctionne plus »

La dépréciation et la suppression sont un processus. Vérifiez la version de Chrome et Chrome Platform Status.

17. Architecture recommandée en 2026

Pour une application ordinaire

• cookie de session first-party,
• Secure,
• HttpOnly,
• un SameSite raisonnable,
• protection CSRF,
• aucune dépendance à un iframe cross-site.

Pour un widget

• CHIPS pour un état isolé par site,
• fallback anonyme,
• Storage Access uniquement pour une fonctionnalité nécessitant une session existante,
• postMessage() avec validation de l'origin.

Pour l'authentification fédérée

• FedCM, s'il correspond à un flux pris en charge,
• une redirection OAuth/OIDC standard comme fallback compatible,
• une session first-party au retour dans l'application.

Pour l'analytique

• collecte first-party,
• consentement et minimisation des données,
• signalement explicite de la couverture manquante,
• agrégation plutôt que promesse d'une identification complète cross-site.

18. Check-list de migration

Inventaire

• Liste de tous les cookies.
• Setter et domaine identifiés.
• Contexte first-party ou tiers identifié.
• Objectif métier connu.
• Propriétaire de l'intégration connu.
• Conséquences d'un blocage connues.
• Cookies inutilisés supprimés.

Sécurité des cookies

• Secure sur les cookies de session.
• HttpOnly là où JavaScript n'a pas besoin d'accès.
• Domain minimal.
• Path minimal.
• SameSite approprié.
• Durée de vie courte.
• Préfixe __Host- là où il convient.

Cross-site

• Aucune supposition que SameSite=None garantit l'accès.
• Détection via hasStorageAccess().
• Gestion du refus de requestStorageAccess().
• CHIPS pour un état isolé.
• FedCM pour une authentification fédérée prise en charge.
• Fallback sans cookies tiers.
• Test en mode Incognito.
• Test avec blocage des cookies tiers.

Privacy Sandbox

• Aucune nouvelle dépendance à Topics.
• Aucune nouvelle dépendance à Protected Audience.
• Plan de sortie d'Attribution Reporting API.
• Plan de sortie de Shared Storage et SelectURL.
• Plan de sortie de Private Aggregation.
• Plan de sortie de Related Website Sets.
• Usage de requestStorageAccessFor() supprimé.
• Chrome release notes surveillées.

Tests

• Chrome normal.
• Chrome Incognito.
• Chrome avec blocage manuel.
• Safari.
• Firefox.
• Compte connecté et non connecté.
• Utilisateur nouveau et existant.
• Intégration sur au moins deux top-level sites.
• Mode hors ligne et erreurs d'API.
• Règles de Chrome Enterprise, si elles concernent le produit.

19. Outils POLPROG

Lors d'un audit, il est utile de combiner l'analyse des cookies avec d'autres couches :

• Santé du site aide à repérer les problèmes techniques et de performance.
• Inspecteur des en-têtes de sécurité permet de vérifier CSP, HSTS et d'autres protections.
• Inspecteur DNS et SSL vérifie la couche domaine ainsi que TLS.
• FlowTrace aide à retracer le flux d'une requête, d'une session et des données entre le navigateur, le CDN et le backend.
• La base de connaissances POLPROG contient des ressources sur la confidentialité, la sécurité et l'architecture web.

Verdict

Chrome n'a pas exécuté son ancien plan de désactivation globale des cookies tiers. Les utilisateurs conservent le choix, et la nouvelle invite distincte n'a pas été mise en place.

Cela ne signifie toutefois pas que les cookies tiers ont retrouvé le statut de standard stable sur lequel on peut fonder un produit en toute sécurité.

En 2026 :

• une partie des utilisateurs ont les cookies bloqués,
• le mode Incognito les bloque par défaut,
• les politiques organisationnelles peuvent les restreindre,
• les autres navigateurs appliquent leurs propres règles,
• le stockage est de plus en plus souvent partitionné,
• de nombreuses API publicitaires de Privacy Sandbox sont retirées,
• les solutions fonctionnelles telles que CHIPS, Storage Access API et FedCM subsistent.

La meilleure architecture ne cherche pas à deviner la future décision de Chrome. Elle fonctionne correctement, que les cookies tiers non partitionnés soient disponibles ou non.