Recharger le wall lors d’un changement de consentement cookies

Dans une intégration Poool Access, le comportement du wall peut dépendre du consentement utilisateur aux cookies.

Cette information est transmise dans la configuration via la variable cookies_enabled. Elle permet d’appliquer le bon scnénario défini dans le Dashboard et d’adapter l’expérience affichée au lecteur.

Pourquoi recharger le wall ?

Lorsqu’un utilisateur arrive sur la page sans avoir accepté les cookies, Access est initialisé avec cookies_enabled = false.

Dans ce cas, un comportement par défaut est appliqué selon votre contexte.

Si l’utilisateur accepte ensuite les cookies (via votre CMP), la configuration côté Access doit changer et passer cookies_enabled = true, mais le wall déjà affiché ne se met pas à jour automatiquement sans action spécifique.

• le wall continue de fonctionner avec l’ancien état
• les scénario configurés pour cookies_enabled = true ne sont pas appliqués

Il est donc nécessaire de recharger le wall pour prendre en compte ce changement.

Implémentation

Deux approches sont possibles selon votre niveau d’intégration et vos contraintes côté expérience utilisateur.

- Rechargement de la page

La méthode la plus simple consiste à recharger la page après acceptation des cookies, en mettant à jour la variable cookies_enabled à true.

Cette solution garantit que toute l’initialisation Access est rejouée avec la bonne configuration.

En revanche, elle implique un rechargement complet de la page, ce qui peut impacter l’expérience utilisateur.

- Réinitialisation du wall

Pour une intégration plus fluide, il est possible de ne recharger que le wall.

L’idée est de :

• mettre à jour la configuration (cookies_enabled = true)
• recréer une instance du paywall

Une seconde initialisation est alors effectuée avec le nouveau contexte.

Le wall est remplacé directement dans la page, sans rechargement global.

Cette approche permet de conserver une expérience utilisateur continue, tout en appliquant correctement les scénarios définis dans le Dashboard.

Point d’attention : Audit.js

Si vous utilisez le script Audit, une précaution est nécessaire.

Audit.js ne se recharge pas dynamiquement une fois initialisé.

Si le script est chargé avec cookies_enabled = false, il ne sera pas réinitialisé après acceptation des cookies.

Cela peut entraîner une perte de données de tracking.

Dans ce contexte, il est recommandé de :

• charger Audit uniquement après consentement
• ou conditionner son chargement à l’état des cookies

Exemple en JS

Un exemple de mise en place est disponible via une sandbox, permettant d’observer :

• le changement de consentement
• la réinitialisation du wall
• le comportement des scripts Access et Audit

Voici le lien

Implémentation en React/Next

Dans une application lorsque la valeur de cookies_enabled change, il est nécessaire de forcer le rechargement du composant afin de réinitialiser correctement le wall avec la nouvelle configuration.

Car React ne recrée pas automatiquement un composant si seules certaines propriétés internes changent.

Le wall déjà monté continue donc d’utiliser l’ancien état (cookies_enabled = false).

Il faut déclencher un remount du composant.

Deux approches courantes :

• Utiliser une key dynamique sur le composant
• Gérer un state qui force la réinitialisation

Mis à jour le : 06/05/2026