Consent Mode v2 sur PrestaShop : ce que c'est et comment le régler

par Luca Cavallini Guides techniques
Consent Mode v2 sur PrestaShop : ce que c'est et comment le régler

Un bandeau cookies et le Consent Mode v2 ne sont pas la même chose

Un bandeau cookies demande une autorisation au visiteur. Le Consent Mode v2, c'est la manière dont cette autorisation est transmise à Google, avant qu'une balise comme Google Analytics ou Google Ads ne reçoive la moindre donnée. Ils se situent à des niveaux différents : vous pouvez avoir un bandeau parfaitement conforme au RGPD et une configuration du Consent Mode qui reste fausse, parce que le bandeau est une interface utilisateur alors que le Consent Mode est un protocole entre votre site et les balises de Google, fait de signaux qui ont un nom précis et un ordre précis dans lequel ils doivent être définis.

Depuis la version 2, obligatoire pour quiconque utilise en Europe des balises Google auprès d'un public soumis au RGPD, les signaux ne sont plus deux mais six : ad_storage et analytics_storage existaient déjà en v1, ad_user_data (autorisation d'envoyer des données personnelles à Google à des fins publicitaires) et ad_personalization (autorisation de les utiliser pour personnaliser les annonces) ont été ajoutés, et en pratique presque toutes les implémentations réelles gèrent aussi functionality_storage et personalization_storage pour les préférences propres au site. Un septième signal, security_storage, reste accordé en permanence, puisqu'il couvre les cookies techniques de sécurité, pas le suivi.

L'ordre compte plus que le contenu : la valeur par défaut doit arriver avant la balise

L'erreur la plus fréquente ne porte pas sur les valeurs choisies mais sur la séquence. Une balise Google (GTM, gtag.js) qui se charge avant que le site ait déclaré une valeur de consentement par défaut se comporte comme si aucun dispositif de consentement n'existait, ce qui est pour elle l'état le plus permissif. Une configuration Consent Mode v2 bien construite suit toujours le même schéma, dans cet ordre :

  • Dès que le document commence à se charger, avant tout script tiers, une valeur par défaut refusée est déclarée pour chaque signal de suivi (denied pour le marketing et les statistiques, granted uniquement pour security_storage), avec un court délai de grâce (500 millisecondes dans notre propre implémentation) qui laisse le temps de relire un choix enregistré précédemment avant qu'une balise ne puisse partir avec les mauvaises valeurs.
  • Si le visiteur a déjà fait un choix lors d'une visite précédente, ce choix est relu dans le cookie de consentement et envoyé immédiatement à Google sous forme de commande de mise à jour du consentement, toujours avant que GTM ou gtag.js ne soient réellement demandés aux serveurs de Google.
  • Ce n'est qu'à ce moment-là, avec le contexte de consentement déjà déclaré, que GTM, une balise Google Analytics 4 directe (si vous ne passez pas par GTM) et tout pixel tiers comme celui de Meta sont chargés, et le pixel lui-même a encore besoin de son propre appel de consentement, pas d'un simple « si le cookie dit oui, charger le script ».

Placer la valeur par défaut au bon endroit du code tient en trois lignes. La placer au mauvais endroit, par exemple dans le même bloc qui charge GTM au lieu de le précéder, annule tout le mécanisme : Google voit toujours arriver la balise avant le signal.

Le bandeau seul ne bloque rien : il faut aussi un blocage générique

Une lacune pratique que le Consent Mode v2 ne comble pas à lui seul, c'est qu'il ne couvre que les balises de Google, pas les autres scripts tiers qu'un thème ou un autre module a pu déposer sur la page (une carte intégrée, un widget d'avis, une vidéo). Une implémentation sérieuse ajoute une couche indépendante qui surveille le DOM pendant la construction de la page, reconnaît un script ou une iframe grâce à une liste de motifs de domaines (par exemple google-analytics.com, facebook.net, doubleclick.net, ou le domaine d'un service vidéo) et, si la catégorie à laquelle il appartient n'a pas encore été acceptée, le remplace par un élément inerte avant qu'il ait pu faire la moindre requête réseau. Ce n'est qu'une fois que le visiteur accepte cette catégorie que le vrai script est remis en place. Sans cette couche, une valeur par défaut refusée ne couvre que les balises que le site a lui-même écrites pour la respecter, pas celles embarquées dans des modules tiers qui ignorent votre Consent Mode et partent quand même.

Un cas réel : une valeur par défaut techniquement correcte, un bandeau que personne ne pouvait lire

Dans notre propre module de consentement, nous avons trouvé le 14 septembre 2026 un défaut instructif : le mécanisme du Consent Mode lui-même était correct, la valeur par défaut refusée partait au bon moment, et pourtant le texte du bandeau (titre, corps, les trois boutons, les noms des catégories) s'affichait en anglais pour quiconque naviguait sur une boutique en français, en espagnol ou en allemand, alors que l'italien et l'anglais étaient corrects. La cause n'était pas une traduction manquante dans le catalogue de chaînes de PrestaShop : le texte du bandeau était écrit directement dans le code du module, dans un tableau qui ne couvrait que deux langues, et pour toute autre langue le code revenait silencieusement à l'anglais. Nous l'avons corrigé en ajoutant les trois blocs de langue manquants (français, espagnol, allemand, 17 chaînes chacun, avec de vrais caractères accentués plutôt que de simples apostrophes) et publié la version 1.0.9.

Ce n'est pas qu'une question cosmétique. Un consentement recueilli en affichant un texte que le visiteur ne peut pas lire est un consentement fragile : le RGPD exige que l'information soit compréhensible pour la personne qui la lit, pas seulement techniquement présente sur la page. Une configuration Consent Mode irréprochable au niveau du code ne vaut pas grand-chose si la personne devant le bandeau lit une langue qu'elle ne parle pas.

Une check-list pratique pour vérifier votre propre configuration

  • Ouvrez le code source de la page d'accueil, le vrai « afficher le code source », pas les outils de développement, et vérifiez que gtag("consent","default",...) apparaît avant toute balise Google Tag Manager ou gtag.js dans le document, pas après.
  • Vérifiez que les six signaux sont présents dans la valeur par défaut, pas seulement les ad_storage et analytics_storage hérités du Consent Mode v1 : l'absence de ad_user_data ou de ad_personalization est l'erreur la plus fréquente dans les configurations « mises à jour » seulement de nom.
  • Vérifiez avec les outils réseau du navigateur qu'un script comme Google Analytics ne part pas réellement avant que le consentement soit donné : une valeur par défaut refusée doit se traduire par zéro requête réseau vers ce domaine, pas seulement par un signal déclaré puis ignoré.
  • Changez la langue de la boutique et regardez à nouveau le bandeau : un texte traduit à moitié est un défaut aussi fréquent qu'invisible pour celui qui l'a publié, puisqu'on le vérifie presque toujours dans la langue de travail de l'équipe.

En bref

Le Consent Mode v2 n'est pas une case à cocher dans le panneau de réglages d'un module cookies : c'est une séquence précise de signaux, où l'ordre compte autant que le contenu, plus une couche de blocage qui doit couvrir des scripts que le site n'a jamais écrits lui-même. Une implémentation techniquement correcte peut encore manquer son but si le texte qui accompagne la demande de consentement n'atteint jamais réellement, dans sa langue, la personne qui doit le lire. Des modules dédiés existent pour PrestaShop, dont un gratuit dans notre propre catalogue (cll_consent), mais la séquence décrite ci-dessus reste valable quel que soit le module qui l'implémente.

Bandeau Cookies et Google Consent Mode v2Module gratuit : téléchargez-le et installez-le immédiatement. Bannière de cookies RGPD avec catégories gran…Voir le produit

Laisser un commentaire

Les commentaires sont modérés avant publication.

← Blog

Chargement...
Retour en haut