Bannière cookies centrale pour le trafic payant seulement

Une bannière centrale protège l’attribution des visiteurs payants, mais elle coûte du confort aux visiteurs SEO et direct qui n’ont rien à perdre. La réponse que je recommande le plus souvent est de n’afficher la version bloquante qu’au trafic qui porte un identifiant de clic payant, et de garder une bannière discrète pour les autres. Cela se fait sans rien stocker, en lisant l’URL d’arrivée, à condition de ne donner aucun avantage au trafic payant sur le choix de consentement.

Le raisonnement de fond est dans l’article sur la bannière centrale ou discrète. Ici, je m’intéresse à la mise en œuvre, en précisant ce que chaque CMP permet réellement et ce que je n’ai pas pu confirmer. Si votre paramétrage doit être repris, c’est une mission que je fais en tant que consultant Consent Mode v2.

Le compromis, dit simplement

Une bannière discrète laisse naviguer le visiteur avant qu’il réponde. Pour un visiteur venu de Google Ads ou d’une publicité Meta, cette navigation fait perdre le gclid ou le fbclid à la session suivante, sauf si vous avez mis en place la propagation dans les liens internes. Pour un visiteur SEO ou direct, une bannière bloquante ajoute de la friction sans gain d’attribution, puisqu’il n’y a pas de clic payant à protéger.

Le compromis consiste donc à segmenter l’affichage sur l’origine du trafic, pas sur la personne. Le visiteur qui arrive par une campagne payante voit une fenêtre centrale qui attend sa réponse. Les autres voient une bannière discrète, comme aujourd’hui. Les deux bannières proposent les mêmes choix, avec le même niveau de refus.

Détecter le trafic payant sans rien stocker

La détection doit rester dans la mémoire de la page. Elle lit l’URL d’arrivée et ne pose ni cookie ni localStorage. Le résultat sert uniquement à choisir la configuration de la CMP sur cette page.

<script>
// Détection du trafic payant sur la page courante.
// Lecture de l'URL seulement : rien n'est écrit dans le navigateur.
(function () {
  var params = new URLSearchParams(window.location.search);

  // Identifiants de clic publicitaire
  var clickIds = ['gclid', 'gbraid', 'wbraid', 'fbclid', 'msclkid'];
  var hasClickId = clickIds.some(function (key) { return params.has(key); });

  // Paramètres de campagne payante
  var medium = (params.get('utm_medium') || '').toLowerCase();
  var hasPaidMedium = ['cpc', 'ppc', 'paid', 'paid_social', 'paidsocial'].indexOf(medium) !== -1;

  var isPaid = hasClickId || hasPaidMedium;

  // Lu par une variable GTM de type « JavaScript personnalisé » ou par le script CMP
  window.trafficIsPaid = isPaid;

  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({ event: 'traffic_qualified', traffic_paid: isPaid });
})();
</script>

Quelques points sur ce code :

• Le referrer n’est pas utilisé pour décider. Il est absent quand la politique de confidentialité du site d’origine le bloque, et il ne distingue pas un clic payant d’un lien organique depuis la même plateforme.
• Le signal ne vit que sur la page d’arrivée. Il ne survit pas à la navigation sans propagation. C’est acceptable pour la bannière : elle sert à la première réponse, sur la landing. Vérifiez seulement que votre CMP ne repasse pas en mode discret après un changement de page tant que le visiteur n’a pas répondu, ce qui dépend de son implémentation.
• Le champ traffic_paid dans le dataLayer est une information de fonctionnement. Ne l’envoyez pas à Google Ads ou Meta comme audience : ce serait une finalité nouvelle, à déclarer.

Mise en œuvre selon votre CMP

La faisabilité dépend de la CMP. Je ne donne ci-dessous que ce que j’ai pu confirmer dans des sources publiques, et je signale le reste comme à vérifier avant de promettre quoi que ce soit au client.

Axeptio

Axeptio permet de personnaliser l’apparence de la bannière et propose des guides Consent Mode v2. La page d’aide que j’ai consultée ne décrit pas de variantes de bannière conditionnelles par URL ou par paramètre. Si votre besoin est un choix de configuration à l’exécution, il faut donc vérifier dans la documentation « Advanced configuration » s’il existe une option équivalente, ou passer par un chargement conditionnel du script CMP sur la base du signal ci-dessus.

Didomi

Didomi met en avant des éléments d’interface prêts à l’emploi, comme les bannières, et une API pour construire des parcours de consentement personnalisés. La page que j’ai lue ne confirme pas de notice par règle de ciblage ni de condition d’affichage par URL. Une variante payante peut donc passer par votre propre intégration SDK, et non par un réglage natif, à valider avec leur équipe. Pour le cadre de l’offre sur devis et la gouvernance multi-marques, voyez mon avis sur Didomi.

Cookiebot

Je n’ai pas pu accéder à la documentation Cookiebot pendant la rédaction. Je ne peux donc pas affirmer qu’elle propose une bannière distincte selon l’origine du trafic, ni les modalités de son API JavaScript. Pour un projet, c’est la première vérification à faire, avant de parler de délais.

Tarteaucitron

À ma connaissance, Tarteaucitron est configurable en JavaScript, ce qui permet en principe de charger une configuration selon le signal (je n’ai pas vérifié sa documentation pour cet article). Sa souplesse se paie en maintenance : c’est à vous de tenir la cohérence des finalités et des libellés entre les deux variantes, et de tester chaque mise à jour.

Dans tous les cas, si votre CMP ne sait pas afficher deux modes, le même résultat s’obtient en chargeant deux configurations différentes depuis le même point d’entrée, ce qui exige une recette plus lourde.

Variante via GTM

Si votre CMP ne propose pas de variante native, GTM peut piloter le choix :

1. Créez une variable « JavaScript personnalisé » qui renvoie window.trafficIsPaid.
2. Déclenchez la balise qui charge la configuration CMP « centrale » sur la valeur true, et la configuration « discrète » sur false.
3. Testez le choix sur la prévisualisation GTM avec ?gclid=TEST puis sans paramètre.

Le déclencheur doit s’exécuter tôt. Si la bannière s’affiche avant que la variable soit prête, vous obtiendrez une bannière discrète sur un visiteur payant, ce qui annule l’intérêt de l’approche.

Conformité CNIL

La CNIL ne prescrit ni forme ni position de bannière, mais elle juge l’ensemble du parcours. Quatre points sont à garder en tête.

• Même liberté de refus. Le bouton « Tout refuser » doit être disponible au premier niveau dans les deux variantes, avec une visibilité équivalente. Une bannière centrale sans refus de premier niveau s’expose à être jugée non conforme, quelle que soit la qualité de la version discrète.
• Pas de dark pattern. Une fenêtre centrale ne doit pas bloquer la navigation sans réponse possible, ni rendre le refus plus pénible que l’acceptation. Mettez un refus visible, pas une seconde page cachée.
• Cohérence des finalités. Les deux bannières doivent décrire les mêmes finalités et les mêmes partenaires. Une version qui cache des finalités à certains visiteurs ne l’est pas.
• Aucun traceur avant choix. La détection ne doit pas déclencher les balises publicitaires, même si la bannière est centrale. Le signal sert à l’affichage, pas à la collecte. C’est la règle que je vérifie en premier lors d’un audit.

Le choix d’une variante selon l’origine du trafic est une décision d’interface. Il n’exempte d’aucune obligation.

Mesurer avant et après

Mesurez quatre semaines avant le changement, puis quatre semaines après, en gardant la même répartition de trafic payant et organique.

• Taux d’interaction sur la landing payante. Part des visiteurs qui répondent avant de changer de page. Il doit monter nettement avec la bannière centrale.
• Part de (direct) / (none) sur les URL taguées. Calculée sur les sessions dont l’URL d’arrivée contient un gclid ou un utm_*. Elle doit baisser.
• Taux de refus sur le trafic payant, comparé au trafic discret. Si l’écart est fort, c’est que la bannière centrale est vécue comme une contrainte, et qu’il faut revoir la mise en forme du refus.
• Volume de conversions importées dans Google Ads. Il doit rester stable ou progresser, sans que le coût par acquisition monte.

Si le taux de refus explose sur le trafic payant sans amélioration de l’attribution, le compromis n’a pas payé. Revenez à une bannière discrète et concentrez-vous sur la propagation des paramètres. Le protocole de test est décrit dans A/B tester sa bannière CMP.

Mes limites

Cette approche est un compromis, pas une solution parfaite. La détection repose sur les paramètres de l’URL : un clic payant dont le lien a perdu son gclid en route passera en discret. Les campagnes sans auto-tagging ni utm_* ne seront pas reconnues. Enfin, le choix de la CMP reste le point qui conditionne la facilité de mise en œuvre, et c’est là qu’il faut vérifier les capacités réelles avant de commencer.

Questions fréquentes

Une bannière centrale pour les visiteurs payants est-elle discriminatoire ?

Non, si les deux variantes offrent le même choix, avec le même refus au premier niveau et les mêmes finalités. Ce qui change est la forme de la fenêtre, pas les droits de la personne.

Peut-on utiliser la présence d’un gclid pour déposer des cookies publicitaires ?

Non. Ce signal sert à choisir l’affichage de la bannière, pas à lancer une collecte avant consentement. Déposer un cookie publicitaire sur cette base revient à contourner le consentement.

Faut-il informer les visiteurs de cette différence ?

Pas nécessairement dans la bannière, mais la politique de confidentialité doit décrire les finalités de manière identique pour tous. Si votre DPO juge utile de le préciser, ajoutez une phrase sur l’affichage selon la source.

Sources

• CNIL, Cookies et autres traceurs : lignes directrices modificatives et recommandation : exigences de refus, de consentement et de finalités.
• Google, Présentation du mode Consentement : comportement des balises selon le consentement.
• Google, Auto-tagging et paramètre gclid dans GA4 : origine des identifiants de clic utilisés pour la détection.