ENFR
Choisir un outil analytics : la grille de gouvernance en 15 questions

Choisir un outil analytics : la grille de gouvernance en 15 questions

Les comparatifs analytics commencent souvent par une liste de fonctionnalités. Ils se terminent par une note globale qui suppose que toutes les équipes cherchent la même chose. Ce n’est pas le cas. Une PME B2B qui veut suivre trois sites, partager un reporting avec une agence et limiter la collecte n’a pas les mêmes contraintes qu’un groupe e-commerce connecté à une régie publicitaire. Une équipe technique qui accepte d’exploiter une instance auto-hébergée ne fait pas le même arbitrage qu’une équipe marketing sans administrateur système. Le bon outil n’est donc pas celui qui possède le plus de fonctions. C’est celui dont les fonctions, les défauts de configuration et le modèle de gouvernance correspondent au besoin. Le comparatif général entre Google Analytics, Matomo et les analytics frugales présente les grandes familles. La grille suivante sert à conduire la décision dans une organisation réelle, sans dépendre d’un classement figé ni de tarifs susceptibles de changer. Avant de noter les outils, écrire le problème Une sélection sérieuse tient sur une page avant la première démonstration. Les décisions attendues Listez cinq à dix décisions que l’analytics doit soutenir :quels canaux amènent des demandes qualifiées ? quelles pages d’entrée contribuent aux conversions ? quels contenus sont consultés ? quels sites progressent ou décrochent ? quels événements produit doivent être suivis ? où une rupture de collecte s’est-elle produite ?Une demande comme « avoir toutes les données » n’est pas exploitable. Les utilisateurs Identifiez les rôles :marketing ; produit ; direction ; agence ; analyste ; développeur ; DPO ou privacy ; clients externes.Le nombre d’utilisateurs importe moins que leurs droits, leurs compétences et la fréquence d’usage. Les contraintes Documentez :nombre de sites ; volume attendu ; pays ; besoins de consentement ; données interdites ; durée ; intégrations ; budget ; capacité d’exploitation ; délai de migration ; exigences contractuelles.Cette page évite qu’une démonstration impressionnante remplace l’analyse. La scorecard en 15 questions Notez chaque outil de 0 à 3 :0 : non couvert ou incompatible ; 1 : possible avec contournement important ; 2 : couvert avec configuration ou limite acceptable ; 3 : couvert naturellement et documenté.Appliquez ensuite un poids de 1 à 3 selon l’importance pour votre équipe. 1. Quelles questions métier l’outil répond-il sans reconstruction lourde ? Testez cinq scénarios concrets, pas une liste de menus. Exemple :afficher les pages d’entrée d’une campagne ; isoler les demandes de démo ; comparer trois sites ; exporter un rapport mensuel ; expliquer une chute de trafic.Un outil puissant mais incompréhensible pour ses utilisateurs réels a un coût élevé. 2. Quelle granularité est réellement nécessaire ? Distinguez :statistiques agrégées ; événements ; parcours ; cohortes ; funnels ; identifiants utilisateurs ; données publicitaires ; session replay.Chaque niveau ajoute des possibilités et une charge de gouvernance. Une équipe qui n’utilise que pages, sources et conversions ne doit pas sélectionner un produit principalement pour des fonctions d’analyse comportementale détaillée. 3. Que collecte la configuration par défaut ? Le défaut compte plus que la fiche produit. Vérifiez :cookies ou autres identifiants ; adresse IP ; URL complète ; user-agent ; géolocalisation ; identifiant publicitaire ; événements automatiques ; paramètres de requête ; signaux inter-sites.Appliquez l’audit des paramètres d’URL et demandez un payload de test. Notez mieux un outil dont le défaut correspond à votre politique, car chaque option à désactiver est une dette de configuration. 4. Les modes stricts et étendus sont-ils séparés clairement ? Certaines équipes veulent un socle minimal sans consentement dans les cas où le cadre le permet, puis des fonctions étendues après choix. Évaluez :séparation des configurations ; comportement avant consentement ; propagation du signal ; possibilité d’activer une fonction par erreur ; traçabilité des changements ; documentation des modes.Un bouton « privacy » vague ne suffit pas. 5. Pouvez-vous expliquer le flux de données ? L’outil doit permettre de répondre à :où arrive la requête ? quelles transformations ont lieu ? où sont stockées les données ? quels sous-traitants interviennent ? le fournisseur réutilise-t-il les données ? quels accès support existent ? quels transferts s’appliquent ?Utilisez le data collection summary comme format d’évaluation. 6. La localisation et les transferts correspondent-ils à vos contraintes ? Évaluez séparément :région d’hébergement ; entité contractante ; sous-traitants ; accès à distance ; mécanismes de transfert ; options d’auto-hébergement.« Hébergé dans l’UE » est un élément, pas une analyse complète. L’auto-hébergement offre du contrôle mais transfère aussi des responsabilités opérationnelles à l’équipe. 7. La rétention, la suppression et les sauvegardes sont-elles maîtrisables ? Demandez :périodes disponibles ; différence entre événements et rapports agrégés ; suppression automatique ; suppression par propriété ; délai de purge des sauvegardes ; traitement des exports ; suppression à la fin du contrat ; preuve ou journal d’opération.Une rétention illimitée par défaut n’est pas une fonctionnalité neutre. 8. Les accès multi-sites sont-ils adaptés ? Pour plusieurs propriétés, vérifiez :rôles par site ; groupes ; invitation d’agences ; accès lecture seule ; export ; journal d’administration ; SSO si nécessaire ; retrait d’accès ; vue portefeuille.Le modèle de dashboard multi-sites aide à transformer ces critères en scénarios de test. 9. Comment l’outil gère-t-il la qualité des données ? Vérifiez :filtrage des bots ; environnements de test ; doublons ; événements invalides ; paramètres inconnus ; délais d’ingestion ; changements de définition ; alertes ; fuseaux horaires ; cardinalité.Un rapport simple sans mécanisme de diagnostic peut être trop pauvre pour une équipe multi-sites. À l’inverse, une plateforme riche qui masque ses transformations peut être difficile à auditer. 10. Les événements et conversions restent-ils gouvernables ? Testez la création, modification et dépréciation d’un événement. Questions :le schéma est-il validé ? les propriétés libres sont-elles contrôlables ? peut-on interdire un champ ? un changement est-il versionné ? les objectifs historiques restent-ils compréhensibles ? une agence peut-elle modifier la collecte sans approbation ?La facilité d’ajouter un événement n’est pas toujours un avantage. Une absence de garde-fou crée rapidement une taxonomie illisible. 11. L’acquisition est-elle lisible sans configuration excessive ? Testez :source et medium ; campagnes UTM ; referrers ; direct ; pages d’entrée ; conversions par source ; canaux personnalisés ; modèles d’attribution si réellement nécessaires.Deux outils peuvent classer différemment le même parcours. Demandez comment les règles sont définies et si elles sont modifiables. 12. L’historique est-il migrable et comparable ? Vérifiez :import disponible ; format ; granularité ; métriques supportées ; coût ; durée ; différence de définitions ; conservation des données sources ; marquage de la date de rupture.Un import n’efface pas les différences de session, visiteur ou conversion. Le reporting doit souvent présenter une rupture méthodologique. 13. Le coût est-il prévisible à votre échelle ? Ne comparez pas uniquement le prix affiché. Calculez :abonnement selon volume ; dépassements ; sites supplémentaires ; utilisateurs ; modules ; stockage ; hébergement ; maintenance ; support ; consent management ; temps de configuration ; reporting manuel ; coût de migration et de sortie.Pour l’auto-hébergement, incluez mises à jour, sauvegardes, supervision, sécurité et disponibilité. Pour un SaaS, incluez la croissance du trafic et les fonctions nécessaires dans les plans supérieurs. Les tarifs doivent être vérifiés au moment de la décision. 14. Quelle charge opérationnelle l’équipe accepte-t-elle ? Classez les tâches :installation ; configuration ; tests ; maintenance ; accès ; conformité ; alertes ; sauvegardes ; support ; formation ; documentation.Un outil « gratuit » peut être coûteux en administration. Un outil simple peut être coûteux si l’équipe doit exporter chaque semaine pour répondre à une question absente. Le bon niveau de complexité est celui que l’organisation peut exploiter durablement. 15. Pouvez-vous sortir proprement ? Évaluez la réversibilité avant la signature :export complet ; formats ouverts ; API ; délai d’accès après résiliation ; suppression ; portabilité des configurations ; récupération des événements ; historique des définitions ; dépendance à des identifiants propriétaires.Une plateforme qui répond au besoin aujourd’hui mais enferme la mesure dans un format inexploitable crée une dette future. Un modèle de pondération Pour une PME SaaS multi-sites, les poids peuvent ressembler à ceci :Critère PoidsQuestions métier 3Granularité 2Collecte par défaut 3Séparation strict/étendu 3Flux et fournisseurs 3Localisation et transferts 2Rétention et suppression 3Accès multi-sites 3Qualité des données 2Gouvernance des événements 2Acquisition 2Migration 2Coût total 3Charge opérationnelle 3Réversibilité 2La note pondérée est : somme(note × poids) / somme(3 × poids)Le résultat peut être exprimé en pourcentage, mais ne transformez pas un écart de deux points en vérité scientifique. La discussion sur les critères compte plus que le classement final. Ajouter des critères éliminatoires Certains critères ne se compensent pas. Exemples :contrat ou DPA indisponible ; absence de suppression ; export impossible ; données interdites collectées sans contrôle ; accès multi-sites incompatibles ; transfert non acceptable ; coût hors budget ; charge d’exploitation impossible ; fonction indispensable absente.Un outil peut obtenir 85 % et être éliminé par un seul point critique. Comment lire les grandes familles d’outils Suites publicitaires et analytics riches GA4 s’intègre profondément à l’écosystème Google et propose de nombreuses dimensions, explorations et connexions publicitaires. Cette profondeur peut être cohérente pour des équipes équipées, ayant un besoin réel d’attribution et d’activation. Elle implique aussi une configuration, une gouvernance des événements et une lecture des scopes plus exigeantes. L’outil ne doit pas être choisi par défaut uniquement parce qu’il est connu. Plateformes contrôlables et auto-hébergeables Matomo offre des options cloud et auto-hébergées, avec un périmètre fonctionnel large. Umami et d’autres projets open source proposent des approches plus compactes. L’auto-hébergement donne du contrôle sur l’infrastructure, mais l’organisation devient responsable de l’exploitation. Demandez qui installe les mises à jour, restaure une sauvegarde et surveille les accès. Analytics SaaS privacy-first Plausible, Fathom, Simple Analytics et d’autres solutions privilégient des rapports plus lisibles et une collecte souvent plus limitée. Elles peuvent réduire la charge de configuration pour les besoins essentiels. Leur simplicité peut devenir une limite pour des analyses avancées, des schémas d’événements complexes ou certaines consolidations. Vérifiez les fonctions présentes, pas seulement la philosophie. Produits émergents Un produit en bêta ou en lancement peut proposer une approche mieux alignée avec votre gouvernance, mais il faut évaluer maturité, documentation, support, export, stabilité et roadmap démontrée. Ne notez jamais une promesse de roadmap comme une fonction disponible. Organiser le test en deux semaines Jour 1 : valider les scénarios Choisissez cinq questions, trois rôles et deux propriétés représentatives. Jours 2 à 4 : déployer un périmètre réduit Installez chaque candidat sur un environnement de test ou une propriété pilote. Utilisez les mêmes pages et événements. Jours 5 à 7 : auditer la collecte Comparez réseau, stockage documenté, consentement, paramètres d’URL et accès. Jours 8 à 10 : faire tester les utilisateurs Demandez à une personne marketing, une personne produit et un administrateur de réaliser les mêmes tâches sans assistance excessive. Jours 11 à 12 : tester export et suppression Exportez, révoquez un accès, modifiez la rétention et demandez la procédure de suppression. Jours 13 à 14 : noter et documenter Remplissez la scorecard, listez les critères éliminatoires et écrivez les compromis acceptés. Les erreurs de sélection les plus fréquentes Choisir sur une démonstration Une démonstration montre le meilleur parcours, pas les opérations quotidiennes. Choisir uniquement sur la privacy La privacy est une contrainte de conception majeure, mais l’outil doit aussi répondre aux décisions. Une solution inutilisée n’améliore pas la gouvernance. Choisir uniquement sur les fonctions Une fonction qui élargit la collecte ou exige une équipe dédiée peut être un coût, pas une valeur. Comparer les tarifs sans volume futur Calculez les scénarios à douze et vingt-quatre mois. Oublier les personnes Le meilleur outil théorique échoue si personne ne comprend les rapports ou ne maintient les règles. Conclusion Un comparatif utile ne demande pas « quel outil est le meilleur ? ». Il demande « quel outil crée le meilleur compromis pour cette organisation ? » La scorecard doit rendre visibles :les décisions attendues ; la collecte par défaut ; la gouvernance ; les droits ; la rétention ; le multi-sites ; le coût total ; la charge opérationnelle ; la capacité de sortie.Le résultat n’est pas une note universelle. C’est une décision explicable, révisable et documentée. FAQ Combien d’outils faut-il tester ? Trois candidats bien choisis suffisent souvent : un outil de référence riche, une option plus contrôlable et une option privacy-first simple. Ajoutez un quatrième uniquement s’il représente un modèle réellement différent. Une solution auto-hébergée est-elle toujours plus conforme ? Non. Elle augmente le contrôle potentiel, mais la conformité dépend de la configuration, de la sécurité, des accès, des finalités, de la rétention et de l’exploitation réelle. Peut-on comparer les prix une fois pour toutes ? Non. Les tarifs, plans et limites évoluent. Vérifiez-les au moment de la décision et modélisez plusieurs volumes. Comment traiter une fonctionnalité annoncée sur la roadmap ? Notez-la comme absente tant qu’elle n’est pas disponible et vérifiable. Une roadmap peut influencer le risque, mais ne doit pas remplacer un besoin actuel. Quelle différence entre un critère pondéré et un critère éliminatoire ? Un critère pondéré peut être compensé par d’autres forces. Un critère éliminatoire rend l’outil incompatible, même avec une excellente note globale. SourcesCNIL, Cookies : solutions pour les outils de mesure d’audience Règlement (UE) 2016/679, principes de minimisation, transparence et responsabilité Google Analytics, Analytics account structure Google Analytics, Data retention Matomo, Privacy Plausible, Data policy Fathom Analytics, Data policy Umami, Documentation

Lire l'article →
Politique de confidentialité analytics : les formulations utiles et celles à éviter

Politique de confidentialité analytics : les formulations utiles et celles à éviter

Une politique de confidentialité peut être juridiquement dense et techniquement fausse. Le cas est fréquent : le texte affirme que « seules des données anonymes » sont utilisées, tandis que le site transmet une URL complète, un identifiant de campagne et une adresse IP à plusieurs prestataires. À l’inverse, certaines politiques listent vingt catégories abstraites sans permettre au lecteur de comprendre ce que fait réellement l’analytics. La qualité ne vient pas du nombre de paragraphes. Elle vient de l’alignement entre :la collecte déployée ; les finalités ; les rôles des acteurs ; le consentement ou l’autre cadre applicable ; les durées ; les droits ; les mots utilisés.Le RGPD exige une information concise, transparente, compréhensible et aisément accessible. Les articles 12, 13 et 14 encadrent notamment le contenu de cette information. Une politique analytics utile doit donc rester lisible tout en décrivant les éléments importants avec assez de précision. Cet article propose une méthode éditoriale et opérationnelle. Il ne fournit pas une clause universelle et ne remplace pas une validation adaptée à l’organisation. Partir de la réalité, pas d’un modèle téléchargé Avant de rédiger, rassemblez quatre sources internes :l’inventaire des outils et traceurs ; le data collection summary ; les contrats, DPA et listes de sous-traitants ; la configuration du consentement et de la rétention.La politique doit être la vue publique de faits vérifiés. Elle ne doit pas servir à deviner le fonctionnement du site. Un modèle juridique peut aider à structurer les rubriques. Il ne peut pas savoir :si vous collectez l’URL complète ou seulement le chemin ; si l’adresse IP est stockée ; si un identifiant visiteur existe ; si le fournisseur réutilise des données ; si les événements contiennent du texte libre ; si une fonctionnalité étendue est activée après consentement ; si un export part vers un entrepôt ; si plusieurs sites partagent le même identifiant.Ces réponses doivent venir de l’audit. Utiliser une information en plusieurs niveaux Une politique unique de dix pages n’est pas toujours le meilleur point d’entrée. Une approche en couches améliore la lisibilité. Niveau 1 : information au moment pertinent À proximité du choix ou de la collecte, indiquez l’essentiel :finalité ; responsable ; caractère nécessaire ou optionnel ; lien vers le détail ; moyen d’accepter, refuser ou retirer lorsque le consentement s’applique.Pour une mesure strictement limitée ne nécessitant pas de consentement dans le contexte évalué, une mention courte peut renvoyer vers la section analytics de la politique. Niveau 2 : section analytics dédiée Cette section explique :ce qui est mesuré ; pourquoi ; comment les données sont réduites ; quel fournisseur intervient ; combien de temps les informations sont conservées ; comment exercer les droits ou poser une question ; quelles fonctionnalités dépendent du consentement.Niveau 3 : documentation approfondie Une page technique, une fiche fournisseur ou une documentation de collecte peut détailler les champs et transformations. Elle ne remplace pas l’information RGPD, mais permet aux lecteurs concernés de comprendre le système sans surcharger la première couche. Les niveaux doivent raconter la même histoire. Les rubriques à couvrir 1. L’identité du responsable de traitement Indiquez l’entité qui détermine les finalités et moyens du traitement, avec ses coordonnées. Lorsque le site appartient à un groupe, ne supposez pas que la marque visible est l’entité juridique responsable. Ajoutez les coordonnées du DPO lorsqu’il existe, ou un point de contact privacy clairement identifiable. Formulation utileLe responsable du traitement des données de mesure d’audience de ce site est [entité], joignable à [adresse ou formulaire]. Pour toute question relative à la protection des données, vous pouvez contacter [DPO ou contact].À éviterNous respectons votre vie privée.Cette phrase exprime une intention mais n’identifie personne. 2. Les finalités précises Séparez les finalités au lieu de tout regrouper sous « améliorer l’expérience ». Exemples :mesurer la fréquentation et les pages consultées ; détecter les erreurs de navigation ; comprendre les sources d’acquisition ; mesurer les demandes de démonstration ; produire des statistiques agrégées ; personnaliser des contenus ; mesurer des campagnes publicitaires.Les trois dernières ne relèvent pas nécessairement du même cadre. Si une mesure minimale fonctionne par défaut et une analytics étendue après consentement, dites-le clairement. Formulation utileNous utilisons une mesure d’audience limitée pour comprendre le volume de visites, les pages consultées et les principales sources de trafic. Les fonctionnalités d’attribution enrichie et [autre fonctionnalité] ne sont activées qu’après votre choix lorsqu’elles requièrent le consentement.À éviterNous collectons des données afin d’améliorer nos services et nos offres.La finalité est trop large pour être informative. 3. Les catégories de données et signaux La politique n’a pas besoin de reproduire chaque clé technique, mais elle doit donner une vision concrète. Selon la configuration :chemin de page ; heure de visite ; domaine référent ; paramètres de campagne autorisés ; type d’appareil et de navigateur réduit ; pays ou région approximative ; événement de conversion ; identifiant pseudonyme éventuel ; adresse IP reçue temporairement ; choix de consentement.Distinguez les données directement stockées des données utilisées seulement pour produire une information agrégée. Formulation utilePour chaque visite, nous enregistrons le chemin de la page, l’heure, le domaine référent lorsqu’il est transmis, une catégorie d’appareil et les paramètres de campagne autorisés. L’adresse IP est [décrire exactement le traitement]. Nous n’envoyons pas le contenu des formulaires à l’outil analytics.À éviterNous ne collectons aucune donnée personnelle.Cette affirmation est souvent trop absolue. Une adresse IP, un identifiant ou une combinaison de signaux peut relever des données personnelles selon le traitement. 4. La base légale et le cadre des traceurs Ne mélangez pas deux questions :l’opération de stockage ou d’accès sur le terminal au titre d’ePrivacy et du droit national ; la base légale du traitement de données personnelles au titre du RGPD.La checklist sur le consentement analytics décrit cette distinction. La formulation doit refléter l’analyse réelle. Elle peut mentionner, selon le cas :consentement ; intérêt légitime, après analyse adaptée ; mesure d’audience limitée entrant dans un cadre national d’exemption sous conditions ; fonctionnalité strictement nécessaire.N’utilisez pas la base légale comme un label marketing. Expliquez aussi comment le choix est recueilli ou comment l’analyse est documentée. À éviterNotre outil est conforme à la CNIL, aucun consentement n’est donc nécessaire.La CNIL précise que l’exemption dépend de la configuration et des conditions. Elle interdit également de présenter une solution comme « certifiée » ou « validée par la CNIL » sur la base de son auto-évaluation. 5. Les destinataires et fournisseurs Identifiez les catégories de destinataires et, lorsque cela améliore la transparence, les fournisseurs principaux. Précisez les rôles :équipes internes habilitées ; prestataire analytics ; hébergeur ; support technique ; agence ; entrepôt de données.« Partenaires de confiance » n’est pas une description suffisante. Pour chaque fournisseur, vérifiez s’il agit comme sous-traitant, responsable indépendant ou dans un autre schéma. La qualification dépend des faits et du contrat. 6. Les transferts internationaux Si des données sont accessibles ou transférées hors de l’Espace économique européen, expliquez les pays ou catégories de transferts, les mécanismes invoqués et les moyens d’obtenir plus d’informations, selon ce qui s’applique. Ne confondez pas :région d’hébergement ; siège du fournisseur ; lieux d’accès du support ; sous-traitants ; transfert juridique.Évitez d’écrire « données hébergées en Europe, donc aucun transfert » sans vérifier la chaîne complète. 7. Les durées de conservation Une durée vague telle que « aussi longtemps que nécessaire » doit être complétée par des critères ou périodes concrètes. Séparez :traceur ou identifiant ; événements bruts ; rapports agrégés ; logs de sécurité ; sauvegardes ; exports.Formulation utileLes événements analytics sont conservés pendant [durée]. Les statistiques agrégées sont conservées pendant [durée ou critère]. Les journaux techniques suivent une durée distincte de [durée]. Les exports manuels sont supprimés selon [procédure].Pour une mesure relevant du cadre français décrit par la CNIL, les recommandations de treize mois pour la durée de vie de certains traceurs et de vingt-cinq mois pour les informations collectées sont des repères à examiner. Elles ne doivent pas être copiées si votre configuration utilise une autre durée sans justification. 8. Les droits et moyens d’exercice Expliquez les droits applicables et fournissez un moyen simple de contact. Selon la base et le traitement, les droits peuvent inclure accès, rectification, effacement, limitation, opposition ou portabilité. Une analytics réellement anonyme peut ne pas permettre d’identifier une personne pour répondre à une demande individuelle. Dites-le avec précision, sans utiliser l’anonymat comme formule de dispense générale. Indiquez aussi la possibilité d’introduire une réclamation auprès de l’autorité de contrôle compétente. 9. Le retrait du consentement ou l’opposition Lorsque le consentement s’applique, fournissez un contrôle accessible pour le retirer aussi facilement qu’il a été donné, selon les règles applicables. Lorsque le traitement repose sur une autre base et qu’un droit d’opposition s’applique, expliquez la procédure. Le lien « gérer mes cookies » doit fonctionner sur mobile, rester visible et mettre à jour le comportement réel des tags. 10. La date et les changements Ajoutez une date de dernière mise à jour et un processus pour les modifications importantes. La politique doit être revue lorsqu’une équipe :ajoute un outil ; active une nouvelle finalité ; modifie un identifiant ; change la rétention ; ajoute un export ; change de fournisseur ; ouvre une propriété dans un nouveau pays ; modifie le consentement.Un historique concis des changements significatifs peut aider les lecteurs réguliers. Un exemple de section courte à adapter Le texte suivant est un squelette éditorial, pas une clause prête à publier.Mesure d’audience Nous utilisons [outil] afin de mesurer la fréquentation du site, les pages consultées et les principales sources de visite. Cette mesure nous aide à détecter les problèmes de navigation et à évaluer l’utilité de nos contenus. Selon notre configuration, les données traitées comprennent [liste concrète]. [Décrire le traitement de l’adresse IP et des identifiants]. Le contenu des formulaires et les paramètres d’URL non autorisés ne sont pas envoyés. [Fournisseur] intervient en qualité de [rôle] et traite les données dans [lieux et transferts pertinents]. Les données sont conservées pendant [durées par couche]. [Expliquer le cadre ePrivacy et la base RGPD retenus, avec les conditions et le fonctionnement du consentement le cas échéant]. Vous pouvez exercer vos droits ou poser une question à [contact]. Vous pouvez [retirer votre consentement / exercer votre opposition] via [moyen].Chaque crochet exige une réponse vérifiée. Les formulations qui fragilisent la crédibilité « Données totalement anonymes » Utilisez cette expression uniquement si l’équipe peut expliquer la méthode et démontrer que les données ne permettent plus raisonnablement d’identifier ou d’individualiser une personne. Sinon, préférez :données agrégées ; identifiants supprimés ; données pseudonymisées ; granularité réduite ; adresse IP non conservée dans les événements.Ces termes ne sont pas interchangeables. « Aucune donnée n’est partagée » Si un prestataire héberge ou traite la collecte, il reçoit des données en tant qu’acteur du traitement. La bonne phrase peut être « aucune donnée n’est vendue » ou « les données ne sont pas utilisées à des fins publicitaires », si c’est exact, mais pas « aucun partage » par réflexe. « Conforme au RGPD » Une conformité dépend du traitement, du responsable, de la configuration, du contrat et des opérations. Présentez les mesures concrètes plutôt qu’un verdict global. « Cookies nécessaires » Expliquez nécessaires à quoi. Un tracker publicitaire n’est pas nécessaire parce que l’équipe marketing le juge utile. « Nous pouvons modifier cette politique à tout moment » Cette clause n’explique ni l’information des personnes ni la gestion des changements significatifs. Ajoutez une date et un mécanisme raisonnable de notification lorsque nécessaire. Aligner la politique avec le produit Une incohérence apparaît souvent lorsqu’une équipe édite la politique une fois par an, alors que la stack change chaque semaine. Intégrez un contrôle dans le cycle de livraison :toute demande de nouveau tag indique finalité, données et fournisseur ; le propriétaire privacy ou analytics examine l’impact ; le data collection summary est mis à jour ; la politique et la CMP sont modifiées si nécessaire ; le déploiement est testé ; la preuve est conservée.Pour les paramètres d’URL, appliquez l’allowlist de collecte avant que le texte ne promette une collecte réduite. Audit éditorial en douze questions Relisez la section analytics et demandez :le responsable est-il identifiable ? les finalités sont-elles séparées ? les données sont-elles décrites concrètement ? la réception temporaire est-elle distinguée du stockage ? la base RGPD est-elle indiquée ? le régime des traceurs est-il expliqué sans raccourci ? les fournisseurs et rôles sont-ils clairs ? les transferts ont-ils été vérifiés ? les durées sont-elles concrètes ? les droits et moyens d’exercice sont-ils accessibles ? le retrait ou l’opposition fonctionne-t-il ? le texte correspond-il au réseau et à la configuration actuels ?Une réponse négative déclenche une correction de la stack ou du texte. Parfois des deux. Conclusion Une bonne politique de confidentialité analytics ne cherche pas à rassurer par des adjectifs. Elle donne des faits compréhensibles. Elle explique qui mesure, pourquoi, avec quels signaux, pour combien de temps, avec quels prestataires, sous quel cadre et avec quels contrôles pour les personnes. Le meilleur processus consiste à partir de l’inventaire technique, à rédiger en couches, à faire valider les qualifications nécessaires et à lier toute évolution de la stack à une mise à jour documentaire. La transparence n’est pas un exercice séparé du produit. C’est la description publique de sa gouvernance. FAQ Faut-il citer le nom de l’outil analytics dans la politique ? Le RGPD impose notamment d’informer sur les destinataires ou catégories de destinataires. Citer le fournisseur principal améliore souvent la clarté, mais la forme exacte dépend du traitement et de la structure de la notice. Peut-on écrire que les données sont anonymes ? Seulement si l’anonymisation est réellement démontrée. Une donnée pseudonymisée, agrégée ou privée d’adresse IP n’est pas automatiquement anonyme. La politique remplace-t-elle la bannière de consentement ? Non. La politique fournit l’information détaillée. Lorsqu’un consentement préalable est requis, le mécanisme doit permettre un choix valable avant le déclenchement des traceurs concernés. Faut-il lister chaque événement analytics ? Pas nécessairement dans la première couche. Décrivez des catégories concrètes et rendez une documentation plus détaillée accessible si elle est utile. Les événements sensibles ou inattendus doivent être explicitement analysés. Que faire lorsqu’un fournisseur change ses sous-traitants ? Évaluer l’impact sur les destinataires, transferts, contrats et risques, puis mettre à jour la documentation et l’information lorsque nécessaire. SourcesRèglement (UE) 2016/679, articles 12, 13 et 14 CNIL, RGPD : exemples de mentions d’information CNIL, Informer les personnes CNIL, Cookies : solutions pour les outils de mesure d’audience CEPD, Lignes directrices sur la transparence au sens du règlement 2016/679

Consentement analytics : ce qu’il faut vérifier avant de promettre « sans bannière »

Consentement analytics : ce qu’il faut vérifier avant de promettre « sans bannière »

« Analytics sans cookies » devient souvent, en une phrase, une promesse d’absence de consentement, puis de site sans bannière. Ces trois affirmations ne sont pas équivalentes. Un outil peut ne pas déposer de cookie tout en lisant ou écrivant une information sur le terminal par un autre mécanisme. Une solution peut proposer une configuration de mesure d’audience limitée, tandis que d’autres modules du même produit exigent une analyse différente. Et même si l’analytics respecte un cadre strict, un site peut charger des vidéos, formulaires, pixels publicitaires ou outils de support qui rendent une interface de consentement nécessaire. La bonne question n’est donc pas : « l’outil est-il cookieless ? » Elle est :Quels traitements et traceurs sont effectivement déployés sur ce site, dans cette configuration, pour quelles finalités et sous quelles conditions ?Cet article présente une grille de vérification. Il ne constitue pas un avis juridique et doit être adapté aux pays, aux usages et à la configuration du site. Trois couches à ne pas confondre 1. La technologie de stockage ou d’accès Le mot « cookie » décrit une technique parmi d’autres. Le cadre ePrivacy vise plus largement le stockage d’informations dans le terminal d’un utilisateur ou l’accès à des informations déjà stockées, selon les règles transposées dans chaque État. Des identifiants en local storage, certains pixels, SDK, mécanismes de fingerprinting ou autres accès au terminal peuvent donc poser la même question de consentement, même sans cookie HTTP traditionnel. Cookieless décrit une caractéristique technique. Ce n’est pas une qualification juridique complète. 2. Le régime ePrivacy des traceurs En France, l’article 82 de la loi Informatique et Libertés transpose le cadre relatif aux traceurs. Le principe est l’information et le consentement préalable pour les opérations concernées, avec des exceptions notamment lorsque le traceur est strictement nécessaire à la fourniture d’un service expressément demandé. La CNIL décrit aussi des conditions sous lesquelles certains traceurs de mesure d’audience peuvent entrer dans un périmètre d’exemption. Il s’agit d’un cadre étroit, pas d’une exemption générale pour toute analytics. 3. Le traitement de données personnelles au titre du RGPD Même lorsqu’une opération sur le terminal ne requiert pas de consentement ePrivacy dans une configuration donnée, le traitement peut rester soumis au RGPD s’il porte sur des données personnelles. Il faut alors documenter notamment les finalités, la base légale pertinente, l’information, la minimisation, la durée, les destinataires, les transferts, la sécurité et les droits. L’absence de bannière ne signifie donc ni absence de traitement, ni absence d’information. Les conditions françaises d’une mesure d’audience limitée La CNIL indique que, pour être limités à ce qui est strictement nécessaire à la fourniture du service et pouvoir être exemptés de consentement dans le cadre décrit, les traceurs doivent notamment :avoir une finalité strictement limitée à la mesure de l’audience du site ou de l’application ; être utilisés pour le compte exclusif de l’éditeur ; produire uniquement des données statistiques anonymes ; ne pas conduire à un recoupement avec d’autres traitements ; ne pas transmettre de données non anonymes à des tiers ; ne pas permettre un suivi global entre plusieurs sites ou applications.La CNIL recommande également l’information des utilisateurs, une durée de vie des traceurs limitée, par exemple treize mois sans prorogation automatique, une conservation des informations collectées limitée à vingt-cinq mois et un réexamen périodique de ces durées. Chaque terme compte. « Finalité strictement limitée » Mesurer les performances techniques, les contenus consultés ou les problèmes de navigation peut entrer dans la logique décrite. Constituer des audiences publicitaires, enrichir un profil CRM, personnaliser des annonces ou suivre une personne entre services relève d’autres finalités. Une même interface produit peut proposer les deux. C’est la fonctionnalité activée qui doit être auditée. « Pour le compte exclusif de l’éditeur » Le fournisseur ne doit pas transformer la collecte en ressource pour son propre ciblage, son profilage ou une mesure transversale non compatible avec le cadre considéré. Lisez le contrat, la documentation du produit et la liste des sous-traitants. Une affirmation commerciale ne suffit pas. « Statistiques anonymes » Le mot anonyme est exigeant. Supprimer un nom, tronquer une IP ou hacher un identifiant ne garantit pas automatiquement l’anonymat. Si un signal permet encore de distinguer ou relier une personne, l’analyse doit rester prudente. Demandez au fournisseur de décrire les transformations et les risques de réidentification. « Pas de suivi global entre sites » Un identifiant commun utilisé pour dédupliquer une personne entre plusieurs propriétés change le périmètre. Cette règle est particulièrement importante pour les groupes et agences qui souhaitent consolider leur audience. Le tableau de bord multi-sites peut agréger des indicateurs sans imposer un identifiant transversal. La checklist avant toute promesse « sans bannière » 1. Inventorier tous les composants du site Ne commencez pas par l’outil analytics. Commencez par le site complet :analytics ; gestionnaire de tags ; vidéos intégrées ; cartes ; chat et support ; formulaires ; anti-fraude ; A/B testing ; session replay ; publicité ; réseaux sociaux ; CDN et sécurité ; scripts des partenaires ; SDK mobiles éventuels.Réalisez un audit des traceurs avant et après chaque choix de consentement. Testez plusieurs pages et parcours. Une analytics stricte ne neutralise pas un pixel publicitaire chargé ailleurs. 2. Décrire les finalités réelles Pour chaque composant, écrivez ce qu’il permet réellement :statistiques agrégées de fréquentation ; analyse de campagne ; personnalisation ; publicité ; sécurité ; enregistrement d’interactions ; assistance ; expérimentation produit.Évitez la catégorie unique « amélioration du service ». Elle est trop large pour gouverner la configuration. 3. Vérifier les opérations sur le terminal Documentez :cookies déposés ou lus ; local storage ; session storage ; identifiants de cache ; SDK ; pixels ; accès à des caractéristiques du terminal ; mécanismes de consentement et de retrait.Le fait qu’aucun cookie n’apparaisse dans un outil de scan ne clôt pas l’analyse. 4. Vérifier les données collectées et les transformations Le data collection summary doit répondre à des questions concrètes :l’adresse IP est-elle reçue, utilisée et stockée ? l’URL complète est-elle transmise ? le user-agent est-il conservé brut ou réduit ? un identifiant visiteur est-il créé ? peut-il être stable entre des jours ou des sites ? les paramètres UTM sont-ils conservés ? des événements libres peuvent-ils contenir du texte ? quelles données sont agrégées ? à quel moment une donnée devient-elle non individualisable ?Un mode « anonyme » dont personne ne peut expliquer le fonctionnement n’est pas une preuve. 5. Vérifier l’usage par le fournisseur Demandez :le fournisseur agit-il uniquement comme sous-traitant pour cette collecte ? réutilise-t-il certaines données pour ses propres finalités ? combine-t-il les données entre clients ? fournit-il un benchmark à partir de données individualisées ? entraîne-t-il un modèle ou enrichit-il un autre produit ? quels sous-traitants reçoivent les données ? quels transferts internationaux s’appliquent ?Une fonctionnalité de benchmark peut parfois être conçue sur des données agrégées et séparées. Elle doit néanmoins être comprise, pas supposée. 6. Vérifier la configuration exacte La documentation peut indiquer « configurable pour respecter les critères ». Cela ne signifie pas que la configuration par défaut de votre compte les respecte. Conservez une preuve des réglages :capture ou export de configuration ; version du script ; paramètres de collecte ; modules désactivés ; domaines autorisés ; rétention ; options de partage ; date de vérification ; responsable.La CNIL invite les éditeurs à demander aux fournisseurs les documents permettant de justifier le cadre et ses modalités opérationnelles. 7. Examiner la rétention Distinguez :durée de vie d’un traceur ou identifiant ; rétention des événements bruts ; rétention des statistiques ; logs techniques ; sauvegardes ; exports.La suppression automatique doit être vérifiée. Une durée affichée dans le tableau de bord ne couvre pas nécessairement les exports créés par l’équipe. 8. Vérifier l’information des visiteurs Même lorsqu’un consentement n’est pas requis pour une mesure strictement encadrée, la CNIL recommande d’informer les utilisateurs de sa mise en œuvre, par exemple dans la politique de confidentialité. L’information doit expliquer, selon le contexte :la finalité ; les données ou catégories pertinentes ; le fonctionnement général ; la durée ; le fournisseur ; les destinataires ; les droits et moyens de contact ; les transferts pertinents.« Nous utilisons une analytics respectueuse de la vie privée » est trop vague. 9. Tester le refus et le retrait Lorsqu’une partie de la stack repose sur le consentement :aucun traceur concerné ne doit partir avant le choix ; le refus doit être aussi simple que l’acceptation selon les règles applicables ; le retrait doit produire un effet ; le signal doit atteindre tous les tags concernés ; les nouvelles pages et composants doivent respecter le choix.Testez le comportement, pas seulement l’apparence de la CMP. 10. Faire valider le périmètre La décision finale appartient au responsable de traitement, accompagné si nécessaire par son DPO ou son conseil. Conservez l’analyse :pays concernés ; finalités ; inventaire ; critères examinés ; documentation fournisseur ; configuration ; tests ; risques résiduels ; date et responsables ; déclencheurs de révision.Une conclusion peut être différente entre un site corporate français, une application authentifiée et un ensemble de propriétés internationales. Cookieless, Consent Mode et mesure sans bannière Cookieless Le terme peut signifier :aucun cookie persistant ; aucun cookie dans un mode précis ; stockage alternatif ; événement sans identifiant ; identifiant dérivé côté serveur ; simple absence de cookies publicitaires.Demandez une définition technique. Le mot seul ne suffit pas. Consent Mode Un mode de consentement transmet l’état du choix aux tags et peut modifier leur comportement. Selon le produit et la configuration, des signaux peuvent encore être envoyés sans cookie publicitaire. Ce mécanisme aide à appliquer une décision. Il ne décide pas à la place de l’éditeur si la collecte sans consentement est permise. Il ne transforme pas non plus une finalité publicitaire en mesure strictement nécessaire. « Pas de bannière » Cette phrase ne peut être évaluée qu’au niveau du site complet. Elle peut être raisonnable lorsqu’aucun composant non nécessaire n’est déployé avant consentement et que la mesure d’audience utilisée respecte effectivement le cadre applicable. Elle devient trompeuse si elle repose seulement sur l’absence de cookie analytics. Les formulations à utiliser ou éviter À éviterpromesse de conformité RGPD totale ; exemption valable dans tous les cas ; équivalence automatique entre absence de cookies et absence de bannière ; certification officielle par la CNIL ; validation officielle par l’autorité ; « aucune donnée personnelle » « aucune analyse juridique nécessaire »La CNIL précise qu’une solution ne peut pas se présenter comme certifiée ou validée par elle sur la seule base de l’auto-évaluation relative à la mesure d’audience. Formulations plus précises« cookieless par défaut » « conçu pour une collecte minimale » « peut être configuré pour une mesure d’audience limitée » « l’applicabilité d’une exemption dépend des finalités, de la configuration et du contexte » « les utilisateurs restent informés de la mesure mise en œuvre » « la stack complète du site doit être auditée »La précision protège la crédibilité autant que la conformité. Quand conserver une bannière Une bannière ou autre mécanisme de consentement reste généralement nécessaire lorsque le site active, selon le cadre applicable :publicité personnalisée ; retargeting ; partage avec des régies ; suivi inter-sites ; enrichissement de profils ; certains outils de session replay ; personnalisation non nécessaire ; intégrations tierces déposant des traceurs non essentiels ; analytics dépassant le périmètre d’une mesure limitée.L’article sur le session replay et la consultation CNIL montre pourquoi une fonctionnalité détaillée d’observation ne doit pas être assimilée à une statistique d’audience agrégée. Un processus de décision simple Cas A : mesure strictement limitée L’équipe utilise une collecte minimale, sans suivi transversal, sans réutilisation fournisseur, avec statistiques anonymes, rétention cadrée, information et documentation. Action : analyser et documenter l’applicabilité du cadre local, puis vérifier le reste du site. Cas B : analytics enrichie après consentement L’équipe veut des événements détaillés, de l’attribution avancée ou des identifiants plus persistants. Action : bloquer les fonctionnalités concernées avant consentement, transmettre le choix correctement et documenter le traitement. Cas C : stack mixte Une mesure minimale fonctionne par défaut, puis des modules étendus sont activés après consentement. Action : séparer techniquement les modes, éviter qu’un changement de rapport active silencieusement une collecte, et tester chaque transition. Cette séparation stricte est plus crédible qu’un réglage unique supposé convenir à tous les usages. Conclusion Une promesse « sans bannière » ne se déduit pas du mot cookieless. Elle résulte d’une analyse du site complet, de ses finalités, de ses opérations techniques et de sa configuration. Avant de communiquer, vérifiez :tous les composants ; les finalités ; les accès au terminal ; les données et identifiants ; les usages du fournisseur ; la configuration ; la rétention ; l’information ; le fonctionnement du consentement lorsqu’il s’applique ; la documentation de la décision.Le résultat peut être une stack sans bannière pour un périmètre strict, une stack avec consentement pour des usages étendus, ou une combinaison clairement séparée. La qualité vient de cette distinction, pas d’un slogan. FAQ Une analytics sans cookies est-elle automatiquement exemptée de consentement ? Non. Il faut examiner les autres opérations sur le terminal, les finalités, les données, les identifiants et le droit national applicable. Cookieless est une caractéristique technique, pas une conclusion juridique. La CNIL certifie-t-elle les outils analytics exemptés ? Non. La CNIL fournit un cadre et un outil d’auto-évaluation, mais précise qu’une solution ne peut pas se présenter comme « certifiée » ou « validée par la CNIL » sur cette base. Peut-on informer les visiteurs sans afficher une bannière ? Oui, lorsque le consentement n’est pas requis pour la collecte considérée, une information peut être fournie dans la politique de confidentialité ou un espace approprié. Son contenu doit rester clair et exact. Les UTM empêchent-ils une exemption ? Pas automatiquement, mais leur usage et leur combinaison doivent rester compatibles avec la finalité limitée, la minimisation et l’absence de suivi transversal. Ils ne doivent jamais contenir de donnée personnelle. Qui décide si le site peut fonctionner sans bannière ? Le responsable de traitement prend la décision et doit pouvoir la documenter, avec l’appui de son DPO ou conseil lorsque nécessaire. Le fournisseur seul ne peut pas garantir la conclusion pour tous les sites. SourcesCNIL, Cookies : solutions pour les outils de mesure d’audience CNIL, Cookies et traceurs : que dit la loi ? CNIL, Cadre de mesure d’audience à comprendre avant de choisir un outil Directive 2002/58/CE relative à la vie privée et aux communications électroniques CEPD, Lignes directrices 05/2020 sur le consentement CEPD, Lignes directrices 2/2023 sur le champ technique de l’article 5(3) ePrivacy

Tableau de bord multi-sites : suivre 5, 10 ou 30 sites sans perdre la lisibilité

Tableau de bord multi-sites : suivre 5, 10 ou 30 sites sans perdre la lisibilité

Suivre un site est un problème de mesure. En suivre dix devient un problème de gouvernance. Au départ, chaque équipe crée sa propriété analytics, nomme ses événements et construit son tableau de bord. Quelques mois plus tard, le groupe dispose de dix définitions de « conversion », trois fuseaux horaires, des sources UTM incompatibles et plusieurs comptes dont personne ne connaît le propriétaire. Le problème n’est pas qu’il manque des graphiques. Il manque une structure commune. Un tableau de bord multi-sites utile doit permettre deux mouvements :comparer les propriétés à partir d’un socle homogène ; descendre dans chaque site sans effacer son contexte métier.Chercher à tout fusionner produit une moyenne abstraite. Tout séparer empêche de voir le portefeuille. La bonne architecture garde les deux niveaux. Commencer par une carte des propriétés Avant de choisir les indicateurs, listez les sites et leur rôle.Propriété Rôle Public principal Conversion utile ResponsableSite corporate Réassurance Prospects, partenaires Contact qualifié CommunicationSite produit A Acquisition PME Demande de démo Growth ASite produit B Acquisition ETI Rendez-vous Growth BCentre d’aide Support Clients Résolution autonome SupportBlog Découverte Audience B2B Inscription ou passage produit ContentDeux sites avec des objectifs différents ne doivent pas être classés uniquement par volume de visites. Le centre d’aide peut être très performant quand il réduit les demandes de support, même si son taux de démonstration est nul. La carte doit également contenir :domaine et sous-domaines ; environnement de production ; outil et identifiant de propriété ; fuseau horaire ; devise éventuelle ; date de création ; propriétaire métier ; propriétaire technique ; personnes ayant accès ; mode de collecte ; durée de conservation ; statut actif, en migration ou archivé.Cette fiche devient l’inventaire de référence. Définir un contrat de mesure commun Le socle multi-sites n’est pas un tableau de bord. C’est un petit contrat de mesure appliqué à chaque propriété. Dimensions communes Choisissez une définition commune pour :page ou chemin ; domaine référent ; source, medium et campagne ; pays ou zone géographique ; type d’appareil ; date et fuseau horaire ; événements principaux ; statut de conversion.Les paramètres d’URL doivent suivre une politique de filtrage commune. Les campagnes doivent utiliser la même nomenclature UTM. Événements communs Une petite bibliothèque suffit : form_submitted demo_requested signup_completed download_completed outbound_clicked search_usedChaque événement doit avoir :une définition ; une condition de déclenchement ; des propriétés autorisées ; un propriétaire ; un test ; une version.Un même nom ne doit pas représenter deux actions différentes. À l’inverse, trois noms différents pour la même demande de contact empêchent toute comparaison. Règles de qualité communes Documentez :filtrage des environnements de test ; exclusion ou traitement des bots ; gestion des domaines internes ; consentement et modes de collecte ; normalisation des chemins ; fuseau horaire ; calendrier de déploiement ; seuils d’alerte.Le résumé de collecte peut contenir le socle global et les exceptions de chaque propriété. Séparer trois niveaux de lecture Un bon système multi-sites ne met pas tous les graphiques sur une seule page. Il crée trois vues. Niveau 1 : la vue portefeuille Cette vue répond aux questions de direction :quels sites gagnent ou perdent du trafic utile ? où les conversions progressent-elles ? quelle propriété présente une anomalie ? quelles équipes ont besoin d’un diagnostic ? quel site ne remonte plus de données ?Elle doit rester courte. Un tableau avec une ligne par propriété est souvent plus utile qu’une mosaïque de vingt courbes. Colonnes possibles :Site Visites Évolution Conversions utiles Taux Canal principal Statut donnéesCorporate 24 500 +6 % 132 0,54 % Organique OKProduit A 18 100 -4 % 284 1,57 % Paid search À examinerProduit B 9 600 +12 % 96 1,00 % Partenaires OKAide 41 000 +2 % n/a n/a Direct OKLes chiffres sont illustratifs. Le statut données est essentiel : un volume en baisse n’a pas le même sens si le script a cessé de fonctionner. Niveau 2 : la vue propriété Chaque site dispose de son tableau de bord métier :acquisition ; pages d’entrée ; contenus ; conversions ; événements ; tendances ; qualité des données.Cette vue conserve les dimensions propres au site. Un SaaS peut suivre l’essai démarré, tandis qu’un centre d’aide suit la recherche sans résultat ou le passage vers le support. Niveau 3 : le diagnostic Le diagnostic sert aux analystes et développeurs :événements par version ; erreurs de collecte ; paramètres inconnus ; écarts entre client et serveur ; ruptures temporelles ; domaines inattendus ; volumes de tests ; délai d’ingestion.Il ne doit pas encombrer le reporting de direction. Mais son absence transforme chaque anomalie en enquête manuelle. Les KPIs que l’on peut comparer Tous les indicateurs ne sont pas additionnables. Volume de visites ou pages vues Ils donnent un ordre de grandeur, mais favorisent naturellement les sites à forte audience. Utilisez-les avec une tendance et un contexte. Conversions définies sur un socle commun Une « conversion utile » peut regrouper plusieurs actions si la règle est explicite, par exemple :demande de démo ; formulaire de contact qualifié ; inscription validée ; achat confirmé.Pour comparer, conservez aussi le détail par type. Une somme seule peut cacher un déplacement vers des actions de moindre valeur. Taux de conversion Le taux permet de comparer des propriétés de tailles différentes, à condition d’utiliser le même dénominateur. Documentez s’il s’agit de visites, visiteurs, sessions ou pages d’entrée. Part des canaux La répartition organique, payante, email, partenaire, referral et direct aide à comprendre la dépendance de chaque site. Elle suppose une taxonomie de campagnes commune. Santé de collecte Ajoutez des KPIs techniques :dernière donnée reçue ; variation du volume d’événements ; part d’événements rejetés ; nombre de paramètres inconnus ; pages sans titre ou chemin ; évolution brutale du direct.La fiabilité de la donnée est un KPI de gouvernance. Ce qu’il ne faut pas additionner naïvement Les visiteurs uniques Une même personne peut visiter plusieurs domaines. Additionner les visiteurs uniques de chaque propriété la compte plusieurs fois. Créer un identifiant global pour dédupliquer les personnes change fortement le profil de collecte. En France, la CNIL précise notamment que l’usage d’un même identifiant à travers plusieurs sites pour un suivi global exclut la mesure du cadre d’exemption décrit pour certains traceurs d’audience. Une équipe ne doit donc pas introduire un suivi transversal uniquement pour obtenir un total plus propre. Pour un reporting frugal, acceptez :une somme de visites par propriété ; une portée non dédupliquée clairement nommée ; ou une analyse agrégée sans identifiant individuel, lorsque la méthode est adaptée.Les conversions hétérogènes Un téléchargement de brochure ne vaut pas automatiquement une vente. Présentez un socle de conversions, puis la composition. Les moyennes simples La moyenne des taux de conversion de dix sites donne le même poids à un site de 100 visites et à un site de 100 000 visites. Utilisez un taux global pondéré ou affichez la distribution. Les périodes non alignées Des fuseaux horaires ou calendriers de campagne différents peuvent déplacer les événements d’un jour ou d’une semaine. Normalisez le temps avant de comparer. Comparer sans punir les petits sites Une vue multi-sites devient vite un classement. C’est rarement une bonne idée. Utilisez plutôt quatre axes :niveau actuel : volume ou taux ; évolution : comparaison à la période précédente ; objectif local : progression vers une cible propre au site ; qualité de mesure : confiance dans la donnée.Un site de niche peut avoir peu de trafic mais une progression saine et des conversions de grande valeur. Une propriété très visitée peut cacher une dépendance excessive au paid ou un tracking cassé. Les sparklines et intervalles de comparaison sont plus utiles qu’un podium. Structurer les accès Le multi-sites augmente le risque d’accès excessifs. Définissez des rôles :propriétaire portefeuille : voit toutes les propriétés et gère les standards ; propriétaire de site : administre sa propriété ; analyste : consulte et exporte selon le besoin ; contributeur : voit les rapports sans modifier la collecte ; agence ou partenaire : accès limité aux propriétés du contrat ; support technique : accès temporaire et journalisé lorsque nécessaire.Évitez les comptes partagés. Revue trimestrielle des accès, retrait automatique au départ d’un prestataire et principe du moindre privilège. Une agence qui gère dix clients ne devrait pas utiliser un seul compte administrateur permanent sur tous les environnements. Organiser le cycle de gouvernance Chaque semaine : surveiller la santé Automatisez des alertes simples :aucune donnée reçue depuis un délai défini ; chute ou hausse anormale ; apparition d’un domaine inconnu ; augmentation des événements rejetés ; changement de part du direct.Chaque mois : lire les décisions Réunissez les propriétaires de sites autour de trois questions :qu’est-ce qui a changé ? quelle action en découle ? quelle hypothèse sera testée ensuite ?Le reporting ne doit pas devenir une tournée de chiffres. Chaque trimestre : revoir le contrat Vérifiez :événements communs ; nomenclature UTM ; propriétés inactives ; accès ; rétention ; nouveaux fournisseurs ; écarts de configuration ; objectifs métier.À chaque lancement : utiliser une checklist Avant d’ajouter un site :attribuer les propriétaires ; choisir le fuseau horaire ; appliquer le socle de collecte ; configurer les filtres ; tester les événements ; vérifier le consentement ; ajouter la propriété au portefeuille ; documenter les exceptions ; définir les alertes ; programmer la première revue.Choisir l’architecture d’outil Plusieurs modèles existent. Une propriété par site C’est la structure la plus lisible pour les accès, la rétention et les configurations. Elle exige une couche portefeuille pour comparer. Une propriété commune avec dimension de site Elle simplifie certains rapports mais mélange les droits, les configurations et les risques de collecte. Une erreur sur une propriété affecte l’ensemble. Une propriété par site plus une vue consolidée C’est souvent le meilleur compromis : séparation opérationnelle et agrégation pour le pilotage. Certains outils proposent des fonctions de roll-up ou de vue consolidée. Vérifiez toujours le plan nécessaire, la méthode de déduplication, les droits et les données réellement regroupées. Le choix dépend moins du nombre de sites que de leur indépendance : équipes, marques, finalités, régions, droits d’accès et configurations privacy. Un modèle de dashboard en une page Bandeau supérieurvisites du portefeuille ; conversions utiles ; taux global pondéré ; nombre de propriétés saines ; nombre d’anomalies ouvertes.Tableau central Une ligne par propriété avec tendance, conversion, canal et statut. Bloc acquisition Répartition des canaux par site, idéalement sous forme de parts comparables. Bloc contenu Top pages d’entrée et pages qui progressent, avec filtre par propriété. Bloc qualité Données manquantes, événements rejetés, accès à revoir et déploiements récents. Chaque bloc doit conduire à une page de détail. La vue portefeuille signale, elle n’explique pas tout. Conclusion Le suivi multi-sites fonctionne quand la gouvernance précède la visualisation. Il faut :une carte claire des propriétés ; un contrat de mesure commun ; des exceptions documentées ; trois niveaux de lecture ; des indicateurs comparables ; des accès limités ; un cycle de revue ; une consolidation qui n’impose pas un suivi individuel transversal.Le bon tableau de bord ne cherche pas à rendre tous les sites identiques. Il leur donne un langage commun sans perdre leur rôle. FAQ Faut-il une propriété analytics par site ? C’est souvent le choix le plus clair pour séparer les accès et configurations. Une vue consolidée peut ensuite comparer les propriétés. Une propriété commune reste possible, mais elle doit être justifiée par des besoins et droits réellement communs. Peut-on additionner les visiteurs uniques de plusieurs sites ? Pas comme une audience dédupliquée. Une personne peut être comptée sur plusieurs propriétés. Indiquez qu’il s’agit d’une somme non dédupliquée ou utilisez une méthode agrégée adaptée, sans introduire par défaut un identifiant global. Combien de KPIs dans la vue portefeuille ? Cinq à huit colonnes bien définies suffisent généralement : volume, tendance, conversion, taux, canal principal et santé de collecte. Le détail appartient aux vues par propriété. Comment gérer des objectifs différents selon les sites ? Gardez un petit socle commun, puis ajoutez des indicateurs locaux. Comparez aussi chaque site à son propre objectif et à sa tendance, pas uniquement aux autres. À quelle fréquence revoir les accès ? Une revue trimestrielle est une pratique raisonnable, complétée par un retrait immédiat lors des départs ou fins de contrat. SourcesCNIL, Cookies : solutions pour les outils de mesure d’audience Google Analytics, Analytics account structure Google Analytics, Roll-up properties Matomo, Roll-Up Reporting Plausible, Consolidated view Règlement (UE) 2016/679, principes de minimisation et de limitation des finalités

Quels paramètres d’URL filtrer dans une analytics privacy-first ?

Quels paramètres d’URL filtrer dans une analytics privacy-first ?

Une URL peut sembler anodine tout en transportant beaucoup plus d’information que le chemin de la page. https://example.com/confirmation? email=alice@example.com& order_id=84721& utm_source=newsletter& session_token=abc123Si un outil analytics collecte l’URL complète, ces valeurs peuvent se retrouver dans les événements, les logs, les exports, les captures d’écran et les rapports partagés. Le problème ne vient pas seulement de l’outil. Il commence souvent dans l’application, qui place une information excessive dans l’adresse. Une approche privacy-first traite le sujet à deux niveaux :ne pas mettre de donnée sensible ou personnelle dans l’URL ; ne transmettre à l’analytics que les paramètres explicitement utiles.Le filtre n’est donc pas une rustine unique. C’est un contrôle de défense en profondeur. Pourquoi les query parameters demandent un traitement spécifique La partie située après ? s’appelle la chaîne de requête. Elle contient des paires clé-valeur séparées par &. Ces paramètres peuvent servir à :attribuer une campagne ; paginer ou trier une liste ; sélectionner une langue ; préremplir un formulaire ; identifier une ressource ; transporter un jeton ; suivre une expérience ; mémoriser un filtre de recherche.Le navigateur, le serveur, le CDN, les outils de supervision et les scripts tiers peuvent tous observer une partie de l’URL. OWASP rappelle que des informations sensibles placées dans la query string peuvent apparaître dans l’historique, les journaux, les systèmes intermédiaires et parfois les en-têtes de provenance, même lorsque la connexion utilise HTTPS. HTTPS protège le transport entre deux points. Il ne rend pas le contenu de l’URL invisible aux systèmes autorisés qui la traitent. La règle principale : autoriser, plutôt que tenter de tout bloquer Une blocklist énumère les paramètres interdits : email phone token user_idElle échoue dès qu’un développeur introduit customer_email, invitee, auth ou une clé inconnue. Une allowlist énumère les paramètres dont l’usage analytics a été justifié : utm_source utm_medium utm_campaign utm_contentTout le reste est supprimé avant transmission ou stockage. L’allowlist est généralement plus robuste pour une collecte minimale. Elle réduit aussi la fragmentation des rapports : /produits/?sort=price, /produits/?sort=name et /produits/?session=xyz peuvent être regroupés sous un chemin stable lorsque ces variantes ne répondent à aucune question de pilotage. Il existe toutefois des applications où certains paramètres fonctionnels doivent rester visibles. La bonne méthode n’est pas « supprimer tout ce qui suit ? », mais classer chaque famille. Une grille de décision en six catégories 1. Paramètres de campagne autorisés Exemples : utm_source utm_medium utm_campaign utm_contentIls peuvent être utiles pour lire l’acquisition, à condition d’appliquer une nomenclature contrôlée et de ne jamais y placer d’identifiant personnel. Le guide sur les UTM, referrers et trafic direct détaille ces règles. Décision possible :collecter une liste courte ; normaliser la casse et les valeurs ; séparer les dimensions de campagne du chemin de page ; supprimer les paramètres de l’URL affichée après capture si cela ne casse pas le parcours.2. Paramètres fonctionnels sans intérêt analytique Exemples : sort view page theme currencyIls peuvent être nécessaires à l’interface sans mériter une dimension analytics. Les garder dans le rapport « pages » crée souvent des centaines de lignes. Décision possible :ne pas les envoyer dans l’URL de page ; mesurer un événement dédié si une décision produit dépend réellement du tri ou de la vue ; conserver seulement une catégorie réduite, par exemple filter_applied, sans recopier la valeur libre.3. Paramètres de contenu potentiellement utiles Exemples : lang category plan variantLeur utilité dépend du modèle de données. Avant de les autoriser, posez trois questions :cette valeur change-t-elle la décision ? existe-t-il une liste fermée de valeurs ? peut-elle contenir du texte saisi ou un identifiant ?Si les réponses sont favorables, transformez le paramètre en dimension contrôlée. Sinon, retirez-le. 4. Identifiants métier Exemples : order_id invoice customer ticket workspaceIls permettent souvent de relier une visite à un dossier, une commande ou un compte. Même lorsqu’ils ne contiennent pas un nom, ils peuvent devenir des données personnelles par recoupement. Décision recommandée :ne pas les transmettre à l’analytics généraliste ; mesurer une catégorie ou un statut agrégé ; traiter les besoins de diagnostic dans un système opérationnel séparé, avec des accès et une rétention adaptés.5. Données personnelles ou texte libre Exemples : email name phone address search messageLe texte libre est particulièrement risqué. Un champ de recherche interne peut contenir un nom, un problème médical, une adresse ou une phrase confidentielle. Décision recommandée :empêcher la donnée d’entrer dans l’URL ; la supprimer du payload analytics ; vérifier aussi les logs et outils tiers ; ne mesurer, si nécessaire, qu’une catégorie ou la présence d’une recherche.6. Secrets et jetons Exemples : token code jwt signature password_reset inviteCes valeurs ne doivent pas être capturées. Elles peuvent donner accès à une action ou à une ressource. Décision recommandée :revoir le design du parcours ; utiliser des jetons à durée courte et usage limité quand l’URL est techniquement nécessaire ; éviter leur journalisation ; supprimer le paramètre de l’adresse dès que possible ; exclure entièrement les pages concernées de l’analytics si le contrôle n’est pas fiable.Filtrer au bon endroit Niveau 1 : dans l’application La meilleure protection consiste à ne pas construire d’URL excessive. Ne préremplissez pas un formulaire avec une adresse email en clair dans la query string. Ne mettez pas un identifiant client dans un lien marketing. Ne copiez pas une recherche libre dans le titre de page. Ce niveau réduit l’exposition dans tous les systèmes, pas seulement l’analytics. Niveau 2 : avant l’envoi analytics Construisez une représentation nettoyée de la page : const current = new URL(window.location.href); const allowed = new Set([ "utm_source", "utm_medium", "utm_campaign", "utm_content", ]);const clean = new URL(current.origin + current.pathname);for (const [key, value] of current.searchParams) { if (allowed.has(key)) { clean.searchParams.set(key, value.toLowerCase().slice(0, 100)); } }const analyticsPage = clean.pathname; const campaign = Object.fromEntries(clean.searchParams);Cet exemple illustre le principe, pas une implémentation universelle. Il faut aussi :gérer les paramètres répétés ; valider les valeurs ; définir une longueur maximale ; refuser le texte libre ; tester les caractères encodés ; tenir compte du routeur de l’application ; vérifier que les erreurs ne font pas revenir à l’URL brute.Le plus sûr est souvent d’envoyer le chemin et les dimensions de campagne dans des champs séparés. Niveau 3 : dans le collecteur ou le proxy Un filtre côté serveur protège contre une erreur du navigateur ou un ancien script. Il peut rejeter les champs non autorisés, tronquer les valeurs et journaliser uniquement un code d’erreur sans recopier la donnée rejetée. Cette couche est essentielle si plusieurs sites ou équipes utilisent le même endpoint. Niveau 4 : dans l’outil analytics Certains outils fournissent des contrôles de redaction ou d’exclusion. GA4 propose notamment une fonction de redaction des emails et de paramètres de requête définis par l’administrateur. Matomo permet d’exclure des paramètres d’URL des rapports de pages. Ces réglages sont utiles, mais ils ne remplacent pas les contrôles précédents. Une donnée peut avoir traversé un tag manager, un log ou un proxy avant d’être masquée dans le rapport. Niveau 5 : dans les exports Un export historique peut conserver des valeurs qui ont ensuite été filtrées dans l’outil. La procédure doit inclure les entrepôts, sauvegardes, fichiers CSV et connecteurs de BI. Votre data collection summary doit distinguer ce qui est reçu, transformé, stocké et exposé. Normaliser les pages sans perdre l’information utile Un rapport de contenu doit généralement regrouper les variantes qui représentent la même ressource. Exemple : /products?sort=price&page=1 /products?sort=name&page=1 /products?utm_source=newsletter /products?session=abcLa dimension principale peut rester : /productsLes éléments utiles sont envoyés séparément : campaign_source=newsletter sort_used=trueCette structure produit des rapports plus lisibles et évite que des dimensions à forte cardinalité consomment inutilement les capacités de l’outil. Attention aux routes où le paramètre définit réellement le contenu Sur certaines architectures, ?article=42 ou ?category=security identifie la ressource. Supprimer le paramètre sans remplacement fusionnerait des pages différentes. Deux solutions :migrer vers des chemins stables, par exemple /articles/42; dériver un identifiant de contenu non personnel et contrôlé dans une dimension dédiée.Ne conservez pas automatiquement l’identifiant brut. Demandez d’abord s’il peut être relié à une personne ou à un dossier. SEO et analytics : deux nettoyages différents Le filtrage analytics et la gestion SEO des paramètres se recoupent, mais ne sont pas identiques. Pour le SEO, une équipe peut utiliser des URL canoniques, des redirections, des règles d’indexation et une structure de liens cohérente. Pour l’analytics, elle choisit la représentation utilisée dans les rapports. Une balise canonique n’empêche pas un script de collecter l’URL complète. Inversement, supprimer un paramètre du rapport analytics ne change pas la manière dont un moteur explore le site. Documentez les deux décisions séparément. Le protocole de test Test 1 : corpus de paramètres Créez une liste d’URL de test couvrant :UTM autorisés ; paramètre inconnu ; email encodé ; identifiant numérique ; valeur très longue ; paramètre répété ; caractères spéciaux ; token factice ; texte de recherche.Test 2 : observation réseau Dans les outils développeur, vérifiez le payload exact envoyé par le navigateur. Recherchez la valeur sensible factice dans toutes les requêtes, pas seulement celle de l’analytics principal. Test 3 : logs et stockage Vérifiez le collecteur, le CDN, les erreurs applicatives et les données brutes. Le fait qu’une valeur n’apparaisse pas dans le tableau de bord ne prouve pas qu’elle n’a jamais été stockée. Test 4 : rapports et exports Contrôlez les rapports pages, les dimensions personnalisées, l’API et un export représentatif. Test 5 : comportement en erreur Désactivez une règle, envoyez une clé inconnue et simulez un payload invalide. Le système doit échouer en mode sûr, sans enregistrer l’URL complète dans un message d’erreur. Gouverner l’allowlist dans le temps Conservez un petit registre avec :Paramètre Statut Finalité Valeurs autorisées Propriétaire Date de revueutm_source Autorisé Acquisition Taxonomie marketing Growth Trimestrielleutm_medium Autorisé Canal Liste fermée Growth Trimestriellelang Dérivé Contenu fr, en Produit Semestrielleemail Interdit Aucune Aucune Engineering Permanentetoken Interdit Sécurité Aucune Security PermanenteToute nouvelle clé doit passer par la même question : quelle décision justifie sa collecte ? Pour un environnement multi-sites, appliquez une allowlist commune par défaut et n’autorisez une exception que si elle est documentée pour la propriété concernée. Conclusion Le bon filtre n’est pas une longue liste de mots interdits. C’est une politique simple :aucune donnée personnelle ou secret dans l’URL ; une allowlist courte pour les signaux de campagne réellement utiles ; des dimensions contrôlées pour les besoins produit ; un nettoyage avant envoi et une validation côté serveur ; des tests sur le réseau, les logs, le stockage et les exports.Cette approche améliore simultanément la privacy, la sécurité et la lisibilité des rapports. Mesurer moins de variantes produit souvent une meilleure compréhension des pages qui comptent. FAQ Faut-il supprimer toute la query string des rapports analytics ? C’est une bonne valeur par défaut pour la dimension page, mais certaines applications utilisent des paramètres pour définir le contenu. Dans ce cas, dérivez une dimension contrôlée plutôt que de conserver l’URL brute. Les paramètres UTM peuvent-ils contenir une adresse email ? Non. Une adresse email dans une URL peut circuler dans de nombreux systèmes. Utilisez des catégories de campagne, jamais des identifiants de personnes. La redaction de GA4 suffit-elle ? Elle réduit certains risques dans GA4, mais ne couvre pas nécessairement les logs, autres tags, proxies ou exports. Filtrez le plus tôt possible et vérifiez toutes les couches. Un identifiant haché peut-il rester dans l’URL ? Le hachage ne rend pas automatiquement une valeur anonyme. Si l’identifiant permet de distinguer, relier ou retrouver une personne, il peut rester une donnée personnelle et ne devrait pas être transmis sans justification. Comment traiter les termes de recherche interne ? Évitez d’envoyer le texte libre. Mesurez plutôt l’usage de la recherche, une catégorie contrôlée ou des statistiques agrégées, après analyse du besoin. SourcesOWASP, Information exposure through query strings in URL MDN, URLSearchParams Google Analytics, Data redaction Matomo, Exclude URL query parameters from tracked URLs Règlement (UE) 2016/679, article 25 et principes de l’article 5 CEPD, Lignes directrices sur la protection des données dès la conception et par défaut