# 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.

- Auteur : Clément Hadrot
- Publié le : 2025-07-16
- Mis à jour le : 2025-07-16
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/consentement-cookies-interactivity-api/

## L’essentiel

- 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

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.