Les cookies tiers ont de nombreuses utilisations, mais ils sont également un outil essentiel pour le suivi intersites. Chrome a restreint les cookies tiers pour 1% des utilisateurs à partir du 1er trimestre 2024 afin de faciliter les tests. De plus, Chrome prévoit d'abandonner progressivement les cookies tiers pour 100% des utilisateurs à partir de début 2025, sous réserve de répondre aux préoccupations de la Concurrence and Markets Authority (CMA) du Royaume-Uni.
Sur cette page, vous trouverez des informations sur les solutions protégeant la confidentialité pour les scénarios intégrés qui s'appuyaient traditionnellement sur des cookies tiers, ainsi que des stratégies pour vous aider à choisir la solution qui répond le mieux à vos besoins.
Les services intégrés incluent les contenus tiers (tels que les vidéos ou les cartes), les composants interactifs (chat, les systèmes de commentaires ou les services de paiement, par exemple), les services de connexion, etc.
L'essentiel du travail de transition à partir des cookies tiers doit être effectué par des développeurs d'intégrations, et non par des sites hébergeant des intégrations. Ce guide traite principalement des solutions destinées aux développeurs qui créent des services intégrés.
Si votre site repose sur une intégration qui utilise des cookies tiers, veillez à auditer et à tester vos parcours liés à l'intégration, et contactez les fournisseurs d'intégration si vous constatez un dysfonctionnement.
Auditer et tester les parcours utilisateur liés aux intégrations
Le meilleur moyen de déterminer si vos intégrations sont concernées par l'abandon des cookies tiers est de tester vos parcours utilisateur intégrés tiers en activant l'indicateur de test de suppression progressive des cookies tiers.
Une fois que vous avez restreint les cookies tiers, testez ces scénarios d'intégration courants:
- Widgets de chat:pouvez-vous démarrer une session de chat ? Pouvez-vous actualiser la page sans perdre votre session ? Pouvez-vous accéder à d'autres pages tout en conservant votre session ?
- Intégrations de contenu:pouvez-vous afficher du contenu vidéo ou d'autres contenus intégrés ? Les préférences des utilisateurs, telles que la langue ou les sous-titres, sont-elles conservées ? Des annonces s'affichent-elles au moment opportun (par exemple, lorsque les utilisateurs ne font pas partie des abonnés Premium) ?
- Connexion:les connexions, y compris les connexions d'authentification unique (SSO), fonctionnent-elles pour les intégrations compatibles ? Sont-ils conservés en cas d'actualisation des pages et de navigation vers des pages utilisant les mêmes intégrations ?
- Widgets de commentaires:pouvez-vous laisser des commentaires, cliquer sur "J'aime" et voter pour des commentaires ?
- Solutions de paiement intégrées:parvenez-vous à finaliser des paiements ?
Dans les sections suivantes, vous trouverez des informations plus spécifiques sur la manière dont ces flux peuvent être affectés.
Cas d'utilisation courants
Il existe un certain nombre d'API qui dépendent traditionnellement des cookies tiers pour les intégrations. Le tableau suivant répertorie certains workflows courants et les API recommandées à utiliser comme synthèse. Les sections suivantes expliquent le raisonnement de ces recommandations.
| Cas d'utilisation | API recommandée pour l'utilisation de cookies tiers |
|---|---|
| Widget Chat | CHIPS |
| Intégrations de carte | CHIPS |
| Domaines de bac à sable pour les contenus utilisateur non approuvés (comme googleusercontent.com et githubusercontent.com) qui doivent être associés à un état spécifique par éditeur |
CHIPS |
| Annonces intégrées dont l'état doit être limité par éditeur | CHIPS |
| Se connecter via un fournisseur d'identité | FedCM |
| Intégration hébergée sur des origines différentes, mais liées. | API Storage Access avec les ensembles de sites Web associés |
| Contenu intégré avec des préférences basées sur la connexion (par exemple, contenu vidéo sans annonce ou préférences linguistiques/sous-titres) |
API Storage Access |
| Widget de commentaires sur les réseaux sociaux nécessitant une connexion | API Storage Access |
Choisir l'API à utiliser pour les cas d'utilisation tiers intégrés
Cette section explique comment choisir une API alternative appropriée et décrit les API recommandées.
L'organigramme suivant vous permet de choisir parmi les options disponibles:
L'organigramme pose trois questions principales que nous allons examiner plus en détail et expliquer pourquoi une API donnée est recommandée dans chaque cas.
1. Les cookies sont-ils spécifiques au site d'intégration ?
De nombreuses intégrations tierces sont utilisées indépendamment sur des sites totalement indépendants. Par exemple, les widgets de chat du service client nécessitent souvent des cookies pour fonctionner, mais n'ont pas besoin de les partager entre deux organisations complètement différentes, qui utilisent la même solution de widget de chat. En fait, dans de nombreux cas, il serait préférable de ne même pas autoriser le partage des cookies.
Si vous fournissez un service d'intégration tiers à d'autres sites et qu'il repose sur des cookies, déterminez s'ils sont spécifiques au service du site sur lequel il est intégré. Sont-elles déjà partagées par des instances de votre élément intégré sur d'autres sites ?
Si les cookies n'ont pas besoin d'être partagés, le partitionnement des cookies à l'aide de CHIPS est l'option la plus simple. Cette API associe les cookies tiers au site de premier niveau, au lieu de les partager entre tous les sites qui utilisent la même intégration tierce. CHIPS est facile à implémenter, car il suffit d'ajouter un attribut Partitioned supplémentaire aux cookies existants. Cela permet aux services intégrés de conserver l'état, mais supprime le stockage intersite partagé qui permettrait le suivi intersites.
Les sites doivent également vérifier si les cookies sont utilisés pour les bonnes raisons. Les cookies ne doivent être utilisés que s'ils sont définis ou doivent être envoyés avec des requêtes HTTP. Si ce n'est pas le cas et que les cookies sont seulement une option de stockage pratique, envisagez plutôt d'utiliser les différentes API de stockage. Cela permet de conserver les données en local lorsqu'elles n'ont pas besoin d'être envoyées. Les API de stockage sont déjà partitionnées dans tous les principaux navigateurs, de la même manière que CHIPS partitionne les cookies.
2. Les cookies sont-ils ceux d'un fournisseur d'identité tiers ?
Les cookies tiers sont fréquemment utilisés dans les intégrations pour fournir des fonctionnalités de connexion gérées par un fournisseur de connexion tiers, tel que Se connecter avec Google. Les cookies partitionnés ne sont pas possibles dans ce cas.
L'API Federated Credential Management (FedCM) est spécifiquement conçue pour ce cas d'utilisation et fonctionne sans cookies tiers. Si FedCM est accepté par le fournisseur d'identité, les cookies tiers risquent d'être inutiles.
Pour en savoir plus sur les effets de l'abandon des cookies tiers sur les workflows de connexion, consultez le guide sur l'identité.
3. Les cookies sont-ils utilisés sur un petit nombre de sites associés ?
Si aucune des options précédentes ne peut remplacer les cookies, vous devez envisager de réactiver l'accès aux cookies tiers pour l'intégration. Vous pouvez activer cette fonctionnalité dans des cas d'utilisation spécifiques et contrôlés à l'aide de l'API Storage Access. Cette API réactive l'accès complet aux cookies tiers (sous réserve de certains contrôles), ce qui en fait l'option la plus puissante. C'est pourquoi la recommandation consiste à l'éviter si une alternative plus restrictive suffirait.
L'utilisation de l'API Storage Access répond à quelques exigences:
- L'utilisateur doit avoir visité au préalable le site de l'intégration, au niveau supérieur. Par exemple, s'il intègre un système de commentaires, l'utilisateur doit également consulter le site de ce système.
- L'utilisateur doit interagir avec l'intégration pour pouvoir partager les cookies. Cela signifie qu'il peut ne pas être possible de charger l'intégralité du contenu intégré avant toute interaction de l'utilisateur.
- L'utilisateur devra peut-être approuver le partage des cookies à l'aide d'un pop-up de navigateur, en particulier lors de la première instance et de façon périodique par la suite.
- Le site d'intégration peut également devoir définir des attributs de bac à sable supplémentaires.
Ces restrictions garantissent que la réactivation des cookies tiers est efficace uniquement lorsque l'utilisateur et le site s'y attendent. Toutefois, dans certains cas, les actions de l'utilisateur peuvent être ignorées. Par exemple, si l'utilisateur a récemment approuvé l'accès, il n'est peut-être pas nécessaire de le relancer pendant un certain temps (tel que défini par le navigateur).
Un autre scénario dans lequel l'utilisateur est susceptible de s'y attendre concerne les sites associés. Par exemple, certaines organisations utilisent un certain nombre d'origines différentes, que le navigateur considère comme intersite. L'utilisation des cookies entre ces organisations est donc considérée comme tierce. Il peut s'agir, par exemple, de marques possédant des sites spécifiques à un pays (comme example.com et example.co.uk) ou des sites Web spécifiques à une marque (comme example.car et example.house).
Dans ce cas, là où il existe peu de sites Web associés, vous pouvez utiliser les Ensembles de sites Web associés. Les sites sont envoyés à Chrome afin que Chrome soit informé qu'ils sont liés. L'accès à l'API Storage Access est ainsi plus convivial, avec moins d'invites.
Pour les sites Web non liés qui sont en fait des tiers et pour lesquels l'accès complet aux cookies tiers est requis parce que les autres API ne sont pas suffisantes, l'utilisation de l'API Storage Access est soumise à des exigences et à des invites complètes.
Comparaison des différentes API
Chacune des solutions présente des caractéristiques et des limites légèrement différentes, ce qui en fait un meilleur choix pour certains cas d'utilisation. Le tableau suivant récapitule les principales différences:
| CHIPS | Stockage partitionné | FedCM | API Storage Access avec les ensembles de sites Web associés | API Storage Access | |
|---|---|---|---|---|---|
| L'utilisateur n'a pas besoin d'avoir préalablement accédé au tiers intégré en tant que site de premier niveau | |||||
| Ne nécessite pas d'invite de l'utilisateur pour approuver l'accès | |||||
| Ne nécessite pas que l'utilisateur interagisse avec l'élément intégré | (Cela peut également être vrai pour les sites intégrés avec un accès de niveau supérieur.) |
||||
| Effort de mise en œuvre | Très faible | Faible | Élevée | Moyenne | Moyenne |
| Permettent de partager des cookies entre plusieurs sites/origines de premier niveau | (Proposition en disucussion.) |
||||
| Disponible sur les navigateurs autres que Chromium | (Reviens à l'API Storage Access.) |
Prise en charge des cas d'utilisation sur différents navigateurs
La compatibilité du navigateur est l'un des principaux facteurs à prendre en compte lorsque vous choisissez une solution, comme indiqué à la dernière ligne du tableau. Certaines API (CHIPS, FedCM et les ensembles de sites Web associés) ne sont disponibles que dans les navigateurs Chromium. À l'heure actuelle, les deux seules solutions multinavigateurs sont les API de stockage partitionnées (lorsque les cookies ne sont pas nécessaires) ou l'API Storage Access (lorsque les cookies sont requis).
Toutefois, comme indiqué précédemment, l'API Storage Access est soumise à un certain nombre de restrictions qui peuvent affecter l'expérience utilisateur sur votre site Web. L'équipe Chrome s'est attachée à ajouter d'autres API, conçues pour répondre à des cas d'utilisation spécifiques et fournir une expérience semblable à ce qui était possible avec les cookies tiers. Il est donc recommandé d'identifier les meilleures options et de les considérer comme des améliorations progressives, avec une solution de remplacement à l'API Storage Access pour les navigateurs non compatibles.
Étant donné que les cookies peuvent être bloqués pour plusieurs raisons (par exemple, en raison des paramètres du navigateur ou des extensions), la détection des fonctionnalités de la prise en charge de l'API peut ne pas être suffisante. Il est préférable de tester si les cookies attendus existent et, si ce n'est pas le cas, de revenir au workflow de l'API Storage Access pour demander l'accès aux cookies tiers.
Agissez dès maintenant !
Si votre élément intégré tiers ne fonctionne plus sans l'utilisation de cookies tiers, il existe plusieurs solutions permettant de remédier à l'impact potentiel, comme détaillé dans cette présentation. Le moment est venu d'auditer votre service et de vous préparer à l'abandon des cookies tiers c'est maintenant !
Pour ceux qui rencontrent des dysfonctionnements dans leurs intégrations, alors que Chrome teste actuellement la suppression des cookies tiers, il existe un certain nombre d'options pour obtenir de l'aide à court terme lors de la migration vers des alternatives décrites dans cet article. Pour en savoir plus, consultez la documentation expliquant comment préserver les expériences utilisateur critiques.
Si vous avez des questions sur des cas d'utilisation d'intégrations tierces qui ne sont pas abordés dans ce guide, vous pouvez signaler un nouveau problème en utilisant la balise "abandon des cookies tiers" dans notre référentiel d'assistance pour les développeurs.