La "preuve du consentement" est un sujet qui revient régulièrement dans les comparatifs de CMP. Certaines solutions proposent un registre dans lequel chaque consentement est enregistré, parfois avec un identifiant, une date et différents détails sur le choix effectué.
Cela peut donner l’impression qu’un site doit obligatoirement conserver une ligne dans une base de données pour chaque visiteur ayant cliqué sur "accepter".
La réalité est plus intéressante. Il faut effectivement pouvoir démontrer qu’un consentement valable a été recueilli lorsqu’on s’en prévaut, mais cela ne signifie pas nécessairement identifier et enregistrer individuellement chaque visiteur dans un registre centralisé.
Je ne suis pas juriste et cet article ne remplace évidemment pas l’analyse d’un DPO ou d’un conseil lorsque le contexte le nécessite. Je vais surtout regarder ce que recommande concrètement la CNIL pour les cookies et autres traceurs.
Oui, il faut pouvoir démontrer le consentement
Le principe n’est pas ambigu : les responsables des traitements doivent être en mesure de démontrer que les utilisateurs ont donné leur consentement lorsque celui-ci constitue la base utilisée. Je l’explique sur Github.
Pour les cookies et autres traceurs, cela implique notamment de pouvoir montrer que le mécanisme utilisé permettait réellement de recueillir un consentement valable.
La nuance importante se trouve dans le mot "démontrer".
Démontrer que le consentement a été correctement recueilli n’est pas nécessairement la même chose que conserver l’identité et le clic de chaque personne ayant utilisé le site.
Ce que la CNIL propose comme preuves
La CNIL donne plusieurs exemples de mécanismes permettant d’apporter cette preuve.
Elle évoque notamment la conservation des différentes versions du code utilisé pour recueillir le consentement, éventuellement avec un mécanisme permettant de prouver leur authenticité et leur date.
Elle cite également les captures d’écran horodatées du rendu présenté aux utilisateurs, les audits réguliers du mécanisme de consentement ou encore la conservation des configurations successives de la CMP.
Ces exemples sont intéressants parce qu’ils portent principalement sur le fonctionnement du dispositif : que voyait l’utilisateur et comment le système réagissait-il au moment où son choix a été recueilli ?
Pourquoi conserver les versions du bandeau ?
Imaginons qu’un site soit contrôlé deux ans après une modification de son bandeau.
La version actuellement visible ne permet pas nécessairement de savoir comment le consentement était recueilli deux ans auparavant. Les textes ont peut-être changé, les boutons ont été déplacés et les services présents sur le site ont évolué.
Conserver les configurations successives permet de reconstituer cette situation.
Une capture du bandeau, la date de sa mise en production, sa configuration et la version du code utilisé peuvent alors être beaucoup plus utiles qu’une simple ligne indiquant qu’un identifiant anonyme a cliqué sur "accepter" à 14 h 32.
Un clic enregistré ne prouve pas à lui seul un consentement valide
C’est probablement le point le plus important.
Une base de données peut parfaitement indiquer qu’un visiteur a cliqué sur "accepter". Mais si l’interface ne lui permettait pas de refuser aussi facilement, si les finalités n’étaient pas correctement présentées ou si les trackers avaient déjà été chargés avant ce clic, cet enregistrement ne résout pas le problème.
Il prouve qu’un événement technique s’est produit. Il ne prouve pas à lui seul que les conditions nécessaires à un consentement valable étaient réunies.
La qualité du mécanisme de recueil reste donc fondamentale.
Conserver le choix dans le navigateur est un autre sujet
Il faut également distinguer la preuve du consentement de la conservation du choix de l’utilisateur.
Une CMP doit généralement se souvenir qu’un visiteur a accepté ou refusé certains services. Sans cela, le bandeau réapparaîtrait à chaque page et le choix ne pourrait pas être appliqué pendant la navigation.
Ce choix peut être conservé localement dans le navigateur. Il n’est pas nécessaire qu’il soit automatiquement envoyé vers une base centrale appartenant à la CMP.
La CNIL recommande d’ailleurs de conserver aussi bien l’acceptation que le refus pendant une durée adaptée afin de ne pas solliciter continuellement les utilisateurs. Elle considère de manière générale une durée de six mois comme une bonne pratique, à adapter selon le contexte.
tarteaucitron conserve le choix sans créer de registre central
tarteaucitron doit évidemment mémoriser les choix nécessaires à son fonctionnement dans le navigateur. C’est ce qui permet de savoir quels services peuvent être chargés lors des pages suivantes.
En revanche, tarteaucitron.io ne maintient pas une base centrale contenant un historique individuel des visiteurs de tous les sites utilisant la CMP.
C’est un choix volontaire. Je ne souhaite pas recevoir une information supplémentaire sur les visiteurs simplement parce qu’un site utilise tarteaucitron.
Le fonctionnement du bandeau et le contrôle des services ne nécessitent pas cette centralisation.
Que peut conserver concrètement un éditeur ?
Pour pouvoir documenter son mécanisme de consentement, je conserverais d’abord les éléments qui permettent de comprendre comment il fonctionnait à une date donnée.
- La version de la CMP utilisée.
- La configuration appliquée à cette période.
- La liste des services déclarés ou contrôlés.
- Une capture du premier niveau du bandeau et du panneau de gestion.
- Les textes présentés aux visiteurs.
- La date des modifications importantes de configuration.
- Lorsque c’est pertinent, le résultat d’audits ou de tests techniques montrant le comportement des trackers avant et après consentement.
Cette documentation permet de démontrer beaucoup plus précisément le fonctionnement réel du site qu’une affirmation générale du type "une CMP était installée".
Un historique Git peut déjà apporter beaucoup
Pour un site maintenu par des développeurs, une partie de cette preuve existe parfois déjà.
Le dépôt Git permet de retrouver le code utilisé à une date donnée. Les commits sont datés et montrent les modifications successives de l’intégration.
Si la configuration de la CMP est elle-même versionnée, il devient possible de retrouver précisément les paramètres qui étaient utilisés.
La CNIL cite d’ailleurs explicitement la conservation du code et de ses différentes versions parmi les moyens pouvant contribuer à démontrer le mécanisme de recueil du consentement.
Les captures d’écran ont aussi leur utilité
Le code ne montre pas toujours facilement ce que voyait réellement l’utilisateur.
Une capture d’écran horodatée permet de conserver l’apparence du bandeau, les textes visibles et la présentation des différents choix.
Pour une modification importante du design ou du fonctionnement du bandeau, conserver une capture desktop et mobile me paraît donc être une précaution très simple.
Cela permet notamment de documenter la manière dont accepter et refuser étaient présentés au même moment.
Les tests techniques complètent la preuve
Un bandeau parfaitement présenté peut malgré tout être mal intégré.
Il est donc intéressant de conserver également une trace des vérifications techniques effectuées : aucun tracker concerné avant consentement, chargement après acceptation, maintien du blocage après refus et possibilité de retirer le consentement.
Ces contrôles peuvent être réalisés manuellement avec les DevTools ou intégrés dans des audits plus formels.
J’explique la procédure de vérification dans mon article consacré au contrôle réel des trackers.
Le registre individuel peut malgré tout répondre à un besoin
Tout cela ne signifie pas qu’un registre de consentements est inutile.
Une organisation peut avoir un contexte particulier, des processus internes ou d’autres traitements pour lesquels elle souhaite disposer d’une traçabilité individuelle. Certaines CMP proposent donc cette fonctionnalité et elle peut constituer un véritable critère de choix.
Je conteste simplement l’idée selon laquelle une CMP qui ne centralise pas chaque clic serait, par définition, incapable de contribuer à la preuve du consentement.
Les recommandations de la CNIL montrent elles-mêmes que plusieurs mécanismes peuvent participer à cette démonstration.
Attention aux données collectées pour prouver qu’on limite les données
Il y a enfin un paradoxe qui mérite d’être considéré.
Ajouter un registre central implique potentiellement de transmettre et conserver de nouvelles informations concernant les visiteurs : identifiant, choix, date, contexte technique ou autres données selon la solution utilisée.
Si ce registre répond à un besoin réel, cette collecte peut naturellement être justifiée et organisée correctement.
Mais je ne pense pas qu’il faille créer automatiquement une nouvelle base de données sur les visiteurs uniquement parce qu’un argument commercial présente le "consent log" comme une fonctionnalité indispensable à toute CMP.
La meilleure preuve commence par un mécanisme correct
Avant de réfléchir à la manière de prouver un consentement, il faut surtout s’assurer que le consentement recueilli est valable.
Le visiteur doit recevoir les informations nécessaires, pouvoir accepter ou refuser librement et les services concernés doivent réellement respecter son choix.
Ensuite, conserver les versions de la configuration, les écrans présentés et les résultats d’audits permet de documenter ce fonctionnement dans le temps.
Une base contenant des millions de clics ne compensera jamais un bandeau ou une intégration qui n’étaient pas corrects au départ.
