Guide d'intégration du consentement aux cookies Webflow : bannière native, code personnalisé et CMP tiers pour 2026
Webflow occupe une position singulière dans l'écosystème des constructeurs de sites web. Il est plus proche d'un outil de design que d'un CMS, plus proche d'un CMS que d'une plateforme d'applications hébergées, et de plus en plus la plateforme que les agences choisissent quand elles veulent des sites marketing entièrement sur mesure sans la charge technique de gérer un stack Next.js ou Drupal. Webflow fournit une bannière native Cookie Consent avec des paramètres par défaut raisonnables, expose l'injection de Custom Code au niveau du site et de la page, s'intègre au HTML intégré et offre aux opérateurs un modèle CMS Collections. Un site Webflow qui a activé la bannière native et s'est arrêté là est rarement totalement conforme ; un site qui a relié la bannière native à un CMP tiers, bloqué son Custom Code et audité ses scripts intégrés est l'une des implémentations les plus propres qu'une agence peut livrer en 2026.
Ce que fait la bannière Cookie Consent native de Webflow et ses limites
Webflow a ajouté la fonctionnalité native Cookie Consent en 2022 et l'a améliorée depuis. La fonctionnalité prend en charge trois catégories de cookies prédéfinies — Essential, Marketing et Personalization — expose une interface de bannière configurable accessible via les paramètres du projet et lie le blocage de Google Analytics au choix de l'utilisateur. La bannière enregistre le consentement de l'utilisateur dans un cookie first-party et expose l'état du consentement aux outils intégrés de Webflow.
Ce que la bannière native de Webflow ne fait pas — et où la plupart des déploiements construits par des agences sont insuffisants — c'est bloquer le Custom Code que les opérateurs ajoutent couramment pour les analyses, les pixels marketing, les widgets de chat et les vidéos intégrées. Les points d'injection Custom Code s'exécutent avant que la bannière ait été rendue, ce qui signifie que tout script tiers ajouté via ces points s'exécute avant qu'il n'existe de décision de consentement. Les agences ajoutent fréquemment Hotjar, Facebook Pixel, un script CRM tiers ou un embed Calendly via Custom Code en supposant que la bannière native gère le blocage. Elle ne le fait pas.
Le paramètre par défaut opt-in vs. consentement implicite
La bannière native expose trois styles de consentement. Le style de consentement implicite a été la source de constats répétés des régulateurs contre les sites hébergés sur Webflow dans l'EEE. Le style opt-in est la valeur par défaut correcte pour tout déploiement ciblant l'EEE, le Royaume-Uni, le Brésil, la Suisse ou toute autre juridiction ayant importé la norme GDPR. L'opérateur doit sélectionner opt-in, configurer les catégories comme étant désactivées par défaut et vérifier en prévisualisation que le bouton de refus est au moins aussi visible que le bouton d'acceptation.
Blocage du Custom Code : le travail que la bannière native ne fait pas
Le schéma d'intégration qui fonctionne sur Webflow comporte trois parties. Premièrement, configurer correctement la bannière native. Deuxièmement, envelopper chaque script Custom Code dans une vérification de consentement avant son exécution. Troisièmement, décider si la bannière native est suffisante ou si un CMP tiers doit la remplacer pour la traçabilité des audits et la configurabilité par fournisseur.
Le schéma de blocage le plus simple consiste à lire le cookie de consentement de Webflow ou l'état du consentement depuis le hook JavaScript exposé par la plateforme et à exécuter conditionnellement la logique tierce. Pour les scripts ajoutés dans la section Footer Code, le schéma consiste à envelopper le snippet dans un écouteur d'événements qui se déclenche sur l'événement de changement de consentement de Webflow. Pour les scripts de la section Head Code — où vivent la plupart des snippets d'analyse et de pixels — le schéma consiste à charger le snippet comme espace réservé, la requête tierce réelle étant différée jusqu'à ce que la vérification du consentement réussisse.
Le schéma d'espace réservé pour les scripts tiers
Le schéma qui fonctionne dans les intégrations Webflow les plus courantes est l'espace réservé <script type="text/plain">. Le script tiers est inclus dans le balisage de la page mais avec l'attribut type défini sur une valeur que le navigateur n'exécutera pas. Un petit script bootstrap — ajouté une fois dans la section Footer Code — écoute l'événement de changement de consentement de Webflow, identifie les scripts à espace réservé correspondant à la catégorie accordée et réécrit leur attribut type en text/javascript pour qu'ils s'exécutent. Le schéma est le même que celui utilisé par le module EU Cookie Compliance de Drupal et que Cloudflare Zaraz applique en périphérie.
L'option CMP tiers : quand la bannière native est insuffisante
Pour les sites nécessitant une piste d'audit plus complète, une configuration par fournisseur, une logique multi-juridictions ou une intégration avec IAB TCF, la bannière native est insuffisante et un CMP tiers — Cookiebot, OneTrust, Usercentrics, Iubenda — doit la remplacer. Il faut désactiver la bannière native en premier.
- Intégration Cookiebot — installez le snippet Cookiebot via Custom Code dans la section Head, marquez les scripts gérés par Cookiebot avec des attributs data-cookieconsent et désactivez la bannière native Webflow dans les paramètres du projet.
- Intégration OneTrust — installez le snippet CDN OneTrust, configurez le tableau de bord OneTrust pour lire la structure des catégories de Webflow et désactivez la bannière native.
- Intégration Usercentrics — installez le snippet Usercentrics, configurez les définitions de services dans le tableau de bord Usercentrics qui reflètent l'inventaire réel des balises de l'opérateur et désactivez la bannière native.
- Intégration Iubenda — installez le snippet Iubenda Consent Solution, configurez la politique et la correspondance des catégories et désactivez la bannière native.
CMS Collections de Webflow et contenu rendu dynamiquement
Les CMS Collections de Webflow méritent une attention particulière car elles introduisent une surface de consentement que les pages statiques n'ont pas. Une page de collection intégrant un widget tiers — un embed YouTube dans un article de blog, un feed TikTok sur une page portfolio — hérite des décisions de consentement prises sur la page hôte, mais le contenu intégré ne respecte pas automatiquement ces décisions à moins que l'opérateur n'ait configuré la collection pour rendre l'embed via un espace réservé click-to-load.
Validation et posture d'audit pour 2026
Un déploiement Webflow défendable en 2026 doit passer quatre vérifications techniques. Premièrement, une session de navigateur propre servie depuis une adresse IP de l'EEE doit produire zéro cookie non essentiel avant que la bannière soit actionnée. Deuxièmement, le chemin de refus doit maintenir cet état. Troisièmement, le chemin d'acceptation ne doit produire que les balises auxquelles l'utilisateur a consenti, et le journal de consentement doit contenir l'enregistrement correspondant. Quatrièmement, un retrait doit immédiatement arrêter les déclenchements de balises supplémentaires et propager le désabonnement aux destinataires tiers en aval.
La bannière native enregistre l'état de consentement de l'utilisateur dans un cookie first-party mais ne tient pas de journal d'audit côté serveur interrogeable par identifiant d'utilisateur ou de session. Pour les déploiements nécessitant une piste d'audit plus complète — rapports multi-juridictions, enregistrements de consentement par fournisseur, intégration avec la norme de documentation attendue de l'EDPB — un CMP tiers est la bonne réponse. Un site Webflow qui a délibérément choisi entre les deux voies, bloqué chaque surface Custom Code et traité le schéma d'intégration des collections a transformé la simplicité du constructeur visuel de la plateforme en une partie défendable de la posture de consentement d'une agence plutôt qu'une dette de conformité cachée.