Le problème : des balises qui se déclenchent trop tôt

Une bannière de consentement ne fonctionne que si les balises qui se trouvent derrière respectent le choix du visiteur. L’échec le plus courant est simple : la bannière s’affiche, mais les scripts d’analytique et de publicité sont déjà chargés et ont posé des identifiants avant que quiconque n’ait cliqué. Y remédier suppose de bloquer les scripts jusqu’au consentement. Il existe trois façons pratiques d’y parvenir.

Méthode 1 : réécrire le type du script

Les navigateurs n’exécutent un élément script que si son type est un type JavaScript. Si vous changez le type en text/plain, le navigateur ignore le script. Vous ajoutez ensuite un attribut data qui indique à quelle catégorie de consentement le script appartient :

• Remplacez type="text/javascript" par type="text/plain".
• Ajoutez un attribut tel que data-category="analytics".
• Lorsque le visiteur consent à cette catégorie, un petit chargeur rétablit le type et insère le script afin qu’il s’exécute.

Idéal pour : une poignée de scripts connus, en ligne ou externes, dans vos modèles. Attention : les scripts injectés par d’autres scripts ne passent jamais par vos modèles et ne sont donc jamais réécrits.

Méthode 2 : conditionner les balises dans un gestionnaire de balises

Si vos balises se trouvent dans Google Tag Manager ou un outil similaire, vous pouvez laisser le conteneur sur la page et contrôler le déclenchement avec des déclencheurs sensibles au consentement. Chaque balise reçoit une exigence de consentement, et le gestionnaire de balises ne la déclenche que lorsque l’état de consentement correspondant est accordé. Le grand avantage est le contrôle centralisé : le marketing peut ajouter des balises sans toucher aux modèles, et la règle accompagne la balise.

Idéal pour : les sites avec de nombreuses balises marketing. Attention : les scripts codés en dur situés hors du conteneur et les balises HTML personnalisées qui chargent elles-mêmes d’autres scripts.

Méthode 3 : charger les scripts dynamiquement au consentement

Ici, vous retirez entièrement les balises script de la page et vous écrivez une fonction qui ne les injecte qu’après un événement de consentement. C’est l’option la plus propre pour les applications monopages et pour les développeurs qui veulent un contrôle total :

1. Écoutez le callback de consentement de votre CMP.
2. Vérifiez quelles catégories ont été accordées.
3. Créez un élément script, définissez sa source et ajoutez-le au document.
4. Exécutez tout code d’initialisation dans le gestionnaire de chargement du script.

Idéal pour : les applications modernes avec une étape de build. Attention : oublier de gérer le visiteur qui revient, dont le choix enregistré doit déclencher le chargement au chargement de la page sans nouveau clic.

Gérer le retrait du consentement

Bloquer avant le consentement n’est que la moitié du travail. Si un visiteur retire ensuite son consentement, cessez d’appeler les outils et assurez-vous qu’ils ne continuent pas à lire ou écrire des identifiants. Retirer un script de la page ne supprime pas le code déjà en mémoire ; un rechargement après le retrait est donc souvent l’approche fiable la plus simple.

Laquelle choisir ?

• Peu de scripts, modèles rendus côté serveur : méthode 1.
• Nombreuses balises marketing, modifiées par des non-développeurs : méthode 2.
• Application monopage ou front-end sur mesure : méthode 3.
• Les parcs mixtes combinent souvent deux d’entre elles. Veillez simplement qu’aucune balise ne soit couverte par aucune.

Comment le tester

1. Ouvrez une fenêtre privée avec le cache vidé.
2. Ouvrez les outils de développement du navigateur sur les onglets Network et Application avant de charger la page.
3. Chargez la page sans toucher à la bannière. Vérifiez qu’aucune requête d’analytique ou de publicité n’est envoyée et qu’aucun cookie ni élément de stockage associé n’apparaît.
4. Acceptez une seule catégorie et vérifiez que seuls les scripts correspondants se chargent.
5. Refusez tout, rechargez et répétez la première vérification.
6. Retirez le consentement et vérifiez le comportement décrit ci-dessus.

Où se situe FlexyConsent

FlexyConsent prend en charge IAB TCF 2.4 et Google Consent Mode v2, et est une CMP certifiée par Google (CMP ID 317). Quelle que soit la méthode de blocage choisie, le rôle de la bannière est de donner à votre code un signal clair de ce que le visiteur a choisi. Votre rôle est de veiller à ce que chaque script le respecte.

Points clés à retenir

• Les scripts qui se chargent avant le choix du visiteur ruinent l’objectif de la bannière.
• La réécriture du type, les déclencheurs de gestionnaire de balises et le chargement dynamique conviennent chacun à un type de site différent.
• Les scripts injectés par d’autres scripts sont la fuite la plus fréquente.
• Gérez les visiteurs qui reviennent et le retrait du consentement, pas seulement la première visite.
• Testez dans une fenêtre privée propre, outils de développement ouverts, avant de toucher à la bannière.