Google Analytics : auditer une ancienne installation

Une installation Google Analytics ancienne doit être réexaminée à partir des balises, des requêtes et des données encore présentes. Les recettes conçues pour Universal Analytics, comme certains anciens réglages d’adresse IP ou protocoles d’envoi, ne permettent pas de valider GA4 aujourd’hui. Un audit utile identifie ce qui fonctionne réellement et ce qui subsiste d’une ancienne architecture.

Cet article, initialement publié en 2018, a été repris pour remplacer ces anciennes recettes techniques par une méthode de revue. Il ne présente plus un proxy ou une empreinte de navigateur hachée comme une solution garantissant l’anonymat.

Ce qu’il faut retenir

• Les anciennes propriétés et instructions Universal Analytics ne constituent plus une configuration actuelle de mesure.
• Un tableau agrégé n’efface pas les données personnelles traitées en amont.
• Le passage par un serveur ou le hachage d’un identifiant ne prouvent pas une anonymisation.
• L’audit doit couvrir les balises, les événements, les exports, les choix et les contrats.
• Le dépôt ou la lecture d’un traceur relève de l’art. 82 de la loi Informatique et Libertés, en plus du RGPD pour les données personnelles traitées.
• Chaque constat d’audit doit déboucher sur une action, un responsable et une preuve.

Reconstituer les points d’installation

Recherchez les balises dans le thème du site, les extensions, le gestionnaire de tags, les scripts intégrés et les envois depuis le serveur. Notez la destination de chaque événement, la personne qui administre la configuration et la finalité actuelle.

Selon Google, les propriétés Universal Analytics standard ont cessé de traiter les données à partir de juillet 2023, tandis que l’arrêt complet, incluant l’extension accordée à certaines propriétés 360, est intervenu en juillet 2024. Un ancien identifiant présent dans le code ne prouve donc pas qu’une mesure utile est encore réalisée.

Ne supprimez pas un script sans comprendre ses dépendances. Identifiez d’abord les balises obsolètes, les doublons et les envois qui restent actifs. Pour la configuration actuelle, utilisez le guide de GA4 et du RGPD.

Examiner les identifiants au lieu de regarder seulement les rapports

Un rapport peut afficher des totaux alors que sa production a nécessité de distinguer des navigateurs ou de rapprocher plusieurs événements. Il faut analyser les données de collecte, les étapes intermédiaires et les possibilités de rapprochement.

La liste contractuelle des services Google mentionne des identifiants en ligne et clients pour Analytics. L’absence de nom dans le tableau de bord ne permet donc pas de conclure que l’éditeur ne participe à aucun traitement de données personnelles.

Établissez une table : paramètre, source, destinataire, utilité, durée et possibilité de relier la donnée à une personne ou à d’autres événements. Les URL, champs de recherche, identifiants de commande et propriétés personnalisées méritent une attention particulière.

Réexaminer les promesses d’anonymisation

Un ancien montage peut tronquer une adresse IP, remplacer une valeur par un condensat ou transmettre les événements via un serveur intermédiaire. Ces opérations peuvent réduire l’exposition ; elles ne suffisent pas à démontrer que toute identification est devenue impossible.

La CNIL distingue anonymisation et pseudonymisation. Une empreinte persistante qui permet de reconnaître un navigateur et de corréler son activité demande une analyse particulière, même si elle ne contient aucun nom. Ne réutilisez pas un procédé de fingerprinting pour affirmer que le suivi sort du RGPD.

Pour un proxy, examinez les données qu’il reçoit, ce qu’il conserve dans ses journaux, ce qu’il transforme et ce qu’il transmet. Le serveur peut créer une nouvelle copie de données personnelles tout en réduisant celles envoyées au prestataire. Le guide des journaux de tracking serveur aide à traiter cette partie souvent oubliée.

Contrôler les flux avec les choix réels

Exécutez des parcours sans choix, avec refus, avec accord limité et après retrait. Observez séparément les lectures ou écritures dans le terminal et les requêtes vers les destinataires.

Dans sa documentation actuelle, Google indique que le mode avancé peut envoyer des signaux sans cookies lorsque le consentement est refusé. L’ancien constat « aucun cookie déposé » n’est donc pas une preuve générale d’absence de transmission. Chaque opération doit être qualifiée au regard du RGPD et des règles applicables aux traceurs.

La procédure d’arrêt des scripts après retrait doit aussi couvrir les changements de page et les transmissions indirectes. Conservez les résultats observés, avec la version de configuration correspondante.

Revoir le contrat et les données déjà exportées

Vérifiez les conditions acceptées pour le service, les rôles des intervenants, les accès de l’agence et les destinations externes. Les conditions de traitement Google s’appliquent aux services et données de leur périmètre ; les produits additionnels peuvent relever d’autres conditions.

Les exports historiques restent à gérer même si l’ancienne propriété n’est plus accessible. Identifiez leur finalité, les personnes habilitées et leur échéance. La disparition d’une interface ne prouve pas que les feuilles de calcul, tableaux de bord et archives de l’agence ont été supprimés.

Terminez par une liste d’actions vérifiables : retirer une balise obsolète, filtrer un paramètre, revoir un déclenchement, restreindre un export ou documenter un transfert. Chaque action doit avoir un responsable et une preuve de résultat.

Cadre juridique à garder en tête pendant l’audit

Deux textes se superposent. Le dépôt ou la lecture d’informations dans le terminal de l’utilisateur relève de l’article 82 de la loi Informatique et Libertés, qui transpose l’article 5(3) de la directive 2002/58/CE : sauf exception, un consentement préalable est requis. Le traitement ultérieur des données personnelles collectées relève ensuite du RGPD (Art. 6(1), Art. 5(1)(c) et (e), Art. 28 si un sous-traitant intervient).

La CNIL admet une exemption de consentement pour certains traceurs de mesure d’audience strictement limités à la production de statistiques anonymes, selon des conditions précises (finalité limitée, durées bornées, absence de recoupement ni de réutilisation par le prestataire). Un audit doit donc vérifier, pour chaque outil, si ces conditions sont réellement réunies ; le choix de l’outil ne règle pas la question. Pour comparer avec une solution configurable dans ce sens, voir Matomo et le RGPD.

Reste la question des transferts. La décision d’exécution (UE) 2023/1795 du 10 juillet 2023 constate l’adéquation du Data Privacy Framework pour les organisations certifiées. Elle ne dispense pas de vérifier que le prestataire est bien certifié pour la catégorie de données concernée, et sa solidité reste suivie par les juridictions européennes. Le point est traité dans l’article sur le Data Privacy Framework et celui sur les transferts hors UE.

Exemple d’audit sur un site fictif

Cet exemple est hypothétique et ne décrit aucun cas réel.

Une boutique en ligne imaginaire reprend son site en 2026. Elle découvre trois installations : un identifiant Universal Analytics resté dans le thème, une balise GA4 posée par l’agence dans le gestionnaire de tags, et un envoi d’événements d’achat depuis le serveur vers la même propriété GA4.

Le constat : l’ancien identifiant ne produit plus de mesure et peut être retiré après vérification des dépendances ; la balise GA4 se déclenche avant tout choix de l’internaute ; l’envoi serveur transmet l’adresse e-mail hachée du client dans un paramètre libre « user_data ». Les actions retenues sont de retirer la balise obsolète, de conditionner la balise GA4 au consentement, de supprimer le paramètre contenant l’e-mail et de réduire la durée de conservation de la propriété à la valeur strictement utile. Chaque ligne reçoit un responsable et une capture ou un export de requête comme preuve.

Ce déroulé montre l’intérêt de la méthode : trois sources différentes, trois risques différents, un seul rapport apparent. Un contrôle limité au tableau de bord n’aurait rien révélé.

Tableau de synthèse de l’audit

Erreurs fréquentes lors d’une reprise d’installation

La première erreur consiste à croire qu’un site « sans cookie visible » ne déclenche aucune collecte : les requêtes réseau et les identifiants côté serveur échappent à l’inspection des cookies. La deuxième est de traiter la bannière comme une preuve en soi, alors qu’elle doit être confrontée aux requêtes réellement émises ; sur ce point, consultez le guide Google Analytics et RGPD et celui du mode de consentement Google. La troisième est d’oublier les accès tiers : l’agence, l’ancien prestataire ou un stagiaire peuvent encore disposer de droits sur la propriété.

Enfin, ne supprimez pas des données ou des propriétés sans avoir examiné les obligations de conservation applicables à vos autres traitements ; la suppression d’un export de mesure n’a pas les mêmes enjeux que celle d’une pièce comptable. Pour fixer des durées cohérentes, voir la durée de conservation des données personnelles.

FAQ

Le paramètre historique anonymize_ip suffit-il pour GA4 ?

Non. Il ne constitue pas une procédure actuelle de conformité. Examinez la documentation GA4 et la collecte réelle, ainsi que les autres identifiants et finalités.

Un envoi côté serveur rend-il automatiquement les données anonymes ?

Non. Il faut analyser les informations reçues et transmises, les journaux et les possibilités de rapprochement. Le serveur change l’architecture, pas automatiquement la qualification des données.

Peut-on ignorer les exports d’Universal Analytics ?

Non. Les fichiers encore conservés ou utilisés doivent posséder une finalité, une durée et des accès justifiés, même après la fermeture du service d’origine.

Faut-il toujours recueillir le consentement pour mesurer l’audience ?

Pas systématiquement : la CNIL prévoit une exemption pour des traceurs strictement limités à des statistiques anonymes, sous conditions. Un outil qui réutilise les données pour son propre compte ou permet de suivre un individu entre sites sort de ce cadre.

Quelle preuve conserver d’un audit ?

Conservez l’inventaire des balises, les captures ou exports des requêtes observées avec la date et la version de configuration, la liste des actions décidées et leur responsable. Ces éléments appuient le principe de responsabilité de l’Art. 5(2).

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.