Contactez-nous

Pas le temps de tout lire ?

Contactez-nous dès maintenant, et nous répondrons à vos besoins dans les plus brefs délais

Contactez-nous

Implémentation d’un système de gestion des cookies

Le 20 février 2020
par Victor G.
Attineos Applications

Pour vous aligner avec ce que dit la loi, si votre site utilise des cookies, vous devez en informer vos utilisateurs et leur permettre de les bloquer s’ils le souhaitent. A travers cet article, nous allons voir toutes les étapes qui vous permettront de mettre ce système en place.

> Afin de bien comprendre tout ce qu’on vous présentera, il est conseillé de déjà connaître Google Tag Manager. Si vous le souhaitez, vous pouvez découvrir cet outil sur cet article que nous avons déjà rédigé.

Préambule

Ce que dit la loi

Vous pouvez trouver toutes les informations dont vous avez besoin directement sur le site de la CNIL. En voici les informations essentielles qui nous concernent:

  • il faut informer les utilisateurs de la finalité des cookies qu’on va créer / lire
  • il faut obtenir leur consentement (ils doivent explicitement accepter d’avoir les cookies et non l’inverse)
  • on doit leur fournir un moyen de les refuser
  • la validité du consentement est de 13 mois
  • certains cookies peuvent être exemptés de consentement (ex: cookie de panier d’achat, cookie d’authentification, etc.). Une liste plus exhaustive est accessible sur le site de la CNIL.
  • si l’utilisateur poursuit sa navigation sur le site (en changeant de page), on peut considérer qu’il a donné son consentement. Sinon, le bandeau de demande de consentement doit toujours être visible.
  • l’utilisateur doit pouvoir revenir sur son choix à tout moment

Concernant le RGPD, tant que vous ne collectez pas d’information personnelles grâce à ces cookies ou que vous ne recoupez pas ces données avec d’autres traitements, vous n’avez pas vraiment à vous en souciez. Cependant, la plupart des grands outils de mesure de traffic dont Google Analytics nécessitent un consentement, comme indiqué dans les récentes recommendations de la CNIL.

Et oui, avant d’aller plus loin ça serait bien de définir ce qu’est un cookie et pourquoi la loi nous impose de les contrôler. Un cookie est un petit fichier qui s’enregistre sur votre poste et qui permet d’enregistrer une information. Ainsi, quand un utilisateur revient sur un site qui a créé un cookie, le site peut y accéder et en extraire des informations.

Actuellement, un grand nombre de ces cookies stockent des informations qui permettent de connaître vos centres d’intérêt et peuvent ainsi vous proposer par exemple des publicités plus ciblées. Cette intrusion dans la vie privée pose question et c’est pourquoi la CNIL ainsi que la communauté européenne ont décidé d’encadrer la création et l’utilisation de ces cookies. L’idée étant de laisser le choix à l’utilisateur pour savoir s’il accepte ce tracking ou non.

Les cookies tels qu'ils peuvent être visualisés dans les outils de développement de Chrome

Concrètement, un cookie c’est une paire clef/valeur à laquelle on peut ajouter une liste définie d’attributs. La clef est l’identifiant du cookie, c’est son nom. La valeur et bien… c’est sa valeur :). Les attributs possibles sont:

  • Expires : c’est la durée de vie du cookie. Lors de sa création, on peut indiquer quand le cookie expire via une date précise ou en donnant une durée de vie Max-Age (sous forme d’un nombre de secondes). Si aucune valeur n’est spécifiée, le cookie devient un cookie de session et expirera quand la session sera terminée. Si on donne un Max-Age négatif, le cookie expire immédiatement.
  • Domain : indique sur quel domain le cookie sera envoyé. Cela peut être un domaine précis (ex: www.attineos.com) ou bien un domaine et tous ses sous-domaines (ex: attineos.com qui incluera www.attineos.com mais également d’autres sous-domaines comme app.attineos.com, etc.).
  • Path : la ou les URL sur lesquelles le cookie sera envoyé
  • Secure : si le cookie est marqué comme étant Secure, il ne sera envoyé que sur les URLs en https:. Cela ne veut pas dire que le cookie est mieux sécurisé.
  • HttpOnly : les cookies en HttpOnly ne sont accessible que côté serveur. En effet, il sera impossible d’y accéder en Javascript ainsi cela permet d’améliorer votre protection contre les failles XSS.
  • SameSite : indique de quel manière votre cookie doit être envoyé suivant le nom de domaine sur lequel vous vous trouvez. Il y a 3 valeurs possibles: None, Lax et Strict. None signifie que le cookie sera toujours envoyé même si vous êtes sur un autre site (ex : utilisation d’un widget de votre site, programme d’affiliation, etc. – le cookie doit avoir été marqué comme étant Secure). Si vous choisissez Strict, le cookie sera envoyé pour chaque requète faite via votre site web. La valeur Lax est comme Strict sauf que le cookie sera envoyé même lors de la requête initiale vers votre site quand vous venez d’un site externe. Vous pourrez trouver plus d’informations et d’exemple sur cette attribut ici.

Schéma récapitulatif de la propriété SameSite

Les différents types de cookies

First party

Les cookies « First party » sont les cookies dont le nom de domain qui leur est associé est le nom de domaine de votre site web. C’est votre propre code (front ou back) ou du code externe (scripts ou iframes) qui sont responsables de leur création. Ils ne peuvent être lus que par votre site.

Third party

Les cookies « Third party » sont des cookies créés par du code externe (généralement des scripts ou des iframes) que vous avez ajouté sur votre site. Ils peuvent être lus par tous les sites qui incluent également ce code externe. Ce sont généralement ces cookies qui sont responsables des publicités ciblées que vous pouvez rencontrer en naviguant sur internet.

Les différentes catégories de cookies

Afin de mieux contrôler vos cookies, il est conseillé de les catégoriser. Ainsi vos utilisateurs pourront décider d’accepter ou de refuser telle ou telle catégorie. La loi n’impose rien de particulier quant à la catégorisation; cependant le schéma suivant est assez répandu et permet normalement de trouver une catégorie pour chacun de vos cookies tout en ne rendant pas trop compliqué la partie technique qui bloquera ou non la création des cookies :

  • Cookies Requis: c’est un peu la seule catégorie dont la loi parle. Ce sont les cookies pour lesquels vos utilisateurs n’ont pas besoin de donner leur accord car sans eux, votre site ne fonctionnera pas correctement. Quelques exemples: cookie de panier d’achat, cookie d’authentification, cookies de « load balancing », etc.
  • Cookies de performance: ce sont les cookies qui permettent de mesurer le nombre de visiteurs, les sources du trafic sur votre site web afin de s’en servir pour en améliorer les performances. Exemples: Google Analytics, Amplitude, Hotjar, etc.
  • Cookies de fonctionnalité: ils permettent d’améliorer les fonctionnalités et la personnalisation de votre site web. Sans eux, certaines fonctionnalités pourraient ne pas fonctionner correctement. Exemples: cookie d’A/B testing, cookie de chat instantané, etc.
  • Cookies de publicité ciblée: ils permettent d’établir un profil des centres d’intérêts de vos utilisateurs afin de leur présenter des publicités ciblées. Exemples: Facebook, Twitter, etc.

Mise en place

En se basant sur ce que nous venons de voir et afin d’être conforme à la loi, on va pouvoir distinguer 3 étapes dans notre mise en place de notre système de gestion des cookies:

  • lister / identifier tous les cookies présents sur notre site afin de pouvoir les catégoriser
  • recueillir le consentement (ou non) de nos utilisateurs
  • bloquer / autoriser les cookies correspondant au choix des utilisateurs

Lister les cookies et les catégoriser

Pour chaque cookie qui sera identifié, il va falloir savoir si ce cookie est un cookie de session (dure le temps de la session de l’utilisateur) ou un cookie permanent et dans ce cas il faudra savoir pour combien de temps il est créé (sa durée de vie). Il faudra également savoir à quoi sert ce cookie et donc en prévoir une petite description. Idéalement, cette liste est à tenir à jour régulièrement.

Pour les cookies que vous créez via votre propre code, vous devriez pouvoir les trouver plus ou moins facilement. Certains de ces cookies ont pu être créés soit directement par vous / votre équipe et d’autres ont pu être créés par votre framework par exemple.

Pour les cookies créés par des dépendances externes, ça devient plus compliqué… Car généralement, vous ne contrôlez pas vraiment la création de ces cookies. De plus, si vous avez des scripts uniquement sur certaines pages, il va falloir aller sur ces pages pour réussir à trouver les cookies. Quant à leur donner une description, ce n’est pas toujours évident non plus. De plus, imaginons qu’une de ces dépendances crée un nouveau cookie, comment allez-vous le savoir (à part en refaisant un tour complet de votre site) ?

Toutes ces questions nous amènent à penser qu’il pourrait être bon d’utiliser un outil pour automatiser cette recherche. Nous allons donc vous présenter ici quelques outils permettant de lister ces différents cookies.

Outils possibles

Cette liste est non exhaustive mais elle reprend les principales solutions efficaces qui existent en ligne. De nombreux outils ne scannent que 4 ou 5 pages de votre site et donc ne permettent pas d’avoir la liste exacte de vos cookies.

OneTrust

Vous pouvez tester l’outil pendant 14 jours de manière gratuite. Depuis peu, ils disposent d’une nouvelle interface (pas forcément plus intuitive). Vous pouvez scanner entièrement un nom de domaine, ainsi que tous ses sous-domaines, sans limite de pages. Il est également possible de passer un formulaire d’authentification afin d’aller scanner la partie connectée de votre site web. Le scan est plutôt efficace même si j’ai eu à faire à quelques soucis de cache.

Pour la catégorisation OneTrust propose les 4 catégories principales et permet d’assigner automatiquement vos cookies en se basant notamment sur leur base de données Cookiepedia. C’est vraiment très pratique et ça fait gagner un temps fou. Et bien évidemment après, vous pouvez modifier ces catégories et leur contenu. Vous pouvez même ajouter d’autres catégories.

Le scan peut ensuite être lancé automatiquement de manière régulière et vous indique quand il a détecté de nouveaux cookies.

Actuellement, c’est surement la solution la plus complète du marché mais pour l’avoir utilisé, j’ai fait face à de nombreux bugs assez gênant qui, au final, ont été résolus plus ou moins rapidement, en contactant le support.

A tester ici : https://www.onetrust.com/free-trial/

Tarification: https://www.onetrustpro.com/buy/

Cookiebot

Pour une solution qui offre une version gratuite sans limite de temps, c’est peut-être ce qu’il y a de mieux. L’interface n’est franchement pas top mais ça fait le job, comme on dit ;). Vous pouvez enregistrer un domaine et effectuer un scan; à la seule petite nuance qu’il n’est pas possible de passer un formulaire de connexion. Cependant, vous pouvez ajouter manuellement des cookies. La catégorisation doit être faite de manière manuelle. Le scan se fait ensuite mensuellement et vous indique quand il a détecté de nouveaux cookies. La principale limite de la version gratuite étant qu’elle ne permet de scanner qu’un seul domaine et ce jusqu’à un maximum de 100 pages.

A tester ici : https://www.cookiebot.com/fr/

Tarification: https://www.cookiebot.com/fr/pricing/

Autre outils

En effectuant mes recherches, je suis tombé sur cet article qui propose de faire un scan de vos cookie vous-même en utilisant PhantomJS. Je dois avouer que je n’ai pas tester ce que ça vaut mais ce qui est sûr c’est que ça sera ensuite à vous de lancer les scans de manière régulière, de voir les différences entre les scans et de catégoriser vos cookies…

Recueillir le consentement

Il peut se faire de plusieurs façon. La plus commune étant une bannière sur votre site proposant à vos utilisateurs d’accepter ou non les cookies. Il est également possible d’offrir un choix plus pointu en proposant notamment d’accepter ou non telle ou telle catégorie de cookie (via ce qu’on peut appeler un « centre de préférences »). Ce choix peut être fait directement dans la bannière ou à un autre endroit sur la même page (dans une modal par exemple). N’oubliez pas que si l’utilisateur change de page sur votre site, cela peut être considéré comme un consentement.

Quand l’utilisateur a fait son choix, il doit pouvoir être capable de le modifier. Il faut donc que vous lui mettiez à disposition une page ou un lien pour refaire son choix.

OneTrust

OneTrust vient par défaut avec une bannière que vous pouvez customiser et qui vous permet d’accepter tous les cookies ou d’ouvrir une modal qui permet un choix plus précis. C’est plutôt bien fait. Vous pouvez également facilement insérer un bouton sur une page qui permet de réouvrir la modal et donc de revenir sur votre choix. Il faut savoir que OneTrust propose des choix de customisation qui ne respectent pas toujours le RGPD (ex: cocher par défaut certaines catégories) et rien ne vous l’indique.

Exemple de design de la bannière OneTrust

CookieBot

Là les choix sont beaucoup plus limités, du moins avec la version gratuite, mais ils vous permettent quand même de proposer les fonctionnalités principales. Ensuite, leur documentation est plutôt bien faite et ainsi vous pourrez créer vous-même les fonctionnalités qu’il pourrait vous manquer. Là encore, pas vraiment de notion de respect du RGPD ou non donc c’est à vous de faire attention.

Exemple de design de la bannière CookieBot

Autre outils

Pour les autres outils, je n’ai pas grand chose à conseiller. Certaines solutions en ligne existent comme cookie-script. Mais vous pouvez également créer votre propre bannière / centre de préférences.

En React, il y a notamment la librairie components-extra qui est basée sur material-ui et qui propose une bannière cookie et un centre de préférences super customisables. Après, cela signifie que c’est à vous d’enregistrer le choix de votre utilisateur et de fournir tout ce qu’il faut autour pour en récupérer la valeur et ainsi bloquer ou non les cookies liés.

Bloquer / autoriser les cookies

Généralement l’enregistrement du choix de votre utilisateur se fait dans un cookie. Et c’est sur ce cookie que vous allez devoir vous baser pour contrôler la création / la lecture des cookies.

Pour les cookies first party qui sont créés dans votre code, malheureusement, il n’y a pas beaucoup d’autres choix que de le faire directement au niveau du code source responsable de leur création / lecture. C’est donc votre responsabilité d’organiser votre architecture de cookies afin de pouvoir contrôler leur création / lecture en fonction du choix de l’utilisateur.

Pour tous les autres cookies créés par des dépendances externes, si vous avez bien mis tous vos scripts dans Google Tag Manager, il ne vous reste plus qu’à faire un peu de configuration. L’idée générale est de lire la valeur du cookie et ainsi de créer des déclencheurs (qui seront utilisés soit en tant que déclencheur, soit en tant qu’exception) qui contrôleront le déclenchement des scripts. Et ainsi bloqueront indirectement la création / lecture des cookies.

Je ne vais pas rentrer dans les détails de l’implémentation car ceux-ci peuvent être très liés à l’outil / à la façon dont vous allez décider de contrôler vos cookies mais nous allons tout de même voir à quoi devrait ressembler votre configuration. Cet exemple est essentiellement basé sur ce qui est proposé dans cet article.

Variables

Pour les variables, sachez qu’il existe une variable de type « Cookie 1st party » grâce à laquelle vous devriez pouvoir facilement lire la valeur du cookie dans lequel vous allez stocker le choix de vos utilisateurs.

Ensuite, vous pouvez créer X variables qui permettront d’accéder plus facilement au choix fait par votre utilisateur pour chaque catégorie de cookie. Si on reprend les catégories exposées dans cette article, cela signifie que vous allez devoir créer 3 variables pour les cookies de performance, les cookies de fonctionnalité et les cookies de publicité ciblée. Ces variables seront de type « Javascript personnalisé » et devront retourner true ou false suivant le choix de l’utilisateur.

Déclencheurs

C’est ici que vous allez devoir faire la majorité de votre configuration :

  • déclencheur de choix effectué : il permet de savoir que votre utilisateur a effectué un choix quant à l’utilisation des cookies. Il doit être déclenché après avoir enregistré son choix dans un cookie. Il y a plusieurs façon de créer / mettre en place ce déclencheur. Soit via un « Événement personnalisé » ou encore via le déclencheur de type « Clic sur un élément ». Vous pourrez l’utiliser afin de déclencher une balise dès qu’un choix est effectué.
  • exception pour chaque type de cookie : ces déclencheurs serviront en tant qu’exception; ce sont eux qui empêcheront les balises d’être déclenchées. Il s’agit de déclencheur de type « Évènement personnalisé », pour le nom de l’événement, on va souhaiter qu’il se déclenche tout le temps (c’est-à-dire à chaque évènement) on va donc leur donner comme valeur .* et utiliser le matching par regex. On indique que l’événement se déclenchera à la condition que la variable correspondant à la catégorie du cookie soit égale à false.
Balises

Il n’y a plus qu’à utiliser nos déclencheurs récemment créés. Pour chaque balise créant des cookies, vous devez ajouter en tant qu’exception le déclencheur correspondant à la catégorie de cookies créés par votre balise. Vous pouvez également ajouter, ce coup-ci en tant que déclencheur classique, le déclencheur de choix effectué, si vous souhaitez que votre balise soit déclenchée dès qu’un choix est effectué (cela peut-être utile notamment pour tout ce qui est tracking de pages vues afin de ne pas perdre la valeur de la première page visitée).

Pour les cookies créés par des iframes, je vous conseille de renommer l’attribut src de vos `

D’autres sujets intéressants