Blog

CookiePass et Google Consent Mode : ce qu’une bannière de consentement fait à votre trafic

Publié 24 septembre 2026· Mis à jour 18 octobre 2026· 4 min de lecture

Ce site utilise CookiePass. C’est un service de consentement aux cookies qui implémente Google Consent Mode v2 comme Google le spécifie, et cette propriété compte finalement plus que les couleurs de la bannière : elle décide de ce que votre balise Google envoie à chaque page vue avant que le visiteur ait répondu, après un oui et après un non. Voici ce que cela donne côté serveur, où chacun de ces hits traverse votre conteneur.

Ce que Consent Mode change vraiment

Choisissez le mode adapté à la politique de votre organisation. Ne désactivez pas un blocage volontaire uniquement pour faire apparaître des événements. **Basic :** bloquez l’extrait de suivi jusqu’au consentement correspondant. Aucun événement de suivi n’est attendu dans SignalHost avant ce consentement. **Advanced :** les balises Google chargent avec des valeurs initiales `denied`. Google peut recevoir des mesures sans cookies avant le choix ou après un refus. Une mesure ne vaut pas consentement.

Le champ `gcs` décrit uniquement le stockage publicitaire et Analytics. Il ne prouve pas les deux autorisations de consentement plus récentes. Vérifiez les quatre dans Google Tag Assistant ; les champs encodés des requêtes peuvent changer.

gcs=G100   ad_storage denied,  analytics_storage denied
gcs=G101   ad_storage denied,  analytics_storage granted
gcs=G110   ad_storage granted, analytics_storage denied
gcs=G111   both granted
(no gcs)   storage summary missing; our current storage gate permits it, not proof of consent

Définissez `analytics_storage`, `ad_storage`, `ad_user_data` et `ad_personalization` sur `denied` avant l’exécution de l’extrait SignalHost. La bannière adapte ensuite chaque autorisation au choix du visiteur.

Comment CookiePass le met en place

Consent Mode v2 exige une séquence, pas un réglage. L’état par défaut doit être déclaré avant le chargement de la balise Google — refusé pour quiconque n’a pas encore choisi —, une mise à jour doit suivre dès que le visiteur décide, et cet état doit être restauré à chaque visite suivante. Si l’ordre est faux, la première page vue de chaque session part comme consentie avant même que la bannière soit affichée.

Voici la séquence que CookiePass produit depuis son propre script, si bien que rien de tout cela n’atterrit dans votre conteneur Tag Manager :

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500
});

// …the visitor accepts all four purposes…
gtag('consent', 'update', {
  ad_storage: 'granted',
  analytics_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted'
});

C’est toute l’intégration. Les balises de Google respectent l’état de consentement automatiquement, y compris celles que SignalHost publie dans votre conteneur web. Rien dans votre conteneur serveur n’a besoin d’une condition de consentement ; en ajouter une à la main, c’est ainsi qu’une balise Google bloquée se retrouve à côté de balises d’événement non bloquées qui envoient les données directement à Google.

Ce que votre conteneur serveur voit avant et après le choix

**Basic :** bloquez l’extrait de suivi jusqu’au consentement correspondant. Aucun événement de suivi n’est attendu dans SignalHost avant ce consentement. **Advanced :** les balises Google chargent avec des valeurs initiales `denied`. Google peut recevoir des mesures sans cookies avant le choix ou après un refus. Une mesure ne vaut pas consentement.

Avant un choix et après Refuser : les autorisations concernées restent sur `denied`.
Statistiques uniquement : `analytics_storage` peut être accordé ; les autorisations publicitaires restent refusées.
Publicité acceptée : n’accordez que les finalités réellement acceptées par le visiteur.
Retrait : les valeurs concernées repassent sur `denied`. Rechargez et vérifiez le choix enregistré.

Un événement visible prouve-t-il que le consentement est correct ? Non. Les événements en direct montrent l’arrivée dans SignalHost, pas les quatre autorisations ni la livraison à une plateforme. Vérifiez le consentement dans Tag Assistant, puis la destination séparément.

Ce que cela signifie pour vos chiffres de trafic

**Basic :** bloquez l’extrait de suivi jusqu’au consentement correspondant. Aucun événement de suivi n’est attendu dans SignalHost avant ce consentement.
**Advanced :** les balises Google chargent avec des valeurs initiales `denied`. Google peut recevoir des mesures sans cookies avant le choix ou après un refus. Une mesure ne vaut pas consentement.

Une liste de contrôle

Avant le début du suivi, votre bannière doit définir les autorisations sur refusé. Après le choix du visiteur, mettez à jour uniquement les finalités qu’il a autorisées, mémorisez son choix et gérez son retrait.
Ouvrez une nouvelle fenêtre privée pour chaque test. Dans Google Tag Assistant, saisissez l’URL du site et examinez les premiers et derniers événements Consent.
Avant un choix et après Refuser : les autorisations concernées restent sur `denied`.
Statistiques uniquement : `analytics_storage` peut être accordé ; les autorisations publicitaires restent refusées.
Publicité acceptée : n’accordez que les finalités réellement acceptées par le visiteur.
Retrait : les valeurs concernées repassent sur `denied`. Rechargez et vérifiez le choix enregistré.
Ajoutez l’URL exacte du chargeur de votre extrait SignalHost aux règles de blocage de la bannière. Votre domaine peut échapper à ses règles Google habituelles. Ne le débloquez qu’après le consentement nécessaire.

[Guide de configuration de la bannière de cookies](/fr/blog/banniere-cookies-consent-mode-serveur)