Analyse technique approfondie
Votre boutique Shopify dépose probablement des cookies avant le consentement. Voici comment le prouver en cinq minutes.
Activez la bannière de cookies de Shopify. Ouvrez l'onglet Network (Réseau) dans une fenêtre privée. Comptez les requêtes qui se déclenchent avant votre premier clic. Pour beaucoup de boutiques, le compte n'est pas à zéro — et c'est précisément cet écart que les autorités examinent.
Voici un test que vous pouvez lancer dès maintenant, sur votre propre boutique, sans autre outil que votre navigateur :
- Ouvrez votre vitrine dans une nouvelle fenêtre privée / navigation privée.
- Avant de cliquer sur quoi que ce soit dans la bannière de cookies, ouvrez les DevTools et regardez les cookies déjà présents ainsi que les requêtes réseau déjà parties.
- Cliquez maintenant sur Refuser. Observez ce qui est supprimé — et ce qui continue de se déclencher malgré tout.
Si vous ne l'avez jamais fait, le résultat est souvent surprenant. Pas parce que Shopify ferait quelque chose de mal — ce n'est pas le cas — mais à cause de l'écart entre ce que vous avez configuré dans l'administration et ce que le navigateur fait réellement au chargement de la page.
L'angle mort : ce que vous déclarez ≠ ce que fait le navigateur
Il y a deux choses très différentes, et presque tout le monde les confond.
La déclaration. Dans votre administration Shopify, vous activez la bannière de consentement, vous cochez les cases, vous branchez la Customer Privacy API. Sur le papier, tout est en place.
Le comportement. Ce que fait un vrai navigateur quand un vrai visiteur charge votre page : quels cookies sont écrits sur le disque, quels pixels se déclenchent, quels domaines tiers sont contactés — et, surtout, à quel moment, par rapport au clic de consentement.
La déclaration vit dans votre administration. Le comportement vit dans le navigateur du visiteur. Une autorité qui audite un site ne lit pas vos réglages d'administration — elle ouvre la page, observe le réseau et lit le pot de cookies. Le navigateur est la source de vérité. Cela n'est pas propre à Shopify ; c'est vrai pour toute stack web. Mais les réglages par défaut, les thèmes et l'écosystème d'applications de Shopify rendent cet écart facile à manquer.
Une précision en préambule : je ne suis pas juriste, et rien ici ne constitue un conseil juridique ni un verdict de conformité. Il s'agit de ce qui est techniquement observable dans votre navigateur. Ce que cela implique pour votre situation précise est une question à poser à un conseil qualifié.
Un chargement de vitrine typique, sur une frise chronologique
Les cinq vraies causes techniques
1. Les propres cookies de Shopify, et la zone grise « nécessaire vs analytics »
Shopify écrit un ensemble de cookies first-party plus ou moins au chargement : _shopify_y, _shopify_s, _y, _s, plus des cookies de panier et de session comme cart, _secure_session_id, _shopify_essential. Certains sont réellement nécessaires — un cookie de panier fait fonctionner le panier. D'autres ont une coloration analytics (la famille _y/_s alimente les analytics de vitrine de Shopify). L'étiquette « strictement nécessaire » fait beaucoup de travail ici, et l'endroit exact où passe la limite fait débat. À retenir, concrètement : ne partez pas du principe que chaque cookie Shopify est dans la catégorie « pas de consentement requis » juste parce que c'est Shopify qui l'a posé.
2. La Customer Privacy API rapporte le consentement — elle ne l'applique pas d'elle-même
La Customer Privacy API de Shopify (window.Shopify.customerPrivacy) est un outil bon et bien réel. Elle expose le statut de consentement du visiteur — analyticsProcessingAllowed(), marketingAllowed() — et déclenche un événement visitorConsentCollected quand le visiteur décide. Mais exposer un signal n'est pas la même chose que bloquer. C'est à chaque script, thème et application de lire ce signal et de se conditionner à lui. Un pixel qui ne vérifie jamais customerPrivacy se déclenchera quoi qu'il arrive. L'API vous tend l'état du consentement sur un plateau ; que votre code l'attende réellement est une autre question.
3. Des pixels codés en dur au chargement par d'anciens scripts ou applications
C'est le grand classique. Un pixel Meta (Facebook), un pixel TikTok ou un tag Google a été collé directement dans theme.liquid il y a deux ans, ou installé par une application qui l'injecte sur chaque page. Il s'exécute dans le <head>, immédiatement, avant même que la bannière ne soit affichée. Le sandbox Customer Events / web pixels moderne de Shopify existe précisément pour faire passer ces tags par la couche de consentement — mais un tag hérité codé en dur contourne tout cela. Il ignore l'existence de la bannière.
4. Un refus qui n'est pas entièrement propagé
Deux modes de défaillance ici. Premièrement : les cookies déjà écrits avant la décision ne sont pas supprimés quand le visiteur refuse — ils restent simplement là. Deuxièmement : un script lit l'état de consentement une seule fois, tôt, met en cache « pas encore de décision » et se déclenche quand même parce qu'il ne revérifie jamais après que le visiteur a cliqué sur Refuser. La bannière dit « refusé ». Le réseau dit le contraire.
5. Des ressources tierces hors du périmètre de la bannière
Des vidéos YouTube intégrées (youtube.com), des Google Fonts récupérées depuis le CDN de Google, un widget de chat, un widget d'avis, une carte intégrée — chacun de ces éléments peut déposer des cookies ou contacter un serveur tiers au chargement, et beaucoup de bannières de consentement ne les couvrent pas du tout parce que ce ne sont pas des « tags », mais du contenu intégré. Ils se trouvent dans un angle mort qui leur est propre.
Ce que vous observez vs ce que vous avez configuré
L'audit maison de cinq minutes
C'est la partie à mettre en favori. Aucun outillage, aucune extension, aucun compte. Juste les DevTools de votre navigateur et quinze minutes la première fois, cinq toutes les fois suivantes. Les étapes sont écrites pour Chrome ; Firefox et Safari sont quasi identiques.
- Ouvrez une fenêtre privée propre Utilisez la navigation privée (Ctrl/⌘ + Shift + N). Un profil propre signifie aucun cookie résiduel ne faussant le résultat. Ne chargez pas encore votre boutique.
- Ouvrez d'abord les DevTools Appuyez sur F12 (ou ⌘ + Opt + I). Allez dans l'onglet Network (Réseau). Cochez Preserve log et Disable cache. Ouvrez-le avant de charger la page afin de capturer les toutes premières requêtes.
- Chargez votre vitrine — et arrêtez-vous. Ne cliquez pas. Laissez la page se stabiliser. Ne touchez pas à la bannière. C'est le scénario un : avant tout consentement.
- Lisez le pot de cookies Allez dans Application ▸ Storage ▸ Cookies (Firefox : Storage ▸ Cookies) et choisissez votre domaine. Listez tout ce qui s'y trouve déjà. Chacun de ces cookies a été posé avant que vous ayez décidé quoi que ce soit.
-
Lisez le réseau
De retour dans Network, filtrez par domaine. Tapez
facebook, puistiktok, puisgoogle-analytics,googletagmanager,doubleclick,youtube. Toute occurrence signifie qu'un tiers a été contacté avant le consentement. Notez-les. - Scénario deux : cliquez sur « Refuser » Refusez maintenant. Puis rouvrez le panneau Cookies. Les cookies pré-posés ont-ils disparu ? Souvent non. Revérifiez les filtres Network — des pixels se déclenchent-ils encore après le refus ? Notez la différence.
- Scénario trois : nouvelle fenêtre, cliquez sur « Accepter » Fermez tout, ouvrez une nouvelle fenêtre de navigation privée, rechargez, et cette fois acceptez. C'est votre référence pour « ce qui se déclenche avec le consentement complet » — utile pour voir ce qui aurait dû être bloqué dans les scénarios un et deux.
Dans l'onglet Network, triez par la colonne Time/Waterfall et trouvez la requête déclenchée par votre clic de consentement. Tout ce qui se trouve au-dessus et qui a chargé un domaine tiers s'est produit avant le consentement. Cette seule vue raconte toute l'histoire.
Les cookies que vous verrez typiquement, et quand ils apparaissent
Les noms et les durées de vie varient selon le thème et la version de Shopify, alors traitez ceci comme un guide de terrain, pas comme une parole d'évangile. Les catégories sont des conventions largement répandues, pas des classifications juridiques.
| Cookie | Posé typiquement | Finalité habituelle |
|---|---|---|
_shopify_y / _y | au chargement | Analytics de vitrine, ~1 an |
_shopify_s / _s | au chargement | Session analytics, ~30 min |
_shopify_sa_p / _shopify_sa_t | au chargement | Analytics marketing / attribution |
cart, cart_sig, cart_ts | fonctionnel | Le panier d'achat lui-même |
_secure_session_id | fonctionnel | Paiement / session |
_tracking_consent, _cmp_a | consentement | Stocke la décision de consentement elle-même |
_fbp | au chargement* | Pixel Meta — devrait attendre le consentement |
_ga, _gid | au chargement* | Google Analytics — devrait attendre le consentement |
* _fbp, _ga et consorts sont ceux à scruter : s'ils apparaissent dans le scénario un (avant tout clic), c'est exactement l'écart dont parle cet article.
Quoi faire face à cela — sans dramatiser
Rien de tout cela n'est une urgence absolue. C'est un problème de configuration et d'hygiène, et il se corrige. Voici des actions réalistes, à peu près par ordre d'impact :
- Auditez vos applications. Chaque application marketing/analytics est un injecteur de pixel potentiel. Désinstallez ce que vous n'utilisez pas — la désinstallation retire généralement aussi le tag. Moins d'applications, moins de surprises.
- Déplacez les pixels dans les Customer Events de Shopify. Les tags ajoutés via le sandbox web pixels sont branchés sur la couche de consentement au lieu de s'exécuter à nu dans
theme.liquid. Si vous avez des pixels codés en dur, les migrer est la correction qui a le plus d'impact. - Faites en sorte que le refus supprime réellement. Quand un visiteur refuse, les cookies posés auparavant devraient être effacés, pas laissés en place. Vérifiez-le dans le scénario deux.
- Conditionnez les intégrations tierces. Chargez YouTube via le mode respectueux de la vie privée (
youtube-nocookie.com), hébergez vos polices en interne, et chargez les widgets en différé derrière le consentement quand c'est possible. - Relancez l'audit après chaque mise à jour de thème ou installation d'application. L'angle mort réapparaît dès que quelque chose de nouveau injecte un tag. Cinq minutes, chaque trimestre.
La bannière de consentement de Shopify bloque-t-elle le suivi à elle seule ?
Pas à elle seule. Elle collecte et expose la décision de consentement via la Customer Privacy API. Qu'un script donné respecte cette décision dépend de la façon dont il a été intégré — via les Customer Events (conditionné) ou codé en dur (non conditionné).
Les propres cookies de Shopify posent-ils problème ?
Beaucoup sont réellement fonctionnels (le panier ne peut pas fonctionner sans l'un d'eux). La zone grise concerne ceux à coloration analytics. La réponse honnête, c'est que la limite « nécessaire vs analytics » fait débat — ce qui est exactement la raison pour laquelle observer le comportement réel vaut mieux que supposer.
Est-ce un problème propre à Shopify ?
Non. Le même écart entre le déclaré et l'observé existe sur WordPress, sur les stacks sur mesure, partout. Shopify fournit en réalité de solides primitives (Customer Privacy API, Customer Events). L'écart se situe dans la configuration et le code tiers, pas dans la plateforme.
Le changement de regard sur le suivi
L'idée à retenir : une configuration de suivi ne vaut que par son comportement observé, pas par sa configuration déclarée. Une case cochée dans un panneau d'administration est une affirmation. L'onglet réseau est la preuve. Les deux divergent en permanence — une nouvelle application, une mise à jour de thème, un extrait collé — et personne ne le remarque parce que personne ne regarde.
Alors regardez. Cinq minutes dans les DevTools vous en disent plus sur ce que fait réellement votre boutique que n'importe quelle page de réglages. Lancez-le sur votre propre boutique aujourd'hui. Puis lancez-le sur celle d'un concurrent — vous ne lirez plus jamais une bannière de cookies de la même façon.