Consent Mode : ce qui se passe vraiment quand un visiteur refuse les cookies
Guides Pratiques

Consent Mode : ce qui se passe vraiment quand un visiteur refuse les cookies

5 octobre 20269 min de lecturePar Ahmad Al-Kardali
Retour au blog

Consent Mode : ce qui se passe vraiment quand un visiteur refuse les cookies

La question revient à chaque fois que j'installe une bannière cookies chez un client : « si les gens refusent, je perds mes statistiques ? »

La réponse courte est non, pas complètement. La réponse longue mérite un article, parce que le Consent Mode est probablement la partie du tracking la plus mal comprise, et celle où j'ai vu le plus de configurations qui font exactement l'inverse de ce que leur propriétaire croit.

Petite précision avant de commencer : je parle ici de la mécanique technique, pas de conformité juridique. Sur ce qui s'applique précisément à votre situation, c'est un juriste qu'il faut consulter, pas un intégrateur.


Le problème que le Consent Mode essaie de résoudre

Avant, c'était binaire. Une bannière cookies bloquait les scripts tant que le visiteur n'avait pas accepté. S'il refusait, aucun script de mesure ne se chargeait, et ce visiteur n'existait tout simplement pas dans vos données.

Ça fonctionne, c'est respectueux, et c'est aussi très frustrant côté mesure. Sur un site où la moitié des gens refusent, vous pilotez avec une vue sur la moitié du trafic, sans savoir si la moitié manquante se comporte de la même façon.

Le Consent Mode propose autre chose. Plutôt que de ne rien charger, les scripts Google se chargent quand même, mais ils adaptent leur comportement au consentement. Concrètement, quand le consentement est refusé, ils envoient des signaux sans aucun identifiant et sans écrire de cookie. Pas de cookie, pas d'identifiant persistant, donc pas de reconnaissance du visiteur d'une visite à l'autre.

C'est la nuance qui échappe à tout le monde : le visiteur qui refuse n'est pas tracké, mais son passage laisse quand même une trace anonyme et non rattachable.


Les quatre signaux à connaître

Le Consent Mode repose sur quelques paramètres qu'on met à jour selon le choix du visiteur. Les deux principaux sont ceux que vous verrez partout :

gtag("consent", "default", {
  analytics_storage: "denied",
  ad_storage: "denied",
  ad_user_data: "denied",
  ad_personalization: "denied",
});

analytics_storage gouverne les cookies de mesure d'audience. ad_storage gouverne les cookies publicitaires. ad_user_data et ad_personalization sont venus s'ajouter ensuite et concernent respectivement l'envoi des données aux services publicitaires et leur usage pour la personnalisation.

Le mot important dans ce bloc, c'est default. C'est l'état de départ, celui qui s'applique avant que le visiteur ait cliqué quoi que ce soit. Puis, une fois qu'il a choisi, on met à jour :

gtag("consent", "update", {
  analytics_storage: "granted",
  ad_storage: "granted",
  ad_user_data: "granted",
  ad_personalization: "granted",
});

Et c'est tout. Les balises qui écoutent ces signaux ajustent automatiquement ce qu'elles font.


L'erreur numéro un : le default posé trop tard

Voici celle que je retrouve le plus souvent, et elle annule complètement l'intérêt du dispositif.

Le bloc default doit s'exécuter avant le chargement de Google Tag Manager. Pas après, pas en même temps, avant. Concrètement, il se place directement dans le <head>, au-dessus du snippet GTM.

La raison est simple. Si GTM se charge en premier, il commence à déclencher ses balises avec les réglages par défaut de Google, qui sont permissifs. Le temps que votre bannière s'affiche et que le visiteur clique, plusieurs balises sont déjà parties. Vous avez une bannière qui donne l'impression de protéger, et un tracking qui a déjà fait son travail avant qu'elle apparaisse.

Sur un site que j'ai audité, le décalage était d'environ 400 millisecondes. Assez pour que la balise de page vue parte systématiquement, y compris pour les visiteurs qui refusaient trois secondes plus tard.

Le test est immédiat : ouvrez l'onglet réseau de votre navigateur en navigation privée, chargez la page, et regardez si des requêtes partent vers Google avant que vous ayez cliqué. Si oui, votre default est mal placé.


L'erreur numéro deux : croire que la bannière suffit

Beaucoup d'outils de bannière cookies proposent une intégration Consent Mode en une case à cocher. Elle fonctionne souvent, mais elle ne couvre que les balises Google.

Si vous avez un pixel Meta, un chat en direct, un outil de heatmap ou n'importe quel script tiers, ceux-là n'écoutent pas les signaux de Google. Ils se fichent complètement de ad_storage. Il faut les bloquer séparément, généralement en les conditionnant à une variable de consentement dans GTM.

C'est le point qui demande le plus de travail, et c'est aussi celui qu'on saute le plus souvent parce que la bannière affiche fièrement qu'elle est configurée.


Ce que deviennent les données refusées

Quand le consentement est refusé, Google reçoit un signal sans identifiant. À partir d'un certain volume, il utilise ces signaux pour estimer les conversions manquantes, par modélisation statistique.

Deux conséquences pratiques à garder en tête.

La première, c'est que la modélisation demande du volume. Sur un site avec quelques centaines de visites par mois, il n'y a pas assez de matière, et les conversions refusées sont simplement perdues. La modélisation profite surtout aux sites avec du trafic conséquent.

La seconde, c'est que vos chiffres deviennent partiellement estimés. Ce n'est pas un problème en soi, mais ça change la façon de les lire. Comparer le nombre de conversions de Google Ads avec vos vrais leads reçus donnera toujours un écart, et cet écart n'est plus forcément un bug. C'est une des raisons pour lesquelles je recommande toujours de garder une source de vérité côté serveur, ne serait-ce qu'un simple compteur de formulaires envoyés.


Et en Suisse, concrètement

C'est la question que me posent tous mes clients valaisans, alors autant la traiter directement.

La Suisse a sa propre loi sur la protection des données, révisée et entrée en vigueur en septembre 2023. Elle est construite dans le même esprit que le RGPD européen, mais elle est nettement moins prescriptive sur la question précise des cookies. Là où le cadre européen impose en pratique un consentement préalable explicite pour les cookies non essentiels, le cadre suisse met davantage l'accent sur l'obligation d'informer de manière transparente.

Sauf que cette différence est moins utile qu'elle en a l'air, pour une raison simple : dès que votre site s'adresse aussi à des visiteurs situés dans l'Union européenne, le RGPD peut s'appliquer à ces visiteurs-là. Pour la plupart des sites suisses romands, qui reçoivent du trafic français et parfois belge, la question se règle d'elle-même. Vous configurez comme si le cadre le plus strict s'appliquait, et vous arrêtez de vous poser la question.

C'est d'ailleurs ce que je conseille systématiquement, pour une raison pragmatique autant que juridique. Une configuration stricte est plus simple à maintenir qu'une configuration qui essaie de distinguer les visiteurs selon leur pays.

Encore une fois, je décris une pratique de terrain, pas un avis juridique. Si votre activité traite des données sensibles ou si vous avez un doute sur votre situation, faites valider par quelqu'un dont c'est le métier.


Comment je vérifie qu'une configuration tient

Trois contrôles, dans cet ordre, et je ne valide jamais sans les trois.

Avant tout clic. Navigation privée, onglet réseau ouvert, chargement de la page. Aucune requête ne doit partir vers un domaine de mesure ou de publicité avant une interaction avec la bannière. C'est le contrôle qui attrape le problème de timing.

Après un refus. Je refuse, je navigue sur deux ou trois pages, et je regarde les cookies déposés dans l'onglet Application du navigateur. Aucun cookie de mesure ou publicitaire ne doit apparaître. Si un _ga est là après un refus, la configuration ne fait pas ce qu'elle prétend.

Après une acceptation. J'accepte, et je vérifie dans le mode prévisualisation de GTM que les balises se déclenchent effectivement et que les données remontent. Ça paraît évident, mais j'ai déjà vu des configurations tellement verrouillées que plus rien ne partait, même après acceptation.


Ce qu'il faut retenir

Le Consent Mode n'est pas une case à cocher, c'est un ordre d'exécution. Le signal par défaut arrive en premier, la bannière ensuite, la mise à jour au clic, et les balises réagissent.

Quand cet ordre est respecté, vous avez un site qui respecte le choix des visiteurs et qui conserve quand même de quoi piloter. Quand il ne l'est pas, vous avez en général le pire des deux mondes : une bannière qui rassure et un tracking qui part trop tôt.

Si vous avez un doute sur votre propre configuration, commencez par le premier contrôle. Navigation privée, onglet réseau, et regardez ce qui part avant votre premier clic. En une minute vous saurez.

Tags :#Consent Mode#Cookies#Google Tag Manager#Tracking#Suisse

Besoin d'aide ?

Confiez votre projet à un expert web en Valais

Partager cet article

Articles Similaires

28 septembre 20268 min

Le dataLayer, ou pourquoi vos conversions ne remontent jamais correctement

Google Tag Manager ne devine rien. Il lit ce que votre site lui donne. Voilà comment fonctionne le dataLayer, et pourquoi c'est presque toujours là que le tracking casse.

#Google Tag Manager#dataLayer#Tracking
18 mai 20267 min

Développeur freelance vs agence web : comment choisir en Suisse ?

Votre projet web nécessite un développeur freelance ou une agence ? Comparaison complète des avantages, inconvénients et coûts en Suisse pour faire le bon choix.

#Développeur freelance#Agence web Suisse#Choisir prestataire web
27 avril 20268 min

Prix d'un site web en Suisse en 2026 : tous les tarifs expliqués

Combien coûte un site web en Suisse en 2026 ? Site vitrine, e-commerce, application web : découvrez les vrais tarifs et comment choisir le bon prestataire.

#Prix site web#Tarifs développeur web#Site web Suisse