Pourquoi les balises soumises à functionality_storage ne se déclenchent jamais
La balise ne se déclenche que si tous les signaux requis sont accordés au moment où son déclencheur s’exécute. Une configuration de consentement peut refuser functionality_storage et personalization_storage par défaut, puis ne mettre à jour que les quatre signaux lus par les balises publicitaires et analytiques de Google. Les deux restent refusés même après une acceptation. Associez-les dans votre bannière ou exigez un signal mis à jour.
Commencez par une analyse.
L'analyse gratuite lit le HTML de votre page d'accueil et votre conteneur Tag Manager public, puis liste les balises de suivi qu'elle trouve.
Gratuit · Sans inscription · Vérification du HTML et du GTM public
À quoi servent functionality_storage et personalization_storage ?
La présentation de Consent Mode par Google liste sept types de consentement. Elle décrit la réaction des balises à quatre d’entre eux : ad_storage, analytics_storage, ad_user_data et ad_personalization. Les trois autres sont définis par leur finalité. functionality_storage couvre par exemple les paramètres de langue, personalization_storage les recommandations de vidéos et security_storage l’authentification et la prévention de la fraude.
Ces deux signaux comptent donc généralement pour une raison : quelqu’un les a indiqués sur une balise. Dans Tag Manager, un widget de chat ou un script de recommandations peut porter une vérification de consentement supplémentaire dans Consent Settings. La règle de Google pour cette vérification est stricte. La balise ne se déclenche que si tous les types de sa liste sont accordés au moment où elle est déclenchée.
Pourquoi la balise reste-t-elle bloquée après une acceptation ?
Parce qu’accepter la bannière et mettre à jour le signal sont deux événements distincts. Sur une remise en conformité que nous avons auditée en août 2026, la page refusait six signaux par défaut et laissait security_storage accordé, ce qui est normal. La configuration de la plateforme de consentement mettait ensuite à jour les signaux publicitaires et analytiques de Google, et rien d’autre. Un écouteur de chat soumis à functionality_storage ne s’est jamais exécuté, même pour les visiteurs qui avaient accepté. Rien n’a signalé de panne, car une balise bloquée est précisément ce qu’une configuration de consentement doit produire.
La vérification lit l’état à cet instant.
Quelles configurations en sont la cause ?
- La mise à jour ne nomme que les signaux de Google. C’est le cas ci-dessus, et le premier à écarter.
- Le nom est mal orthographié dans la mise à jour. Dans une mise à jour écrite à la main, une faute de frappe crée un autre type de consentement, et le vrai reste à sa valeur par défaut.
- La bannière n’a pas de catégorie correspondante. Sans choix fonctionnel ou de personnalisation à proposer, une plateforme n’a rien à envoyer pour ce signal, sauf si elle lui associe une autre catégorie.
- Le visiteur n’a pas choisi cette catégorie. Si quelqu’un accepte uniquement l’analytique, la balise doit rester bloquée. La configuration fonctionne alors comme prévu.
- Le déclencheur ne s’est exécuté qu’avant le choix. Nous avons lu le code d’exécution de Tag Manager en novembre 2026 : une vérification échouée met fin à cette tentative, et rien ne la relance quand le consentement change. La balise a besoin d’un déclencheur exécuté après la mise à jour, ce que couvre l’article sur l’événement de mise à jour du consentement. Si elle se déclenche aussi une fois par page, lisez d’abord la note sur les tentatives bloquées.
Vérifiez aussi le défaut inverse. La documentation de l’API des modèles de Google considère comme accordé un type de consentement jamais défini, et le code applique la même logique aux vérifications de consentement supplémentaires. Si votre commande par défaut omet ces deux signaux, une balise soumise à l’un d’eux peut se déclencher avant tout choix du visiteur.
Comment savoir quel est votre cas ?
Acceptez tout dans Tag Assistant
Ouvrez votre site dans Tag Assistant avec un profil de navigateur vierge et cliquez sur Tout accepter. Tout accepter écarte le choix du visiteur comme cause possible.
Lisez le signal après le choix
Dans Summary, sélectionnez le dernier événement Consent et ouvrez l’onglet Consent. Comparez les colonnes de valeur par défaut et de mise à jour pour le signal requis par votre balise. Si l’onglet ne l’affiche pas, exécutez
google_tag_data.ics.entriesdans la console. C’est un objet interne susceptible de changer, mais il montre la valeur par défaut et la mise à jour enregistrées par Google pour chaque type.Identifiez la cause
Refusé par défaut sans mise à jour après Tout accepter signifie que votre plateforme n’envoie pas ce signal. Une mise à jour vers accordé signifie que le signal est correct : passez à la balise. Aucun état signifie que la balise réussit sa vérification au lieu de l’attendre.
Vérifiez la balise et son déclencheur
Ouvrez Consent Settings dans la balise et comparez chaque type requis à l’orthographe de Google, caractère par caractère. Un type mal orthographié n’a aucun état, cette vérification passe donc alors qu’elle devrait retenir la balise. Regardez ensuite quand elle a été bloquée. Une balise bloquée uniquement sur un déclencheur de chargement de page avant le choix a besoin d’un déclencheur exécuté après la mise à jour du consentement.
Corrigez à l’endroit du défaut
Si le signal n’est jamais mis à jour, associez-lui la catégorie de la bannière dans votre plateforme de consentement ou dans la mise à jour envoyée par votre code. Si votre plateforme ne peut pas l’envoyer, exigez un signal qu’elle envoie et qui correspond à ce que le visiteur a accepté.
Testez l’acceptation, le refus et le retour du visiteur
Répétez la vérification de trois façons. La balise doit se déclencher après Tout accepter, rester bloquée après un refus ou lorsque seules d’autres catégories sont choisies, puis se déclencher à nouveau quand le même visiteur revient.
Le guide Tag Assistant de Google détaille l’onglet Consent. Si vous hésitez encore sur ce qu’un script doit attendre, consultez la catégorie de consentement d’un script.
Une seule catégorie de la bannière doit-elle piloter les deux signaux ?
Oui. Certaines plateformes envoient les deux depuis une seule catégorie fonctionnelle, d’autres les gardent séparés. Les deux approches conviennent si le texte de la bannière décrit ce que font les balises. L’essentiel est que chaque signal requis par votre conteneur repose sur une catégorie.
Velo les garde séparés. Avec Consent Mode activé, chaque choix envoie les sept types : la catégorie Fonctionnel définit functionality_storage, Personnalisation définit personalization_storage et security_storage reste accordé. Un réglage à surveiller : là où Velo demande avant de stocker quoi que ce soit, une catégorie masquée dans la bannière ne peut pas être accordée, et son signal reste donc refusé même après Tout accepter. Vérifiez votre conteneur avant d’en retirer une. Le guide Consent Mode détaille la configuration.
Questions fréquentes
Les questions que l'on pose sur ce sujet.
Pourquoi ma balise qui attend functionality_storage ne se déclenche-t-elle jamais ?
Une cause fréquente est un signal refusé au départ qui ne reçoit jamais de mise à jour de votre plateforme de consentement. La balise ne se déclenche que si tous les types requis sont accordés au moment où son déclencheur s’exécute : elle reste donc bloquée même après une acceptation. Acceptez tout dans Tag Assistant, ouvrez le dernier événement Consent et vérifiez si le signal a changé.
Les balises Google utilisent-elles functionality_storage ou personalization_storage ?
La présentation de Consent Mode par Google définit les deux, mais ne décrit la réaction des balises qu’à ad_storage, analytics_storage, ad_user_data et ad_personalization. Ces deux signaux comptent lorsqu’une balise de votre conteneur les indique comme type de consentement requis.
Que se passe-t-il si functionality_storage n’a pas d’état par défaut ?
Elle réussit. La documentation des modèles de Google considère comme accordé un type de consentement jamais défini, et le code de Tag Manager que nous avons lu en novembre 2026 fait de même pour les vérifications de consentement supplémentaires. Une balise soumise à un signal sans état peut se déclencher avant le choix du visiteur.
Une balise bloquée se déclenche-t-elle seule quand le visiteur accepte ?
Non. La vérification est lue quand le déclencheur s’exécute et, dans le code de Tag Manager que nous avons lu en novembre 2026, une balise bloquée n’est pas relancée quand le consentement change. Il lui faut un déclencheur exécuté après la mise à jour du consentement, comme l’événement de consentement de votre plateforme.
functionality_storage doit-il être accordé par défaut ?
Uniquement lorsque le stockage est strictement nécessaire à une demande du visiteur. Selon les règles ePrivacy de l’UE, le reste du stockage attend le consentement. Un refus par défaut suivi d’une vraie mise à jour est donc la configuration sûre dans l’UE. Le Royaume-Uni a désormais ses propres exceptions, dont une pour adapter un site aux préférences du visiteur : consultez les recommandations de l’ICO pour le trafic britannique.
© 2026 par
