Google Consent Mode v2 dans WordPress : un guide pratique de configuration

Ce qu'est Google Consent Mode v2 et ce qu'il n'est pas

L'aperçu officiel de Consent Mode de Google le décrit comme un moyen d'ajuster le comportement des balises et SDK de Google en fonction des choix de consentement de l'utilisateur. Cela importe car la bannière recueille le choix d'un visiteur, mais les balises ont toujours besoin d'un signal structuré indiquant ce qui est autorisé.

En d'autres termes, le bandeau et le Consent Mode résolvent des parties différentes du même flux de travail. Google indique explicitement que vous êtes responsable de l'obtention du consentement et de la communication de cet état de consentement à Google. Si vous utilisez WordPress avec Google Analytics, Google Ads ou Google Tag Manager, cette distinction est plus importante que l'étiquette « v2 ».

Les quatre paramètres de consentement que les équipes doivent comprendre

La documentation actuelle de Google se concentre sur quatre paramètres qui ont souvent de l'importance dans les implémentations de sites web : ad_storage, analytics_storage, ad_user_data, et ad_personalization. Google a ajouté les deux derniers dans la mise à jour Consent Mode v2 pour le trafic EEA, de sorte que la documentation plus ancienne ou les configurations plus anciennes peuvent ne pas correspondre à ce dont vous avez besoin maintenant.

Consent Mode de base ou avancé : la différence pratique

Google documente deux modèles de mise en œuvre. Dans le Consent Mode de base, les balises sont bloquées jusqu'à ce que le visiteur accorde son consentement. Dans le Consent Mode avancé, les balises se chargent avec des paramètres de consentement par défaut et ajustent ensuite leur comportement après le choix du visiteur.

Le compromis est simple. Le mode de base est conceptuellement plus simple car rien d'optionnel ne s'exécute avant le consentement. Le mode avancé peut soutenir une meilleure continuité de mesure car Google utilise des pings et un modèle sensibles au consentement lorsque le consentement est refusé. Aucun de ces modèles ne supprime la nécessité de définir des valeurs par défaut correctes ou d'aligner l'implémentation avec votre politique et la logique de votre bandeau.

Pourquoi les équipes se bloquent dans WordPress

Le point de défaillance n'est généralement pas WordPress lui-même. C'est le timing. Un site peut afficher un bandeau et tout de même envoyer le mauvais signal si l'état par défaut est absent, chargé trop tard ou mis à jour uniquement pour le chemin « accepter tout ». C'est pourquoi les conseils de dépannage de Google se concentrent si lourdement sur la présence des par défaut avant que les balises n'utilisent le consentement.

Un flux de configuration pratique pour WordPress

1. Décidez votre cartographie des catégories avant de toucher aux balises

Commencez par les catégories que vous exposez aux visiteurs et le comportement Google que ces catégories doivent influencer. Si le consentement analytique et publicitaire sont séparés dans votre bandeau, vos mises à jour doivent refléter cette distinction de manière cohérente.

2. Définir les par défaut refusés dès le début

Le guide de dépannage Tag Assistant de Google montre clairement le modèle par défaut : définissez les paramètres de consentement tôt dans le cycle de vie de la page et ne les définissez pas asynchroniquement après que d'autres balises aient déjà commencé. Pour de nombreuses constructions WordPress, cela signifie de vérifier l'ordre des scripts, le moment de déclenchement de GTM et si un autre plugin injecte des balises Google avant que les paramètres de consentement ne soient prêts.

3. Mettre à jour le consentement après le choix réel du visiteur

Après acceptation, rejet ou sauvegarde de préférences personnalisées, mettez à jour l'état du consentement Google pour correspondre au choix du visiteur. C'est là qu'un flux CMP axé sur la revue aide : vous pouvez comparer les catégories du bandeau, les catégories de la politique et les signaux Google réels, au lieu de traiter le bandeau comme une boîte noire.

4. Garder l'inventaire des cookies WordPress en vue

Le cœur de WordPress utilise lui-même des cookies pour les utilisateurs connectés et les commentateurs, selon la documentation officielle des développeurs WordPress. Cependant, les décisions de Consent Mode dépendent généralement davantage des couches optionnelles que vous ajoutez : balises d'analyse, balises publicitaires, intégrations, gestionnaires de balises et plugins. Une configuration épurée associe le signalage Google à un inventaire actuel des cookies et des scripts.

Comment vérifier l'implémentation avec Tag Assistant

La vérification est là où de nombreuses équipes voient enfin si le site fait ce qu'elles pensent qu'il fait. Google recommande Tag Assistant pour vérifier le comportement du Consent Mode, et ses conseils de dépannage pointent vers des erreurs récurrentes telles que l'absence de consentement par défaut et une couverture de paramètres incomplète.

• Ouvrez le site dans une session fraîche et confirmez que l'état par défaut apparaît avant que les balises optionnelles ne dépendent du consentement.
• Vérifiez que ad_storage, analytics_storage, ad_user_data, et ad_personalization sont tous présents lorsqu'ils sont pertinents.
• Accepter tout, rejeter les cookies optionnels et enregistrer un choix personnalisé pour confirmer que chaque chemin met à jour l'état.
• Comparez les catégories de consentement dans la bannière avec les balises qui s'exécutent réellement sur la page.
• Répétez le test sur les modèles clés tels que la page d'accueil, les pages d'atterrissage et les flux liés au paiement.

Si votre propriété GA4 est liée à des services Google nécessitant un consentement et que vous avez des visiteurs de l'EEE, Google Analytics peut également signaler l'absence de signaux de consentement affirmatif pour la mesure publicitaire ou la personnalisation. Cela rend la vérification une tâche opérationnelle continue, et non seulement une liste de contrôle de lancement.

Comment ACookies s'intègre au flux de travail WordPress

ACookies est conçu pour les équipes WordPress souhaitant gérer le comportement des bannières, la prise en charge de Google Consent Mode, les enregistrements de consentement, le scan des cookies et la politique de cookies en un seul endroit. La page du produit pour Google Consent Mode v2 pour WordPress se concentre sur les par défaut initiaux, met à jour après le choix du visiteur et vérifie avec des outils tels que Tag Assistant.

Le travail d'implémentation est plus facile lorsque vous pouvez également inspecter ce qui s'exécute sur le site. Le Scanner de cookies assisté par l'IA et le générateur de politique de cookies gratuit prend en charge un flux de travail axé sur la révision, Tarifs ACookies explique les niveaux de site Pro pour les équipes ayant besoin du plugin à l'intérieur de WordPress.

Erreurs courantes à repérer avant la publication

L'échec le plus courant consiste à supposer que la bannière seule prouve que le côté Google est correct. En pratique, les problèmes viennent généralement de l'ordre des scripts, d'une correspondance partielle des catégories ou de chemins de code personnalisés qui mettent à jour un paramètre mais pas les autres.

Une autre erreur consiste à traiter le Consent Mode comme un raccourci juridique. La documentation de Google est claire : vous devez toujours obtenir le consentement et communiquer le choix de l'utilisateur. L'orientation de la Commission européenne sur le consentement est tout aussi claire : un consentement valide doit être éclairé, spécifique et donné par un acte positif, avec une capacité pratique de le retirer.