Cookies RGPD sur PrestaShop : bandeau, blocage réel et preuve

Un bandeau de consentement qui s'affiche pendant que Google Analytics, Google Ads, Meta ou TikTok se chargent ne protège pas vos visiteurs et ne vous donne aucune preuve de leur choix. Cookies RGPD traite le consentement dans le back-office de PrestaShop : il neutralise les scripts, iframes et pixels tiers dans le HTML envoyé, laisse le visiteur choisir dans un bandeau accessible, enregistre chaque décision dans un journal en ajout seul avec une référence et génère la politique cookies de la boutique. Il envoie aussi les signaux Google Consent Mode v2, sans compte, sans clé API et sans service externe.

Ce guide explique ce que fait le module, comment l'installer, réussir une première configuration et l'utiliser au quotidien.

Points forts :

• Blocage réel avant le consentement : scripts tiers, iframes (YouTube, Vimeo, Google Maps), pixels et ressources tierces neutralisés dans le HTML, puis rechargés selon la catégorie acceptée
• Journal en ajout seul : référence unique, date UTC, action, catégories, versions, pays et signaux, exportable en CSV et JSON
• Preuve technique : chaque ligne est chaînée par une empreinte SHA-256 et le contrôle d'intégrité signale une modification ou une suppression
• Bandeau accessible et personnalisable : trois positions, contraste vérifié, textes par langue, panneau par catégorie et retrait en un clic
• Consent Mode v2 et politique cookies : signaux envoyés avant tout tag, page CMS générée dans chaque langue et tableau réutilisable par shortcode
• Analyse de la boutique : six pages contrôlées, domaines inconnus signalés, analyses planifiées et page de contrôle pour les employés

Découvrir le module et ses formules

---

Présentation

Le consentement aux cookies est encadré en Europe par la directive ePrivacy (2002/58/CE) et le RGPD : le visiteur doit être informé, consentir librement, spécifiquement et par catégorie, et pouvoir retirer son choix aussi facilement qu'il l'a donné. Dans une boutique PrestaShop, le sujet dépasse largement la fenêtre qui s'affiche en bas de page. Les traceurs viennent du thème, des modules de paiement, des réseaux sociaux, des vidéos intégrées et des campagnes publicitaires. Et le jour où un client, une agence ou une autorité demande ce qui a été accepté, il faut pouvoir répondre avec une date, une version du texte et des catégories précises.

Le module réunit ces trois besoins — bloquer, informer, documenter — dans une seule interface. Il réécrit le HTML côté serveur pour neutraliser les éléments tiers avant le consentement, affiche un bandeau et un panneau de préférences, enregistre chaque décision dans un journal qui ne se réécrit pas, et prépare la politique cookies à partir de l'inventaire réel de vos services.

C'est une aide au recueil et à la documentation du consentement. Le module ne certifie pas la conformité de votre boutique, ne remplace pas un conseil juridique et ne transforme pas la politique générée en document validé par un juriste. Il vous donne les moyens techniques de faire ce que la loi demande, et la trace de ce que vous avez fait.

Le bandeau sur la boutique : trois choix d'égale importance et un lien vers la politique cookies

Fonctionnalités

Bloquer les scripts, iframes et pixels avant le consentement

À chaque page servie, le module analyse le HTML et neutralise les éléments qui correspondent à un service tiers actif : un script voit son adresse conservée mais ne s'exécute pas, une iframe YouTube, Vimeo ou Google Maps est remplacée par un bloc qui nomme le service bloqué et propose de le charger en acceptant la catégorie, un pixel de suivi perd sa source, et les ressources tierces annoncées dans l'en-tête sont traitées de la même façon. Quand le visiteur accepte une catégorie, le navigateur recrée les éléments autorisés dans l'ordre de la page, avec leurs attributs d'origine.

Sans JavaScript, rien de non essentiel ne se charge : les éléments neutralisés restent inertes, y compris ceux d'un bloc <noscript>. Un garde-fou à l'exécution intercepte aussi les scripts et iframes ajoutés après le chargement par un autre script, et les libère dès que la catégorie correspondante est acceptée.

Le module ne peut pas arrêter les requêtes qu'un script déjà autorisé émet lui-même (fetch, sendBeacon, new Image()), les conversions côté serveur ni un script évalué par eval. Un gestionnaire de balises doit donc être classé dans la catégorie des balises qu'il charge, ou s'appuyer sur Consent Mode. Cette limite est assumée : mieux vaut la connaître que croire à un blocage total.

Un bandeau clair et un panneau par catégorie

Le bandeau peut prendre trois formes : barre en bas de la fenêtre, carte centrée ou panneau latéral. Vous réglez les couleurs, le logo, la position, l'ordre des boutons et les textes dans chaque langue, avec un aperçu en direct sur ordinateur et sur mobile. Les boutons « Tout accepter », « Tout refuser » et « Personnaliser » partagent le même composant, la même taille et le même poids visuel ; aucune case n'est pré-cochée et le défilement de la page n'enregistre jamais un accord.

Le panneau de préférences présente les quatre catégories : strictement nécessaires (toujours actives), mesure d'audience, publicité et remarketing, fonctionnalités. Pour chaque service, le visiteur voit la finalité, les cookies habituels et leur durée, le destinataire et le lien vers la politique de confidentialité du fournisseur. Chaque catégorie est enregistrée séparément, et le choix en cours est rappelé avec sa date et sa référence.

Le contraste du texte, des boutons et des liens est mesuré à l'enregistrement : sous le rapport de 4,5:1, le module refuse la configuration et affiche la valeur mesurée. Le bandeau et le panneau visent le niveau WCAG 2.1 AA : dialogue sémantique, rôles ARIA, navigation au clavier, fermeture par la touche Échap, focus visible, cibles de 48 px et boutons empilés sur mobile. C'est une cible de conception, pas une certification.

Revenir sur son choix à tout moment

Un onglet flottant discret, un lien en pied de page et un shortcode [wpcc_preferences] permettent d'ouvrir le panneau depuis n'importe quelle page. Le retrait d'une catégorie supprime les cookies habituels de ses services sur le domaine et ses domaines parents, puis recharge la page, car un script déjà exécuté ne peut pas être déchargé. Le retrait est enregistré comme un consentement, avec la même facilité que l'accord. Les cookies HttpOnly et ceux d'autres domaines ne peuvent pas être supprimés par une page : le panneau et la politique l'indiquent.

Après la durée choisie — 12 mois par défaut, réglable de 1 à 13 mois — le consentement expire : le bandeau redemande le choix, les catégories non essentielles sont de nouveau bloquées et le nouveau choix rejoint l'historique du même visiteur. Le bouton « Redemander à tous les visiteurs » déclenche la même demande immédiatement, par exemple après un changement de texte important.

Journaliser chaque décision

Chaque choix crée une ligne dans un journal en ajout seul : référence unique au format CC-XXXX-XXXX-XXXX, date UTC, boutique, langue, page, action (accord, refus, personnalisation, retrait, refus par signal du navigateur), catégories, version du bandeau, de la politique et du consentement, pays détecté et signaux GPC/DNT. L'adresse IP est conservée sous forme de clé HMAC-SHA256 par défaut ; vous pouvez choisir de la tronquer ou de ne pas la stocker. La référence est affichée au visiteur après son choix.

Le journal se filtre par période, action, source, variante, pays, référence ou clé de visiteur, et s'exporte en CSV ou JSON avec les filtres en cours. Les lignes plus anciennes que la durée de conservation — 36 mois par défaut, réglable de 6 à 120 mois — sont supprimées automatiquement par la maintenance quotidienne. Aucun nom, e-mail ou identifiant client n'est enregistré.

Chaque choix, sa référence et ses catégories, prêts à être exportés

Prouver l'intégrité du journal

Les lignes sont chaînées : chacune contient l'empreinte SHA-256 de la ligne précédente, et la première part d'une empreinte nulle. Le contrôle d'intégrité du module reparcourt la chaîne, recalcule chaque empreinte et vérifie que la dernière ligne correspond à la tête enregistrée. Une ligne modifiée ou supprimée casse la chaîne et déclenche l'alerte « Le journal des consentements a été modifié en dehors du module ».

C'est une preuve technique : elle montre qu'une ligne a été changée ou retirée sans que la chaîne soit recalculée. Elle ne constitue pas un horodatage qualifié et ne détecte pas quelqu'un qui aurait un accès à la base et recalculerait toute la chaîne. Le module ne répare jamais une chaîne rompue : il la signale, et vous décidez de la suite.

Envoyer Google Consent Mode v2

Le module peut envoyer les signaux Google Consent Mode v2 avant tout tag : ad_storage, analytics_storage, ad_user_data, ad_personalization, security_storage et les signaux fonctionnels. Les valeurs par défaut sont refusées dans l'Union européenne, l'EEE, le Royaume-Uni et la Suisse, puis mises à jour à chaque choix. La temporisation d'attente et la réduction des données publicitaires sont réglables. Google demande Consent Mode v2 pour la publicité et la mesure dans ces régions ; ce n'est pas une obligation légale en soi.

Un seul émetteur de signaux doit être actif. Le module peut les envoyer lui-même, ou coopérer avec le module Google Tracking s'il est installé : dans ce cas, il lui transmet le choix et ne double pas les commandes. Si les deux émettent, le module affiche un avertissement et propose de corriger la source. Les trois services Google peuvent aussi être réglés en mode consent_mode, qui les charge avant le consentement en suivant les signaux ; ce choix explicite est accompagné d'un avertissement.

Générer la politique cookies

La politique cookies est construite à partir de l'inventaire réel : qu'est-ce qu'un cookie, qui est responsable, comment le consentement est demandé, les catégories et leurs bases juridiques, les services et cookies tiers avec leurs durées habituelles, les cookies natifs de PrestaShop (session, panier, langue, devise), le journal de consentement et les moyens de retrait, puis la version et la date. Elle est publiée comme page CMS dans chaque langue de la boutique, avec une adresse lisible, et un tableau de cookies peut être inséré dans une autre page avec le shortcode [wpcc_cookie_table].

C'est un modèle à relire et à adapter : le module affiche cet avertissement et demande une confirmation avant la première publication. Si la page a été modifiée à la main depuis la dernière publication, le module le signale et demande une seconde confirmation avant de la remplacer. Si l'inventaire change — un service ajouté, une durée modifiée —, le tableau de bord alerte : « La politique cookies ne correspond plus à vos services ».

Analyser la boutique et surveiller les nouveaux traceurs

L'analyse parcourt six pages représentatives : accueil, catégorie, produit, page CMS, contact et panier. Pour chacune, elle relève les scripts, iframes, pixels et cookies, et distingue ce qui se charge avant le consentement, ce qui est bloqué jusqu'au choix et ce que la boutique dépose elle-même. Le rapport propose une comparaison avant/après et signale les pages qui n'ont pas pu être analysées, avec la raison.

Les domaines inconnus sont listés à part : vous pouvez les rattacher à un service existant, en faire un service personnalisé ou les ignorer. Un nouveau domaine déclenche une alerte sur le tableau de bord et, si vous l'activez, un e-mail après l'analyse planifiée. L'analyse peut être lancée à la demande ou selon une fréquence quotidienne, hebdomadaire ou mensuelle, par la tâche cron de l'hébergeur ou l'adresse à jeton affichée dans les réglages.

Ce qui se charge avant le choix, ce qui est bloqué et ce qu'il reste à classer

Tableau de bord et assistant d'installation

Le tableau de bord réunit, sur 7, 30 ou 90 jours, les taux d'acceptation, de refus et de personnalisation, l'évolution quotidienne, les services les plus souvent bloqués, la dernière analyse et les alertes de configuration : mode test encore actif, assistant non terminé, aucun service actif, règle vide, domaines inconnus, analyse ancienne ou échouée, chaîne rompue, politique absente ou obsolète, double émetteur Consent Mode, règle pays qui masque le bandeau dans l'UE. Chaque alerte mène à l'écran qui permet de la corriger.

L'assistant en quatre étapes guide la première mise en service : analyser la boutique, classer les services détectés, choisir le bandeau, publier la politique puis passer en mode live. Chaque étape peut être ignorée et reprise plus tard. Les réglages par défaut sont prudents : le module s'installe en mode test, aucun service non classé n'est bloqué et une règle vide ne bloque rien.

Les choix des visiteurs, catégorie par catégorie, et l'évolution dans le temps

Mode test et page de contrôle

Après l'installation, le module reste en mode test : les visiteurs reçoivent la page PrestaShop inchangée, sans bandeau ni blocage. Vous pouvez ouvrir un aperçu du bandeau sur la boutique, avec une bannière « Mode test » et une balise noindex, et utiliser une page de contrôle réservée aux employés. Cette page ouvre une page de la boutique dans un cadre et affiche les cookies visibles par le navigateur, les services chargés, les éléments neutralisés et l'état des catégories avant et après un choix. Elle indique aussi ce qu'elle ne peut pas voir : les cookies HttpOnly et ceux d'autres domaines.

Le passage en mode live se fait depuis l'assistant ou la page de configuration, après une confirmation qui rappelle ce qui va changer : le bandeau est affiché à tous les visiteurs et les services classés sont bloqués jusqu'à leur acceptation.

Ciblage par pays, GPC et DNT

Par défaut, le bandeau est affiché à tous les visiteurs. Des règles par pays permettent de l'afficher, de le masquer ou de le remplacer par une simple notice, avec un préréglage « UE/EEE, Royaume-Uni et Suisse ». La détection peut venir de la géolocalisation native de PrestaShop, si la base MaxMind est installée, ou d'un en-tête pays fourni par votre CDN ou proxy. Une règle qui masque le bandeau dans ces pays déclenche un avertissement.

Le module reconnaît aussi les signaux Global Privacy Control et Do Not Track, activables séparément : un visiteur qui les envoie est traité comme refusant les catégories non essentielles, sans voir le bandeau, et la décision est enregistrée avec l'action et le signal correspondants. L'onglet reste disponible pour accepter une catégorie plus tard.

Multiboutique, langues et cache

Chaque boutique d'un multiboutique a ses réglages, ses textes, ses services, son journal, ses analyses et sa politique. Les textes existent dans toutes les langues installées ; le module fournit le français, l'anglais, l'espagnol, l'italien et le polonais, et une langue sans traduction utilise les textes anglais par défaut avec une invitation à les écrire. L'export et l'import JSON des réglages, des textes, des services et des règles pays permettent de dupliquer une configuration entre boutiques, sans copier le journal ni les statistiques.

Le HTML est identique pour tous les visiteurs : le choix est appliqué dans le navigateur, ce qui rend le module compatible avec le cache natif de PrestaShop et avec Cache Pro. Côté boutique, un seul fichier JavaScript et un seul fichier CSS, sans jQuery ni appel externe. Le cache est purgé à chaque enregistrement de réglages qui change la boutique ; si un cache serveur ou CDN stocke vos pages, le module rappelle de le purger aussi.

Installation

1. Installer le module. Dans le gestionnaire de modules, téléversez l'archive ZIP et installez-la. Le module apparaît dans le menu « Consentement cookies ».
2. Activer la licence. Ouvrez la page de configuration et saisissez votre clé de licence. Sans licence valide, le module reste désactivé ; il se réactive dès que la licence est valide.
3. Lancer l'assistant. L'étape 1 analyse six pages de la boutique et relève les services et les domaines inconnus. L'étape 2 vous fait classer chaque service détecté. L'étape 3 règle le bandeau, les couleurs et l'ordre des boutons. L'étape 4 prépare et publie la politique cookies.
4. Vérifier en mode test. Ouvrez l'aperçu du bandeau et la page de contrôle, faites un choix, vérifiez les cookies et les services avant et après.
5. Passer en mode live. Confirmez le passage : le bandeau est affiché à tous les visiteurs et les services classés sont bloqués jusqu'à acceptation. Configurez ensuite l'analyse planifiée si vous le souhaitez.

Configuration

Classer les services et les domaines inconnus

La page Services liste les services par catégorie, avec leur mode, le nombre de règles et de cookies, la date de dernière détection et un interrupteur d'activation. La bibliothèque couvre notamment Google Analytics 4, Google Tag Manager, Google Ads, Meta, TikTok, LinkedIn, Pinterest, Bing, X, Criteo, Awin, Hotjar, Matomo, Clarity, HubSpot, Klaviyo, Mailchimp, Zendesk, Crisp, Tawk.to, Brevo, YouTube, Vimeo et Google Maps, avec leur catégorie, leurs cookies habituels et la localisation du destinataire. Vous pouvez modifier un service, restaurer les valeurs d'origine ou créer un service personnalisé avec vos propres domaines, chemins ou extraits de script.

Les domaines inconnus relevés par l'analyse se classent depuis la page Domaines : rattacher à un service, créer un service personnalisé prérempli avec le domaine, ou ignorer. Chaque enregistrement recompile les règles, purge le cache et écrit une ligne dans le journal des actions.

Régler le bandeau

La page Bandeau règle la position, les couleurs, le logo, l'ordre des boutons et les textes dans chaque langue, avec un aperçu en direct et un interrupteur ordinateur/téléphone. L'onglet Test A/B prépare une seconde variante de texte et de couleurs, répartit les visiteurs à parts égales et compare les taux d'acceptation ; sous 100 décisions par variante, le module indique qu'il n'y a pas encore assez de choix pour conclure. Les deux variantes conservent des boutons d'égale importance et aucun texte trompeur.

Consent Mode, analyses et maintenance

La page de configuration règle l'émetteur Consent Mode, la temporisation, la réduction des données publicitaires, les valeurs par défaut hors UE, les signaux GPC et DNT, la durée avant nouvelle demande, la durée de conservation du journal et le mode de stockage de l'adresse IP. Elle affiche aussi la commande et l'adresse de la tâche cron, avec le jeton et la date du dernier passage. La maintenance quotidienne purge les lignes expirées, les analyses au-delà des 20 dernières et les fichiers d'import temporaires, et vérifie l'intégrité du journal par étapes.

Droits des employés

Les droits suivent ceux du menu PrestaShop : consulter, configurer et exporter. Un profil qui peut consulter voit les pages, les préférences et l'état d'intégrité ; un profil qui peut configurer gère les services, le bandeau, les analyses et la publication de la politique ; seul un profil autorisé à exporter télécharge le journal et les réglages.

Cas d'usage

• Une boutique qui utilise GA4, Google Ads, Meta ou TikTok. Les scripts publicitaires et de mesure sont bloqués jusqu'au consentement, puis rechargés par catégorie ; Consent Mode v2 reçoit le choix.
• Une boutique avec des vidéos et des cartes. Les iframes YouTube, Vimeo et Google Maps sont remplacées par un bloc explicatif : le visiteur voit ce qui est bloqué et peut l'afficher en acceptant la catégorie fonctionnelle.
• Une agence qui gère plusieurs boutiques. Chaque boutique garde ses réglages et son journal ; l'export/import JSON et la duplication permettent d'appliquer la même configuration, puis de l'ajuster.
• Une boutique qui a reçu une question ou un courrier sur ses cookies. L'analyse montre ce qui se charge avant le choix, les domaines inconnus sont classés, et le journal fournit les références des choix déjà enregistrés.
• Une boutique qui veut changer de CMP sans abonnement. Le module fonctionne dans la boutique, sans service hébergé ni compte : les données de consentement restent dans votre base.

Prérequis et compatibilité

• PrestaShop 1.7.8, 8.0+ et 9.0+
• PHP 7.4 ou plus
• Une licence valide, activée depuis la page de configuration
• Les thèmes Classic et Hummingbird
• Une tâche cron (ou le module « Gestionnaire de tâches cron ») pour les analyses planifiées et la maintenance ; la maintenance se déclenche aussi à la première ouverture du back-office du module chaque jour
• Facultatif : la géolocalisation native de PrestaShop (base MaxMind) pour le ciblage par pays, ou un en-tête pays fourni par un CDN
• Interface et textes en français, anglais, espagnol, italien et polonais ; chaque langue installée peut recevoir ses propres textes

Sans licence valide, le module se désactive : le bandeau n'est plus affiché, les scripts tiers ne sont plus bloqués et aucun choix n'est enregistré. Vos réglages, services, journal et page de politique sont conservés, et le module se réactive dès que la licence est valide.

---

FAQ

Le module bloque-t-il vraiment les scripts avant le consentement ?

Oui, pour les scripts, iframes, pixels et ressources tierces qui correspondent à un service actif. Le module réécrit le HTML côté serveur : l'adresse d'un script est conservée mais il ne s'exécute pas, une iframe est remplacée par un bloc explicatif et un pixel perd sa source. Sans JavaScript, rien de non essentiel ne se charge. Il ne peut pas arrêter les requêtes qu'un script déjà autorisé fait lui-même, les conversions côté serveur ou un script évalué par eval : un gestionnaire de balises doit être classé dans la catégorie de ses balises, ou s'appuyer sur Consent Mode.

Faut-il un compte, une clé API ou un service externe ?

Non. Le module fonctionne entièrement dans votre boutique : pas de CMP hébergée, pas de registre dans le cloud, pas d'appel à un service tiers et pas de clé API. Les données de consentement restent dans votre base de données. Les liens vers les politiques de confidentialité des fournisseurs sont de simples liens ouverts dans un nouvel onglet.

Comment prouver ce qu'un visiteur a accepté ?

Chaque choix reçoit une référence affichée au visiteur et une ligne dans le journal : date UTC, catégories, action, versions du bandeau, de la politique et du consentement, pays et signaux. Les lignes sont chaînées par une empreinte SHA-256 et le contrôle d'intégrité signale une modification ou une suppression. C'est une preuve technique, pas un horodatage qualifié : elle ne détecte pas quelqu'un qui recalculerait toute la chaîne avec un accès à la base.

Que se passe-t-il si un visiteur refuse ou retire son consentement ?

Les scripts des catégories refusées ne sont pas chargés. En cas de retrait, le module supprime les cookies habituels des services de la catégorie sur le domaine et ses domaines parents, puis recharge la page, car un script déjà exécuté ne peut pas être déchargé. Le retrait est enregistré comme un choix, avec la même facilité que l'accord. Les cookies HttpOnly et ceux d'autres domaines ne peuvent pas être supprimés par une page : le panneau et la politique l'indiquent.

Le module est-il conforme à Consent Mode v2 de Google ?

Il envoie les signaux attendus par Google : valeurs par défaut avant tout tag, refus dans l'UE, l'EEE, au Royaume-Uni et en Suisse, mise à jour à chaque choix, temporisation et réduction des données publicitaires. Google demande Consent Mode v2 pour la publicité et la mesure dans ces régions ; ce n'est pas une obligation légale en soi. Un seul émetteur doit être actif : choisissez le module ou le module Google Tracking, et corrigez la source si les deux émettent.

Le module ralentit-il la boutique et fonctionne-t-il avec le cache ?

Le HTML est identique pour tous les visiteurs, car le choix est appliqué dans le navigateur : le module est compatible avec le cache natif de PrestaShop et avec Cache Pro. Côté boutique, il ajoute un seul fichier JavaScript et un seul fichier CSS, sans jQuery ni appel externe. Le cache est purgé à chaque enregistrement de réglages qui change la boutique ; si un cache serveur ou CDN stocke vos pages, pensez à le purger aussi.

Que se passe-t-il sans JavaScript ?

La page reste utilisable et rien de non essentiel ne se charge, car les éléments neutralisés restent inertes. En revanche, le bandeau et le panneau ne peuvent pas s'afficher ni enregistrer un choix sans JavaScript : aucun consentement n'est recueilli, et les catégories non essentielles restent bloquées. C'est le comportement prudent, mais il faut le savoir si votre thème dépend fortement de JavaScript.

Fonctionne-t-il en multiboutique et sur PrestaShop 1.7.8 ?

Oui. Le module fonctionne sur PrestaShop 1.7.8, 8.0+ et 9.0+ avec PHP 7.4 minimum, avec les thèmes Classic et Hummingbird. En multiboutique, chaque boutique a ses réglages, ses textes, ses services, son journal, ses analyses et sa politique ; l'export et l'import JSON permettent de dupliquer une configuration, sans copier le journal ni les statistiques.

Que se passe-t-il si ma licence expire ?

Le module se désactive : plus de bandeau, plus de lien en pied de page, plus de blocage des scripts tiers, plus de signal Consent Mode et plus de choix enregistré. Vos réglages, services, journal et page de politique sont conservés, et la page de politique reste publiée. La page de configuration permet d'activer ou de renouveler la licence ; le module se réactive dès qu'elle est valide.

La politique cookies est-elle prête à publier ?

C'est un modèle généré à partir de votre inventaire : il décrit les catégories, les services, les cookies et les durées connues, mais il doit être relu et adapté à votre boutique. Le module affiche cet avertissement et demande une confirmation avant publication. Il ne remplace pas un conseil juridique et ne certifie pas la conformité de votre politique.

Est-ce une CMP certifiée IAB TCF ?

Non. Le module ne génère pas de chaînes de consentement IAB TCF et ne s'adresse pas aux éditeurs de publicité programmatique, qui ont besoin d'une certification délivrée par IAB Europe. Il ne couvre pas non plus les régimes hors UE/EEE, Royaume-Uni et Suisse (CCPA/CPRA, LGPD, etc.), ni un registre de consentement hébergé dans le cloud.

---

Support

Pour toute aide, contactez-nous depuis votre espace client WePresta ou par e-mail à mail@wepresta.shop, selon l'option de support de votre formule.

Avant de nous écrire, préparez :

• les versions de PrestaShop et de PHP
• le thème utilisé
• l'adresse de la page concernée et une capture de l'écran
• si possible, la référence d'un consentement concerné et la date du problème

---

Changelog

Version 1.0.0

• Bloque les scripts, iframes, pixels et ressources tierces avant le consentement, puis les charge selon la catégorie acceptée.
• Remplace les iframes YouTube, Vimeo et Google Maps par un bloc explicatif avec un bouton pour les afficher.
• Intercepte les scripts et iframes ajoutés après le chargement et les libère quand la catégorie est acceptée.
• Fournit une bibliothèque de services prêts à classer et des services personnalisés par domaine ou expression.
• Analyse six pages de la boutique et signale les domaines inconnus, avec analyses planifiées et alertes par e-mail.
• Propose un bandeau en trois positions, personnalisable par langue, avec contraste vérifié et aperçu en direct.
• Ouvre un panneau de préférences par catégorie, avec les services, les cookies et leur durée.
• Permet de revenir sur son choix par un onglet, un lien en pied de page ou un shortcode.
• Enregistre chaque décision dans un journal en ajout seul, avec référence, export CSV/JSON et purge automatique.
• Chaîne les lignes par une empreinte SHA-256 et contrôle l'intégrité du journal.
• Envoie les signaux Google Consent Mode v2 avant tout tag et coopère avec le module Google Tracking.
• Génère la politique cookies dans chaque langue et publie la page CMS, avec un tableau réutilisable par shortcode.
• Ajoute un tableau de bord, un assistant en quatre étapes, un mode test et une page de contrôle pour les employés.
• Gère le ciblage par pays, les signaux GPC et DNT, le multiboutique et cinq langues.
• Fonctionne avec PrestaShop 1.7.8, 8.0+ et 9.0+ et PHP 7.4 minimum.

Découvrir le module et ses formules