Consentement aux cookies pour PrestaShop : ce que la loi exige vraiment

Revu en juin 2026. Les références d’application (CNIL, TDDDG, Garante) reflètent la position à cette date et évoluent avec le temps ; il s’agit de conseils techniques, pas d’un avis juridique — confirmez les points propres à vos marchés auprès d’un conseiller qualifié.

Presque toutes les boutiques PrestaShop affichent une bannière de cookies. Très peu sont réellement conformes — et la raison est technique, pas juridique. La bannière reste poliment dans un coin pendant que Google Analytics, Facebook Pixel et une demi-douzaine d’autres scripts se sont déjà déclenchés au chargement de la page, ont déposé leurs cookies et ont envoyé leurs données. Le client clique sur "Accepter" ou "Refuser" ; cela ne change rien, car le suivi a eu lieu avant même qu’il voie le choix proposé. Cette seule erreur — déclencher des cookies avant le consentement — est l’infraction la plus fréquente sur les boutiques PrestaShop, et c’est aussi celle qui transforme une bannière de conformité en simple théâtre juridique.

Ce guide porte précisément sur le consentement : à quoi doit ressembler un consentement valable, pourquoi l’ordre des opérations (bloquer d’abord, déclencher ensuite) est décisif, et comment cela fonctionne concrètement dans l’architecture de hooks et de modules de PrestaShop. Pour une vue plus large — droits des personnes concernées, politique de confidentialité, registre RGPD, données que vous pouvez conserver — consultez GDPR and cookie compliance for PrestaShop et le guide plus général GDPR for online stores. Ici, nous restons concentrés sur la bannière et les scripts qui se cachent derrière.

Deux textes, une règle à respecter

Les cookies se trouvent au croisement de deux textes du droit européen, et il vaut la peine de savoir qui fait quoi — car ils tirent dans des directions légèrement différentes.

L’effet combiné est simple à énoncer et facile à mal appliquer : vous devez obtenir un consentement explicite et éclairé avant de déposer ou de lire tout cookie non essentiel. Notez le mot avant. ePrivacy concerne l’acte d’écrire sur l’appareil, donc le consentement doit venir en premier — pas "la bannière est visible pendant que le script tourne", mais bien le script ne s’exécute réellement qu’après l’accord de l’utilisateur.

Ce qui compte comme "strictement nécessaire" sur une boutique PrestaShop

Voici une liste courte et défendable de cookies que vous pouvez déposer sans demander l’autorisation — parce que la boutique ne peut pas fonctionner sans eux, et que le client a demandé cette fonctionnalité, par exemple en ajoutant un produit à son panier :

• Le cookie de session de PrestaShop (PrestaShop-xxxxxxxx, la session front-office) — conserve le panier, l’état de connexion et le jeton CSRF d’une page à l’autre. Sans lui, il n’y a pas de boutique.
• L’authentification client — mémorise qu’un client connecté l’est toujours.
• Les jetons de sécurité — protection CSRF sur les formulaires et le tunnel de commande, signaux de fraude ou de bot.
• Le cookie de consentement lui-même — vous avez le droit de mémoriser le choix que l’utilisateur vient de faire.
• La répartition de charge / le routage — cookies de session persistante qui envoient l’utilisateur vers le bon serveur.

Tout ce qui dépasse cette ligne — analytics, pixels publicitaires, tests A/B, flux sociaux intégrés, lecteurs vidéo qui déposent des cookies de suivi — nécessite d’abord un consentement. Un test utile : si le cookie sert à vous aider vous (mesurer, recibler, optimiser) plutôt qu’à fournir la page demandée par le client, il est non essentiel.

À quoi doit vraiment ressembler un consentement valable

"Ils ont cliqué sur quelque chose" ne suffit pas à constituer un consentement. Le RGPD fixe un seuil de qualité, et les régulateurs — en particulier la CNIL en France et les autorités allemandes de protection des données — l’interprètent désormais strictement. Un consentement valable est :

• Donné librement. Un vrai choix, sans pénalité en cas de refus. Un cookie wall — "acceptez tout ou vous ne pouvez pas utiliser le site" — échoue à ce critère dans la plupart des pays de l’UE, car le consentement n’est pas libre lorsque la seule alternative est l’absence d’accès.
• Spécifique et granulaire. Le consentement aux analytics est distinct du consentement marketing. Un seul bouton global "accepter les cookies" qui regroupe tout est trop grossier ; les interrupteurs par catégorie (nécessaires / analytics / marketing / préférences) sont le standard accepté.
• Éclairé. L’utilisateur comprend ce qu’il accepte. Cela ne veut pas dire qu’il faut une politique de 10 000 mots dans la bannière — un résumé en langage clair avec un lien vers la liste complète des cookies suffit.
• Non équivoque et positif. Une action explicite — cliquer sur "Accepter". Continuer à naviguer n’est pas un consentement. Faire défiler la page n’est pas un consentement. Les cases précochées sont explicitement interdites.
• Retirable aussi facilement qu’il a été donné. Si un clic a enregistré le consentement, un clic (depuis un lien persistant "Paramètres des cookies" dans le pied de page) doit pouvoir le retirer.

Qu’est-ce que cela implique pour le design de votre bannière ? "Tout refuser" doit être aussi visible et aussi accessible en un clic que "Tout accepter", dès le premier niveau — pas enterré deux clics plus loin sous "Gérer les préférences". Une bannière où dire non est plus difficile que dire oui correspond exactement au dark pattern qui attire les sanctions, et il est trivial pour un régulateur (ou un client agacé) de le repérer.

L’erreur qui casse 90 % des bannières PrestaShop : déclencher avant le consentement

C’est ici que les spécificités de PrestaShop comptent, car l’échec est presque toujours architectural. La plupart des boutiques ajoutent le suivi en plaçant un extrait Google Analytics, Pixel ou Tag Manager dans un module accroché à displayHeader (ou en le collant directement dans le header.tpl du thème, ou via un module d’édition live / injection HTML dans l’en-tête, ou encore avec le module ps_googleanalytics). Toutes ces solutions injectent le script dans chaque page au moment où la page est rendue — c’est précisément à ce moment que le cookie est écrit, bien avant que le visiteur lise la bannière, et encore plus avant qu’il y réponde.

La bannière de cookies, de son côté, n’est que du JavaScript front-end qui affiche une boîte. Si les deux ne sont pas reliés, la bannière est cosmétique et vous n’êtes pas conforme, quelle que soit son apparence. Deux modes d’échec dominent :

• Déclenchement au chargement. Les scripts s’exécutent immédiatement dans hookHeader ; la bannière apparaît ensuite. Les cookies sont déjà déposés. Cliquer sur "Accepter" ou "Refuser" ne change rien à ce qui s’est déjà produit.
• Le refus est ignoré. L’utilisateur clique sur "Tout refuser", mais le script analytics — enregistré indépendamment de la bannière — se déclenche quand même sur la page suivante. Les deux systèmes n’ont jamais été connectés.

La correction relève de l’ordre des opérations, pas du juridique. Les scripts non essentiels doivent être bloqués par défaut et injectés uniquement après le consentement à la catégorie concernée. En pratique, cela correspond à l’une de ces trois architectures : (1) l’outil de consentement contrôle lui-même l’injection des scripts et retient les tags jusqu’à l’accord de l’utilisateur ; (2) vous faites passer le tout par Google Tag Manager et conditionnez chaque tag à un déclencheur de consentement ; ou (3) vous passez par Google Tag Manager avec Google Consent Mode v2 — mais uniquement comme couche d’appui, pas comme solution autonome de conformité. Consent Mode n’aide que si son état de consentement par défaut est défini sur denied et qu’aucun stockage ni suivi non essentiel n’a lieu avant l’accord du visiteur ; les pings "restreints, sans cookies" que Google envoie avant le consentement peuvent malgré tout être juridiquement sensibles et doivent être évalués et configurés avec soin, au lieu d’être supposés conformes. À lui seul, il ne satisfait pas l’exigence de blocage préalable imposée par ePrivacy. Vous pouvez vérifier dans quel camp se trouve votre boutique sans aucun outil particulier : ouvrez les outils de développement du navigateur, allez dans le panneau Application → Cookies lors d’une première visite avant de cliquer sur quoi que ce soit, et cherchez _ga, _fbp et leurs équivalents. S’ils sont là, votre bannière est décorative.

À quoi ressemble "bloquer d’abord" dans le balisage

La technique concrète derrière une couche de consentement qui bloque réellement est simple : un script qui doit attendre n’est pas livré comme un <script src> normal. Il est livré avec un type neutralisé afin que le navigateur ne l’exécute pas, puis la couche de consentement réécrit ce type en text/javascript uniquement lorsque la catégorie correspondante est acceptée. Le voir une fois suffit à démystifier toute l’idée de "blocage avant consentement" :

<!-- BLOCKED until consent: the browser parses but does NOT run this. -->
<script type="text/plain" data-cookiecategory="analytics"
        src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>

<!-- When the visitor accepts "analytics", the consent layer flips the type
     so the browser then executes it — never before. -->

Si un script est déjà un type="text/javascript" actif (ou n’a pas de type du tout) dans le code source de votre page, il n’est pas bloqué — il s’exécute au chargement, avec ou sans bannière. Cet attribut est la frontière pratique entre une couche de consentement qui fonctionne et une bannière posée par-dessus des scripts déjà déclenchés. Et alors ? Lorsque vous évaluez un module de cookies ou une configuration GTM, afficher la source et vérifier si les tags de suivi sont neutralisés (text/plain) vous indique en cinq secondes si le blocage préalable est réel ou cosmétique.

Ce que PrestaShop fournit nativement — et où cela s’arrête

PrestaShop fournit quelques éléments juridiques de base, et il est utile de savoir exactement jusqu’où ils vont avant d’installer un module.

Le résumé honnête : les outils natifs de PrestaShop couvrent bien la transparence et les droits liés aux données, mais aucun ne fait la chose dont parle cet article — empêcher l’écriture de cookies non essentiels tant que le visiteur n’a pas dit oui. Cette tâche exige une couche de consentement qui contrôle réellement l’injection des scripts.

Mettre en place un vrai consentement dans PrestaShop

Si un module dédié existe, c’est précisément à cause de la limite ci-dessus : il vous faut quelque chose qui intercepte les scripts de suivi et les libère par catégorie, depuis le back-office, sans modifier les fichiers du thème ni câbler des déclencheurs de tags à la main. Notre Lightweight Cookie Banner est conçu pour ce travail précis sur PrestaShop :

• Blocage par défaut, libération par catégorie. Les scripts analytics et marketing sont retenus jusqu’à ce que le visiteur consente à cette catégorie — nécessaires / analytics / marketing / préférences, chaque interrupteur fonctionne indépendamment. C’est le blocage préalable que la loi exige réellement, pas une bannière posée sur des scripts déjà exécutés.
• Refuser aussi facilement qu’accepter. "Tout refuser" apparaît au premier niveau avec la même importance que "Tout accepter", ce qui vous évite les sanctions liées aux dark patterns qui rattrapent d’autres boutiques.
• Un enregistrement du consentement. Le module stocke quand chaque visiteur a consenti et à quoi — la preuve dont vous aurez besoin si une autorité de protection des données vous demande comment le consentement a été obtenu.
• Un nouveau consentement en cas de changement. Ajoutez une nouvelle catégorie de suivi ou modifiez votre politique de cookies, et le module redemande l’accord au lieu de s’appuyer silencieusement sur un ancien consentement.
• Réellement léger. Il se charge sans alourdir votre page — la couche de conformité ne vous coûte donc pas le score PageSpeed que vous avez protégé.

Quel est le bénéfice concret ? Vous le configurez depuis le back-office au lieu de payer un développeur pour greffer une logique de consentement dans votre thème, et la bannière cesse d’être un risque déguisé en protection. C’est une aide technique — elle vous apporte le blocage préalable et l’enregistrement du consentement attendus par la loi — mais elle ne rend pas, à elle seule, votre boutique "conforme" ; votre politique de cookies, vos choix de catégorisation et vos informations sur les sous-traitants restent sous votre responsabilité de responsable du traitement. Si votre boutique s’appuie aussi sur l’écosystème Google, associez-la à Consent Mode v2 afin que GA4 continue à modéliser les conversions des visiteurs qui refusent — Consent Mode estime statistiquement cette part perdue, il ne récupère pas leurs données réelles, et vous respectez toujours le "non" en bloquant d’abord.

Différences par pays : la même règle, appliquée de façon inégale

La règle du consentement préalable vaut dans toute l’UE, mais l’appétit des autorités pour l’appliquer varie. Quelques exemples qui influencent la configuration de votre bannière :

• France (CNIL). La plus stricte sur le design des bannières : "Tout refuser" doit être au premier niveau, à égalité avec "Tout accepter". La CNIL a prononcé à plusieurs reprises des amendes importantes spécifiquement à cause de boutons de refus difficiles à trouver.
• Allemagne. Les analytics exigent un consentement, point final, et le TDDDG (successeur du TTDSG) inscrit en dur dans le droit national la règle ePrivacy du consentement préalable. Les autorités allemandes sont peu réceptives aux arguments d’"intérêt légitime" pour le suivi.
• Italie (Garante). Exige une bannière à la première visite proposant accepter / refuser / gérer, ainsi qu’une politique de cookies liée ; l’autorité a explicitement écarté le défilement comme preuve de consentement.
• Espagne (AEPD) suit le standard européen et publie des recommandations détaillées sur les bannières, avec une application historiquement plus légère qu’en France ou en Allemagne.
• Royaume-Uni (ICO). Après le Brexit, le Royaume-Uni a conservé les règles sous la forme du UK GDPR et du PECR ; l’obligation de consentement préalable est substantiellement la même, appliquée par l’ICO.

Pour une vue juridique transfrontalière plus large, au-delà des cookies, consultez e-commerce law in the EU.

Accepter le trou dans les analytics — et s’y préparer

Conséquence inconfortable d’un consentement correctement mis en œuvre : vos analytics deviennent moins complets. Lorsqu’une part significative des visiteurs refuse le suivi — des chiffres autour de 30 à 40 % sont souvent rapportés, mais considérez-les comme un ordre de grandeur et mesurez votre propre taux d’acceptation à partir des enregistrements de consentement — vous perdez simplement la visibilité sur cette tranche. Ce n’est pas un bug à contourner ; c’est le coût de la conformité, et prétendre le contraire est précisément ce qui ramène les boutiques dans le piège du "déclencher avant consentement". Les atténuations raisonnables : s’appuyer sur Consent Mode v2 pour les conversions modélisées (estimées, non récupérées), envisager la mesure côté serveur pour les données que vous pouvez collecter sans cookies sur l’appareil, et déplacer votre analyse des parcours individuels vers des tendances agrégées qui restent exploitables avec un échantillon plus petit.

Questions fréquentes

Comment savoir, tout de suite, si ma bannière bloque vraiment quelque chose ?

Ouvrez votre boutique dans une nouvelle fenêtre de navigation privée, ouvrez DevTools → Application → Cookies, et regardez avant de toucher à la bannière. Si _ga, _fbp ou _gcl_au sont déjà présents, les scripts se sont déclenchés au chargement et votre bannière est cosmétique. Cliquez ensuite sur "Tout refuser" et rechargez : s’ils réapparaissent, le refus n’est pas relié aux scripts. Un second indice se trouve dans le code source de la page — les tags bloqués portent type="text/plain" ; les tags actifs, non.

"Tout accepter" plus un lien "Gérer les préférences" suffit-il, ou faut-il un "Tout refuser" visible ?

Il vous faut un "Tout refuser" au premier niveau, avec la même visibilité et le même coût en clic que "Tout accepter". Cacher le refus derrière "Gérer les préférences" est précisément le dark pattern sanctionné à plusieurs reprises par la CNIL et d’autres autorités. Une visibilité équivalente sur le premier écran est le choix sûr sur les marchés les plus stricts.

Google Consent Mode v2 rend-il ma bannière conforme à lui seul ?

Non. Consent Mode indique aux tags Google si le visiteur a consenti et modélise les conversions que vous perdez à cause de ceux qui refusent — il les estime, il ne récupère pas de données réelles. C’est une couche d’appui, pas le blocage préalable exigé par ePrivacy. Si des cookies non essentiels sont encore écrits avant que le visiteur donne son accord, Consent Mode ne vous sauve pas ; il vous faut d’abord une couche qui retient réellement les scripts.

Puis-je conserver le module ps_googleanalytics de PrestaShop tout en restant conforme ?

Seulement si quelque chose le conditionne. Seul, ps_googleanalytics injecte son tag au chargement de la page et dépose le cookie GA avant le consentement. Vous devez soit le faire passer par une couche de consentement / GTM qui le bloque jusqu’à l’acceptation de la catégorie "analytics", soit le remplacer. Le module n’est pas le problème ; son déclenchement inconditionnel l’est.

Les cookie walls ("acceptez ou partez") sont-ils autorisés ?

Dans la plupart des pays de l’UE, non — le consentement n’est pas "librement donné" lorsque la seule alternative est de perdre l’accès au site. Certaines juridictions et certains modèles avec alternative payante font débat, mais pour une boutique PrestaShop classique, un cookie wall est un mauvais réglage par défaut. Proposez plutôt un vrai chemin de refus.

Le minimum pratique pour rester à l’écart des problèmes

Si vous voulez être conforme sans surconcevoir le dispositif, procédez dans cet ordre :

• Installez une couche de consentement qui bloque les scripts — pas une bannière qui se contente d’informer. (Lightweight Cookie Banner si vous voulez la gérer depuis le back-office.)
• Configurez-la pour retenir les analytics et le marketing jusqu’à ce que la catégorie correspondante soit acceptée.
• Placez "Tout refuser" au premier niveau, à égalité avec "Tout accepter".
• Publiez une politique de cookies claire (créez une page CMS si votre installation n’en a pas déjà une) listant chaque cookie, sa finalité et sa durée de vie.
• Vérifiez avec les outils de développement : première visite, contrôle dans Application → Cookies avant de cliquer — aucun _ga / _fbp ne doit exister. Cliquez ensuite sur "Tout refuser" et confirmez qu’ils n’apparaissent toujours pas.
• Conservez les enregistrements de consentement afin de pouvoir montrer comment et quand le consentement a été obtenu.

Ce n’est pas le maximum juridique absolu dans chaque juridiction — certaines exigent des informations plus détaillées — mais cela couvre les fondamentaux et vous tient à l’écart des sanctions qui se produisent réellement. Pour une formulation propre à chaque marché, une heure avec un avocat connaissant vos pays cibles vaut le coût ; ne laissez simplement pas la recherche d’une documentation parfaite vous empêcher de corriger le point qui compte vraiment aujourd’hui : s’assurer qu’aucun cookie n’est déposé avant que le visiteur ait dit oui.

Guides associés

• Conformité RGPD et cookies pour PrestaShop : ce dont vous avez vraiment besoin
• RGPD pour les boutiques en ligne : ce que vous devez faire (et ce que vous pouvez éviter)
• Droit du e-commerce dans l’UE : guide des règles essentielles pour les marchands
• Accessibilité des boutiques en ligne : ce que l’European Accessibility Act change pour vous