Les cookies tiers ont de nombreuses utilisations, mais ils jouent aussi un rôle clé dans le suivi intersites.
Chrome propose une nouvelle expérience de choix de l'utilisateur avec les cookies tiers. Vous devez préparer votre site pour les utilisateurs qui choisissent de naviguer sans cookies tiers.
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 la plus adaptée à vos besoins.
Les services intégrés, ou intégrations, incluent du contenu tiers (comme des vidéos ou des cartes), des composants interactifs (chat, systèmes de commentaires ou services de paiement, par exemple), les services de connexion, etc.
L'essentiel du travail de transition depuis les cookies tiers doit être effectué par les développeurs d'intégration, 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 s'appuie sur une intégration qui utilise des cookies tiers, veillez à auditer et à tester vos parcours liés aux intégrations. Si vous constatez des dysfonctionnements, contactez des fournisseurs d'intégration.
Auditez et testez les parcours utilisateur liés à l'intégration
Le meilleur moyen de déterminer si vos intégrations sont concernées par des cookies tiers est de tester vos parcours utilisateur pour ce type d'intégrations 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 ?
- Intégration de contenu:pouvez-vous regarder du 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 ? Les annonces s'affichent-elles au moment opportun (par exemple, ne les voyez-vous pas en tant qu'abonnés Premium ?) ?
- Connexion:les connexions (y compris les connexions SSO) fonctionnent-elles pour les intégrations compatibles ? Sont-elles conservées lors des actualisations de pages et lors de la navigation vers les 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:parvenez-vous à finaliser les 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
Vous pouvez utiliser un certain nombre d'API pour les intégrations qui reposaient traditionnellement sur des cookies tiers. Le tableau suivant présente certains workflows courants et les API recommandées pour récapituler les points abordés. Les sections suivantes expliquent les raisons de ces recommandations.
| Cas d'utilisation | API recommandée pour l'utilisation des cookies tiers |
|---|---|
| Widget de chat | CHIPS |
| Intégrations de cartes | CHIPS |
| Domaines bac à sable pour le contenu utilisateur non approuvé (comme googleusercontent.com et githubusercontent.com) dont l'état doit être défini au niveau de l'éditeur |
CHIPS |
| Annonces intégrées nécessitant une portée limitée par état par éditeur | CHIPS |
| Se connecter via un fournisseur d'identité | FedCM |
| Intégration hébergée sur des origines différentes, mais associées. | API d'accès à l'espace de stockage avec les ensembles de sites Web associés |
| Le contenu est intégré avec des préférences de connexion (comme du contenu vidéo sans publicité ou des 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 autre API appropriée et décrit les API recommandées.
L'organigramme suivant vous aide à choisir l'une des options disponibles:
<ph type="x-smartling-placeholder">L'organigramme pose trois questions principales. Nous les examinerons plus en détail et expliquerons 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 de manière indépendante sur des sites sans aucun rapport. Par exemple, les widgets de chat destinés au service client nécessitent souvent des cookies pour fonctionner, mais ils n'ont pas besoin de les partager entre deux organisations complètement différentes qui utilisent toutes les deux la même solution de widget de chat. Dans de nombreux cas, il serait même préférable de ne pas autoriser le partage de cookies.
Si vous proposez 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 du site sur lequel il est intégré. Sont-elles déjà partagées 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 permettre leur partage par tous les sites utilisant le même système d'intégration tiers. Les CHIPS sont faciles à implémenter, car il suffit d'ajouter un attribut Partitioned supplémentaire aux cookies existants. Cela permet aux services intégrés de continuer à enregistrer l'état, mais supprime le stockage intersites partagé qui permettrait le suivi intersites.
Les sites doivent également vérifier si des cookies sont utilisés pour de bonnes raisons. Les cookies ne doivent être utilisés que s'ils sont définis ou s'ils 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 une option de stockage pratique, il est préférable 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 les principaux navigateurs, de la même manière que CHIPS partitionne les cookies.
2. Les cookies correspondent-ils à un fournisseur d'identité tiers ?
Les cookies tiers sont souvent 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 une option dans ce cas.
L'API Federated Credential Management (FedCM) est spécialement conçue pour ce cas d'utilisation. Elle fonctionne sans cookies tiers. Si FedCM est accepté par le fournisseur d'identité, les cookies tiers ne seront peut-être plus nécessaires.
Pour savoir comment remédier aux effets des cookies tiers sur les workflows de connexion, consultez le guide sur les identités.
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 des cookies tiers pour l'intégration. Vous pouvez activer cette fonctionnalité dans des cas d'utilisation spécifiques et contrôlés avec l'API Storage Access. Cette API réactive l'accès complet des cookies tiers (susceptible de faire l'objet de 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.
L'utilisation de l'API Storage Access est soumise à certaines conditions:
- L'utilisateur doit avoir déjà visité le site de l'intégration de niveau supérieur. Par exemple, si l'utilisateur intègre un système de commentaires, il doit également se rendre sur le site de ce système.
- L'utilisateur doit interagir avec l'élément intégré pour que les cookies puissent être partagés. Par conséquent, il n'est pas toujours possible de charger l'intégralité du contenu intégré avant l'interaction de l'utilisateur.
- L'utilisateur devra peut-être approuver le partage des cookies à l'aide d'une fenêtre pop-up du navigateur, en particulier sur 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 réactiver les cookies tiers uniquement lorsque l'utilisateur et le site s'y intéressent. 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 lui demander pendant un certain temps (tel que défini par le navigateur).
Un autre scénario dans lequel cela est susceptible d'être attendu par l'utilisateur concerne les sites connexes. Par exemple, certaines organisations utilisent différentes origines, considérées comme intersites par le navigateur. L'utilisation de cookies sur ces origines est donc considérée comme une utilisation de cookies tiers. Il peut s'agir, par exemple, de marques ayant des sites spécifiques à un pays (comme example.com et example.co.uk) ou de sites spécifiques à une marque (comme example.car et example.house).
Dans ce cas, lorsqu'il existe un petit nombre de sites Web associés, vous pouvez utiliser les Ensembles de sites Web associés. Les sites sont envoyés à Chrome pour que celui-ci sache qu'ils sont liés. Cela permet d'accéder à l'API Storage Access de manière plus conviviale, avec moins d'invites.
Pour les sites Web non liés qui sont en réalité tiers et pour lesquels un accès complet aux cookies tiers est requis parce que les autres API ne sont pas suffisantes, l'utilisation de l'API Storage Access fera l'objet d'exigences et d'invites complètes.
Comparaison des différentes API
Chacune de ces solutions présente des caractéristiques et des limites légèrement différentes, qui en font un meilleur choix pour certains cas d'utilisation. Le tableau suivant récapitule les principales différences:
| CHIPS | Stockage partitionné | FedCM | API d'accès à l'espace de stockage avec les ensembles de sites Web associés | API Storage Access | |
|---|---|---|---|---|---|
| L'utilisateur n'a pas besoin d'avoir déjà 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 | |||||
| L'utilisateur n'a pas besoin d'interagir avec l'élément intégré | (Cela peut également s'appliquer aux sites intégrés dotés d'un accès de niveau supérieur.) |
||||
| Efforts de mise en œuvre | Très faible | Faible | Élevée | Moyenne | Moyenne |
| Peut être utilisé pour partager des cookies entre plusieurs sites/origines de premier niveau | (Proposition en cours de discussion.) |
||||
| Disponible sur les navigateurs autres que Chromium | (Revient à l'API Storage Access.) |
Prendre en charge les cas d'utilisation sur tous les navigateurs
Comme nous l'avons évoqué dans la dernière ligne du tableau, la compatibilité du navigateur est l'un des facteurs majeurs lors du choix d'une solution. Certaines API (CHIPS, FedCM, Related WebSite Sets) ne sont disponibles que sur les navigateurs Chromium. À l'heure actuelle, les deux seules solutions multinavigateurs sont les API de stockage partitionné (lorsque les cookies ne sont pas requis) ou l'API Storage Access (lorsque les cookies sont requis).
Cependant, 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 a travaillé sur l'ajout d'autres API, qui sont conçues pour répondre à des cas d'utilisation spécifiques et offrir une expérience semblable à celle qu'il était possible d'utiliser avec les cookies tiers. Par conséquent, nous vous recommandons d'envisager les meilleures options et de les considérer comme des améliorations progressives, avec un recours à 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 des fonctionnalités via l'API peut ne pas être suffisante. Il est préférable de tester si les cookies attendus existent. Si ce n'est pas le cas, revenez 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 l'utilisation de cookies tiers, il existe plusieurs solutions pour remédier à l'impact potentiel, comme expliqué dans cette présentation. Le moment est venu d'effectuer un audit de votre service pour détecter les cookies tiers. C'est maintenant !
Si vous rencontrez des problèmes d'intégration, car Chrome teste actuellement la suppression des cookies tiers, il existe un certain nombre d'options à court terme pour obtenir de l'aide tout en passant aux alternatives décrites dans cet article. Pour en savoir plus, consultez la documentation sur la préservation des expériences utilisateur essentielles.
Si vous avez des questions concernant 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 cliquant sur "Abandon des cookies tiers" dans notre dépôt d'assistance pour les développeurs.