Dépannage FlowConsent
Les cinq problèmes FlowConsent les plus fréquents et leurs corrections : bannière absente, tag Google malgré le refus, verdicts inattendus, scan en erreur.
La plupart des problèmes FlowConsent relèvent de cinq schémas, et chacun a une vérification intégrée qui l'identifie : l'assistant d'installation pour les soucis de snippet, l'erreur console et la télémétrie pour la course Consent Mode, le scan de conformité pour tout ce qui fuit. Suivez le symptôme qui correspond au vôtre.
La bannière ne s'affiche pas
Presque toujours le snippet : absent de la page, ou portant le mauvais code licence. Lancez l'assistant d'installation (Builder → Intégration) : il récupère votre page en ligne côté serveur et constate exactement cela — chargeur trouvé ou non, et si le code licence du snippet correspond à votre bannière. Les causes classiques derrière ses constats :
- le snippet a été collé mais le site n'a jamais été publié (Webflow et la plupart des site builders n'embarquent le custom code qu'à la publication) ;
- le snippet vient d'une autre bannière ou d'un autre workspace — le code licence dans l'URL ne correspond pas ;
- le snippet est dans le body ou un widget de pied de page au lieu du
<head>.
Un tag Google part malgré le refus
C'est la course du dataLayer : un gtag('config') est entré dans le dataLayer avant les défauts de consentement, Google l'a donc traité sans aucune restriction — les cookies sont posés quoi que fasse la bannière, et aucune CMP ne peut l'empêcher après coup.
Deux vérifications l'identifient immédiatement :
- la console du navigateur affiche une erreur FlowConsent nommant les identifiants de tags entrés avant le consent default (la bannière le remonte aussi en télémétrie
ConsentDefaultRaceLost) ; - l'assistant d'installation signale « tag Google avant le stub », et sur Webflow pointe spécifiquement un tag injecté par les réglages du site.
La correction : retirer le tag du canal qui l'injecte trop tôt — sur Webflow, le Measurement ID GA de Site settings → Apps & Integrations — et déclarer le service dans Builder → Services. Puis garder le stub Consent Mode en premier dans votre <head>. Voir le guide Webflow.
Le scan rend « Violations » sans que vous sachiez pourquoi
Le verdict liste les domaines traceurs contactés et les services identifiés. Quand il vous surprend, le tag passe en général par un canal que la bannière ne voit pas au moment de l'injection :
- une intégration du site builder ou de l'hébergeur (réglages Webflow, plugin WordPress) qui charge le tag nativement ;
- un conteneur de tag manager qui déclenche ses tags sans tenir compte du consentement ;
- un script codé en dur dans un gabarit par un développeur passé.
Ouvrez le rapport de preuve du scan : les exemples d'URL disent où chaque requête est partie, ce qui identifie en général qui l'a injectée. La bannière bloque les tags par motif d'URL quel que soit le canal qui les injecte — mais seulement s'ils entrent dans la page comme des scripts qu'elle peut intercepter avant exécution.
La page Conformité alerte sur un cookie non déclaré
Le dernier scan a observé des cookies que votre bannière ne déclare pas — ni via un service actif, ni dans vos cookies personnalisés. Typiquement des cookies first-party maison (attribution, session de panier…) qu'aucun catalogue de services ne peut connaître ; seul un scan les découvre.
L'alerte propose une déclaration en un clic dans les cookies personnalisés de la bannière. Deux suites restent à votre charge : rédiger la finalité du cookie (l'alerte ne peut pas la deviner), et republier la bannière pour que la liste publique des cookies la reflète.
Le scan rend « erreur »
Un verdict error signifie que le scan n'a pas pu aboutir — le plus souvent un timeout sur une page lente ou lourde — et aucune conclusion ne peut en être tirée : ce n'est ni conforme ni une violation, et cela ne déclenche jamais d'alerte de régression.