Rédigé par Benjamin Poilvé – LINC (Laboratoire d’Innovation Numérique de la CNIL) – 15 janvier 2020
Une nouvelle responsabilité : recueillir le consentement des utilisateurs
Dès 1996, l’impact des cookies en termes de vie privée était pointé dans un article du Financial Times et avait suscité l’intérêt de la FTC. En Europe, la directive ePrivacy de 2002 a créé une obligation d’informer sur les opérations de lecture et écriture dans les terminaux, transformée en une obligation d’obtenir le consentement pour ces opérations en 2009. Ces règles ont pour objectif de protéger l’intégrité des terminaux en encadrant l’usage de traceurs, et notamment les cookies, avec pour but d’adresser les problématiques soulevées par l’utilisation de tels traceurs en terme de protection de la vie privée. En 2018, le RGPD est venu préciser et renforcer cette notion de consentement.
Aujourd’hui la méthode de monétisation la plus courante sur le web est la publicité ciblée. Au cours de ces dernières années, des méthodes de plus en plus complexes se sont ainsi développées pour tracer les utilisateurs afin de leur proposer des contenus publicitaires toujours plus ciblés. Ces méthodes reposent notamment sur l’usage de traceurs qui sont spécifiquement visés par la directive ePrivacy et dont l’usage pour des finalités publicitaires nécessite un consentement.
De plus, un certain nombre d’acteurs proposent aux développeurs de sites web des services gratuits et des fonctionnalités à intégrer dans leur site (comme les outils d’analyse de fréquentation, l’intégration de vidéos, l’intégration de cartes, de « like », etc.), pour développer, entre autres, leur réseau de collecte d’information sur les utilisateurs. En effet, si ces services sont généralement gratuits, les plateformes qui les proposent peuvent exploiter les données produites en traçant les utilisateurs des sites qui les utilisent sur toutes les pages qui les intègrent, le plus souvent pour des finalités de ciblage publicitaire.
L’éditeur, qui est responsable du site consulté par l’internaute, doit alors s’assurer que des traceurs ne sont pas utilisés sans que l’utilisateur y ait consenti, que ce soit par lui ou par ces fournisseurs de services tiers. Cela peut paraitre complexe car ces outils sont le plus souvent intégrés sous la forme de scripts (ou tags), sans moyen simple de les activer ou désactiver à priori.
La solution du tag manager : une approche destinée à limiter les collectes non maîtrisées
En raison de cette nouvelle nécessité de « contrôle » le lancement des scripts intégrés sur leurs pages, les éditeurs de sites ont eu besoin de faire appel à une nouvelle gamme d’outils : les gestionnaires de scripts ou « tags managers ». Ces solutions permettent de « compartimenter » les scripts de tiers et de ne les activer que lorsque cela est nécessaire. Ils permettent aussi de simplifier la gestion des scripts intégrés sur les sites.
Dans le cadre d’une demande de consentement, c’est alors en général l’éditeur qui installe la solution sur son site, celle-ci regroupant généralement à la fois l’interface de recueil du consentement et la solution de « tag management« .
C’est l’éditeur (ou son sous-traitant) qui a la maîtrise sur l’activation des scripts des tierces parties via l’outil. En principe, lorsque l’outil est correctement implémenté, le déclenchement des tags (et donc le dépôt de cookies) est conditionné au consentement de l’utilisateur sans que l’information du consentement n’ait besoin de remonter à l’entité qui dépose le cookie : si l’internaute ne consent pas, le script du tiers n’est tout simplement pas activé.
Si cette solution permet à l’éditeur de garder le contrôle des tiers qui peuvent déposer des cookies sur son site, elle pose cependant un certain nombre de problèmes d’usage, dus notamment à la multiplication des tiers présents sur chaque page et au développement de la pratique du RTB (ou real-time bidding).
En effet, avec le RTB, il est parfois compliqué de déterminer tous les tiers qui vont vouloir se prévaloir du consentement (parfois des centaines) et ces tiers n’ont pas forcément de contact direct avec l’éditeur, ce qui pose complexifie l’information de l’ l’utilisateur.
Face à cette problématique, l’IAB (Interactive Advertising Bureau) a annoncé en 2017 le début d’un travail sur un standard à code source ouvert permettant « aux sites web, publicitaires et leur partenaires technologiques d’obtenir, d’enregistrer et de mettre à jour le consentement des utilisateurs à voir leurs données personnelles traitées dans le cadre du RGPD à venir (tda) ». Cette initiative prend le nom de « Transparency and Consent Framework » (TCF).
La proposition de l’IAB : un cadre global pour la gestion des consentements, des fournisseurs et des finalités
Le TCF fait intervenir un certain nombre d’acteurs dont les rôles et les devoirs réciproques sont définis par l’IAB qui joue, dans ce dispositif, le rôle d’organisme de normalisation. L’IAB fournit un certain nombre de services techniques, ainsi qu’une promesse d’interopérabilité des protocoles.
Ces acteurs sont :
-
Les Consent Management Platforms (CMP) : les opérateurs de plateforme de gestion du consentement, qui vont gérer techniquement les outils permettant de recueillir ce consentement. Ils doivent candidater auprès de l’IAB pour se voir attribuer un identifiant et pouvoir proposer leurs services. Leur rôle est de créer une plateforme de recueil du consentement suivant les spécifications publiées par l’IAB. Les CMP doivent s’engager à respecter les règles de fonctionnement du TCF (les « policies »). Ils ont la responsabilité partagée de la donnée de consentement (« TC string« ), une chaine de caractères permettant de stocker les consentements utilisateurs par rapport aux différents acteurs publicitaires (ci-après Vendors) et leurs finalités respectives. Ils peuvent stocker cette donnée sur le terminal de l’utilisateur dans un cookie.
-
Les Vendors : les acteurs de l’écosystème publicitaire qui vont utiliser des données récupérées à l’aide de traceurs pour des finalités publicitaires. Ils doivent également candidater auprès de l’IAB pour être inscrits sur la Global Vendor List (GVL), liste tenue à jour et publiée par l’IAB et listant l’intégralité des Vendors ayant adhéré au Transparency and Consent Framework. La validation de leur candidature n’est possible que s’ils ont préalablement publié une politique de protection de la vie privée ainsi que des informations sur les traitements publicitaires qu’ils vont mettre en place, précisant notamment les bases légales de ces traitements ainsi que l’attestation de leur volonté de respecter les règles du TCF. Les finalités et les bases légales utilisables par les Vendors dans le cadre du Transparency and Consent Framework sont déterminées par l’IAB. Il est important de noter qu’à la différence des éditeurs, les Vendors ne sont pas liés à une CMP en particulier.
-
Les Publishers : les éditeurs de sites web ou d’applications mobiles. Ils n’ont pas besoin de s’enregistrer auprès de l’IAB, et peuvent avoir recours à des CMP pour obtenir le consentement de leurs utilisateurs pour l’utilisation de cookies ou d’autres traceurs pour des finalités publicitaires. Les Publishers doivent également respecter les règles du TCF.
De manière générale la donnée de consentement est stockée dans un cookie créée sur un domaine enregistré par l’IAB (consensu.org) ayant une durée de validité de 13 mois, et accessible en lecture et écriture par les CMP approuvés par l’IAB. Le détail des consentements accordés ou refusés par l’utilisateur, Vendor par Vendor et finalité par finalité est stocké dans ce cookie. La donnée en elle-même est nommée « TC string« .
Les CMP sont en quelque les « gardiens » de cette donnée, ils implémentent différentes méthodes (API, redirections en « daisy-chain ») pour la rendre disponible aux acteurs publicitaires pour qu’ils sachent si l’utilisateur leur a donné son consentement ou pas. Si tous les acteurs de la chaine publicitaire doivent pouvoir lire le contenu de la « TC string », seules les CMP peuvent écrire dessus.
Dans la pratique la CMP mise en place par l’éditeur a alors pour rôle d’enregistrer le consentement, de le stocker, de le restituer, mais aussi de le transmettre aux Vendors lorsqu’il y a lieu. L’information de consentement (ou d’absence de consentement) est donc communiquée directement aux Vendors via la « TC string« . Contrairement aux solutions de tag management, que le consentement soit donné ou non par un utilisateur, les tags sont bel et bien activés ; ce sera donc au Vendor de ne pas lire ou écrire de données dans le terminal de l’utilisateur si ce dernier n’a pas consenti.
Les limites du Transparency and Consent Framework de l’IAB
Si le TCF propose de construire un cadre de confiance dans lequel des techniques comme le RTB pourraient fonctionner en respectant le consentement des utilisateurs, un certain nombre de problématiques subsistent.
La première est liée au procédé de transfert de la « TC string« . En effet celle-ci peut passer par plusieurs tiers avant d’atteindre un acteur en particulier. Or, en l’absence de procédés de signature électronique ou d’autres mesures permettant d’assurer son intégrité, il est possible qu’elle subisse une modification de la part de l’un d’entre eux, de manière malicieuse ou simplement du fait d’une mauvaise configuration. Cela pose des questions en termes de sécurité juridique d’acteurs bien intentionnés qui fonderaient alors leurs traitements sur un consentement non valide.
La deuxième est qu’il n’est pas clair que le format de la « TC string » en lui-même permette de stocker précisément les choix exprimés par l’utilisateur, particulièrement dans le cadre d’une unique chaine de consentement partagée entre plusieurs CMP.
Le consentement se décompose selon les spécifications du Transparency and Consent Framework sur deux dimensions :
-
Les finalités, c’est-à-dire les fonctionnalités permises par l’utilisation de la donnée.
-
Les Vendors.
L’utilisateur peut exprimer son choix selon ces deux axes, mais il est important de noter que, en raison de limitations techniques (liées à la taille maximale d’un cookie) ces choix ne sont pas stockés de manière matricielle (c’est-à-dire réglage de chacune de finalités pour chacun des Vendors), ce qui limite l’expressivité du choix de l’utilisateur et peut entrainer des incompréhensions pour l’utilisateur.
Par exemple, imaginons un utilisateur qui visite un premier site sur lequel uniquement le Vendor A est présent. Il souhaite lui autoriser la finalité 1.
S’il visite ensuite un second site avec le Vendor B auquel il donne tous les droits, il y a alors une différence entre l’attente utilisateur et l’état de la TC string. Le choix exprimé était en effet de limiter les finalités du Vendor A, ce qui n’est pas reflété dans la « TC string« .
