Bloquer les cookies WordPress avant le consentement

L’essentiel du problème de conformité cookies du web se trouve sur WordPress. C’est aussi là que sont installées le plus de bannières de consentement, et là qu’un nombre étonnant d’entre elles ne font pas grand-chose.

Nous avons publié katla-app/wordpress, un plugin qui connecte un site WordPress ou WooCommerce à Katla. Il charge le script de consentement, bloque les scripts et contenus intégrés non consentis sur le serveur, et affiche les politiques de cookies et de confidentialité que Katla génère à partir des cookies réellement trouvés par l’analyse.

Le problème du blocage dans le navigateur

Le bloqueur de cookies de Katla empêche les cookies d’être écrits. C’est la bonne brique de base, et sur un site construit à la main elle suffit généralement, parce que vous maîtrisez les scripts présents sur la page.

WordPress, c’est autre chose. Un thème met un script en file d’attente. Trois plugins en ajoutent quatre autres. Un page builder injecte un pixel. Au moment où un visiteur charge la page, elle contient des traceurs que personne n’a ajoutés délibérément. Et un traceur qui se charge a déjà envoyé à un tiers une requête contenant une adresse IP et un référent, qu’il ait réussi ou non à déposer un cookie.

Bloquer tout cela dans le navigateur est une course que l’on ne gagne pas à coup sûr. Le script de consentement doit s’exécuter, modifier les bonnes variables globales et neutraliser la balise avant que celle-ci ne s’exécute. Parfois, ça marche. Puis un plugin d’optimisation réordonne vos scripts, et ça ne marche plus.

Alors bloquez-le avant l’envoi de la page

Le plugin bloque côté serveur, pendant que WordPress assemble encore le HTML. Associez un handle de script à une catégorie, dans l’onglet Blocking ou dans le code :

add_action( 'wp_enqueue_scripts', function () {
	katla_block_script( 'google-analytics', 'analytics' );
	katla_block_script( 'facebook-pixel', 'marketing' );
}, 20 );

Le script qui arrive dans le navigateur est inerte :

<script type="text/plain" data-katla-src="…" data-katla-category="analytics"></script>

Il n’y a pas de course, parce que la version exécutable n’a jamais existé dans la réponse.

Le détail auquel nous tenons le plus, c’est le sort des scripts inline. Une balise d’analyse tient rarement en un seul fichier : il y a un chargeur, puis un gtag('config', …) inline ou un push dans le dataLayer rattaché au même handle via wp_add_inline_script. Les bloqueurs qui ne gèrent que le src ont tendance à les perdre, et la balise revient après le consentement mal configurée, ou pas du tout. Ce plugin neutralise les scripts inline avec leur handle et les rejoue dans l’ordre du code source dès que la catégorie est autorisée : la balise est restaurée exactement telle que WordPress l’avait assemblée.

WooCommerce, là où casser coûte cher

Sur une boutique, un plugin de consentement a une deuxième mission aussi importante que la conformité : ne pas casser la boutique. Bloquez le mauvais handle et le panier ne se met plus à jour, ou la commande échoue en silence, et c’est un client qui vous l’apprend.

L’intégration WooCommerce est donc surtout une liste de choses que le plugin refuse de faire. Les cookies de panier, de session et de commande contournent entièrement le bloqueur : woocommerce_cart_hash, wp_woocommerce_session_*, wc_fragments_* et consorts. Les handles critiques pour la boutique, comme wc-cart-fragments, wc-checkout et wc-blocks-checkout, sont retirés de la liste de blocage : une règle mal pensée ne peut pas faire tomber la commande. Le plugin déclare sa compatibilité avec HPOS et avec les blocs panier et commande.

Une exception délibérée : les cookies d’attribution des commandes (sbjs_*) ne sont pas sur liste d’autorisation. Ce sont des cookies marketing, pratiques certes, mais marketing. Si vous voulez qu’ils disparaissent avant le consentement, conditionnez le handle wc-order-attribution.

Trois niveaux de contrôle

Par défaut, aucun code n’est nécessaire : Katla affiche la bannière et la fenêtre de préférences, dont le style se règle depuis votre tableau de bord.

Si vous préférez maîtriser le balisage, le mode headless charge le bloqueur et window.KatlaConsent sans l’interface hébergée, et le plugin affiche sa propre bannière, traduite via WordPress et stylée avec des propriétés CSS personnalisées, pour qu’elle hérite de votre thème :

add_filter( 'katla_banner_css_vars', function () {
	return array(
		'katla-primary' => '#111111',
		'katla-radius'  => '0px',
		'katla-font'    => 'var(--wp--preset--font-family--body)',
	);
} );

Ou désactivez complètement l’interface et construisez la vôtre à partir de window.KatlaConsent et de l’événement katla:consent. Dans les trois cas, le même bloqueur travaille en dessous.

Des politiques vraiment présentes dans la page

[katla_policy] affiche votre politique de cookies et de confidentialité générée côté serveur, dans le HTML de la page. Pas une iframe, pas un fetch côté client : du vrai balisage, indexable, stylé par votre thème et régénéré à partir de vos cookies à mesure qu’ils changent. Chaque shortcode a son bloc Gutenberg, avec en plus [katla_cookie_table] si vous ne voulez que les tableaux, et [katla_cookie_settings] pour le lien « gérer les préférences » dont votre page de politique a de toute façon besoin.

Bien démarrer

Il vous faut un site Katla vérifié avec au moins une analyse terminée : le plugin a besoin des données des cookies pour afficher les politiques. Ensuite :

wp plugin activate katla-consent
wp katla site-id 00000000-0000-0000-0000-000000000000
wp katla verify

Ou collez le Site ID dans Settings → Katla Consent.

Le guide WordPress couvre les shortcodes, les filtres, les commandes WP-CLI et les spécificités de WooCommerce, et la page WordPress et WooCommerce détaille les étapes d’installation et répond aux questions que les équipes WordPress se posent avant de changer d’outil. Le plugin est sur GitHub, à l’adresse katla-app/wordpress : issues et pull requests bienvenues.