Comment ajouter une bannière de cookies à un site Webflow

Tous les articles

Pour ajouter une bannière de cookies à un site Webflow, collez le script de votre plateforme de consentement dans Site settings, Custom code, Head code, au-dessus de tous les autres scripts de suivi, puis publiez. Videz d'abord les champs natifs Google Analytics et Meta Pixel sous Apps and Integrations : tout ce qui s'y trouve se charge hors de votre gestionnaire de balises, là où aucune barrière de consentement ne l'atteint.

Webflow charge le suivi depuis deux endroits, et votre bannière n'en gouverne qu'un

Les guides sur cette question s'arrêtent presque tous au même endroit : inscrivez-vous auprès d'un outil de consentement, collez l'extrait dans le head, publiez. C'est exact, mais ce n'est pas ce qui détermine si la configuration tient. Sur un site Webflow, le suivi entre dans la page par deux endroits indépendants, et une bannière n'en gouverne qu'un.

Site settings, Custom code est l'endroit que vous contrôlez. Valeurs par défaut, bannière et conteneur se trouvent tous dans le champ Head code, dans l'ordre où vous les placez, et chaque balise déclenchée par le conteneur peut être soumise à une condition de consentement.

Site settings, Apps and Integrations est l'endroit dont on oublie qu'on s'en est servi. Collez-y un identifiant de mesure GA4 et Webflow injecte Google Analytics sur chaque page à votre place ; collez un identifiant Meta Pixel et il fait de même pour le pixel. Aucun des deux ne passe par votre conteneur, donc rien de ce que vous y configurez ne les affecte. Conditionner votre balise GA4 ne change rien tant qu'un identifiant de mesure reste dans ce champ.

Les deux champs ne se comportent même pas de la même façon. Le champ Meta Pixel propose une option Delay for cookie consent qui retient le pixel jusqu'à ce que le consentement soit enregistré, et la documentation de Webflow précise explicitement que l'activer exige malgré tout une bannière de votre côté. Le champ Google Analytics n'a pas d'équivalent : l'un peut être mis en attente, l'autre non.

Vider ces champs modifie ce que GA4 comptabilise : établissez donc d'abord une référence. Notez une semaine de sessions GA4 à côté d'un autre décompte fiable pour les mêmes jours, comme les requêtes CDN ou les commandes. Une fois la bannière en ligne, le taux d'acceptation dans votre outil de consentement montre quelle part de l'écart tient au consentement. Cette part varie selon la région, l'audience et le design de la bannière : mesurez la vôtre plutôt que d'emprunter un chiffre.

Comment configurer une bannière de cookies dans Webflow ?

1. Videz d'abord les champs de suivi natifs

   Ouvrez Site settings, Apps and Integrations. Si un identifiant de mesure GA4 ou un identifiant Meta Pixel s'y trouve, Webflow injecte lui-même cette balise sur chaque page, hors de votre conteneur, là où aucune condition de consentement posée sur vos balises ne l'atteint. Videz ces champs et chargez les deux via le conteneur. Laisser l'un d'eux en place alors que la même balise tourne aussi dans le conteneur provoque un double comptage en plus d'une fuite.

2. Placez les valeurs par défaut refusées au-dessus de tout le reste

   Tout en haut de Site settings, Custom code, Head code, définissez une valeur par défaut Consent Mode qui refuse ad_storage, analytics_storage, ad_user_data et ad_personalization. Elle doit se trouver au-dessus de la bannière et du conteneur : une valeur par défaut qui arrive après le déclenchement d'une balise est une correction tardive, pas une valeur par défaut. Placée dans son propre petit script, elle tient aussi bon si la requête de la bannière est lente ou échoue.

3. Ajoutez la bannière, puis le conteneur

   Les deux vont dans le même champ Head code, la bannière en premier pour qu'elle enregistre son état avant que le conteneur ne soit interprété. Le champ accepte jusqu'à 50,000 caractères, largement assez pour les trois ensemble : rien ne justifie donc de déplacer une longue configuration ailleurs pour gagner de la place.

4. Placez le noscript du conteneur dans le Footer code

   Webflow vous donne un emplacement dans le head et un autre avant la balise body fermante, mais aucun juste après la balise body ouvrante, là où la documentation place normalement le fragment noscript d'un conteneur. Le Footer code est l'emplacement qui fonctionne ici, et il compte bien moins que l'extrait du head.

5. Traitez les scripts déjà présents dans le head

   Tout script de fournisseur collé directement dans le Head code se charge de lui-même et ne peut pas être conditionné par un gestionnaire de balises qui ne l'a jamais pris en charge. Faites l'inventaire de ce champ avant de déclarer le site terminé. Chaque script doit soit passer dans le conteneur sous forme de balise conditionnée, soit être encapsulé pour que la couche de consentement puisse le retenir, soit être défendu comme strictement nécessaire : une question d'éligibilité à trancher script par script.

6. Publiez, puis vérifiez sur le domaine en production

   Le code personnalisé apparaît dans l'aperçu mais n'est mis en ligne qu'à la publication : une vérification dans le Designer ne prouve donc rien. Publiez, chargez le domaine en production dans un profil vierge, et ne cliquez sur rien : aucun cookie d'analyse ou de publicité déposé, aucune requête vers vos fournisseurs. Acceptez ensuite et vérifiez que tout apparaît. Testez le domaine en production, pas seulement le sous-domaine de staging webflow.io, car les deux peuvent porter des états publiés différents.

La séquence complète d'avant mise en ligne, qui vaut la peine d'être déroulée une bonne fois, se trouve dans comment tester une bannière de cookies avant la mise en ligne.

Qu'est-ce qui piège les gens sur Webflow ?

L'aperçu n'est pas la version publiée. La documentation de Webflow le dit clairement : les effets du code personnalisé apparaissent dans l'aperçu, mais ne sont mis en ligne qu'une fois le site publié. Chaque vérification du consentement doit se faire sur le site publié.

Les Components dupliquent tout ce que vous y mettez. Un extrait de code placé dans un Component utilisé dans un en-tête global est livré sur chaque page qui utilise ce Component. Deux conteneurs sur une page forment un problème à part entière, qui ressemble à un défaut de consentement bien avant que quiconque ne soupçonne l'en-tête. Les extraits valables pour tout le site ont leur place dans Site settings.

Le code d'une page s'exécute après le code global du site. Le code personnalisé d'une page individuelle apparaît après le code global dans le balisage. C'est le bon ordre pour les valeurs par défaut, et cela signifie qu'un script de valeurs par défaut ajouté à une seule page ne peut pas la sauver : le conteneur global a déjà été interprété plus haut.

La bannière documentée pour le Pixel verrouille un pixel, ce n'est pas une couche de consentement. Webflow documente la création à la main d'une bannière pour son Meta Pixel natif : des Interactions pour l'afficher et la masquer, plus un script dans le Footer code qui accorde le consentement au pixel au clic. Le dispositif se limite à ce pixel, et la documentation le dit. Lu comme une couche de consentement générale, il ne suffit pas : il accorde le consentement mais n'offre aucun moyen de le retirer, le bouton de refus se contente de masquer la bannière, et il ne gouverne rien d'autre sur la page. Pouvoir retirer son consentement aussi facilement qu'on l'a donné est une exigence de l'article 7 du RGPD : c'est donc un point de départ, pas une ligne d'arrivée.

Quand la bannière est en place et que des cookies apparaissent encore

Passez les sources en revue dans l'ordre où elles s'avèrent le plus souvent être la réponse. D'abord les champs Apps and Integrations, que rien dans votre conteneur ne révèle. Ensuite, les scripts collés directement dans le Head code. Puis un extrait de code dupliqué via un Component. Seulement alors, ouvrez le conteneur.

Une quatrième source n'est pas du fait de Webflow : une balise correctement conditionnée peut tout de même charger en aval le pixel d'un autre fournisseur, un cas traité ici. La séquence complète d'avant mise en ligne se trouve dans comment tester une bannière de cookies avant la mise en ligne.

Une question de placement revient sur presque tous les projets Webflow : dans le head ou dans le gestionnaire de balises ? Les deux, chacun pour son rôle. Gardez dans le Head code un petit script qui fixe les valeurs par défaut sur refusé, pour que l'état refusé existe avant que quoi que ce soit ne se charge, et placez l'outil lui-même là où les personnes qui gèrent les balises peuvent y accéder. Un outil présent uniquement dans le head dont la requête échoue laisse le conteneur se déclencher sans aucune valeur par défaut enregistrée : l'échec se produit alors dans le mauvais sens.

Velo s'installe sur Webflow sous la forme d'un seul extrait de code dans ce champ Head code : valeurs par défaut, bannière et état du consentement que lit le conteneur, dans le bon ordre par construction.