vendredi 25 septembre 2026

À propos

Contact

FSE

Consentement cookies sur un site en éditeur de site, sans plugin tiers

Pour limiter les dépendances externes sur un site FSE léger, voici comment construire un bandeau de consentement basique avec un bloc minimal en Interactivity API.

Par Clément Hadrot • 16 juillet 2025 • 4 min de lecture • Aucun commentaire
Consentement cookies sur un site en éditeur de site, sans plugin tiers

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é

L'essentiel à retenir : Un bloc minimal suffit pour un consentement basique à deux choix ; localStorage évite tout appel serveur pour mémoriser le choix ; Reste à compléter selon la complexité RGPD réelle du site

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.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi