Puis-je déplacer un script dans Google Tag Manager pour le soumettre au consentement ?
Oui pour la plupart des scripts de fournisseurs, et Google Tag Manager vous offre un vrai verrou : la balise ne s'exécute que lorsque son déclencheur se lance et que ses paramètres de consentement l'autorisent. L'exception concerne tout script qui doit agir avant le rendu de la page ou voir la toute première requête, car un conteneur ne peut pas le lancer assez tôt.
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
Qu'est-ce que le passage d'un script dans Google Tag Manager change ?
Un script codé en dur dans le head s'exécute dès que le parseur l'atteint. Aucun verrou ne se trouve devant lui, et c'est pourquoi un extrait de fournisseur placé dans le head est la raison la plus fréquente pour laquelle un site dépose des cookies avant que le visiteur ait accepté quoi que ce soit.
Déplacez-le dans un conteneur et il cesse d'être du balisage pour devenir une balise. Il s'exécute désormais quand un déclencheur le lance et quand ses paramètres de consentement l'autorisent. C'est exactement ce que vous vouliez. C'est aussi la partie que l'on sous-estime : vous n'avez pas seulement ajouté un verrou, vous avez changé le moment où le script s'exécute. Pour la plupart des fournisseurs, c'est sans conséquence. Pour quelques-uns, c'est tout le problème.
Quels scripts ne peuvent pas passer dans le conteneur ?
Trois profils échouent au déplacement, et pour la même raison de fond. Un conteneur se charge et s'évalue alors que la page a déjà commencé, et ces scripts doivent agir avant.
- Tout ce qui doit s'exécuter avant le rendu. Les scripts de personnalisation et d'A/B testing réécrivent la page avant que le visiteur ne la voie. Derrière un déclencheur, ils arrivent après le premier affichage : le visiteur voit le contenu d'origine apparaître, puis changer. Ce scintillement est précisément ce que le script devait empêcher : le déplacer ne le conditionne pas, cela le casse.
- Tout ce qui doit voir la première requête. Certains outils anti-bots et antifraude sont conçus pour observer le tout premier instant d'une visite. Lancés depuis un conteneur, ils voient une page déjà ouverte depuis un moment, et leur verdict change en conséquence.
- La couche de consentement elle-même. Vous ne pouvez pas soumettre au consentement ce qui recueille le consentement. La bannière doit pouvoir s'exécuter avant qu'une décision existe : c'est pourquoi elle a sa place dans le head, et pourquoi c'est l'un des rares scripts réellement strictement nécessaires.
Quand un script ne peut pas être déplacé, la réponse honnête est de le laisser là où il est et de le conditionner sur place : votre outil de consentement le bloque dans la page, par catégorie, au lieu qu'un conteneur le retienne. Même résultat, mécanisme différent, et la question de la catégorie est traitée dans dans quelle catégorie de consentement ranger un script.
Le critère, c'est le moment, pas la catégorie.
- Doit s'exécuter avant le rendu : personnalisation, A/B testing
- Doit voir la première requête : certains outils anti-bots et antifraude
- La couche de consentement elle-même
- Mesure d'audience
- Pixels publicitaires et de retargeting
- Enregistrement de sessions
- Widgets de chat et d'assistance
- Lecteurs intégrés et widgets sociaux
Un conteneur ne peut rien lancer assez tôt pour devancer le premier affichage.
Comment déplacer un script sans en laisser une copie derrière soi ?
Retirez-le d'abord du head
Pas en dernier. Un script présent aux deux endroits s'exécute deux fois, et la copie du head s'exécute sans verrou : la balise que vous venez de créer dans le conteneur ne prouve donc rien. C'est la façon la plus courante dont une migration a l'air terminée sans rien changer.
Recréez-le sous forme de balise
Une balise Custom HTML contenant l'extrait du fournisseur, ou le modèle propre au fournisseur si la galerie en propose un. Préférez le modèle : il expose les paramètres du fournisseur sous forme de vrais champs et arrive généralement avec ses paramètres de consentement déjà déclarés.
Définissez les paramètres de consentement sur la balise, pas seulement sur le déclencheur
Dans une balise web, ces réglages se trouvent sous Advanced Settings, puis Consent Settings. Vous y exigez un consentement supplémentaire pour que la balise se déclenche, et vous indiquez les types de consentement dont elle dépend. Google documente ce panneau dans sa présentation du consentement dans Tag Manager. Le déclencheur est l'autre contrôle. Il vous faut les deux, pour la raison expliquée dans la section suivante.
Publiez, puis testez sur la page en ligne
Le mode aperçu tourne avec le câblage de débogage du conteneur et, très souvent, avec un état de consentement que vous avez vous-même validé une minute plus tôt. Il est utile pour confirmer qu'une balise existe. Il ne prouve rien sur ce que reçoit un vrai visiteur.
Vérifiez les deux chemins dans la page, pas dans le conteneur
Sur le chemin du refus, le fournisseur doit être absent du DOM et absent du resource timing : rien n'a été injecté, rien n'a été chargé. Sur le chemin de l'acceptation, il doit apparaître dans les deux. C'est le resource timing qui compte : si l'hôte du fournisseur a été chargé, il a été chargé, quoi qu'ait indiqué le conteneur.
Une exception à l'étape trois, et elle compte : tout ce qui précède concerne les scripts de fournisseurs tiers. Les balises de Google intègrent leurs propres vérifications de consentement, si bien qu'une vérification Additional Consent sur une balise GA4 ou Google Ads la bloque purement et simplement au lieu d'adapter son comportement. Faut-il bloquer les balises de Google jusqu'au consentement explique pourquoi, et comment lire ce que fait réellement votre conteneur.
Si le fournisseur apparaît encore sur le chemin du refus après tout cela, le script que vous avez déplacé n'est probablement pas celui qui se déclenche. Quelque chose d'autre sur la page le charge, ce qui est une autre panne, avec son propre diagnostic dans pourquoi le pixel Facebook se charge encore quand vos balises sont bloquées.
Une vérification du consentement sur la balise équivaut-elle à un déclencheur qui attend ?
C'est la distinction qui décide si le verrou tient vraiment. Un déclencheur contrôle quand une balise est examinée. Les paramètres de consentement contrôlent si elle a le droit de s'exécuter une fois examinée.
Conditionnez avec un déclencheur seul et vous avez couvert le premier chargement de page, rien de plus. Une balise dont le déclencheur est un événement ultérieur, un clic, l'envoi d'un formulaire, un changement de route dans une application monopage, est examinée de nouveau au moment où cet événement se produit. Sans exigence de consentement sur la balise, elle s'exécute alors, quel que soit le choix du visiteur.
Placez aussi l'exigence sur la balise et elle tient, quel que soit le chemin par lequel la balise est atteinte. Le déclencheur dit quand envisager le déclenchement ; les paramètres de consentement disent si le déclenchement est autorisé. Ensemble, ils font du verrou une propriété de la balise, et non d'un seul des chemins qui y mènent.
Un script que vous dites strictement nécessaire peut-il échapper au verrou ?
La dernière contrainte n'est pas technique. On défend parfois un fournisseur comme strictement nécessaire pour qu'il puisse s'exécuter avant le consentement, et il arrive que l'argument tienne. Ce qui compte, c'est que la notice de consentement du site et son tableau des cookies disent la même chose, mot pour mot.
Si votre notice range un fournisseur dans une catégorie que le visiteur est invité à refuser, la balise doit respecter ce refus. Un script qui tourne sans verrou alors que la page dit au visiteur qu'il peut le refuser, c'est une contradiction qu'un régulateur peut lire directement sur votre propre site, et elle est bien plus facile à repérer qu'un conteneur mal configuré.
Velo bloque par catégorie dans la page et transmet la même décision au conteneur, si bien que le choix du visiteur s’applique en même temps à la page et au conteneur.
Questions fréquentes
Les questions que l'on pose sur ce sujet.
Puis-je déplacer un script dans Google Tag Manager pour le soumettre au consentement ?
Généralement oui, et pour la plupart des scripts de fournisseurs, c'est la bonne décision. Une fois que le script est une balise et non plus du balisage dans le head, il ne s'exécute que lorsqu'un déclencheur le lance et que ses paramètres de consentement l'autorisent. Les exceptions sont les scripts qui doivent agir avant que le conteneur puisse les atteindre : tout ce qui doit s'exécuter avant le rendu de la page, comme l'A/B testing et la personnalisation, tout ce qui est conçu pour observer la toute première requête, et la couche de consentement elle-même, qui ne peut pas être conditionnée à la décision qu'elle sert justement à recueillir. Ceux-là restent dans le head et y sont bloqués par catégorie.
Quels scripts doivent rester dans le head du site ?
Ceux dont le rôle dépend d'une exécution précoce. Les scripts de personnalisation et d'A/B testing réécrivent la page avant le premier affichage : les lancer depuis un conteneur produit exactement le scintillement qu'ils étaient censés éviter. Certains outils anti-bots et antifraude sont conçus pour voir le tout premier instant d'une visite. Et la bannière de consentement elle-même doit s'exécuter avant qu'une décision existe. Tout le reste, y compris les pixels publicitaires et de retargeting, l'enregistrement de sessions, les widgets de chat et les lecteurs intégrés, passe dans un conteneur sans rien perdre.
Une vérification du consentement sur la balise équivaut-elle à un verrou par déclencheur ?
Non, et c'est cette différence qui décide si le verrou tient. Un déclencheur contrôle quand une balise est examinée ; les paramètres de consentement contrôlent si elle peut s'exécuter une fois examinée. Si vous ne conditionnez qu'avec un déclencheur, vous avez couvert le premier chargement de page, mais une balise lancée par un clic ultérieur, l'envoi d'un formulaire ou un changement de route est examinée de nouveau à ce moment-là et s'exécutera quel que soit le choix du visiteur. Définir aussi l'exigence de consentement sur la balise fait du verrou une propriété de la balise, et non d'un seul des chemins qui y mènent.
Comment vérifier qu'un script est vraiment bloqué avant le consentement ?
Testez sur la page publiée plutôt qu'en mode aperçu, car l'aperçu tourne avec un câblage de débogage et souvent avec un état de consentement que vous avez vous-même défini quelques instants plus tôt. Sur le chemin du refus, le fournisseur doit être absent du DOM de la page et absent du resource timing, ce qui montre ensemble que rien n'a été injecté et que rien n'a été chargé. Sur le chemin de l'acceptation, les deux doivent le montrer. Le resource timing est le critère décisif : si l'hôte du fournisseur a été sollicité, il a été sollicité, quoi qu'ait indiqué le conteneur.
La confidentialité web, au même endroit.
Analysez votre site →© 2026 par
