Quelque chose ne fonctionne pas comme prévu avec WPConsent ? Ce guide vous aide à diagnostiquer et à résoudre les problèmes les plus courants, des bannières manquantes aux problèmes de blocage de scripts. Le guide de dépannage couvre les outils de débogage intégrés, le vidage du cache, les conflits de plugins et comment collecter les informations système pour le support.
Table des matières
- Utilisation du paramètre d’URL de débogage
- Vérification des erreurs dans la console de votre navigateur
- Vidage des caches
- Correction d’une bannière manquante
- Correction des scripts non bloqués correctement
- Résolution des conflits avec d’autres plugins
- Résolution des problèmes de compatibilité de thème
- Utilisation des informations système pour le support
- Liste de contrôle de référence rapide
- FAQ
- Conclusion
Utilisation du paramètre d’URL de débogage
WPConsent inclut un paramètre de débogage intégré qui désactive temporairement le blocage des scripts sur n’importe quelle page. Cela vous aide à déterminer si un problème est causé par le blocage des scripts ou par autre chose.
Pour l’utiliser, ajoutez ?wpconsent_debug à la fin de n’importe quelle URL de votre site :
https://example.com/?wpconsent_debug
https://example.com/contact/?wpconsent_debug
Lorsque ce paramètre est présent, WPConsent ignore le traitement de son tampon de sortie. Les scripts qui seraient normalement bloqués s’exécutent sans modification. La bannière de consentement apparaît toujours normalement.
Utilisez le paramètre de débogage lorsque :
- Vous suspectez que le blocage de scripts casse la mise en page ou un formulaire d’une page.
- Un service tiers ne fonctionne pas et vous souhaitez confirmer que WPConsent en est la cause.
- Vous devez comparer le comportement de la page avec et sans blocage.
Pour tester, chargez la page une fois avec le paramètre et une fois sans. Si le problème disparaît lorsque ?wpconsent_debug est présent, le problème est lié au blocage des scripts. Consultez la section correction des scripts non bloqués correctement pour les étapes suivantes.
Remarque : Le paramètre de débogage n’affecte que le chargement de la page unique où il est présent. Ce n’est pas un paramètre persistant et cela ne modifie rien dans votre base de données.
Vérification des erreurs dans la console de votre navigateur
La console du navigateur est l’un des outils les plus utiles pour diagnostiquer les problèmes de frontend avec WPConsent.
Ouverture de la console
- Tout d’abord, ouvrez votre site Web dans Chrome, Firefox ou Edge.
- Ensuite, appuyez sur F12 (ou faites un clic droit n’importe où et sélectionnez Inspecter).
- Ensuite, cliquez sur l’onglet Console.
- Enfin, rechargez la page pour capturer tous les messages depuis le début.
Identification des erreurs courantes
- Erreurs JavaScript (texte rouge) : Celles-ci indiquent qu’un élément échoue. Recherchez les erreurs mentionnant
wpconsent,wpconsent-frontend, ou les noms des services de suivi. - Échecs réseau : Passez à l’onglet Réseau et filtrez par erreurs. Les requêtes échouées vers les fichiers de build de WPConsent (
frontend.js,frontend.css) empêchent le chargement de la bannière. - Attributs de script bloqués : Dans l’onglet Éléments, recherchez
data-wpconsent-src. Si vous trouvez des scripts avectype="text/plain"et un attributdata-wpconsent-category, le blocage des scripts fonctionne correctement.
Vidage des caches
La mise en cache est la source de confusion la plus courante lors de la configuration de WPConsent. Si vous modifiez un paramètre et que vous ne voyez pas le résultat, un cache en est presque toujours la raison.
Vider le cache des cookies WPConsent
WPConsent met en cache les données de catégorie et de service de cookies à l’aide des transients WordPress. Ces transients se rafraîchissent automatiquement, mais vous pouvez les vider manuellement si les données de cookies semblent obsolètes.
- Tout d’abord, allez dans WPConsent >> Outils.
- Ensuite, cliquez sur l’onglet Base de données.
- Vous verrez la ligne État du cache, qui indique quand le cache a été créé pour la dernière fois.
- Ensuite, cliquez sur le bouton Vider le cache.
- Un message de succès confirme que le cache a été vidé.

Cela vide les transients suivants :
wpconsent_needs_google_consent— si les scripts Google Consent Mode se chargent.wpconsent_preference_cookies— données de cookies mises en cache pour le panneau des préférences.wpconsent_preference_slugs— slugs de catégories et de services mis en cache.
Vider les caches de pages côté serveur
Si vous utilisez un plugin de mise en cache (WP Rocket, W3 Total Cache, LiteSpeed Cache, WP Super Cache, etc.) ou un cache au niveau du serveur, videz-le après l’une des modifications suivantes :
- Activation ou désactivation de la bannière de consentement
- Activation ou désactivation du blocage des scripts
- Modification des paramètres de blocage de contenu
- Ajout ou suppression de services ou de catégories
Chaque plugin de mise en cache a sa propre méthode de vidage. Voici les approches courantes :
- WP Rocket : Allez dans la barre d’administration WordPress, puis cliquez sur WP Rocket >> Vider le cache.
- LiteSpeed Cache : Accédez à LiteSpeed Cache >> Toolbox >> Purge All.
- W3 Total Cache : Allez dans Performance >> Dashboard et cliquez sur empty all caches.
- Cloudflare / CDN : Connectez-vous à votre tableau de bord CDN et videz également le cache là-bas.
Le blocage de scripts de WPConsent utilise la mise en mémoire tampon de sortie PHP. Le premier chargement de page non mis en cache produit du HTML avec les scripts correctement bloqués. Votre plugin de mise en cache stocke ensuite ce HTML modifié. Si vous avez activé WPConsent après que les pages aient déjà été mises en cache, les versions mises en cache n’ont pas le blocage appliqué. Le vidage force une nouvelle construction de page.
Vider les caches du navigateur
Votre navigateur stocke localement les CSS, JavaScript et parfois des pages entières. Pour exclure la mise en cache du navigateur :
- Ouvrez une fenêtre privée/de navigation privée (
Ctrl+Shift+Nsous Chrome,Ctrl+Shift+Psous Firefox). - Accédez à votre site.
Ou effectuez un rechargement forcé :
- Windows/Linux :
Ctrl+Maj+R - Mac :
Cmd+Maj+R
Une fenêtre privée efface également le cookie de consentement wpconsent_preferences de consentement, de sorte que la bannière apparaît comme si vous étiez un nouveau visiteur.
Suppression des cookies pour un nouveau test
Pour forcer la réapparition de la bannière sans ouvrir de fenêtre privée :
- Ouvrez d'abord les outils de développement du navigateur (F12).
- Ensuite, allez dans l'onglet Application (Chrome) ou Stockage (Firefox).
- Développez ensuite Cookies et sélectionnez le domaine de votre site.
- Trouvez le cookie
wpconsent_preferenceset supprimez-le. - Enfin, rechargez la page.
Correction d’une bannière manquante
Si la bannière de consentement n'apparaît pas sur votre site, suivez ces vérifications dans l'ordre.
1. Vérifier que la bannière est activée
Accédez à WPConsent >> Conception de la bannière et confirmez que la case Afficher la bannière sur le frontend est cochée en haut de la page. Cliquez ensuite sur Enregistrer si vous apportez des modifications.
Alternativement, allez dans WPConsent >> Paramètres et vérifiez le bouton Bannière de consentement dans l'onglet Paramètres.
2. Vérifier l'existence d'un cookie de consentement
Si vous avez déjà interagi avec la bannière, un cookie de consentement existe déjà. Ouvrez une fenêtre privée/de navigation privée ou supprimez le cookie wpconsent_preferences comme décrit dans la suppression des cookies pour un nouveau test.
3. Vérifier les paramètres de géolocalisation
Si vous utilisez la fonctionnalité de géolocalisation de WPConsent, la bannière peut être configurée pour s'afficher uniquement dans des régions spécifiques. Si votre emplacement n'est inclus dans aucun groupe de géolocalisation actif, la bannière n'apparaîtra pas. Vérifiez vos règles de géolocalisation dans WPConsent >> Géolocalisation pour confirmer que votre région est couverte. Pour plus de détails, consultez le guide de géolocalisation.
4. Vider tous les caches
Suivez les étapes de la suppression des caches pour vider les caches côté serveur et côté navigateur.
5. Vérifier les erreurs JavaScript
Ouvrez la console du navigateur et recherchez les erreurs. Si frontend.js ne parvient pas à se charger, la bannière ne peut pas être rendue. Les causes courantes incluent :
- Un plugin de sécurité bloquant les scripts inline ou le fichier JavaScript de WPConsent.
- Un plugin de minification ou d'optimisation qui corrompt le script. Essayez de désactiver temporairement des plugins tels qu'Autoptimize, l'optimisation de fichiers de WP Rocket ou SiteGround Optimizer.
6. Vérifier le mode éditeur du constructeur de pages
WPConsent supprime automatiquement la bannière dans les interfaces d'édition de Bricks Builder et Divi Builder. Pour voir la bannière, prévisualisez la page ou affichez-la sur le frontend réel.
7. Désactiver les autres plugins
Si aucune des solutions ci-dessus ne résout le problème, désactivez temporairement tous les autres plugins à l'exception de WPConsent. Si la bannière apparaît, réactivez les plugins un par un pour trouver le conflit. Consultez la résolution des conflits avec d'autres plugins pour plus de détails.
Correction des scripts non bloqués correctement
Si les scripts de suivi s'exécutent avant que le consentement ne soit donné, ou si des scripts sont bloqués alors qu'ils ne devraient pas l'être, suivez ces étapes de diagnostic.
Confirmation du blocage des scripts activé
Accédez à WPConsent >> Paramètres et vérifiez :
- Le bouton bascule Bannière de consentement est activé.
- Le bouton bascule Blocage des scripts est activé.
Le blocage des scripts nécessite que la bannière soit activée. Si la bannière est désactivée, le blocage des scripts est automatiquement désactivé.
Vérification des interactions du mode de consentement
Lorsque le Mode de consentement Google est activé, les scripts Google Analytics, Google Tag Manager et Google Ads ne sont pas intentionnellement bloqués. Ils s'exécutent dans un mode restreint sans cookies jusqu'à ce que le visiteur accorde son consentement. C'est un comportement correct, pas un bug. Pour utiliser le blocage complet à la place, désactivez le Mode de consentement Google depuis WPConsent >> Paramètres dans l'onglet Paramètres.
La même chose s'applique au Mode de consentement Clarity pour Microsoft Clarity.
Vérification du paramètre de débogage
Si l'URL contient ?wpconsent_debug, le blocage des scripts est désactivé pour ce chargement de page. Supprimez le paramètre de l'URL.
Inspection du code source de la page
- Tout d'abord, ouvrez la page dans votre navigateur.
- Ensuite, faites un clic droit et sélectionnez Afficher la source de la page (pas Inspecter l'élément, qui affiche le DOM en direct après l'exécution de JavaScript).
- Ensuite, recherchez
data-wpconsent-src.
Si vous trouvez des balises de script avec les attributs type="text/plain" et data-wpconsent-src, le blocage fonctionne. Les scripts sont modifiés dans le HTML avant que le navigateur ne les reçoive.
Si vous ne trouvez pas ces attributs sur un script que vous vous attendez à ce qu'il soit bloqué, ce script ne figure pas dans la liste des scripts connus de WPConsent. La liste de blocage est mise à jour à distance. Dans la version payante, vous pouvez ajouter des règles de blocage personnalisées sous WPConsent >> Paramètres dans l'onglet Avancé.
Vidage du cache du serveur
Un cache de page obsolète peut servir du HTML généré avant que le blocage des scripts ne soit activé. Videz tous les caches comme décrit dans vider les caches.
Résolution des conflits avec d’autres plugins
Les conflits de plugins sont la cause la plus fréquente de comportement inattendu avec les plugins de consentement. Voici une approche systématique pour les diagnostiquer.
Identification du conflit
- Tout d'abord, accédez à Plugins >> Plugins installés dans votre administration WordPress.
- Ensuite, désactivez tous les plugins sauf WPConsent.
- Ensuite, vérifiez si le problème est résolu.
- S'il l'est, réactivez les plugins un par un, en testant après chacun.
- Lorsque le problème réapparaît, vous avez trouvé le plugin conflictuel.
Reconnaître les types de conflits courants
Autres plugins de consentement ou de cookies. L'exécution simultanée de 2 plugins de gestion du consentement provoque des conflits. Si vous migrez depuis un autre plugin de consentement (Complianz, CookieYes, Cookie Notice, GDPR Cookie Consent, etc.), désactivez le plugin précédent avant de configurer WPConsent.
Plugins d’optimisation JavaScript. Les plugins qui combinent, minifient ou diffèrent le JavaScript (Autoptimize, optimisation de fichiers de WP Rocket, SiteGround Optimizer, Perfmatters, Flying Scripts) peuvent casser le script frontend de WPConsent. Excluez les scripts wpconsent de l’optimisation dans les paramètres de l’autre plugin.
Plugins de sécurité. Les plugins qui ajoutent des en-têtes de politique de sécurité de contenu (CSP) ou bloquent les scripts inline (Wordfence, iThemes Security, NinjaFirewall) peuvent empêcher le chargement de WPConsent. Mettez en liste blanche les fichiers de script et de style de WPConsent dans le plugin de sécurité.
Plugins de mise en cache. Voir vider les caches. L’étape la plus importante est de purger tous les caches après avoir modifié les paramètres de WPConsent.
Résolution du conflit
Une fois que vous avez identifié le plugin conflictuel, essayez ces approches :
- Recherchez une option d’exclusion ou de liste blanche dans les paramètres du plugin conflictuel. La plupart des plugins d’optimisation et de sécurité vous permettent d’exclure des scripts ou des chemins spécifiques.
- Mettez à jour les deux plugins vers la dernière version. Les problèmes de compatibilité sont souvent résolus dans les mises à jour.
- Contactez le support si le conflit persiste. Incluez la sortie des informations système (voir utilisation des informations système pour le support) ainsi que le nom et la version du plugin conflictuel.
Résolution des problèmes de compatibilité de thème
WPConsent utilise Shadow DOM pour afficher la bannière de consentement, ce qui l’isole du CSS de votre thème. Cela signifie que les styles du thème n’affectent pas la bannière et la bannière n’affecte pas votre thème. Dans de rares cas, un thème peut toujours interférer.
La bannière n’apparaît pas malgré son activation
Certains thèmes utilisent une mise en mémoire tampon de sortie agressive ou un rendu de contenu personnalisé qui peut entrer en conflit avec le tampon de sortie de WPConsent. Pour tester :
- Tout d’abord, basculez temporairement vers un thème WordPress par défaut (Twenty Twenty-Five, Twenty Twenty-Four ou Twenty Twenty-Three).
- Ensuite, vérifiez si la bannière apparaît.
- Si c’est le cas, le problème vient de la gestion de la sortie de votre thème.
Contactez le développeur de votre thème avec ces informations. Il pourrait avoir besoin d’ajuster la priorité de sa mise en mémoire tampon de sortie.
La bannière apparaît mais se superpose ou est mal positionnée
La bannière utilise un positionnement fixe ou absolu avec un z-index élevé. Si votre thème possède des éléments avec des valeurs de z-index très élevées (en-têtes fixes, menus flottants), ils peuvent se superposer à la bannière.
Essayez de changer la position de la bannière dans WPConsent >> Conception de la bannière. Si la bannière est définie sur Bas, essayez Haut, ou basculez vers la mise en page Modale (version payante) pour l’afficher au centre de la page.
Erreurs JavaScript du thème après le consentement
Si le JavaScript de votre thème dépend d’un script tiers que WPConsent bloque (par exemple, une intégration Google Maps dans l’en-tête), le script du thème peut générer des erreurs car la ressource tierce n’est pas encore disponible.
La solution dépend de votre configuration :
- Si le service bloqué appartient à une catégorie connue, le script se charge après que le visiteur a donné son consentement pour cette catégorie. La page se recharge automatiquement et le script du thème s’exécute normalement.
- Si le service ne figure pas dans la liste connue de WPConsent, vous pouvez l'ajouter en tant que script personnalisé dans la version payante, ou l'exclure du blocage.
Utilisation des informations système pour le support
WPConsent inclut une page Informations système qui recueille des détails techniques sur votre installation WordPress, la configuration du serveur et les plugins actifs. Ces informations sont essentielles lorsque vous demandez de l'aide.
Accéder aux informations système
- Tout d’abord, allez dans WPConsent >> Outils.
- Ensuite, cliquez sur l'onglet Informations système.
- Les informations système apparaissent dans une zone de texte en lecture seule.

Comprendre ce qui est inclus
Le rapport d'informations système contient les sections suivantes :
| Section | Détails |
|---|---|
| Informations sur le site | URL du site, URL d'accueil et si le site est une installation multisite. |
| Configuration de WordPress | Version de WordPress, langue, structure des permaliens, thème actif, état de WP_DEBUG et limite de mémoire. |
| Téléversements/Constantes WordPress | Chemins du répertoire de contenu, chemins de téléversement et constantes associées. |
| Plugins Must-Use | Tous les plugins must-use installés et leurs versions. |
| Plugins WordPress actifs | Tous les plugins actifs avec leurs numéros de version et leur statut de mise à jour. |
| Plugins WordPress inactifs | Tous les plugins inactifs avec leurs numéros de version. |
| Configuration du serveur Web | Version de PHP, version de MySQL et logiciel du serveur Web. |
| Configuration PHP | Limite de mémoire, limites de téléversement, temps d'exécution, max input vars et état d'affichage des erreurs. |
| Extensions PHP | Si cURL, fsockopen, SOAP et Suhosin sont disponibles. |
| Configuration des sessions | Si les sessions PHP sont activées et leur configuration. |
Partage des informations système avec le support
- D'abord, cliquez dans la zone de texte de l'onglet Informations système.
- Ensuite, sélectionnez tout le texte (
Ctrl+AouCmd+A). - Copiez-le ensuite (
Ctrl+CouCmd+C). - Enfin, collez-le dans votre ticket de support ou votre e-mail.
L'intégralité du rapport est en texte brut, il se colle donc proprement dans n'importe quel formulaire de support ou e-mail.
Test des connexions SSL
L'onglet Informations système inclut également une section Tester les connexions SSL. Pour exécuter le test, cliquez sur le bouton Tester la connexion pour vérifier que votre serveur peut effectuer des requêtes HTTPS sortantes vers l'API WPConsent. Si ce test échoue, le scanner et les mises à jour de la liste de blocage à distance ne fonctionneront pas.

Causes courantes d'échec du test SSL :
- Votre fournisseur d'hébergement bloque les connexions HTTPS sortantes.
- Un pare-feu bloque les requêtes vers des domaines externes.
- Les certificats SSL du serveur sont obsolètes.
Contactez votre fournisseur d'hébergement si le test SSL échoue.
Liste de contrôle de référence rapide
Utilisez cette liste de contrôle lorsque quelque chose ne fonctionne pas comme prévu :
- Ouvrez une fenêtre privée/de navigation privée pour exclure les cookies de consentement et le cache du navigateur.
- Ajoutez
?wpconsent_debugà l'URL pour exclure le blocage de scripts comme cause. - Vérifiez la console du navigateur pour les erreurs JavaScript.
- Vérifiez que la bannière est activée dans les paramètres de WPConsent.
- Vérifiez que le blocage de scripts est activé si les scripts sont censés être bloqués.
- Videz tous les caches : cache des cookies WPConsent, cache de page côté serveur et cache du navigateur.
- Désactivez les autres plugins un par un pour identifier les conflits.
- Basculez sur un thème par défaut pour exclure les problèmes de thème.
- Vérifiez la page Informations système et exécutez le test SSL pour vérifier la connectivité du serveur.
- Copiez les informations système et incluez-les dans votre demande de support.
FAQ
J'ai modifié un paramètre mais rien ne s'est passé sur le frontend. Qu'est-ce qui ne va pas ?
Un cache est très certainement la raison. Videz tous les caches (cache des cookies WPConsent, cache de page côté serveur et cache du navigateur) comme décrit dans le vidage des caches. Testez ensuite dans une fenêtre privée/de navigation privée.
Comment savoir si le blocage de scripts cause un problème sur mon site ?
Ajoutez ?wpconsent_debug à l'URL. Si le problème disparaît, le blocage de scripts en est la cause. Consultez la section correction des scripts non bloqués correctement pour les prochaines étapes.
Ma bannière s'affiche à chaque chargement de page, même après l'avoir acceptée. Que se passe-t-il ?
Le cookie wpconsent_preferences n'est pas sauvegardé ou est effacé entre les chargements de page. Vérifiez que la durée de consentement dans WPConsent >> Paramètres est définie sur une valeur supérieure à 0. Vérifiez également qu'aucun plugin de sécurité ou de performance ne supprime les cookies. Si vous utilisez la fonctionnalité Consentement partagé, confirmez que le domaine du cookie correspond à votre configuration de sous-domaine.
J'utilise un constructeur de page et la bannière n'apparaît pas dans l'éditeur. Est-ce normal ?
Oui. WPConsent supprime automatiquement la bannière dans les interfaces d'édition de Bricks Builder et Divi Builder. Prévisualisez la page ou affichez-la sur le frontend réel pour voir la bannière.
Conclusion
Ce guide couvre les problèmes les plus courants de WPConsent, des bannières manquantes aux problèmes de blocage de scripts et aux conflits de plugins. La plupart des problèmes sont résolus en vidant les caches, en vérifiant la console du navigateur ou en isolant un plugin conflictuel. Lorsque vous avez besoin d'aide supplémentaire, le rapport System Info donne à notre équipe de support tout ce dont elle a besoin pour vous aider.
Pour plus de détails sur les outils mentionnés ici, consultez la documentation System Info et Database & Cache Management. Si votre question n’a pas trouvé de réponse ici, consultez la page des questions fréquemment posées.