GTM : auditer un modèle de balise communautaire

Un modèle communautaire Google Tag Manager peut être utilisé, mais son installation ne suffit pas à autoriser les collectes qu’il déclenche. Avant publication, rapprochez la finalité annoncée, les permissions accordées, les données envoyées et le comportement après refus. Si une destination ou un usage reste inexpliqué, gardez la balise inactive jusqu’à résolution. Sa présence dans la galerie ne constitue pas une validation RGPD de votre site.

Ce guide concerne un modèle de balise pour un conteneur Web. Un modèle serveur nécessite une revue complémentaire : les données déjà reçues par le serveur et leurs transmissions ultérieures doivent aussi être maîtrisées.

Définir ce que la balise a le droit de faire

Commencez par une phrase compréhensible par le marketing et le DPO : « transmettre au prestataire publicitaire un événement d’achat pour mesurer les campagnes, après accord de l’internaute ». Cela permet de distinguer ce projet d’une statistique interne, d’une relance ou d’un service demandé par le client. Le nom commercial du modèle ne détermine pas sa finalité juridique.

L’article 82 de la loi Informatique et Libertés impose un consentement préalable aux lectures ou écritures dans le terminal, sauf ses exceptions précises de communication ou de service strictement nécessaire demandé par l’utilisateur. Le besoin de mesurer une campagne publicitaire ne rend pas ses traceurs nécessaires à la commande. Texte de l’article 82.

Lorsqu’il y a des données personnelles, documentez également la base légale, les destinataires, l’information, la conservation et les éventuels transferts. Un accord portant sur un traceur ne permet pas toutes les réutilisations. Les Art. 5(1)(b) et (c) imposent finalité et minimisation ; l’Art. 7(3) permet le retrait du consentement. RGPD, principes et consentement.

La CNIL rappelle que ces règles concernent aussi des technologies autres que les cookies. Supprimer un cookie tout en maintenant un autre identifiant ne suffit donc pas à conclure. CNIL, cookies et traceurs. Pour préparer le choix proposé aux visiteurs, utilisez le guide sur les cookies et le consentement.

Examiner la version et les permissions du modèle

Demandez au prestataire le modèle réellement utilisé, sa version, sa documentation et la configuration prévue. Une fiche commerciale décrivant une intégration ne remplace pas le contenu installé dans votre conteneur. Conservez aussi la version de ce conteneur : plusieurs balises peuvent employer le même modèle avec des paramètres différents.

Google décrit des permissions distinctes pour lire des cookies, accéder au stockage local, consulter la couche de données, charger un script ou envoyer un pixel. Leur portée peut être restreinte : noms de clés, cookies ou destinations selon la permission. La journalisation possède aussi son propre réglage. Ces autorisations techniques délimitent des capacités ; elles ne valent pas consentement de l’internaute. Documentation officielle des permissions Web.

Pour chaque capacité, le développeur relie l’opération à une donnée et à un usage. Le DPO peut alors arbitrer la nécessité sans prétendre lire seul tout le code. Une lecture large doit être expliquée par un besoin précis ; « le modèle le demande » n’est pas ce besoin.

Examinez également la chaîne chargée par le modèle. Si un script externe réalise la collecte, sa version et ses paramètres font partie du périmètre. Autoriser le chargement depuis un domaine connu ne démontre pas quels champs seront ensuite transmis ni à quels destinataires. Demandez des explications sur les fonctions optionnelles, notamment le rapprochement d’identités.

Une fiche de revue renseignée pour une boutique

Cas hypothétique. Une boutique de luminaires veut mesurer les achats issus de ses campagnes. L’agence propose un modèle communautaire, désigné ici « Conversion boutique » pour l’exemple, sans référence à un produit réel. La finalité retenue exclut le rapprochement par courriel et la constitution de profils à partir du service après-vente.

L’agence décrit un envoi comprenant un événement, une référence technique d’achat, le montant et la devise. Elle propose aussi, en option, d’envoyer l’adresse complète de la page et des coordonnées du client. Le responsable du site décide ainsi :

Ce tableau est une décision proposée pour ce scénario, pas le résultat d’un audit d’une extension existante. Si le modèle ne sait pas appliquer ces limites, l’équipe choisit une configuration ou une solution compatible avant de l’activer. Elle ne collecte pas les champs supplémentaires dans l’espoir de les supprimer plus tard.

La référence technique ne devient pas anonyme parce qu’elle ne contient pas le nom. Si la boutique peut la rattacher à une commande, elle la traite comme une donnée personnelle. Le même raisonnement vaut pour les informations encodées ou hachées lorsqu’un rapprochement reste possible.

L’analyse de l’adresse de page mérite une vérification spécifique des paramètres UTM et des données personnelles. Une campagne propre peut aboutir à une page dont d’autres paramètres révèlent des informations que personne ne souhaitait envoyer.

Vérifier la logique du consentement, pas seulement un libellé

Dans GTM, les vérifications intégrées peuvent adapter le comportement d’une balise ; elles ne signifient pas toutes « aucun envoi après refus ». Les vérifications supplémentaires constituent un réglage distinct. L’option « Non défini » signifie qu’aucune vérification supplémentaire n’est effectuée. Google réserve aussi le déclencheur d’initialisation du consentement aux balises qui gèrent ces états : ce n’est pas un moyen d’exécuter plus tôt une balise commerciale. Aide Google sur le consentement dans GTM.

Un point technique mérite une demande explicite au développeur : l’API isConsentGranted considère notamment un type non défini comme accordé ; une option d’exécution systématique peut également influencer sa réponse. Un simple appel à cette fonction ne démontre donc pas qu’un accord positif a été recueilli. Google documente ces comportements dans la référence des API de modèles.

Dans la boutique fictive, la règle de réception est claire : l’événement publicitaire reste bloqué sans l’accord requis. L’agence doit montrer comment cette règle est traduite depuis la plateforme de consentement jusqu’à la balise. Elle précise les états initiaux, les changements de choix et les paramètres concernés. Les noms des signaux techniques ne remplacent pas les finalités expliquées au visiteur.

Observer quatre parcours avant publication

La recette proposée se déroule avec des données fictives et examine les requêtes, leur contenu et les stockages concernés. Aucun essai réel de votre modèle n’est prétendu réalisé ici. Le responsable technique fournit les observations ; le responsable du site décide si elles correspondent au dossier validé.

1. Avant choix : ouvrir une session sans choix mémorisé et effectuer une commande fictive. Pour le scénario publicitaire retenu, aucun événement de cette balise ne doit partir. Examiner aussi les demandes chargées automatiquement à l’ouverture.
2. Après refus : poursuivre la navigation et changer de page. Le refus doit rester effectif, y compris lors d’un événement tardif ; une commande doit rester possible.
3. Après acceptation : vérifier que seuls les champs retenus atteignent la destination identifiée. L’existence d’une requête autorisée ne prouve pas que son contenu est limité.
4. Après retrait : rester sur la même page, provoquer un nouvel événement puis naviguer. Vérifier l’arrêt attendu et le traitement des éventuels envois en attente.

Gardez, pour chaque parcours, l’état du choix, la version examinée, l’action effectuée et une trace expurgée du résultat. Une capture du bandeau prouve son affichage, pas l’absence de transmission. Évitez de constituer un dossier de preuve contenant de vraies coordonnées de clients.

Si un flux interdit apparaît, désactivez la balise concernée, recherchez son origine et corrigez avant une nouvelle recette. Le problème peut venir du modèle, de sa configuration ou d’une seconde installation. Supprimer seulement la balise examinée ne suffit pas si un autre chemin continue l’envoi. Le guide du retrait des scripts actifs traite ce contrôle dans la durée.

Suivre les mises à jour et les transmissions suivantes

La galerie relie les versions à des références de modifications du dépôt, et les utilisateurs peuvent être avertis d’une mise à jour. Conservez cette référence avec vos décisions ; les notes de version aident à identifier ce qui change, sans remplacer l’examen. Gestion des versions de modèles par Google.

Une nouvelle destination, un champ supplémentaire ou une modification du respect des choix justifie de reprendre les points concernés et les parcours affectés. Attribuez cette revue à une personne nommée. Si le changement est insuffisamment expliqué, différez son activation ; si l’ancienne version présente elle-même un risque, suspendez la collecte plutôt que de la conserver par défaut.

Enfin, un envoi vers votre domaine ne clôture pas l’analyse. Le serveur peut retransmettre les événements et conserver des journaux contenant leurs paramètres. Examinez ce second trajet avec le guide du tracking serveur et de la conservation des journaux. La réception technique, la réutilisation publicitaire et la conservation doivent correspondre au même périmètre autorisé.

Ce qu’il faut retenir

• Une version, une configuration et une finalité précises forment le périmètre de revue.
• Les permissions techniques ne constituent pas un accord juridique.
• Le contenu des requêtes et le retrait doivent être observés, y compris sans rechargement.
• Une mise à jour ou un serveur intermédiaire ne doit pas introduire un flux non examiné.

FAQ

Faut-il préférer systématiquement un modèle communautaire à une balise HTML ?

Le format ne permet pas, à lui seul, de choisir. Comparez les capacités nécessaires, la possibilité de les limiter, la transparence du code et la maintenance. Un modèle dont les flux restent inexpliqués ne répond pas au besoin de preuve.

L’absence de cookie rend-elle inutile l’audit ?

Non. Examinez les autres lectures du terminal, les données personnelles envoyées et les traitements ultérieurs. Un nom de technologie ne décide pas de l’application de l’article 82 ou du RGPD.

Peut-on autoriser toutes les permissions pour éviter les erreurs ?

Cette solution élargit le périmètre sans démontrer sa nécessité. Identifiez l’opération qui échoue et accordez seulement les accès justifiés ; si le besoin n’est pas explicable, ne publiez pas la configuration.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.