Le mode de consentement est le mécanisme par lequel vos outils de mesure et de publicité adaptent leur comportement selon ce que le visiteur a accepté. Sa mise en place est devenue une condition d’accès à certaines fonctionnalités publicitaires en Europe, et elle est souvent faite à moitié.
Les règles générales de la bannière cookies ont été traitées séparément. Cet article porte sur l’articulation technique avec les outils de mesure.
Le principe
Sans mode de consentement, votre choix est binaire : soit le script de mesure se charge, soit il ne se charge pas.
Avec le mode de consentement, le script se charge dans un état restreint tant que le visiteur n’a pas accepté. Il n’écrit pas de cookie, il ne transmet pas d’identifiant, et il peut envoyer des signaux dépourvus de données personnelles.
Deux conséquences pratiques. Vous conservez une mesure agrégée sur les visiteurs qui refusent. Et le passage du refus à l’acceptation est pris en compte immédiatement, sans rechargement.
Point à ne pas confondre : ce mécanisme ne dispense pas du consentement. Il définit ce que font vos outils en son absence.
Les quatre signaux
Le dispositif repose sur quatre indicateurs, chacun accordé ou refusé indépendamment.
Deux concernent la mesure d’audience : le stockage à des fins d’analyse, et la transmission des données de mesure.
Deux concernent la publicité : le stockage publicitaire, et l’usage des données à des fins de personnalisation ou de mesure publicitaire.
Trois règles de mise en œuvre.
Chaque signal doit correspondre à une finalité de votre bandeau. Si votre bandeau propose « mesure d’audience » et « publicité », la correspondance est simple. S’il ne propose qu’un choix global, vous ne pouvez pas renseigner les signaux correctement.
Tous les signaux doivent être déclarés, même ceux que vous n’utilisez pas. Un signal absent est traité comme non renseigné, ce qui n’est pas la même chose que refusé.
L’état par défaut est le refus, jusqu’à ce que le visiteur choisisse.
L’ordre d’exécution, point critique
C’est l’erreur technique la plus fréquente et elle rend tout le dispositif inopérant.
L’état par défaut doit être déclaré avant le chargement des scripts de mesure. Si le script se charge d’abord et que l’état arrive ensuite, le premier événement part avec les réglages par défaut de l’outil, c’est-à-dire sans restriction.
Concrètement, la séquence est : déclaration de l’état par défaut, puis chargement du gestionnaire de balises, puis mise à jour de l’état quand le visiteur choisit.
Sur PrestaShop, cela suppose que le code de déclaration soit injecté très haut dans la page, avant tout autre script de mesure. Un module de consentement qui se charge après le gestionnaire de balises ne peut pas fonctionner correctement.
Vérification : regardez l’ordre des scripts dans le code source de votre page d’accueil. La déclaration d’état doit précéder tout le reste.
DataFirefly Cookie Manager — propulsé par le moteur open-source tarteaucitron.jsLe bandeau cookies conforme CNIL, sans renoncer à la mesure.€220.00
Le blocage préalable reste nécessaire
Confusion fréquente qu’il faut lever.
Le mode de consentement gère le comportement des outils qui le prennent en charge. Il ne bloque pas les autres.
Vos scripts de chat, de carte, de vidéo intégrée, d’avis clients ou de test comportemental ne le connaissent pas. Ils doivent être bloqués par votre dispositif de consentement, comme avant.
La configuration correcte combine donc deux mécanismes : un blocage préalable pour tout ce qui dépose des traceurs sans le prendre en charge, et le mode de consentement pour les outils compatibles.
Erreur à éviter : croire que la mise en place du mode de consentement dispense du blocage. Elle ne couvre qu’une partie de votre page.
La mise à jour au moment du choix
Trois points d’implémentation.
La mise à jour doit être immédiate, sans rechargement de page. Un visiteur qui accepte doit voir la mesure complète s’activer sur sa session en cours.
Elle doit refléter le choix par finalité, pas appliquer un accord global. Un visiteur qui accepte la mesure et refuse la publicité doit produire deux signaux accordés et deux refusés.
Le choix doit être mémorisé et réappliqué à chaque visite, jusqu’à expiration.
Point complémentaire : le retrait du consentement doit également mettre à jour les signaux, dans l’autre sens. Un dispositif qui ne gère que l’acceptation est incomplet.
Ce que vous mesurez en cas de refus
Question légitime, et la réponse mérite d’être nuancée.
En état restreint, les outils peuvent transmettre des signaux sans identifiant ni cookie. Ces signaux permettent une estimation du comportement des visiteurs ayant refusé, par modélisation.
Trois précisions honnêtes.
Cette estimation est une modélisation, pas une mesure. Elle produit des ordres de grandeur, pas des chiffres exacts.
Elle suppose un volume suffisant de données observées pour être calculée. Sur une petite boutique, elle peut ne pas être disponible.
Elle ne rétablit pas ce que le refus a supprimé. Elle atténue la perte, elle ne l’annule pas.
Présenter ce mécanisme comme un moyen de « récupérer les conversions perdues » est une lecture excessive qui circule beaucoup.
Vérifier que cela fonctionne
Quatre contrôles, tous réalisables dans le navigateur.
Avant tout choix, ouvrez la console et regardez les requêtes sortantes. Les appels de mesure peuvent partir, mais sans cookie et avec les paramètres indiquant l’état restreint.
Après un refus, vérifiez qu’aucun cookie de mesure ou de publicité n’est déposé.
Après une acceptation, vérifiez que les cookies apparaissent et que les appels comportent les identifiants attendus.
Sur un retour de visite, vérifiez que le choix précédent est réappliqué sans redemander.
Ajoutez un contrôle dans l’outil de mesure lui-même, qui expose généralement un rapport sur l’état des signaux reçus. C’est là que se voient les incohérences que la console ne montre pas.
Les erreurs fréquentes
Un seul signal renseigné. Certaines configurations ne déclarent que le stockage analytique et laissent les trois autres non renseignés.
L’état par défaut accordé. Erreur grave : elle revient à collecter avant consentement.
La correspondance approximative. Une finalité « marketing » de votre bandeau mappée sur les quatre signaux à la fois, ce qui ne respecte pas le choix du visiteur.
Le dispositif absent sur certaines pages. Le tunnel de commande ou les pages d’atterrissage publicitaires échappent parfois au bandeau, par un modèle de page différent.
Ce dernier cas est le plus dommageable : les pages qui comptent le plus pour votre mesure sont celles où le dispositif manque.
L’articulation avec l’envoi serveur
Point à traiter si vous transmettez des événements depuis votre serveur.
L’envoi serveur ne passe pas par le navigateur, donc il ignore l’état des signaux, sauf si vous le lui transmettez explicitement.
Deux conséquences. Votre implémentation serveur doit connaître l’état du consentement du visiteur, ce qui suppose de le stocker et de l’associer à la session.
Et elle doit conditionner ou restreindre l’envoi en conséquence. Transmettre des données publicitaires depuis le serveur pour un visiteur qui les a refusées dans le navigateur est un contournement, pas une optimisation.
Le Cookie Manager pour PrestaShop met en place cette chaîne sur PrestaShop 8 et 9 : déclaration de l’état par défaut avant tout script de mesure, correspondance entre les finalités du bandeau et les quatre signaux, mise à jour immédiate au choix et blocage préalable des scripts tiers qui ne prennent pas ce mécanisme en charge.
