Actualités e-commerce

RGPD 2026 et Consent Mode v2 sur PrestaShop : configuration complète pour rester conforme et garder son tracking GA4

RGPD Consent Mode v2

Depuis mars 2024, Google impose le Consent Mode v2 à tout site qui veut conserver l’accès aux données GA4 et Google Ads pour les utilisateurs européens. En 2026, beaucoup de boutiques PrestaShop tournent encore avec une configuration mal comprise — soit en Consent Mode v1 oublié dans un coin, soit en v2 mal câblé, soit pire, sans Consent Mode du tout. Le résultat est invariablement le même : des données GA4 partielles, des audiences Google Ads qui ne se remplissent plus, et un risque de conformité RGPD que la CNIL prend de moins en moins à la légère depuis ses sanctions de 2024-2025.

Ce guide couvre la configuration complète du Consent Mode v2 sur PrestaShop 8 : ce qui a changé par rapport à v1, le stack technique à mettre en place (CMP + Google Tag Manager + GA4), les erreurs typiques qu’on voit en audit, et comment vérifier que tout marche réellement avant de considérer le sujet comme bouclé.

Le Consent Mode v1 (lancé en 2020) gérait deux paramètres de consentement : ad_storage et analytics_storage. C’était suffisant pour différencier le tracking analytics du tracking publicitaire, et la CNIL acceptait l’approche.

Le Consent Mode v2 (mars 2024) ajoute deux paramètres supplémentaires :

  • ad_user_data — autorisation d’envoyer des données utilisateur à Google pour de la publicité (par exemple, hash d’email pour les Customer Match). Sans cette autorisation, vos audiences personnalisées Google Ads ne se remplissent plus.
  • ad_personalization — autorisation d’utiliser ces données pour de la publicité personnalisée (remarketing, audiences similaires, etc.). Sans cette autorisation, vos campagnes de remarketing tournent à vide.

Pour conserver l’accès aux fonctionnalités Google Ads complètes, ces deux paramètres doivent être positionnés explicitement, en plus des deux historiques. Si vous ne le faites pas, Google considère que vous n’avez pas migré et bloque progressivement les fonctionnalités les plus dépendantes des données utilisateur (Customer Match, audiences avancées, remarketing dynamique).

L’autre changement majeur, c’est la distinction entre Consent Mode basique et Consent Mode avancé. En basique, si l’utilisateur refuse les cookies, aucun tag Google ne se déclenche du tout — vous perdez 100 % de la donnée pour ce visiteur. En avancé, les tags Google se déclenchent quand même mais en mode « cookieless » (envoi de pings anonymes), et Google utilise ensuite la modélisation statistique pour combler les trous des utilisateurs qui ont refusé. C’est nettement plus puissant, mais c’est aussi plus délicat à implémenter — et c’est là que la majorité des configurations partent en vrille.

Dernier point : le Consent Mode v2 doit être déclaré avant tout autre tag Google sur la page (GA4, Google Ads, Floodlight, etc.). Si l’ordre n’est pas respecté, les premiers événements partent sans état de consentement et votre conformité RGPD est cassée. C’est l’erreur la plus fréquente qu’on voit en audit.

Le stack à mettre en place sur PrestaShop 8

La configuration propre repose sur trois composants qui doivent travailler ensemble.

Une CMP (Consent Management Platform). C’est le bandeau cookies que voit le visiteur, qui collecte son choix et l’expose techniquement aux autres scripts de la page. Sur PrestaShop 8, plusieurs options existent : tarteaucitron (gratuit, français, IAB TCF non requis pour les sites non-publishers), Axeptio ou Didomi (CMP IAB TCF v2.2 si vous avez besoin du framework publicitaire), ou des solutions intégrées dans des modules dédiés.

Google Tag Manager. Le hub central qui orchestre vos tags. Sans GTM, gérer le Consent Mode v2 directement dans le code théorique de PrestaShop est faisable mais devient ingérable dès qu’on ajoute Google Ads, Meta Pixel, TikTok Pixel, et d’autres trackers. GTM centralise la logique et permet de conditionner chaque tag à l’état de consentement courant.

GA4 et les destinations Google Ads. En aval, ce sont les destinations qui consomment l’information de consentement. GA4 et Google Ads lisent automatiquement les paramètres Consent Mode quand ils sont correctement positionnés via GTM ou via les tags directs.

L’orchestration : la CMP signale à GTM le choix de l’utilisateur via un dataLayer push, GTM déclenche les tags Google avec les bons paramètres de consentement, GA4 et Google Ads enregistrent les données selon ce que le consentement permet. Si l’un de ces trois maillons est mal configuré, la chaîne se casse silencieusement.

Sur PrestaShop 8 spécifiquement, le défi est que ces composants viennent de modules différents qui ne se parlent pas par défaut. Sans coordination, vous avez votre CMP qui fait son travail, GTM qui fait le sien, et GA4 qui collecte tout ou rien selon les hasards de l’ordre de chargement. La configuration manuelle est possible mais pénible ; un module dédié qui gère la chaîne complète est généralement plus fiable.

Configuration de la CMP : tarteaucitron, Axeptio, ou solution intégrée

Le choix de la CMP dépend de votre besoin réel.

Tarteaucitron est une CMP française open source largement utilisée sur PrestaShop. Avantages : gratuite, conforme RGPD strict, gestion granulaire des services tiers (Google Tag Manager, GA4, Hotjar, YouTube, etc.), et personnalisable visuellement. Limites : configuration technique parfois pénible, pas de framework IAB TCF v2.2 (donc inadaptée si vous publiez de la pub display via SSP). Pour 95 % des boutiques PrestaShop classiques (vente de produits, pas de monétisation publicitaire), tarteaucitron est suffisant.

Sur PrestaShop 8, le module Cookie Manager Tarteaucitron intègre la librairie avec une configuration back-office propre, gère les services tiers courants en quelques clics, et expose les states de consentement vers GTM via des événements dataLayer standards. La connexion avec GTM est automatique, ce qui élimine la majorité des erreurs de timing.

Axeptio et Didomi sont des CMP commerciales (à partir de 30-100 € par mois selon le volume), avec support IAB TCF v2.2. À choisir si vous monétisez avec de la publicité programmatique, ou si vous opérez dans un secteur sensible (santé, finance) où le niveau de conformité doit être documenté. Pour la majorité des boutiques e-commerce classiques, c’est de la sur-ingénierie.

Solutions tout-en-un. Certains modules combinent CMP + tracking GA4/Ads + Consent Mode v2 dans un seul package, ce qui élimine les conflits de version et de timing. C’est ce que fait le module Google Tag Pro sur PrestaShop : tracking GA4 et Google Ads enhanced ecommerce complet, Consent Mode v2 natif, et compatibilité avec les CMP courantes (tarteaucitron, Axeptio, Didomi) via détection automatique. Approche pragmatique pour les boutiques qui veulent un setup conforme sans bricolage.

Quel que soit le choix, le test à faire après installation : recharger la page en navigation privée, refuser les cookies dans le bandeau, et vérifier dans les Outils Développeur > Réseau que aucun tag Google ne charge avant que vous fassiez votre choix. Si un tag charge avant, votre CMP n’est pas configurée correctement et votre conformité RGPD est cassée.

Côté GTM, la configuration suit toujours la même séquence : initialiser le Consent Mode avec un état par défaut « tout refusé », puis envoyer un événement consent update dès que l’utilisateur a fait son choix dans la CMP.

Tag de configuration Default (à déclencher en premier sur toutes les pages). Ce tag pose les valeurs par défaut du Consent Mode avant tout autre tag :

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'wait_for_update': 500
});

Le paramètre wait_for_update indique à Google d’attendre jusqu’à 500 ms avant d’envoyer les premiers pings — le temps que la CMP ait pu déterminer le choix de l’utilisateur (cookie persistant existant ou nouveau choix). Ce paramètre évite les pings dupliqués qui partent une fois en mode « tout refusé » puis une seconde fois après le consentement.

Tag Update (à déclencher après le choix utilisateur). Ce tag met à jour les valeurs en fonction du choix exprimé dans la CMP :

gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

Sur GTM, ce tag se déclenche sur un événement custom (par exemple consent_granted) que la CMP pousse dans le dataLayer après le clic « Accepter » de l’utilisateur. Si l’utilisateur fait un choix granulaire (accepte analytics mais refuse pub), seuls les paramètres correspondants passent à granted.

Configuration des tags GA4 et Google Ads. Une fois le Consent Mode initialisé, les tags GA4 et Google Ads classiques fonctionnent normalement et lisent automatiquement les paramètres de consentement. Vous n’avez rien à modifier sur ces tags individuels — c’est tout l’intérêt de la centralisation Consent Mode.

L’astuce mode avancé. Pour activer le Consent Mode avancé (modélisation statistique des refus), il faut configurer dans GTM le paramètre « URL passthrough » et « Redact ads data » au niveau du conteneur. Ces options envoient des pings anonymisés même quand le consentement est refusé, ce qui permet à Google de modéliser le comportement de la cohorte refusante. Le détail : ces pings sont sans cookies, sans identifiants utilisateur, conformes RGPD.

Vérifier que tout marche : debugging avec Google Tag Assistant

Une fois la configuration en place, la vérification se fait avec deux outils Google.

Google Tag Assistant (https://tagassistant.google.com). Vous saisissez l’URL de votre boutique, l’outil charge la page dans une session de debug et trace tous les événements qui partent. Pour chaque événement, vous voyez les paramètres envoyés, dont les states de Consent Mode courants. Le test critique : ouvrir Tag Assistant, faire le parcours d’achat complet (homepage → fiche produit → ajout au panier → checkout → paiement), et vérifier que tous les événements partent avec les bons states.

Avant le consentement utilisateur, tous les événements doivent partir avec denied sur les 4 paramètres. Après consentement « tout accepter », tous doivent passer à granted. Si vous voyez un événement qui part avec un mix incohérent, ou un événement qui part avec granted avant le consentement, votre configuration est cassée.

L’extension Chrome Tag Assistant Companion. Plus puissante que la version web, elle s’installe dans Chrome et trace en temps réel tous les hits Google envoyés depuis le site visité. Pratique pour debug en navigation normale (pas dans une session Tag Assistant artificielle). L’extension affiche en temps réel les Consent States de chaque hit, ce qui permet de repérer les incohérences entre pages ou entre actions.

Le rapport « États de consentement » dans GA4. Une fois la configuration stabilisée depuis quelques jours, allez dans GA4 > Administration > Diagnostics. Le rapport « États de consentement » indique le pourcentage d’événements reçus avec consentement granted vs denied. Sur une boutique européenne avec une CMP correctement configurée, vous devriez voir 30 à 60 % d’événements en granted (selon votre design de bandeau et l’intensité de votre dark pattern). Si vous voyez 100 % de granted, votre CMP ne demande pas vraiment le consentement. Si vous voyez 0 % de granted, votre Update tag ne se déclenche pas.

Les erreurs typiques qu’on voit en audit

Sur les audits RGPD/Consent Mode des boutiques PrestaShop, les six erreurs suivantes reviennent en boucle.

Erreur 1 : le Default tag est déclenché après le tag GA4. Le Consent Mode doit être initialisé en tout premier dans le code de la page, avant que GA4 ou Google Ads ne se charge. Si l’ordre n’est pas respecté, GA4 envoie son premier ping (vue de page) sans état de consentement, donc en mode « consent inconnu », et la CNIL peut considérer que vous trackez avant consentement. Solution : dans GTM, mettre le Default tag avec le déclencheur « Initialization » (qui se déclenche avant tous les autres déclencheurs).

Erreur 2 : le Update tag ne se déclenche jamais. Symptôme classique : tous les pings restent en denied même après que l’utilisateur a cliqué « Tout accepter ». Cause : la CMP ne pousse pas l’événement attendu dans le dataLayer, ou GTM est configuré pour écouter le mauvais nom d’événement. À vérifier en console : taper dataLayer et chercher l’événement de consentement après avoir cliqué Accepter.

Erreur 3 : GTM bloqué par la CMP elle-même (le paradoxe). Certaines CMP mal configurées considèrent GTM comme un « tracker tiers » à bloquer avant consentement. Résultat : GTM ne charge pas, donc le Consent Mode n’est jamais initialisé, donc rien ne marche. La CMP doit autoriser GTM à charger avant le consentement (GTM lui-même est neutre, ce sont les tags qu’il déclenche qui dépendent du consentement).

Erreur 4 : conflits multi-modules. Sur les boutiques PrestaShop qui ont accumulé plusieurs modules de tracking au fil des années (un ancien module GA Universal, le natif PrestaShop GA4, un module GTM, un module Meta Pixel, etc.), les tags se court-circuitent entre eux. Le code GA4 part deux fois, le Consent Mode est posé puis écrasé par un autre module. Solution : auditer tous les modules de tracking actifs et n’en garder qu’un seul qui orchestre tout.

Erreur 5 : pas de gestion du retour utilisateur. Quand un utilisateur change d’avis et clique « Modifier mes préférences » dans le footer, la CMP doit déclencher un nouvel événement Update qui passe les paramètres au nouveau choix. Beaucoup de configurations gèrent l’événement Accept initial mais pas les changements ultérieurs, donc l’utilisateur qui retire son consentement continue d’être tracké comme s’il avait accepté.

Erreur 6 : Consent Mode v1 oublié à côté. Plusieurs boutiques migrées de v1 à v2 ont conservé l’ancien tag par erreur. Les deux Consent Modes coexistent et se disputent les paramètres, avec des résultats imprévisibles. Solution : supprimer toute trace du Consent Mode v1 (tags GTM, code dans le thème, modules anciens) avant de mettre en place v2.

Et la « modélisation » Google : ce qu’on récupère malgré le refus

Le grand argument de vente du Consent Mode avancé, c’est la modélisation statistique. Quand un utilisateur refuse les cookies, Google envoie quand même des pings anonymisés (pas d’identifiant, pas de cookie), et ses algorithmes ML utilisent ces signaux pour estimer ce qui se serait passé si l’utilisateur avait accepté. Concrètement, votre rapport GA4 affiche des conversions modélisées en plus des conversions observées.

Dans la réalité 2026, voici ce qu’on observe :

Conditions d’éligibilité. La modélisation ne se déclenche que si votre propriété GA4 a un volume minimum (1000 événements par jour environ, selon Google) et au moins 1000 utilisateurs sans consentement par jour. En dessous, GA4 affiche les données « brutes » sans modélisation, et vous perdez réellement les utilisateurs qui ont refusé. Pour une boutique avec 200-500 visiteurs jour, la modélisation ne sera probablement pas active sur tout votre trafic.

Côté Google Ads, c’est plus généreux. Les campagnes Google Ads bénéficient de la modélisation à partir de seuils plus bas, et l’effet est immédiatement visible sur le ROAS rapporté. Si vous faites de l’achat média Google, le Consent Mode avancé bien configuré peut récupérer 20 à 40 % de conversions « manquées » dans les rapports.

Réalité vs marketing. Google présente la modélisation comme une compensation magique, mais ce sont des estimations statistiques avec une marge d’erreur réelle. Le vrai bénéfice n’est pas tant le chiffre récupéré que la possibilité pour les algorithmes de bidding Google Ads de continuer à apprendre — c’est ça qui maintient la performance de vos campagnes Smart Bidding malgré la baisse du consentement explicite.

L’alternative serveur-à-serveur. Pour les boutiques qui veulent maximiser la collecte sans dépendre uniquement de la modélisation, le tracking server-side via GTM Server est une option. Plus complexe à mettre en place, mais récupère une partie significative des données perdues côté client. Sujet d’un autre article.

Conclusion : un investissement obligatoire qui demande de la rigueur

Le Consent Mode v2 sur PrestaShop n’est plus une option en 2026. C’est une obligation à la fois pour rester conforme RGPD et pour garder accès aux fonctionnalités complètes de Google Ads. La configuration n’est pas extraordinairement complexe, mais elle exige de la rigueur : ordre de déclenchement précis, coordination CMP/GTM/GA4, vérification systématique avec Tag Assistant.

L’erreur la plus coûteuse, c’est de penser que « ça doit marcher » parce qu’on a installé une CMP et que le bandeau cookie s’affiche. Sans vérification end-to-end avec Tag Assistant, vous découvrez les bugs de configuration des mois plus tard, en perdant des données et en risquant la conformité.

Pour aller plus loin sur les sujets connexes, parcourez nos tutoriels PrestaShop ou nos actualités e-commerce où nous suivons les évolutions réglementaires et techniques au fil des annonces Google et CNIL.

Et si vous voulez un setup tracking GA4 et Google Ads complet avec Consent Mode v2 natif et compatibilité CMP automatique, le module Google Tag Pro implémente la chaîne complète sur PrestaShop 8 — installation guidée, configuration en quelques clics, debugging intégré.