Analyse gratuite À propos Assistance Contact
Adopter Velo

Vous avez déjà un compte ? Se connecter

Que faire si vous recevez une plainte au sujet de votre bannière de cookies

Conformité 26 août 2026· 7 min de lecture
La mascotte Velo parcourt une liste de constats pendant qu'un fantôme lit derrière elle

Tous les articles

Mesurez avant de répondre. Enregistrez ce que votre site fait réellement sur chaque parcours de consentement, dans un profil vierge, puis rapprochez la plainte de ces preuves, point par point : reconnaissez ce qui tient, réfutez ce qui ne tient pas avec la requête ou le cookie qui le contredit, et faites une contre-proposition là où le remède est mauvais. La cause ne figure généralement pas sur la liste.

La console n'est pas une preuve. Les données envoyées, si.

Quand une plainte arrive, le réflexe est de sortir une checklist de conformité. C'est la bonne référence pour ce qu'une bannière doit faire, et les autorités comme les grands fournisseurs de consentement la couvrent bien. Mais elle répond à une autre question que celle qui se pose à vous : non pas à quoi ressemble une bannière conforme, mais ce que votre site a fait à la personne qui s'est plainte.

Le premier geste est donc un enregistrement, pas une revue des réglages. Quatre parcours dans un profil vierge : premier chargement sans aucun clic, acceptation, refus, et visite de retour avec le choix enregistré. Notez les cookies et les domaines de fournisseurs que chacun produit. Dix minutes, et c'est la seule chose ici qui aura du poids plus tard.

Le conteneur sur lequel nous avons travaillé avait un audit indiquant que chaque balise était configurée pour le consentement, sans rien d'oublié. Le même jour, un profil vierge, bannière toujours à l'écran, déposait sept cookies et appelait six domaines de fournisseurs. Aucune des deux affirmations n'était fausse. Elles répondaient à des questions différentes.

Une plainte au sujet d'une bannière de cookies est-elle généralement exacte ?

Une plainte arrive sous forme de liste numérotée, et il est tentant de la dérouler comme un verdict. Lisez-la comme un ensemble d'affirmations, chacune vraie ou fausse, chacune vérifiable dans l'enregistrement que vous venez de faire.

Sur le parc dont s'inspire cet article, la liste comptait huit points numérotés. Trois étaient inexacts : l'affirmation selon laquelle aucune balise ne posait de valeur par défaut à denied était fausse, puisque les valeurs par défaut étaient déjà correctes, et depuis un certain temps ; trois des balises citées comme non filtrées l'étaient en fait déjà ; et un point visait carrément la mauvaise balise. Quatre étaient exacts et ont été reconnus sans discussion. Un était juste sur le problème mais faux sur le remède, et appelait une contre-proposition plutôt qu'un oui ou un non.

La répartition compte plus que chaque point pris isolément. Reconnaître quelque chose de faux est aussi dommageable que nier quelque chose de vrai : cela vous engage sur une modification qui ne corrige rien et affaiblit toutes les autres affirmations de la réponse. Les deux cas appellent le même traitement : des preuves jointes à la réponse.

Vérifier une liste de constats de cette façon suit une procédure propre, la même que la liste arrive avec une plainte ou avec un audit : comment savoir si une balise signalée dépose vraiment des cookies avant le consentement.

Huit points vérifiés. La cause n’y figurait pas.

Ce que la liste a donné

  • 3 inexacts une fois mesurés
  • 4 exacts, reconnus
  • 1 bon problème, mauvais remède

Chacun tranché par une requête ou un cookie.

Absent de la liste

  • Une balise de fournisseur qui en charge deux autres
  • Des scripts codés en dur dans l'en-tête du site
  • Hors de portée du conteneur

D'où venait réellement la fuite.

L'audit disait que chaque balise était configurée. Vrai, mais hors sujet. Le même jour, profil vierge, bannière toujours affichée : 7 cookies déposés, 6 domaines de fournisseurs appelés.

Comment une plainte a été confrontée à un enregistrement en conditions réelles. Les chiffres proviennent d'une seule mise en conformité anonymisée et illustrent la démarche, pas un benchmark.

La cause ne figure généralement pas sur la liste

Un plaignant rapporte ce qui est visible de l'extérieur : des cookies présents, des fournisseurs appelés, une bannière qui n'a arrêté ni les uns ni les autres. Ce qui les a chargés, c'est à vous de le trouver.

Deux endroits expliquent l'essentiel, et aucun n'apparaît dans un audit du gestionnaire de balises. Le premier est une balise de fournisseur qui charge d'autres fournisseurs. Ici, la balise d'une plateforme marketing faisait venir deux pixels publicitaires à elle : filtrer cette seule balise a arrêté les trois, ce qui a renversé une conclusion antérieure selon laquelle le conteneur seul ne pouvait pas régler la plainte. Cherchez-la en premier : nous avons traité le cas le plus souvent remarqué dans pourquoi le pixel Facebook se charge encore quand vos balises sont bloquées.

Le second est l'en-tête de votre propre site. Les scripts collés dans le modèle se chargent avant que le conteneur puisse avoir son mot à dire, et aucun réglage de consentement ne les atteint, par construction et non par erreur de configuration. Trois subsistaient ici une fois le travail sur le conteneur terminé, et il fallait un développeur plutôt qu'un accès au gestionnaire de balises.

Comment rédiger une réponse défendable à une plainte ?

L'ordre compte : chaque étape décide de ce que la suivante peut affirmer.

  1. Enregistrez les quatre parcours de consentement avant d'écrire quoi que ce soit

    Fenêtre privée, panneaux réseau et stockage ouverts, sur une page que vous n'avez pas visitée. Capturez le premier chargement sans aucun clic, puis l'acceptation, puis le refus, puis une visite de retour avec le choix enregistré. Conservez les cookies et les domaines de fournisseurs de chacun.

  2. Rapprochez la plainte de cet enregistrement, point par point

    Marquez chaque point numéroté comme exact, inexact ou partiellement exact, avec la requête ou le cookie précis qui tranche. Ne répondez pas depuis la console du gestionnaire de balises : elle montre ce qui est configuré, et une plainte porte sur ce qui s'est passé.

  3. Cherchez la cause qui n'est pas sur la liste

    Les points qui vous ont été envoyés décrivent ce qui était visible de l'extérieur. Demandez-vous séparément ce qui charge ces cookies : si une balise de fournisseur en charge d'autres, et ce qui est codé en dur dans l'en-tête de votre propre site.

  4. Répartissez les correctifs selon leur responsable

    Classez chaque problème confirmé dans l'une de trois catégories : corrigeable dans le conteneur, uniquement dans le code du site, ou uniquement dans le portail d'un fournisseur. Elles ont des responsables et des délais différents, et une réponse qui promet une correction dans le conteneur pour un script de l'en-tête du site ne survivra pas à la relance.

  5. Revérifiez les quatre parcours, pas la vue d'audit

    Répétez l'étape un sur la version publiée et comparez les enregistrements. Vérifiez qu'un fichier de conteneur en cache ne vous induit pas en erreur. Il est servi avec un cache court, et notre propre premier test de vérification lisait ici la version précédente, sans que rien ne le signale. Contrôlez la version du fichier qui vous est servi avant de croire à un échec.

  6. Répondez avec la mesure, pas avec des assurances

    Indiquez ce que vous avez mesuré, ce que vous avez trouvé, ce qui a été corrigé, et ce qui reste à faire, avec une date et un responsable. Les points que vous contestez s'accompagnent de preuves, pas d'un démenti sec.

Deux choses à avoir avant qu'une plainte arrive

Un enregistrement de référence, réalisé quand tout va bien, transforme tout ce qui précède en comparaison plutôt qu'en enquête : tester une bannière de cookies avant la mise en ligne est la même procédure, à un moment plus calme. Et l'enregistrement du consentement. Une bannière prouve ce qui a été proposé, pas ce que quelqu'un a choisi, et l'article 7, paragraphe 1, du RGPD vous demande de démontrer qu'un visiteur a consenti. Seul l'enregistrement y répond.

Notre position sur le sujet

Nous développons une plateforme de consentement : lisez ceci en gardant cela à l'esprit. Nous considérons les données réellement envoyées comme la source de vérité, parce que c'est aussi là que se voient les dégâts sur la mesure. Les choix de consentement masquent une partie de vos sessions à l'outil d'analyse, et dans quelle proportion dépend de votre région, de votre audience et du design de votre bannière. Le taux de consentement de votre CMP est le moyen le plus rapide de l'estimer, et la comparaison entre les sessions GA4 et les journaux de requêtes de votre serveur ou de votre CDN en est le contrôle indépendant. Une configuration correcte ne fait pas revenir dans vos rapports les visiteurs qui ont refusé. Elle fait correspondre ce que vous mesurez à ce que les visiteurs ont choisi.

La version qui dérange, c'est qu'une bannière peut être bien choisie, correctement installée et pourtant fuir, parce que l'essentiel de ce qui fuit n'a jamais été à la portée de l'outil de consentement. Ce trou existe à tous les niveaux de prix, y compris le nôtre.

Questions fréquentes

Les questions que l'on pose sur ce sujet.

Que faire si vous recevez une plainte au sujet de votre bannière de cookies ?

Mesurez avant de répondre. Dans une fenêtre privée, panneau réseau ouvert, enregistrez ce qui se passe sur quatre parcours : premier chargement sans aucun choix, acceptation, refus, et visite de retour avec un choix enregistré. Rapprochez ensuite la plainte, point par point, de cet enregistrement. Ce n'est qu'alors que vous savez quels points tiennent, lesquels ne tiennent pas, et ce qui cause réellement le problème.

Une plainte au sujet d'une bannière de cookies est-elle généralement exacte ?

En partie. Sur la mise en conformité dont s'inspire cet article, trois des points numérotés se sont révélés faux une fois confrontés aux données réellement envoyées plutôt qu'à la console, quatre étaient exacts et ont été reconnus, et un appelait une contre-proposition. Traitez la liste comme des affirmations à tester, pas comme un verdict : reconnaître un point faux vous engage sur une modification qui ne corrige rien.

D'où viennent les scripts si le gestionnaire de balises affirme que tout est filtré ?

Deux endroits que le gestionnaire de balises ne voit pas. L'en-tête de votre propre site, où des scripts codés en dur se chargent entièrement hors du conteneur. Et une balise de fournisseur qui charge d'autres fournisseurs : ici, la balise d'une plateforme marketing faisait venir deux pixels publicitaires à elle, si bien que filtrer cette seule balise a arrêté les trois. Un audit du conteneur rend compte du conteneur, et aucun des deux n'y figure.

Peut-on se fier à l'audit de consentement du gestionnaire de balises ?

Non, et c'est précisément le piège. Sur le conteneur en question, l'audit intégré indiquait que chaque balise était configurée pour le consentement, alors qu'un profil vierge, bannière toujours affichée, déposait sept cookies et appelait six domaines de fournisseurs. L'audit décrit la configuration. Une plainte porte sur le comportement, et seul un enregistrement le montre.

Comment prouver que votre bannière de cookies a été corrigée ?

Enregistrez de nouveau les quatre mêmes parcours de consentement après la publication, et gardez l'avant et l'après côte à côte. C'est cette paire qui rend une réponse défendable : elle nomme les cookies et les appels de fournisseurs qui existaient avant et montre leur absence ensuite. Méfiez-vous d'un fichier de conteneur périmé en cache : il est servi avec un cache court, et un test sur la version précédente signale un échec qui n'existe pas.