Tracking respectueux du RGPD avec Google Consent Mode

Loi sur la vie privée et mesure précise sont souvent présentées comme un compromis : respectez les choix de vos visiteurs et perdez vos données, ou gardez vos données et risquez une amende. Ce cadrage est faux. Avec Google Consent Mode v2 et une configuration côté serveur bien faite, vous pouvez honorer pleinement le consentement et tout de même bien mesurer votre boutique PrestaShop.

Cet article explique comment fonctionne Consent Mode v2, ce que « refusé par défaut » signifie en pratique, comment le tracking côté serveur et le hachage SHA-256 soutiennent la conformité, et — tout aussi important — ce que ces outils ne font pas pour vous. La conformité est une combinaison de technologie et des bases juridiques, et vous avez besoin des deux. Rien de tout cela n'est un conseil juridique ; voyez-le comme une orientation pratique.

Ce qu'est Google Consent Mode v2

Consent Mode est le cadre de Google pour adapter le comportement de ses balises selon les choix de consentement d'un visiteur. Plutôt qu'un binaire activé/désactivé, il utilise des signaux de consentement — tels que analytics_storage et ad_storage — que votre bannière de cookies positionne sur accordé ou refusé.

La version 2 (Consent Mode v2) a ajouté deux signaux liés à la publicité, ad_user_data et ad_personalization, et Google l'exige désormais pour les annonceurs utilisant ses plateformes dans l'Espace économique européen. Quand un visiteur refuse le consentement, les balises de Google respectent ce choix et limitent ce qu'elles collectent et stockent.

L'idée clé est que Consent Mode est le pont entre votre bannière de consentement et les balises de Google. La bannière capte le choix ; Consent Mode le communique à GA4 et Google Ads pour qu'ils se comportent en conséquence.

Refusé par défaut : partir du non

Une configuration conforme part du refus, pas de la permission. « Refusé par défaut » signifie qu'avant qu'un visiteur n'interagisse avec votre bannière, les signaux de consentement sont positionnés sur refusé, donc aucun cookie d'analyse ou de publicité n'est écrit et aucune donnée personnelle n'est collectée à ces fins.

C'est seulement quand le visiteur accorde activement le consentement que les signaux basculent sur accordé et que le tracking complet commence. Cet ordre compte : sous le RGPD et les règles ePrivacy, le consentement doit être donné avant le tracking non essentiel, pas supposé puis retiré plus tard.

Quand le consentement est refusé, Consent Mode peut tout de même envoyer des pings sans cookie que Google utilise pour une modélisation agrégée et respectueuse de la vie privée — mais aucun identifiant et aucune donnée personnelle. Le visiteur qui dit non est respecté ; vous perdez simplement la mesure granulaire pour cette visite, ce qui est exactement comme il se doit.

Comment le tracking côté serveur s'y intègre

Une idée fausse fréquente est que le tracking côté serveur est un moyen d'esquiver le consentement. Ce n'est pas le cas, et le traiter ainsi serait une grave erreur de conformité. Une configuration côté serveur correcte respecte les mêmes signaux de consentement que le tracking côté client — quand le consentement est refusé, les événements ne sont pas envoyés.

Ce que la livraison côté serveur améliore réellement, c'est la fiabilité et le contrôle pour les visiteurs qui ont consenti. Elle récupère les conversions consenties que les bloqueurs de publicités et l'ITP laisseraient autrement tomber pour des raisons purement techniques, et elle vous offre un point unique — le conteneur sGTM auto-hébergé — où vous contrôlez exactement quelles données sont envoyées plus loin et lesquelles sont retirées.

Ce contrôle est en soi un bénéfice pour la vie privée. Vous décidez ce qui quitte votre boutique, vous pouvez minimiser la charge utile, et vous gardez les identifiants sensibles côté serveur. Voyez comment ça marche pour les spécificités PrestaShop.

Hachage et minimisation des données

L'autre pilier est ce qui arrive aux données personnelles avant leur transmission. PrestaSignal normalise et hache en SHA-256 toutes les PII — e-mail, téléphone, nom, ville, région et similaires — à l'intérieur de votre boutique avant que quoi que ce soit ne soit envoyé. SHA-256 est une fonction à sens unique, donc le destinataire reçoit une empreinte irréversible, jamais un e-mail ou un numéro de téléphone lisible.

Cela soutient le principe RGPD de minimisation des données : vous ne partagez que ce qui est nécessaire à la correspondance, sous une forme non réversible. Le pays et le code postal sont parfois envoyés en clair là où une plateforme l'exige, mais les détails identifiants qui comptent le plus sont d'abord hachés.

Le hachage n'est pas une exemption magique du RGPD — des données hachées liées à une personne peuvent rester des données personnelles — mais il réduit nettement l'exposition et constitue une garantie reconnue. Notre page confidentialité & données liste exactement ce qui est envoyé et sous quelle forme.

Ce dont vous avez encore besoin

La technologie gère la mécanique du consentement, mais elle ne vous rend pas conforme à elle seule. Vous avez encore besoin des bases juridiques et opérationnelles autour d'elle.

D'abord, une vraie bannière de consentement (une Consent Management Platform) qui bloque réellement les balises non essentielles jusqu'à ce que le visiteur opte pour, et qui enregistre son choix. Ensuite, une politique de confidentialité claire et exacte expliquant ce que vous collectez, pourquoi et avec qui vous le partagez — tenue à jour avec votre configuration réelle. Enfin, une politique de cookies honnête décrivant les cookies utilisés.

Consent Mode, la livraison côté serveur et le hachage sont la couche d'application technique qui rend ces documents vrais en pratique. Réussissez les deux moitiés — la paperasse et la tuyauterie — et vous avez une configuration qui respecte vos visiteurs et résiste à l'examen. Pour de l'aide sur l'alignement du côté technique, réservez un audit.