Conformité RGPD & Consent Mode v2

Le trou noir de données et le faux dilemme

Vous avez ajouté une bannière de cookies. Une semaine plus tard, GA4 affiche 30 % à 50 % de trafic en moins. Google Ads voit moins de conversions. Smart Bidding tourne avec peu de données : votre CPA explose et votre ROAS chute. Des signaux perdus affament l’algorithme et font grimper votre CAC.

Vous voilà face à un choix qui semble impossible : rester en règle et ne plus rien voir, ou garder vos données et risquer une amende. C’est un faux dilemme.

Le risque est réel. De nombreux plugins de bannière WordPress, purement cosmétiques, ne bloquent aucun script avant le consentement. La bannière s’affiche, mais GA4 et les pixels publicitaires se déclenchent quand même. Ce n’est pas de la conformité. Avec la nLPD suisse (nFADP), les dirigeants s’exposent à des amendes pénales personnelles jusqu’à 250 000 CHF. Dans l’UE, les amendes du RGPD visent l’entreprise.

Voici la sortie. La conformité stricte n’est pas une sanction. C’est une opportunité technique. Avec Google Consent Mode v2, vous respectez le choix du visiteur et vous modélisez, légalement, les données que vous ne pouvez pas observer.

Démonter les mythes

Mythe 1 : « Si un utilisateur refuse, je perds 100 % des données. »

Pas avec le Consent Mode v2 avancé. Quand un visiteur refuse, vos balises se chargent quand même, mais elles se comportent autrement. Elles envoient des pings anonymes, sans cookie. Pas d’identifiant utilisateur. Pas de cookie. L’IA de Google s’appuie sur ces signaux pour modéliser les conversions manquantes. Pour Google Ads, cela peut récupérer jusqu’à 70 % des parcours de conversion que vous perdriez sinon. Vos enchères retrouvent leur signal.

Mythe 2 : « N’importe quel plugin de bannière gratuit suffit. »

Faux. La plupart des plugins gratuits sont des surcouches HTML cosmétiques. Ils affichent une bannière et ne bloquent rien. Une vraie CMP agit comme un pare-feu d’exécution. Elle bloque physiquement les scripts tant que le visiteur n’a pas donné son consentement explicite. Si votre bannière ne bloque rien, vous portez le risque juridique et vous subissez quand même la perte de trafic.

Mythe 3 : « Les bannières de consentement ruinent la vitesse du site. »

Les CMP commerciales lourdes comme OneTrust, oui. Elles chargent de gros bundles, provoquent du layout thrashing et font grimper votre score INP. Des pages lentes vous coûtent des conversions. J’utilisetarteaucitron.js à la place. Il est open source et léger. Il s’exécute en asynchrone et laisse le thread principal libre. Votre site reste rapide et vous restez conforme.

Les quatre signaux et le câblage technique

Depuis mars 2024, Google exige quatre signaux de consentement. Chacun pilote un comportement précis :

• analytics_storagepilote les cookies et la mesure de GA4.
• ad_storagepilote les cookies publicitaires de Google Ads et des autres balises publicitaires.
• ad_user_datadétermine si des données utilisateur peuvent être envoyées à Google à des fins publicitaires.
• ad_personalizationpilote la publicité personnalisée, comme le remarketing.

Surveillez les deux derniers. Si ad_user_data etad_personalization ne passent pas à « granted » après le consentement, vos listes de retargeting Google Ads cessent immédiatement de se mettre à jour. Vos audiences vieillissent et vos campagnes de remarketing s’arrêtent sans bruit.

tarteaucitron.js se connecte nativement à Google Consent Mode v2. Il définit l’état par défaut, puis met à jour les quatre signaux selon le choix du visiteur. Aucun fournisseur externe. Aucun verrouillage. Aucun abonnement mensuel. Le code est à vous et vous pouvez auditer chaque ligne.

Éviter les race conditions grâce à un câblage précis

Une race condition survient quand une balise s’exécute avant que la CMP ait défini l’état « denied » par défaut. La balise se déclenche avec tous les droits. C’est contraire à la loi sur la vie privée, et cela corrompt vos données, car ces hits n’auraient jamais dû être collectés comme « granted ».

Je règle cela avec deux paramètres :

• Le bon déclencheur. Dans GTM, le consentement par défaut s’exécute sur le déclencheurConsent Initialization - All Pages. Il part avant toutes les autres balises.
• Une courte attente. Je règlewait_for_update sur une valeur comme 500 ms. Les balises attendent ce délai pour que la CMP retrouve le choix enregistré d’un visiteur connu avant de se déclencher.

Voici la configuration propre. D’abord l’état par défaut, puis la mise à jour après l’acceptation du visiteur :

// État par défaut avant interaction : tout est refusé
gtag('consent', 'default', {
  analytics_storage: 'denied',
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500
});

// Mise à jour de l'état dès que l'utilisateur donne son consentement explicite via la CMP
gtag('consent', 'update', {
  analytics_storage: 'granted',
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted'
});

Tout démarre à « denied ». Rien n’est stocké et rien n’est partagé. Ce n’est qu’au consentement explicite du visiteur, via la CMP, que l’appel de mise à jour passe les signaux à « granted ». Un visiteur qui refuse reste sur l’état par défaut, et le Consent Mode envoie les pings sans cookie qui alimentent la modélisation des conversions. Conforme par défaut. Mesuré par conception.