Un client associatif gérant un site vitrine simple, sans tracking publicitaire ni cookies tiers complexes, ne voulait pas installer un plugin de gestion de consentement complet pour un besoin somme toute basique : informer le visiteur qu’un cookie technique de mesure d’audience était déposé, et lui laisser le choix de l’accepter ou de le refuser. Un plugin dédié aurait ajouté entre 40 et 80 Ko de JavaScript pour une fonctionnalité que l’Interactivity API, native depuis la 6.5, permettait de couvrir en une fraction de ce poids.
Voici la construction complète de ce bloc minimal de consentement, à adapter selon la complexité réelle des traceurs utilisés sur chaque projet.
Ce que ce bloc couvre, et ce qu’il ne couvre pas
Avant toute chose, une précision importante : ce bandeau convient à un besoin de consentement basique, un cookie de mesure d’audience unique par exemple, avec un choix binaire accepter ou refuser. Pour un site avec de multiples catégories de cookies, des partenaires publicitaires tiers ou des transferts de données hors Union européenne, une solution de gestion de consentement complète, éventuellement certifiée, reste nécessaire — ce n’est pas le sujet traité ici.
Structure du bloc personnalisé

Le bloc s’enregistre classiquement via block.json, avec le support de l’Interactivity API activé par la propriété supports.interactivity et un rendu dynamique côté serveur pour insérer les directives nécessaires :
{
"apiVersion": 3,
"name": "client-asso/consentement-cookies",
"title": "Bandeau de consentement",
"category": "widgets",
"supports": { "interactivity": true },
"render": "file:./render.php"
}
Le fichier de rendu produit un balisage minimal, avec les directives data-wp-interactive, data-wp-bind et data-wp-on--click qui relient les boutons à la logique déclarative du store d’état :
<div
class="consentement-cookies"
data-wp-interactive="client-asso"
data-wp-bind--hidden="!context.visible"
data-wp-context='{ "visible": true }'
>
<p>Ce site dépose un cookie de mesure d'audience anonyme. Vous pouvez l'accepter ou le refuser.</p>
<button data-wp-on--click="actions.accepter">Accepter</button>
<button data-wp-on--click="actions.refuser">Refuser</button>
</div>
La logique côté client, en quelques lignes
Le fichier JavaScript du store reste volontairement minimal, sans framework ni dépendance, en s’appuyant uniquement sur le module natif @wordpress/interactivity chargé automatiquement par WordPress :
import { store, getContext } from '@wordpress/interactivity';
store( 'client-asso', {
actions: {
accepter() {
const contexte = getContext();
contexte.visible = false;
localStorage.setItem( 'consentement_mesure_audience', 'accepte' );
document.dispatchEvent( new CustomEvent( 'consentement:accepte' ) );
},
refuser() {
const contexte = getContext();
contexte.visible = false;
localStorage.setItem( 'consentement_mesure_audience', 'refuse' );
},
},
} );
L’événement personnalisé consentement:accepte, diffusé sur le document, permet ensuite de déclencher le chargement conditionnel du script de mesure d’audience uniquement après acceptation, sans jamais le charger par défaut avant le choix de l’utilisateur.
Vérifier le choix précédent au chargement de la page
Côté rendu PHP, une vérification simple de la valeur stockée permet de ne pas réafficher le bandeau à chaque visite si un choix a déjà été exprimé, tout en gérant côté client la relecture de localStorage au chargement initial du bloc.
document.addEventListener( 'DOMContentLoaded', () => {
const choix = localStorage.getItem( 'consentement_mesure_audience' );
if ( choix === 'accepte' ) {
document.dispatchEvent( new CustomEvent( 'consentement:accepte' ) );
}
} );
Charger le script de mesure conditionnellement
Le script de mesure d’audience lui-même n’est jamais enregistré via wp_enqueue_script() classique au chargement de la page. Il est chargé dynamiquement, uniquement après réception de l’événement d’acceptation, via une insertion de balise script construite en JavaScript, ce qui garantit qu’aucun cookie n’est déposé avant un consentement explicite.
- Aucun cookie déposé avant acceptation explicite de l’utilisateur.
- Un choix mémorisé côté navigateur, sans appel serveur ni cookie technique du bandeau lui-même.
- Un poids total de script largement inférieur à une solution de plugin généraliste.
Un bandeau de consentement minimal reste un choix d’architecture, pas une garantie de conformité complète : pour tout site avec plusieurs catégories de traceurs, une solution de gestion de consentement dédiée reste la voie la plus sûre.
Pour aller plus loin
Ce bloc convient parfaitement à un site simple avec un unique traceur de mesure d’audience. Dès qu’un site ajoute des cookies publicitaires tiers, des pixels de réseaux sociaux ou des transferts de données hors Union européenne, la complexité de gestion des préférences par catégorie dépasse largement ce que ce bloc minimal peut raisonnablement couvrir sans devenir lui-même une solution de gestion de consentement à part entière.