Google Analytics et Loi 25 au Québec

GA4 n’enregistre plus des pages vues rattachées à une session, mais des événements : page_view, scroll, click, form_start, et tout ce qu’on décide d’ajouter. Certains se déclenchent d’eux-mêmes si la mesure améliorée est activée.

Chaque événement part avec un contexte : page, provenance, langue, résolution, appareil, et une estimation de localisation. Pris isolément, rien de tout cela n’identifie quelqu’un. Rassemblé et rattaché à un identifiant stable, l’ensemble décrit le parcours d’une personne.

Dans sa configuration par défaut, GA4 dépose deux témoins de première partie :

• _ga : l’identifiant du client, conservé deux ans par défaut. C’est lui qui permet de reconnaître le même navigateur d’une visite à l’autre.
• _ga_<ID> : l’état de la session en cours, propre à la propriété mesurée.

Ces deux témoins sont posés par votre domaine, pas par Google. Cela ne change rien à leur finalité : ils servent à reconnaître un visiteur, ce qui est précisément le type de fonction sur laquelle la personne doit être informée.

Google indique ne pas conserver les adresses IP dans GA4, mais s’en sert pour estimer la localisation avant de les écarter. La donnée transite donc, même si elle n’est pas stockée.

Les événements sont envoyés à l’infrastructure de Google, hors Québec. La Loi 25 demande, avant de communiquer des renseignements personnels à l’extérieur du Québec, de procéder à une évaluation des facteurs relatifs à la vie privée et d’encadrer la communication.

C’est un point que la configuration technique ne règle pas : il relève de la documentation interne de l’entreprise, pas du code de la page.

Un conteneur s’identifie par un code de la forme GTM-XXXXXXX présent dans la page. Son contenu, lui, est chargé depuis les serveurs de Google : GA4, Meta Pixel, Google Ads, un outil de carte de chaleur, une balise ajoutée il y a trois ans par une agence qui ne travaille plus avec vous.

C’est ce qui rend l’inventaire difficile : la page ne déclare qu’un conteneur, pas ce qu’il contient. Le seul moyen de voir l’intérieur est d’ouvrir le conteneur, ou d’observer les requêtes qu’il déclenche.

Le déclencheur le plus courant est aussi le plus problématique : « toutes les pages », qui exécute la balise au chargement, sans condition. C’est le réglage par défaut, et c’est celui qu’on retrouve sur la majorité des sites où la mesure part avant le choix.

Faire attendre une balise suppose de lier le conteneur au bandeau de consentement. Deux approches coexistent :

• Par déclencheur : la balise n’a pour condition que l’événement émis par la bannière au moment du choix. Simple à vérifier : sans l’événement, rien ne part.
• Par état de consentement : le mode consentement de Google, qui module le comportement des balises selon des paramètres. Plus souple, et plus difficile à contrôler de l’extérieur.

Le mode consentement transmet aux balises Google l’état du choix du visiteur, à travers quelques paramètres : analytics_storage pour la mesure, ad_storage, ad_user_data et ad_personalization pour la publicité. Les balises adaptent leur comportement en conséquence.

Il ne remplace pas la bannière : il en dépend. C’est la bannière qui met ces paramètres à jour au moment du clic.

La distinction est capitale et rarement expliquée aux entreprises qui l’installent.

• Mode de base : les balises ne se chargent pas tant que le consentement n’est pas donné. Aucune requête ne part avant le choix.
• Mode avancé : les balises se chargent dès l’arrivée et envoient, en l’absence de consentement, des signaux sans témoin. Il part donc quelque chose avant le choix, même sans identifiant.

Dans l’onglet Réseau, la différence est visible : en mode avancé, /g/collect apparaît avant tout clic, avec un paramètre indiquant l’absence de consentement.