Les cookies tiers ont de nombreux usages, mais ils sont également un élément clé du suivi multisite.
Les cookies tiers peuvent être bloqués par des restrictions du navigateur, des paramètres utilisateur, des indicateurs pour les développeurs ou des règles d'entreprise.
Vous devez faire en sorte que votre site ou service offre une expérience optimale à tous vos utilisateurs, que les cookies tiers soient disponibles ou non.
Sur cette page, vous trouverez des informations sur les solutions respectueuses de la confidentialité pour les scénarios d'intégration qui s'appuient 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 du contenu tiers (comme des vidéos ou des cartes), des composants interactifs (comme des systèmes de chat ou de commentaires, ou des services de paiement), des services de connexion, etc.
La majeure partie du travail de transition depuis les cookies tiers doit être effectuée par les développeurs d'intégrations, plutôt que par les sites qui les hébergent. Ce guide abordera principalement les solutions destinées aux développeurs qui créent des services intégrés.
Si votre site repose sur un élément intégré qui utilise des cookies tiers, assurez-vous d'auditer et de tester les parcours liés à l'intégration, et contactez les fournisseurs d'éléments intégrés si vous constatez des problèmes.
Auditer et tester vos parcours utilisateur liés à l'intégration
Pour savoir si vos intégrations sont concernées par les cookies tiers, le mieux est de tester vos parcours utilisateur d'intégration tierce avec l'indicateur de test des cookies tiers activé.
Une fois que vous avez limité les cookies tiers, testez les scénarios d'intégration courants suivants :
- 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 et maintenir votre session ?
- Contenu intégré : pouvez-vous voir le contenu vidéo ou d'autres contenus intégrés ? Les préférences des utilisateurs, comme la langue ou les sous-titres, sont-elles conservées ? Voyez-vous les annonces comme prévu (par exemple, si vous êtes abonné Premium, vous ne devriez pas les voir) ?
- Connexion : les connexions, y compris les connexions SSO (authentification unique), fonctionnent-elles pour les intégrations qui les acceptent ? Sont-ils conservés lorsque la page est actualisée et lorsque l'utilisateur accède à des pages qui utilisent 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 : pouvez-vous effectuer des paiements ?
Dans les sections suivantes, vous trouverez des informations plus spécifiques sur la façon dont ces flux peuvent être affectés.
Cas d'utilisation courants
Il existe plusieurs API qui peuvent être utilisées pour les intégrations qui reposent traditionnellement sur des cookies tiers. Le tableau suivant répertorie certains workflows courants et les API recommandées à utiliser comme résumé général. Les sections suivantes expliqueront le raisonnement de ces recommandations.
| Cas d'utilisation | API recommandée pour l'utilisation de cookies tiers |
|---|---|
| Widget de chat | CHIPS |
| Intégrations de cartes | CHIPS |
| Domaines de bac à sable pour le contenu utilisateur non fiable (tels que googleusercontent.com et githubusercontent.com) qui nécessitent un état limité à chaque éditeur |
CHIPS |
| Annonces intégrées dont l'état doit être défini par éditeur | CHIPS |
| Se connecter via un fournisseur d'identité | FedCM |
| Intégrations hébergées sur des origines différentes, mais liées. | API Storage Access avec les ensembles de sites Web associés |
| Contenus intégrés avec des préférences basées sur la connexion (comme des contenus vidéo sans publicité ou des préférences de langue/sous-titres) |
API Storage Access |
| Widget de commentaires sur les réseaux sociaux nécessitant une connexion | API Storage Access |
Choisir l'API appropriée pour les cas d'utilisation tiers intégrés
Cette section explique comment choisir une API alternative appropriée et présente les API recommandées.
L'organigramme suivant vous aide à choisir parmi les options disponibles :
L'organigramme pose trois questions principales. Nous allons les 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 nombreux composants intégrés tiers sont utilisés de manière indépendante sur des sites sans aucun rapport. Par exemple, les widgets de chat pour le service client nécessitent souvent des cookies pour fonctionner, mais n'ont pas besoin de partager ces cookies entre deux organisations complètement différentes qui utilisent toutes les deux 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 de cookies.
Si vous fournissez un service d'intégration tiers à d'autres sites et qu'il repose sur des cookies, déterminez si ces cookies sont spécifiques au service sur le site sur lequel il est intégré. Sont-ils déjà partagés par des instances de votre intégration 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 leur permettre d'être partagés par tous les sites qui utilisent le même contenu intégré tiers. CHIPS est facile à implémenter, car il suffit d'ajouter un attribut Partitioned aux cookies existants. Cela permet aux services intégrés de continuer à enregistrer l'état, mais supprime le stockage partagé multisite qui permettrait le suivi multisite.
Les sites doivent également vérifier si les cookies sont utilisés pour les bonnes raisons. Les cookies ne doivent être utilisés que lorsqu'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 ne sont utilisés que comme option de stockage pratique, il convient d'envisager 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 les cookies CHIPS.
2. Les cookies appartiennent-ils à un fournisseur d'identité tiers ?
Les cookies tiers sont souvent utilisés dans les éléments intégrés pour fournir des fonctionnalités de connexion gérées par un fournisseur de connexion tiers, comme Se connecter avec Google. Les cookies partitionnés ne sont pas une option dans ce cas.
Federated Credential Management (FedCM) est une API dédiée à ce cas d'utilisation. Elle fonctionne sans cookies tiers. Si FedCM est compatible avec le fournisseur d'identité, les cookies tiers ne seront peut-être plus nécessaires.
Pour en savoir plus sur la façon de gérer les effets 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 remplace les cookies de manière appropriée, vous devez réactiver l'accès aux cookies tiers pour l'intégration. Cette fonctionnalité peut être activée dans des cas d'utilisation spécifiques et contrôlés avec l'API Storage Access. Cette API réactive l'accès complet aux cookies tiers (sous réserve des contrôles). Il s'agit donc de l'option la plus puissante. C'est pourquoi nous vous recommandons de l'éviter si une alternative plus restrictive suffit.
Pour utiliser l'API Storage Access, vous devez remplir certaines conditions :
- L'utilisateur doit avoir déjà consulté le site de l'intégration au premier niveau. Par exemple, si vous intégrez un système de commentaires, l'utilisateur doit également visiter le site de ce système de commentaires.
- L'utilisateur doit interagir avec l'intégration avant que les cookies puissent être partagés. Cela signifie qu'il peut être impossible de charger l'intégralité du contenu intégré avant l'interaction de l'utilisateur.
- L'utilisateur devra peut-être approuver le partage de cookies avec une fenêtre pop-up du navigateur, en particulier lors de la première instance et périodiquement par la suite.
- Le site d'intégration peut également avoir besoin de définir des attributs de bac à sable supplémentaires.
Ces restrictions permettent de s'assurer que l'action puissante de réactivation des cookies tiers n'est effectuée que 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 lui redemander l'autorisation pendant un certain temps (défini par le navigateur).
Un autre scénario dans lequel l'utilisateur s'attend probablement à ce que cela se produise concerne les sites associés. Par exemple, certaines organisations utilisent plusieurs origines différentes, qui sont considérées comme inter-sites par le navigateur. L'utilisation de cookies sur ces origines est donc traitée comme tierce. Il peut s'agir de marques avec des sites spécifiques à un pays (comme example.com et example.co.uk) ou de sites Web spécifiques à une marque (comme example.car et example.house).
Dans ce cas, où le nombre de sites Web associés est faible, vous pouvez utiliser les ensembles de sites Web associés. Les sites sont envoyés à Chrome pour que le navigateur sache qu'ils sont associés. Cela permet d'accéder à l'API Storage Access de manière plus conviviale, avec moins d'invites utilisateur.
Pour les sites Web non associés qui sont en fait des tiers et pour lesquels un accès complet aux cookies tiers est requis, car les autres API ne sont pas suffisantes, l'utilisation de l'API Storage Access sera soumise à l'ensemble des exigences et des invites.
Comparaison des différentes API
Chacune de ces solutions présente des caractéristiques et des limites légèrement différentes qui les rendent plus adaptées à 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 déjà accédé à la partie intégrée en tant que site de premier niveau. | |||||
| Ne nécessite pas d'invite à l'utilisateur pour approuver l'accès | |||||
| Ne nécessite pas d'interaction de l'utilisateur avec l'intégration | (Cela peut également être vrai pour les sites intégrés avec un accès de niveau supérieur.) |
||||
| Effort d'implémentation | Très faible | Faible | Élevée | Moyenne | Moyenne |
| Peut être utilisé pour partager des cookies sur plusieurs sites/origines de premier niveau | (Proposition en cours de discussion.) |
||||
| Disponible sur les navigateurs autres que Chromium | (Utilise l'API Storage Access.) |
Prendre en charge les cas d'utilisation dans les navigateurs
Comme indiqué dans la dernière ligne du tableau, la compatibilité du navigateur est l'un des principaux facteurs à prendre en compte lors du choix d'une solution. Certaines API (CHIPS, FedCM, ensembles de sites Web associés) ne sont disponibles que sur les navigateurs Chromium. Les deux seules solutions cross-browser actuellement disponibles sont les API de stockage partitionné (lorsque les cookies ne sont pas nécessaires) et l'API Storage Access (lorsque les cookies sont nécessaires).
Toutefois, comme indiqué précédemment, l'API Storage Access comporte un certain nombre de restrictions qui peuvent affecter l'expérience utilisateur sur votre site Web. L'équipe Chrome s'est efforcée d'ajouter les autres API, qui sont conçues pour répondre à des cas d'utilisation spécifiques et offrir une expérience similaire à celle qui était possible avec les cookies tiers. Il est donc recommandé de réfléchir aux meilleures options et de les traiter comme des améliorations progressives, avec un retour à l'API Storage Access pour les navigateurs non compatibles.
Étant donné que les cookies peuvent être bloqués pour plusieurs raisons (par exemple, les paramètres du navigateur ou les extensions), la détection de la compatibilité des fonctionnalités avec les API peut ne pas être suffisante. Il est préférable de tester l'existence des cookies attendus et, dans le cas contraire, de revenir au workflow de l'API Storage Access pour demander l'accès aux cookies tiers.
Agissez dès maintenant !
Si votre intégration tierce ne fonctionne plus sans cookies tiers, plusieurs solutions sont disponibles pour résoudre les problèmes potentiels, comme indiqué dans cette présentation. Le moment est venu d'auditer votre service vis-à-vis des cookies tiers. C'est maintenant !
Si vous rencontrez des problèmes avec vos intégrations maintenant que Chrome teste la suppression des cookies tiers, vous disposez de plusieurs options à court terme pour vous aider à migrer vers les alternatives décrites dans cet article. Pour en savoir plus, consultez la documentation sur la préservation des expériences utilisateur critiques.
Si vous avez des questions sur les 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 le tag "third-party cookie deprecation" (abandon des cookies tiers) dans notre dépôt d'assistance aux développeurs.