Recherche interne : filtrer les données dans GA4

Un visiteur peut saisir son email, son numéro de dossier ou une information intime dans la recherche du site. Pour mesurer l’utilisation de ce moteur dans GA4, la réponse la plus sûre est de ne pas transmettre la saisie libre lorsque le besoin porte seulement sur le nombre de recherches ou l’absence de résultat. Désactiver l’événement automatique concerné ne suffit cependant pas si le même texte part encore dans l’URL ou le titre de page.

Retrouver chaque copie de la recherche

Dans les mesures améliorées de GA4, l’événement view_search_results peut exploiter un paramètre présent dans l’URL et renseigner search_term. Les noms reconnus par défaut comprennent q, s, search, query et keyword ; d’autres peuvent être configurés. Le responsable du site doit donc examiner le flux réellement activé, pas seulement le formulaire visible.

Un exemple fictif illustre le problème : le visiteur cherche « dossier DEMO-583 ». Le site affiche les résultats, conserve la saisie dans l’adresse et construit un titre qui la reprend. Une balise personnalisée peut aussi envoyer cette valeur dans un autre événement. Retirer une seule de ces copies laisse les autres chemins ouverts.

La documentation Google sur les informations permettant l’identification dans Analytics vise notamment les URL, les titres et les champs libres. Les prescriptions contractuelles du produit s’ajoutent au RGPD : sa notion de PII ne délimite pas, à elle seule, toutes les données personnelles au sens européen.

Établissez un inventaire avec l’intégrateur : emplacement de la saisie dans le navigateur, balises qui la lisent, requêtes envoyées et destinataires. Incluez les modifications sans rechargement complet de page et le retour vers les résultats. Le guide des paramètres UTM et données personnelles complète ce contrôle des adresses.

Décider ce que la mesure doit réellement expliquer

« Améliorer la recherche » reste trop vague pour justifier toutes les valeurs possibles. Une question plus précise conduit à un choix différent : veut-on savoir si le moteur est utilisé, combien de recherches n’aboutissent pas, ou quels produits manquent au catalogue ? Ces objectifs ne demandent pas nécessairement la même information.

Le nombre de recherches renseigne le premier point. Une valeur limitée « résultat présent » ou « aucun résultat » renseigne le deuxième. Pour le troisième, une revue de besoins produits peut être organisée séparément, avec une collecte adaptée ; exporter indistinctement toutes les phrases dans un outil de mesure n’est pas la seule solution.

L’Art. 5(1)(c) impose de limiter les données personnelles à ce qui est nécessaire. L’Art. 25 demande de traduire cette exigence dans la conception et les réglages par défaut. Une collecte exhaustive suivie d’un tri occasionnel ne remplit pas la même fonction qu’une limitation avant transmission. Sources : principes du RGPD et protection dès la conception.

Spécification proposée pour un catalogue de luminaires

Le responsable marketing d’une boutique fictive veut évaluer le fonctionnement du moteur, sans analyser les personnes. Il retient la question suivante : parmi les recherches ayant obtenu une réponse du moteur, quelle part ne présente aucun produit ? Voici une spécification de travail, à adapter et à mettre en œuvre par son intégrateur ; ce n’est pas une configuration GA4 déjà testée.

Un nom d’événement proposé dans le projet doit être distingué d’un événement standard du produit. L’équipe documente son propre choix et ses conditions de déclenchement, au lieu de supposer qu’une option existante réalise exactement cette spécification.

Calculer sans transformer une absence de mesure en zéro

Dans un jeu de démonstration fictif, le moteur produit 120 réponses exploitables : 102 avec résultat et 18 sans résultat. Le taux recherché est donc 18 divisé par 120, soit 15 %. Il s’agit d’un taux par recherche mesurée, pas de la proportion de visiteurs insatisfaits. Une même personne peut avoir effectué plusieurs recherches.

Si une panne empêche le moteur de répondre, la recherche n’entre pas artificiellement dans les 18 réponses sans produit. Si la mesure est bloquée par un choix de confidentialité, l’absence d’événement ne prouve pas qu’aucune recherche n’a eu lieu. Le tableau de bord doit présenter son périmètre, notamment cette couverture incomplète.

Cette distinction évite une mauvaise décision commerciale. Un pic de problèmes techniques appelle une intervention sur le service ; un ensemble de réponses vides peut conduire à revoir le catalogue ou la pertinence du moteur. Conserver tout le texte libre n’est pas nécessaire pour distinguer ces deux problèmes.

Corriger avant la transmission, sur tous les chemins

Commencez par interrompre la collecte automatique de recherche si elle envoie une saisie non maîtrisée. Le réglage des mesures améliorées permet de sélectionner les options ; cela ne constitue pas une désactivation générale des autres événements ni de leurs paramètres. Une balise personnalisée doit être examinée séparément. Source : options des mesures améliorées.

L’intégrateur doit ensuite traiter chaque copie identifiée. Dans la spécification ci-dessus, changer le nom search_term en « requête » ne résout rien : le contenu reste le même. De même, supprimer la colonne visible d’un rapport n’empêche pas son arrivée dans le service.

Organisez une vérification avant l’envoi plutôt qu’un nettoyage tardif après chargement. Si une première requête part avec le texte puis qu’une seconde utilise une adresse corrigée, la transmission initiale a déjà eu lieu. Le moment de la correction fait partie du résultat attendu.

Le masquage des données GA4 peut compléter cette prévention sur les flux web : Google décrit une détection des emails et le masquage des paramètres d’URL spécifiés, côté client avant collecte. Cette détection reste imparfaite. Elle ne couvre pas le protocole de mesure ni les importations de données ; elle n’analyse pas non plus les en-têtes HTTP. Ne la présentez pas comme une protection de tous les flux du site.

Un filtre d’email ne repère pas nécessairement un numéro de dossier, un nom ou une phrase intime. Ajouter q à une liste de paramètres ne démontre pas que sa copie dans un autre champ a disparu. Pour le besoin retenu, l’absence de texte libre dans la mesure reste le critère de réception.

Préparer un contrôle que le DPO peut comprendre

Le contrôle doit avoir des entrées et des résultats attendus lisibles. Voici trois recherches de démonstration à exécuter sur un environnement approprié, sans données réelles. Le nombre de produits affichés dépendra du catalogue de cet environnement ; il doit être relevé, et non inventé dans le compte rendu.

Le traitement utile au fonctionnement de la recherche reste lui-même à encadrer : cette table n’autorise pas une conservation indéfinie des requêtes dans les journaux du moteur. Elle sépare ce fonctionnement de la mesure transmise à GA4.

Pour chaque entrée, l’intégrateur conserve les éléments nécessaires pour expliquer le résultat : version du site, paramètres actifs, requêtes pertinentes et valeurs observées. Le DPO peut alors rapprocher la décision métier de ce qui sort effectivement. Un simple écran de rapport vide ne constitue pas une preuve suffisante d’absence de transmission.

Si la valeur apparaît dans un chemin inattendu, maintenez le flux concerné désactivé, corrigez ce chemin et reprenez le contrôle. N’activez pas la mesure réduite avant d’avoir confirmé son périmètre. La recherche peut continuer à fonctionner sans envoyer son contenu libre au dispositif statistique.

Encadrer le contexte et les données déjà envoyées

Un terme courant n’est pas automatiquement une donnée sensible. Toutefois, une recherche associée à une personne identifiable peut révéler des informations relevant de l’Art. 9(1), selon son contenu et son contexte. La réduction à une catégorie ne neutralise pas ce problème si la catégorie révèle précisément la même information. Pour ces parcours, examinez les pages sensibles à exclure du reciblage ; une mesure technique ne doit pas alimenter par défaut une audience publicitaire.

La suppression du texte libre ne rend pas nécessairement l’ensemble du dispositif anonyme. Des identifiants, des adresses techniques ou d’autres événements peuvent subsister. La base légale, l’information, la conservation et les règles relatives aux traceurs doivent donc être traitées séparément. L’Art. 82 de la loi Informatique et Libertés conserve son rôle pour les opérations sur le terminal ; alléger un paramètre ne crée aucune exemption.

Si des valeurs personnelles ont déjà été envoyées, séparez correction future et traitement de l’historique. Identifiez les événements, périodes, exports et accès concernés, puis appliquez la procédure de suppression des données envoyées par erreur dans GA4. Une correction locale ne supprime pas spontanément les copies chez les destinataires.

Enfin, qualifiez l’incident. Lorsqu’il constitue une violation de sécurité, documentez l’analyse des risques et examinez les notifications prévues aux Art. 33 et 34. Il n’existe ni notification automatique de toute anomalie statistique ni dispense générale parce que la transmission était involontaire. Attribuez le suivi à une personne jusqu’à la vérification des mesures prises.

Ce qu’il faut retenir

• Définissez l’indicateur avant de collecter la saisie libre.
• Contrôlez événement, URL, titre et balises personnalisées.
• Un résultat nul, une panne et une absence de mesure sont différents.
• Prévention future et nettoyage de l’historique sont deux opérations distinctes.

FAQ

Un avertissement près du champ suffit-il ?

Non. Il peut aider les visiteurs à éviter certaines saisies, mais ne garantit pas ce qu’ils écriront. La collecte doit rester proportionnée et techniquement maîtrisée.

Peut-on remplacer le texte par son empreinte ?

Cela ne rend pas automatiquement la donnée anonyme. Une empreinte peut permettre des rapprochements ; elle est inutile lorsque l’objectif demande seulement un compteur et un état du résultat.

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.