Pourquoi redonnez-vous votre consentement toutes les semaines sur certains sites ?

Les pop-in RGPD semblent parfois bégayer. Mauvaise nouvelle : ce n’est pas un bug, mais un effet collatéral d’une collecte du consentement un peu trop globale et d’un parti pris plutôt court-termiste…

Une impression de déjà-vu. C’est ce que suscite très régulièrement la navigation sur le web aujourd’hui. Et pour cause : alors que l’utilisateur a déjà donné son consentement, un grand nombre de sites web persistent à renouveler ce consentement, parfois seulement quelques jours après l’avoir demandé. Et pourtant, si ce bégaiement des pop-in de consentement irrite légitimement les utilisateurs, il ne s’agit nullement d’un bug. Explications.

Sur le marché, plusieurs solutions de gestion des consentements – les CMP, pour Consent Management Platform – sont à la disposition des éditeurs de sites. Certaines sont gratuites et génériques, d’autres, payantes et plus personnalisables. Surtout, certaines s’adossent exclusivement au framework de l’IAB, là où d’autres – c’est le cas de la CMP de Commanders Act – ne s’y limitent pas. Cette différence est essentielle, et bien la saisir suppose d’appréhender l’esprit du framework IAB.

Le framework IAB, une lecture orientée « vendors » du RGPD

Sans surprise, ce framework est inspiré par une lecture orientée « vendors » du RGPD (Règlement Général sur la Protection des Données). Entendez par « vendors » les acteurs dont les services et solutions exploitent des données à caractère personnel. Le framework de l’IAB consiste, une fois le consentement obtenu ou refusé, à communiquer cette réponse à ces acteurs. Ce consentement peut être donné globalement (pour toute la liste des « vendors »), par usage (on parle de « purpose » dans le langage IAB) ou par acteur. Mais, finalement, le principe reste le même : le framework fait confiance au « vendor » pour respecter le statut du consentement.

Très concrètement, dans le modèle de l’IAB, les tags des services utilisés par un site sont donc chargés en même temps que les pages web, que le consentement soit donné ou pas. Et il revient aux « vendors » de tenir compte du consentement (obtenu ou rejeté) pour exploiter ou non les données. Ce mode de fonctionnement est radicalement différent de celui de la CMP de Commanders Act : avec elle, les tags ne sont tout simplement pas chargés tant que l’utilisateur n’a pas donné son consentement. Aucune information n’est donc transmise. Rien de magique ici : c’est le fait de coupler CMP et TMS (Tag Management System) qui permet de conditionner ce chargement des tags à l’obtention du consentement.

Renouvellement incessant des consentements

Le mode de fonctionnement des CMP dérivées du framework IAB présente une autre limite. Et c’est elle qui explique le renouvellement incessant des consentements. La liste des « vendors » évolue régulièrement. À l’heure où nous publions cet article, la dernière mise à jour numérotée 135 date ainsi du 21 février 2019. Comme les mises en œuvre les plus courantes de ces CMP « IAB-centric » collectent le consentement en une fois pour l’ensemble de la liste, dès que celle-ci accueille un nouveau vendor, ce consentement doit être renouvelé. Logique. Voilà pourquoi les utilisateurs voient la fameuse pop-in s’afficher parfois plusieurs fois par mois.

Notons que ce phénomène pourrait être moindre si les mises en œuvre s’appuyaient davantage sur l’obtention d’un consentement par « purpose » (versus un consentement pour tous les usages). Dans ce cas, le renouvellement du consentement serait nécessaire uniquement en cas de mise à jour des vendors concernés par l’un des usages acceptés par l’utilisateur – la personnalisation par exemple ou encore la publicité.

Un pari court-termiste

Dans la pratique ce consentement par les usages est délaissé au profit d’une validation globale afin de maximiser le taux d’acceptation. Un pari que l’on peut considérer court-termiste : après plusieurs sollicitations mensuelles pour renouveler le consentement, il ne serait pas surprenant de voir les utilisateurs se lasser au point de baisser la fréquence de leurs visites…

Question légitime pour les éditeurs de sites : comment gérer les consentements relatifs à des « vendors IAB » tout en épargnant aux utilisateurs ces renouvellements intempestifs de leurs consentements ? La solution existe : elle consiste à charger une liste de vendors IAB spécifique (celle qui correspond strictement aux tags à activer sur un site) afin d’éviter une mise à jour dès qu’un nouvel acteur est inscrit dans la liste globale de l’IAB.

C’est la voie choisie par Commanders Act dont la CMP fonctionne également sur la base des « purposes ». Résultat, les consentements sont obtenus sur la base d’usages explicites associés à une liste spécifique de « vendors ». Une collecte qui concilie conformité (au RGPD) et qualité de l’expérience (les renouvellements de consentement sont sensiblement réduits). Last but not least : le procédé est ouvert aux « vendors » non-IAB. Car, oui, ne l’oublions pas, tous les acteurs Martech ne sont pas inscrits sur la liste de l’IAB, mais tous sont bien concernés par le RGPD…