Les impacts du Réglement Général sur la protection des données sont si vastes qu'une mise en conformité des sites et applications Web, à l'ère de l'usage massif des systèmes de gestion des balises, apparaît souvent comme la partie la plus simple à résoudre d'une vaste équation. Qu'en est-il dans les faits ? Réponse avec un passage en revu des paramétrages nécessaires sur Google Tag Manager, outil leader sur le marché des gestionnaires de balises gratuits.
Petits rappels préliminaires
Sur le Web, l'un des enjeux majeur de la mise en conformité réside dans la capacité à bloquer par défaut toute collecte de données non indispensable au bon fonctionnement d'une plateforme. Ce blocage ne pourra être levé qu'une fois que l'utilisateur aura exprimé de façon explicite son consentement, après que les finalités et enjeux liés à la collecte de données aient été exposés et un mécanisme lui permettant d'effectuer un choix révocable et proportionné lui ait été proposé.
Les systèmes de gestion des balises ont pour vocation la centralisation, l'alimentation, la gestion ainsi que le déploiement de l'ensemble des codes marketing et publicitaires d'un dispositif Web. Cela conduit à leur conférer un rôle central dans la mise en oeuvre du processus de mise en conformité, que ce soit en déployant le mécanisme de recueil et de gestion du consentement proprement dit ou en étant responsables, en bout de chaîne, du déclenchement ou du blocage d'une balise.
Google Tag Manager ne propose pas de module spécifique lié au RGPD. Par conséquent, l'outil joue un rôle de passerelle entre le système de recueil du consentement et les codes des éditeurs logiciels qui y sont assujettis et qu'il se charge de déclencher ou bloquer selon le bon vouloir de l'utilisateur.
Les instruments incontournables : variables et règles de blocage
Puisque Google Tag Manager n'est pas en charge du recueil du consentement, il s'avère nécessaire de créer en son sein des variables, à même de l'informer du choix d'un utilisateur à tout instant : refus total ou partiel, acceptation totale ou partielle, ou encore absence de choix. Concrètement, ces variables seront alimentées par des cookies, des valeurs stockées dans le stockage local du navigateur ou encore par des fonctions JavaScript, autant de moyens utilisés par les centres de gestion de la vie privée déployés sur un site afin de garder en mémoire les choix d'un utilisateur et qui sont systématiquement accessibles au moyen d'une API plus ou moins développée.
Ces variables, constituent le matériau brut à partir duquel créer différents déclencheurs. Bien que cela puisse paraître de prime abord contre-intuitif, il s'agit de paramétrer des règles à même d'identifier le refus de l'utilisateur. En effet, Google Tag Manager évaluant les différentes règles de déclenchement associées à une balise avec l'opérateur OU, créer un déclencheur cherchant à vérifier le consentement du visiteur ne permettrait pas de bloquer une balise en l'absence d'accord de sa part.
Une alternative consiste à modifier l'ensemble des règles existantes afin de leur intégrer une condition supplémentaire venant vérifier la valeur des variables liées au module de gestion de la vie privée. Dans les faits, une telle approche apparaît peu attractive, car elle s'avère extrêmement chronophage et totalement inadaptée dans le cas où une même balise en viendrait à relever de différentes catégories existantes au sein du module de gestion de la vie privée.
La difficile gestion de l'avant consentement
En attachant une ou plusieurs règles de blocages à l'ensemble des balises, le respect du choix exprimé par l'utilisateur est garantie. En revanche, avec un tel dispositif, l'impact sur les données collectés par les responsables du site concerné peut s'avérer considérable. En effet, même en imaginant un scénario où l'utilisateur exprimerait un consentement dès la première page visitée, cela interviendrait nécessairement après le chargement initial du conteneur.
Comment dès lors exécuter sur cette page les balises qui avaient été bloquées à l'origine, sans plus attendre ? En effet, une absence de rappel du conteneur aurait pour conséquence une absence totale de collecte de données sur la page de destination réelle du visiteur.
C'est bien là que le bât blesse, car il n'existe aucune fonction permettant d'exécuter à nouveau des balises qui auraient du se déclencher dès le chargement initial du conteneur. Le recours à un événement personnalisé, qui serait déclenché en cas de consentement de l'utilisateur, ne constitue pas une réponse adaptée, dès lors que les balises qui doivent être rappelées ne se déclenchent pas sur toutes les pages. En effet, il convient alors de prendre en compte les critères secondaires prenant la forme de conditions sur d'autres variables.
Or Google Tag Manager méconnait la notion de contrainte ou de filtres qui viendraient s'ajouter aux déclencheurs, sans pour autant constituer des bloqueurs. A moins de mettre en oeuvre une mécanique extrêmement complexe, ou de déporter les codes à rappeler dans des conteneurs tiers, l'outil ne permet pas à date de répondre à cette problématique pourtant essentielle du fait de son architecture
En conclusion
Il est aisé d'interfacer Google Tag Manager avec un centre de gestion de la vie privée de sorte à pouvoir autoriser ou bloquer le déclenchement de balises en fonction du choix exprimé par un visiteur. En revanche, la question du rappel du conteneur, sur la page où le consentement de l'utilisateur est recueilli, afin de minimiser les pertes de données, s'avère extrêmement complexe à adresser avec cet outil.