EN FR

Tag : Rgpd

Tous les articles du blog avec ce tag.

Rétention des données analytics : combien de temps garder quoi, et pourquoi

Rétention des données analytics : combien de temps garder quoi, et pourquoi

« Nous conservons les données analytics pendant vingt-cinq mois. » La phrase semble précise. Elle ne dit pourtant pas :si elle concerne les événements bruts ou les rapports ; si l’identifiant visiteur expire au même moment ; si les logs du collecteur suivent une autre durée ; si les sauvegardes sont purgées ; si les exports CSV restent sur les ordinateurs ; si une nouvelle visite réinitialise le délai ; si les statistiques réellement anonymes sont conservées plus longtemps.Une politique de rétention utile ne repose pas sur un nombre unique. Elle décrit le cycle de vie de chaque couche de données et relie chaque durée à une finalité. La CNIL rappelle que les données personnelles ne peuvent pas être conservées indéfiniment et que le responsable doit déterminer la durée en fonction de l’objectif de la collecte. Elle distingue notamment la base active, l’archivage intermédiaire et, dans des cas particuliers, l’archivage définitif. Pour l’analytics web, la majorité des équipes ont surtout besoin d’une base active bien limitée, d’une suppression effective et, éventuellement, de statistiques suffisamment agrégées pour les tendances longues. Commencer par la finalité, pas par le réglage disponible Un outil peut proposer 2, 14, 25 ou 50 mois. Ces options ne déterminent pas automatiquement la durée juste. Posez d’abord la question métier :Pendant combien de temps cette donnée individualisée reste-t-elle nécessaire pour prendre la décision définie ?Exemples :comparer la saisonnalité d’un site peut justifier plus de douze mois de tendances ; diagnostiquer une rupture de collecte nécessite peut-être quelques semaines de logs ; attribuer une campagne B2B longue peut demander plusieurs mois ; garder un identifiant visiteur pendant plusieurs années « au cas où » est beaucoup plus difficile à justifier ; conserver un total mensuel agrégé peut être possible plus longtemps qu’un événement détaillé.La durée doit être proportionnée à la granularité et au risque. Cartographier sept couches de rétention 1. Traceurs et identifiants sur le terminal Cette couche comprend :cookies ; identifiants en local storage ; identifiants de session ; autres mécanismes persistants.Documentez :durée initiale ; renouvellement lors d’une visite ; portée du domaine ; usage entre plusieurs sites ; suppression au retrait ; comportement lorsque le consentement expire.Dans le cadre français de certains traceurs de mesure d’audience susceptibles d’être exemptés de consentement, la CNIL recommande une durée de vie permettant une comparaison pertinente, par exemple treize mois, sans prorogation automatique à chaque visite. Cela ne signifie pas que treize mois convient à tout identifiant. C’est un repère lié au cadre décrit et aux conditions associées. 2. Événements bruts Les événements contiennent le plus de détail :timestamp ; page ; source ; appareil ; propriétés d’événement ; identifiant éventuel ; métadonnées techniques.Ils servent au diagnostic, aux funnels ou à la reconstruction de rapports. Leur granularité augmente le risque de singularisation et le coût de gouvernance. Questions :les événements sont-ils nécessaires au-delà du cycle d’analyse ? peut-on les agréger après 30, 90 ou 180 jours ? quelles propriétés peuvent être supprimées plus tôt ? les événements invalides sont-ils rejetés ou stockés ? la suppression d’une propriété s’applique-t-elle à l’historique ?3. Données pseudonymisées Un identifiant remplacé, haché ou rotatif ne rend pas automatiquement les données anonymes. Si l’équipe ou le fournisseur peut relier des événements, cette couche reste à traiter avec prudence. Définissez :clé et méthode ; possibilité de réidentification ; séparation des tables ; accès ; période de rotation ; suppression de la table de correspondance ; besoin réel de continuité.Une rotation n’a d’intérêt que si les anciennes périodes ne peuvent pas être reconnectées sans justification. 4. Statistiques agrégées Les rapports quotidiens ou mensuels peuvent parfois être conservés plus longtemps, surtout lorsqu’ils ne permettent plus d’isoler une personne. Exemples : visites mensuelles par site conversions mensuelles par canal pages vues hebdomadaires par catégorie taux de conversion trimestrielMais le mot « agrégé » n’est pas magique. Une cellule avec une seule conversion dans une petite zone peut rester révélatrice. Définissez des seuils, réduisez les dimensions et testez la singularité. Si les données sont véritablement anonymes, elles sortent du champ des données personnelles. Cette conclusion doit être démontrée, pas simplement déclarée. 5. Logs techniques Le collecteur, le CDN, le reverse proxy et l’application peuvent conserver :adresse IP ; URL complète ; user-agent ; codes d’erreur ; payload rejeté ; identifiant de requête.Les logs sont souvent oubliés parce qu’ils ne figurent pas dans le dashboard analytics. Ils répondent à des finalités de sécurité, disponibilité ou diagnostic différentes. Définissez une durée séparée, des accès restreints et un filtrage des données sensibles. Évitez qu’un message d’erreur recopie un payload complet pendant des mois. 6. Sauvegardes Une sauvegarde n’est pas une exemption permanente à la suppression. Documentez :fréquence ; période de rotation ; chiffrement ; personnes habilitées ; procédure de restauration ; comportement d’une donnée supprimée après restauration ; délai de purge ; sauvegardes hors ligne ou snapshots.Il peut être techniquement disproportionné de modifier chaque sauvegarde immédiatement. Dans ce cas, l’organisation doit limiter l’usage, la durée et la réintroduction des données supprimées, avec une procédure documentée. 7. Exports et systèmes secondaires Les exports créent une rétention parallèle :CSV envoyé par email ; feuille de calcul ; entrepôt ; BI ; stockage d’agence ; présentation ; ticket de support ; sauvegarde locale.Le réglage du fournisseur analytics n’efface pas ces copies. Chaque export doit avoir :un propriétaire ; une finalité ; un emplacement approuvé ; une durée ; une règle d’accès ; une suppression.Réduire les exports est souvent plus efficace que rédiger une politique complexe pour les gouverner. Construire une matrice de rétention Un exemple pour une PME SaaS :Couche Finalité Durée proposée Déclencheur Suppression ResponsableIdentifiant de visite limité Mesure de tendance 13 mois maximum dans le cadre analysé Création, sans renouvellement automatique Expiration Analytics ownerÉvénements bruts Analyse et diagnostic 6 mois Date de l’événement Tâche automatique DataRapports mensuels agrégés Pilotage historique 36 mois Fin du mois Agrégation puis purge Finance/GrowthLogs collecteur Sécurité et erreurs 30 jours Réception Rotation EngineeringSauvegardes Reprise d’activité 60 jours Création du snapshot Rotation InfrastructureExports ponctuels Analyse définie 90 jours Date d’export Suppression par propriétaire AnalystePreuve de consentement Démonstration du choix Durée définie selon risque et prescriptions Choix Politique dédiée PrivacyLes valeurs sont illustratives, sauf lorsqu’un cadre précis est explicitement cité. Une autre organisation peut retenir des périodes différentes après analyse. Le tableau doit expliquer le déclencheur. « Six mois » n’a pas le même sens à partir de la collecte, de la dernière visite, de la clôture d’une campagne ou de la résiliation. Comprendre les réglages de l’outil GA4 : distinguer explorations et rapports agrégés La documentation GA4 indique que les contrôles de rétention concernent les données utilisateur et événement. Pour les propriétés standard, les options documentées incluent notamment 2 ou 14 mois pour les données utilisateur et événement. Google précise aussi que ce réglage n’affecte pas les rapports agrégés standards et qu’il concerne notamment les explorations et rapports de funnel. Une équipe peut donc croire avoir réduit toute la rétention alors qu’une partie des rapports reste disponible sous forme agrégée. Le réglage « reset on new activity » peut également repousser l’expiration de certaines données utilisateur à chaque nouvelle activité. Il faut vérifier s’il correspond à la politique choisie. Autres fournisseurs Les outils privacy-first, plateformes auto-hébergées et solutions cloud ont des modèles différents :rétention fixe ou configurable ; événements bruts accessibles ou non ; statistiques agrégées conservées ; sauvegardes gérées par le fournisseur ; suppression par site ; export API ; politique à la résiliation.Ne réutilisez pas une durée trouvée dans un comparatif. Vérifiez la documentation et le contrat au moment de la configuration. La recommandation CNIL des vingt-cinq mois Pour les traceurs de mesure d’audience dans le cadre d’exemption décrit en France, la CNIL recommande que les informations collectées soient conservées pendant une durée maximale de vingt-cinq mois, avec réexamen périodique. Trois précautions :maximum ne signifie pas durée par défaut : une période plus courte peut suffire ; le cadre est conditionnel : finalité, anonymat statistique, absence de recoupement et autres conditions restent nécessaires ; les couches doivent rester séparées : logs, exports et identifiants ont leur propre analyse.Une politique peut donc fixer six mois pour les événements détaillés et vingt-quatre mois pour des rapports agrégés, si cela correspond au besoin et à l’analyse. Elle ne doit pas copier vingt-cinq mois sur toutes les bases par facilité. Tester la suppression Une politique non testée est une intention. Test 1 : données expirées Créez des événements de test horodatés ou utilisez un environnement avec une durée courte. Vérifiez qu’ils disparaissent du stockage, de l’API et des rapports concernés. Test 2 : identifiant Contrôlez l’expiration du cookie ou autre identifiant, le renouvellement et le comportement après retrait. Test 3 : export Suivez un fichier depuis sa création jusqu’à sa suppression. Vérifiez les copies, pièces jointes et corbeilles. Test 4 : sauvegarde restaurée Restaurez une sauvegarde dans un environnement isolé et vérifiez que la procédure réapplique les suppressions ou bloque l’usage des données qui auraient expiré. Test 5 : fin de contrat Demandez au fournisseur :délai d’export ; date de suppression ; sauvegardes ; confirmation ; données conservées pour obligations légales ; sous-traitants concernés.Conservez la réponse avec le dossier de sortie. Éviter les déclencheurs qui prolongent silencieusement la durée Plusieurs mécanismes peuvent repousser la suppression :renouvellement de cookie à chaque visite ; mise à jour de la ligne utilisateur ; import dans un nouvel entrepôt ; agrégation qui conserve les dimensions rares ; sauvegarde jamais tournée ; export dupliqué dans un dossier partagé ; compte de test réutilisé ; changement de politique appliqué seulement aux nouvelles données.Documentez si une modification de durée agit rétroactivement ou non. Rétention et multi-sites Une politique unique ne convient pas toujours à trente propriétés. Un site corporate, un espace authentifié et un centre d’aide peuvent avoir :des finalités différentes ; des volumes différents ; des données différentes ; des risques différents ; des pays différents.Utilisez un socle commun et des exceptions approuvées. Le dashboard multi-sites doit afficher la santé de collecte, mais l’administration doit aussi suivre la durée, le mode et la date de prochaine revue de chaque propriété. Ne mutualisez pas un identifiant entre sites uniquement pour simplifier la rétention. Qui doit valider la durée ? La décision croise plusieurs rôles :le métier explique la période nécessaire ; l’analytics owner décrit la granularité ; l’ingénierie confirme la suppression technique ; la sécurité traite les logs ; le DPO ou conseil évalue le cadre ; l’infrastructure décrit les sauvegardes ; les achats vérifient le contrat.Le propriétaire final doit être nommé. « La data » n’est pas un responsable. Le résumé de collecte et la politique de confidentialité analytics doivent reprendre les mêmes durées, avec un niveau de détail adapté à leur public. Une revue trimestrielle en dix questionsles finalités ont-elles changé ? les données détaillées sont-elles encore utilisées ? les rapports longs peuvent-ils être davantage agrégés ? les identifiants se renouvellent-ils ? les suppressions ont-elles réussi ? de nouveaux exports existent-ils ? les sauvegardes tournent-elles ? les fournisseurs ont-ils changé leur politique ? les documents publics sont-ils alignés ? une propriété inactive peut-elle être supprimée ?La meilleure réduction de risque est souvent la suppression d’un site, d’un export ou d’un événement devenu inutile. Conclusion Une durée de rétention n’est pas un nombre placé dans une politique. C’est un système qui relie finalité, granularité, accès, déclencheur et suppression. Une politique solide :sépare les identifiants, événements, agrégats, logs, sauvegardes et exports ; justifie chaque période ; évite les renouvellements silencieux ; teste les purges ; documente les exceptions ; aligne outils, contrats et information publique.Commencez par les données les plus détaillées. Demandez combien de temps elles servent réellement, puis agrégez ou supprimez. La conservation historique ne doit pas être financée par une collecte individuelle indéfinie. FAQ La CNIL impose-t-elle toujours vingt-cinq mois pour l’analytics ? Non. La CNIL recommande un maximum de vingt-cinq mois pour les informations collectées dans le cadre spécifique de certains traceurs de mesure d’audience exemptés sous conditions. Une durée plus courte peut être nécessaire ou suffisante. Les statistiques agrégées peuvent-elles être conservées indéfiniment ? Seulement si elles sont véritablement anonymes ou si un autre cadre justifie leur conservation. Une agrégation faible ou très segmentée peut encore permettre d’isoler une personne. Le réglage de rétention GA4 efface-t-il tous les rapports ? Non. Google indique que le réglage des données utilisateur et événement n’affecte pas les rapports agrégés standards. Il faut comprendre précisément quelles surfaces et données sont concernées. Faut-il supprimer les données des sauvegardes immédiatement ? La réponse dépend de l’architecture et du risque. Les sauvegardes doivent avoir une rotation limitée, des accès contrôlés et une procédure empêchant la réutilisation de données expirées après restauration. Quand commence la durée de conservation ? Le déclencheur doit être défini : collecte, dernière activité, fin de campagne, agrégation ou clôture du contrat. Évitez le renouvellement automatique lorsque le cadre ou la politique ne le permettent pas. SourcesCNIL, Les durées de conservation des données CNIL, Cookies : solutions pour les outils de mesure d’audience Règlement (UE) 2016/679, article 5, paragraphe 1, point e Google Analytics, Data retention Plausible, Data policy CNIL, Guide pratique sur les durées de conservation

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

Data collection summary : documenter clairement ce que votre analytics collecte

Data collection summary : documenter clairement ce que votre analytics collecte

Installer un outil analytics prend parfois quelques minutes. Expliquer précisément ce qu’il collecte peut prendre beaucoup plus longtemps. La difficulté ne vient pas seulement du volume de données. Elle vient de la dispersion de l’information. Une partie se trouve dans le plan de marquage, une autre dans la documentation du fournisseur, une autre dans le gestionnaire de consentement, et une dernière dans le code du site. Quand une question arrive, par exemple « transmettons-nous l’URL complète ? », « l’adresse IP est-elle stockée ? » ou « combien de temps gardons-nous les événements ? », personne ne dispose forcément d’une réponse complète. Un data collection summary est un document court qui rassemble ces réponses. Il décrit la collecte telle qu’elle fonctionne réellement, et non telle qu’on l’imagine à partir d’une page marketing. Ce n’est ni un avis juridique, ni un remplacement du registre des traitements, ni une politique de confidentialité. C’est une vue technique et opérationnelle qui relie les trois. À quoi sert un data collection summary ? Le document répond à une question simple :Pour chaque donnée ou signal collecté, savons-nous d’où il vient, pourquoi nous le collectons, où il va, combien de temps nous le gardons et qui peut y accéder ?Cette vue est utile à plusieurs équipes. L’équipe produit peut vérifier qu’un nouvel événement répond à un besoin réel. L’équipe marketing peut comprendre quelles dimensions sont disponibles sans supposer que « l’outil doit sûrement les avoir ». L’équipe technique dispose d’une référence pour les filtres, les transformations et les environnements. Le DPO ou le conseil juridique peut confronter la réalité technique aux documents de conformité. La direction peut enfin savoir quel risque et quelle dette accompagnent la mesure d’audience. Le RGPD impose notamment des principes de finalité, de minimisation, de transparence et de limitation de la conservation. Il prévoit aussi, selon les situations, une information des personnes et la tenue d’un registre des activités de traitement. Le data collection summary ne crée pas ces obligations, mais il facilite la production d’informations exactes et cohérentes. Ce document n’est pas le registre des traitements La distinction est importante. Le registre des activités de traitement est un document de gouvernance prévu par l’article 30 du RGPD dans les cas où il s’applique. Il décrit un traitement à un niveau relativement large : finalités, catégories de personnes, catégories de données, destinataires, transferts, durées et mesures de sécurité. Le data collection summary descend au niveau de l’implémentation. Il peut préciser que :l’URL est enregistrée sans la chaîne de requête ; l’adresse IP est utilisée brièvement pour une opération technique puis non conservée ; le user-agent est réduit à une famille de navigateur ; les paramètres utm_source, utm_medium et utm_campaign sont conservés ; un identifiant de formulaire n’est envoyé qu’après validation ; les données brutes et les rapports agrégés n’ont pas la même durée de conservation.La politique de confidentialité, elle, traduit les éléments pertinents dans un langage destiné aux visiteurs. Elle ne doit pas devenir une copie de la documentation technique, mais elle ne peut être fiable que si cette documentation existe. On peut donc résumer les rôles ainsi :Document Public principal Niveau de détail FonctionRegistre des traitements Interne, conformité Traitement et catégories Démontrer et piloter la conformitéData collection summary Interne, produit et technique Champs, flux et contrôles Décrire la collecte réellement déployéePolitique de confidentialité Visiteurs et utilisateurs Information claire Expliquer les traitements pertinents aux personnesPlan de marquage Produit, marketing, développement Événements et règles Définir ce qui doit être mesuréCes documents se complètent. Ils ne doivent pas se contredire. Les 10 colonnes d’un résumé utile Un tableur suffit. L’important est la qualité des colonnes et la discipline de mise à jour. 1. Donnée ou signal Nommez la donnée sans jargon commercial : chemin de page, domaine référent, type d’appareil, événement de formulaire, identifiant de site, paramètre UTM, pays dérivé, adresse IP temporaire. Évitez les catégories vagues comme « données techniques ». Elles masquent les choix concrets. 2. Exemple de valeur Un exemple réduit les ambiguïtés. Pour un chemin de page : /tarifs/. Pour une source : newsletter. Pour un événement : demo_requested. N’utilisez pas de vraie donnée personnelle dans le document. Un exemple synthétique suffit. 3. Source Précisez où le signal apparaît : navigateur, serveur, formulaire, CMS, CDN, script analytics ou import externe. Cette colonne aide à repérer les données collectées indirectement. Un outil peut, par exemple, recevoir une URL ou un en-tête avant même que votre code de tracking ne les transforme. 4. Finalité opérationnelle Écrivez une phrase qui relie la donnée à une décision : « mesurer les pages d’entrée qui génèrent une demande de démonstration » est plus utile que « analyse marketing ». Une finalité trop large est un signal d’alerte. Si une donnée sert supposément à tout, son besoin n’est probablement pas assez défini. 5. Transformation avant stockage Indiquez ce qui est supprimé, tronqué, agrégé ou dérivé :suppression des paramètres non autorisés ; normalisation du chemin ; réduction du user-agent ; géolocalisation approximative puis suppression de l’adresse IP ; hachage d’un identifiant, avec la précision qu’un hachage n’est pas automatiquement une anonymisation ; agrégation quotidienne ou mensuelle.Cette colonne permet de distinguer ce que le système reçoit de ce qu’il conserve. 6. Destination et sous-traitants Listez les systèmes qui reçoivent la donnée : endpoint de collecte, stockage brut, base agrégée, outil de BI, export, fournisseur cloud ou prestataire analytics. Ajoutez la région d’hébergement et les transferts pertinents lorsqu’ils sont connus et documentés. Ne déduisez pas la localisation juridique d’un simple nom de région cloud. 7. Durée de conservation Séparez les couches lorsque nécessaire :logs techniques ; événements bruts ; données pseudonymisées ; statistiques agrégées ; sauvegardes ; exports manuels.Une seule durée globale est souvent trompeuse. La CNIL rappelle que la durée doit être déterminée selon la finalité et limitée au nécessaire. Pour les traceurs de mesure d’audience susceptibles d’entrer dans le cadre d’une exemption en France, elle recommande notamment une durée de vie de treize mois pour les traceurs et une conservation des informations collectées limitée à vingt-cinq mois. Ces repères ne dispensent pas d’analyser la configuration réelle. 8. Accès Décrivez les rôles, pas seulement les noms : administrateurs, analystes, agence, support, prestataire d’hébergement. Précisez si l’accès porte sur les rapports agrégés, les événements bruts ou les exports. « L’équipe marketing a accès » est insuffisant si un compte générique permet aussi de télécharger toutes les données. 9. Dépendance au consentement ou à la configuration Cette colonne doit rester factuelle. Indiquez par exemple :collecté uniquement après signal de consentement ; désactivé en mode de mesure stricte ; activé uniquement pour certaines campagnes ; soumis à une analyse locale ePrivacy ; utilisé pour une mesure d’audience limitée, sous réserve que toutes les conditions applicables soient remplies.N’écrivez pas simplement « exempté » sans documenter les conditions, le périmètre et la configuration. 10. Suppression et responsable Enfin, indiquez comment la donnée disparaît et qui vérifie le processus : suppression automatique, tâche planifiée, purge fournisseur, procédure manuelle, échéance de contrat, suppression d’un export. Ajoutez un propriétaire interne et une date de dernière revue. Sans responsable, le document vieillit dès la prochaine mise en production. Exemple minimal pour une PME SaaS Voici un extrait volontairement simplifié :Signal Finalité Traitement avant stockage Conservation AccèsChemin de page Mesurer les contenus consultés Query string supprimée, chemin normalisé 25 mois pour les rapports Produit, marketingDomaine référent Comprendre les sources de visite Origine uniquement lorsque transmise 25 mois Marketingutm_source Identifier une campagne déclarée Valeurs normalisées selon une nomenclature 25 mois MarketingÉvénement demo_requested Mesurer une conversion B2B Aucun contenu de formulaire envoyé 25 mois Produit, ventes en agrégéAdresse IP Sécurité et dérivation géographique approximative Utilisée temporairement, non stockée dans l’événement Durée technique documentée Opérations restreintesUser-agent Répartition technique Réduit à une catégorie de navigateur et appareil 25 mois ProduitCe tableau ne prouve rien à lui seul. Il doit correspondre au réseau observé, au code et aux réglages du fournisseur. C’est pourquoi il est utile de commencer par un audit des traceurs effectivement chargés et de comparer le résultat au plan de marquage minimaliste. Méthode de construction en cinq étapes Étape 1 : partir du trafic réseau Ouvrez les outils de développement du navigateur, rechargez les pages représentatives et observez les requêtes. Faites le test avant et après chaque choix de consentement, sur plusieurs parcours et appareils. Relevez les domaines, les payloads, les paramètres d’URL et les événements. Le réseau montre ce qui est transmis depuis le navigateur. Il ne montre pas nécessairement toutes les transformations côté serveur, mais il constitue un point de départ vérifiable. Étape 2 : lire le code et la configuration Inspectez le script de collecte, le gestionnaire de tags, les règles du CMP, les variables d’environnement et les filtres. Une documentation fournisseur générique ne dit pas quelle option votre site a activée. Vérifiez également les fonctionnalités annexes : enregistrement de session, enrichissement publicitaire, export vers une régie, connexion CRM ou identifiants utilisateurs. Étape 3 : interroger le fournisseur avec des questions fermées Demandez des réponses vérifiables :l’URL complète est-elle reçue et stockée ? les paramètres de requête sont-ils filtrables avant stockage ? l’adresse IP est-elle journalisée ailleurs que dans les événements ? quelles sauvegardes contiennent encore les données après suppression ? le fournisseur réutilise-t-il les données pour son propre compte ? quels sous-traitants et transferts sont concernés ? les exports obéissent-ils à la même politique de conservation ?Une réponse « privacy-friendly » ne remplit aucune colonne. Étape 4 : confronter les documents Comparez le résumé technique au registre, au contrat de sous-traitance, à la politique de confidentialité et au bandeau de consentement. Les incohérences sont plus importantes que la qualité littéraire de chaque document pris séparément. Exemple classique : la politique affirme que seules des statistiques agrégées sont collectées, alors que le gestionnaire de tags envoie un identifiant utilisateur à un outil tiers. Étape 5 : instaurer une revue liée aux changements Le document doit être revu lors de toute modification significative :nouvel outil ; nouvel événement ; changement de domaine de collecte ; activation d’un export ; nouvelle durée de conservation ; modification du consentement ; changement de sous-traitant ; ajout d’une propriété ou d’un site.Une revue trimestrielle légère permet aussi de détecter les écarts silencieux. Les erreurs qui rendent le document inutile Copier la documentation commerciale La documentation du fournisseur décrit un produit possible. Votre résumé doit décrire votre instance, vos options et vos flux. Confondre pseudonymisation et anonymisation Un identifiant haché ou rotatif peut rester une donnée personnelle s’il permet encore de distinguer ou relier une personne. Utilisez des termes précis et documentez le risque de réidentification. Oublier les URL Les URL complètes peuvent contenir des emails, identifiants de commande, termes de recherche interne ou jetons. Même un outil conçu pour collecter peu peut recevoir une donnée excessive si le site place cette donnée dans l’adresse. Ne documenter que le tableau de bord Le rapport visible n’est qu’une surface. Les logs, exports, événements bruts, sauvegardes et intégrations comptent aussi. Laisser le document sans propriétaire Une fiche parfaite mais non maintenue devient rapidement plus dangereuse qu’une fiche absente, car elle donne une confiance injustifiée. Checklist de validation Avant d’approuver le résumé, vérifiez que :chaque donnée a une finalité spécifique ; les données reçues et les données stockées sont distinguées ; les paramètres d’URL et champs libres ont été audités ; les durées sont définies par couche ; les destinataires et accès sont nommés ; le consentement et les modes de configuration sont explicités ; la suppression est testable ; le contenu concorde avec les documents publics et contractuels ; un responsable et une date de revue sont indiqués ; toute affirmation d’anonymisation est techniquement justifiée.Conclusion Un data collection summary n’est pas un document de plus à ranger dans un dossier conformité. C’est une interface commune entre produit, marketing, technique et juridique. Sa valeur vient de sa précision. Une équipe qui sait exactement ce qu’elle collecte peut supprimer les données inutiles, expliquer les données utiles, configurer correctement ses outils et répondre plus vite aux questions internes ou externes. Commencez par une seule propriété web et les dix signaux les plus importants. Vérifiez-les dans le réseau et le code, puis élargissez seulement si la collecte réelle le justifie. FAQ Le data collection summary est-il obligatoire au titre du RGPD ? Ce format précis n’est pas imposé par le RGPD. Il peut toutefois aider à produire et maintenir des documents obligatoires ou nécessaires, notamment le registre des traitements et l’information des personnes. Faut-il publier ce document ? Pas nécessairement. Il contient souvent des détails techniques internes. Les informations pertinentes pour les personnes doivent être reprises clairement dans la politique de confidentialité ou d’autres notices appropriées. Une adresse IP non stockée doit-elle apparaître ? Oui si elle est reçue ou utilisée, même brièvement. Le résumé doit distinguer réception, traitement temporaire, transformation et stockage. Peut-on utiliser le même résumé pour plusieurs sites ? Seulement si les flux et configurations sont réellement identiques. Pour un environnement multi-sites, gardez un socle commun et documentez les écarts par propriété. À quelle fréquence faut-il le mettre à jour ? À chaque changement significatif de collecte ou de destination, avec une revue périodique. Une vérification trimestrielle est un rythme pratique pour une petite équipe, sans constituer une règle juridique universelle. SourcesRèglement (UE) 2016/679, notamment articles 5, 13, 25 et 30 CNIL, Le registre des activités de traitement CNIL, Cookies : solutions pour les outils de mesure d’audience CEPD, Lignes directrices 4/2019 sur la protection des données dès la conception et par défaut Chrome for Developers, Network features reference OWASP, Information exposure through query strings in URL

Audit des traceurs d’un site web : la checklist pratique pour une PME

Audit des traceurs d’un site web : la checklist pratique pour une PME

Un audit de traceurs ne consiste pas à compter les cookies affichés dans un navigateur puis à produire une capture d’écran. L’objectif est plus utile : comprendre quels composants communiquent avec quels services, à quel moment, pour quelle finalité et avec quelles données. Cette distinction est importante. Un site peut ne déposer aucun cookie et envoyer malgré tout des informations à des tiers. À l’inverse, un cookie peut être strictement nécessaire au fonctionnement demandé par l’utilisateur. Le mot « cookie » ne suffit donc pas à qualifier le risque, la finalité ou le régime applicable. Pour une PME, un SaaS B2B ou une équipe qui gère plusieurs sites, le bon livrable n’est pas un rapport de cinquante pages. C’est un inventaire vérifiable, relié à des responsables, à des décisions et à un plan d’action. Avant de commencer, gardez une limite claire en tête : un audit technique n’est pas un avis juridique. Il fournit les faits nécessaires pour documenter la configuration et décider avec les personnes compétentes. Ce que l’audit doit permettre de répondre À la fin de l’exercice, l’équipe devrait pouvoir répondre sans approximation à huit questions :Quels scripts, pixels, SDK et ressources tierces sont chargés ? Quels cookies, stockages locaux ou identifiants sont créés ? Quelles requêtes partent avant le choix de l’utilisateur ? Quelles données apparaissent dans les URL, en-têtes et corps de requête ? Quel fournisseur reçoit chaque information ? Quelle finalité opérationnelle justifie chaque composant ? Combien de temps les données et identifiants sont-ils conservés ? Qui peut accéder aux données, les exporter ou modifier la configuration ?Cette grille évite un piège fréquent : auditer uniquement la bannière, sans vérifier ce que le site fait réellement. La CNIL rappelle que la notion de traceur est technologiquement large. Elle couvre notamment les cookies HTTP, pixels, stockages locaux et certaines techniques d’empreinte. L’absence de cookie visible n’est donc pas une preuve suffisante d’absence de traçage. Préparer un périmètre représentatif Un audit réalisé uniquement sur la page d’accueil est rarement concluant. Les composants varient selon les pages, les parcours et l’état de consentement. Construisez un échantillon qui couvre au minimum :la page d’accueil ; une page de contenu ; une page produit ou service ; une page de tarification ; un formulaire ; une page de confirmation ; un espace authentifié, s’il existe ; une page intégrant une vidéo, une carte, un chat ou un outil de prise de rendez-vous ; une URL de campagne avec paramètres UTM ; les versions linguistiques ou domaines principaux dans un environnement multi-sites.Testez aussi plusieurs états :nouvelle visite sans choix enregistré ; refus de tous les traceurs optionnels ; acceptation sélective ; acceptation globale ; retour avec un choix déjà mémorisé ; navigation privée ou profil navigateur vierge.Pour les pages sensibles, ajoutez un scénario spécifique. Un espace client, une page de santé, un formulaire RH ou une console d’administration ne doit pas être traité comme une simple page éditoriale. La méthode d’audit en sept étapes 1. Partir d’un navigateur propre Utilisez un profil navigateur vierge, sans extension susceptible de bloquer ou réécrire les requêtes. Ouvrez les outils de développement avant de charger la page et activez la conservation du journal réseau. Notez précisément :l’URL testée ; la date ; le navigateur et sa version ; le scénario de consentement ; l’environnement, production ou préproduction ; l’identité de la personne qui a réalisé le test.Cette traçabilité rend l’audit reproductible. Elle permet aussi de comparer un résultat avant et après correction. 2. Inventorier les composants chargés Dans l’onglet Réseau, filtrez successivement les requêtes de type script, image, fetch, XHR et document. Relevez les domaines tiers ainsi que les fichiers chargés depuis votre propre domaine mais fournis par un prestataire. Un script servi en first party n’est pas nécessairement maîtrisé en interne. Un proxy, un gestionnaire de tags ou un CDN peut masquer l’origine fonctionnelle du composant. Pour chaque entrée, enregistrez :Champ Exemple de questionComposant Quel script ou service est chargé ?Propriétaire Quelle équipe l’a demandé ?Fournisseur Qui opère le service ?Finalité Mesure, support, sécurité, publicité, vidéo ?Déclenchement Avant choix, après acceptation, à l’action ?Données observées URL, referrer, IP, identifiant, événement ?Destination Domaine et région de traitement connues ?Action Conserver, configurer, différer ou supprimer ?Ne vous contentez pas du nom commercial. Un même fournisseur peut proposer plusieurs produits avec des comportements très différents. 3. Vérifier les stockages côté navigateur Inspectez :les cookies first party et third party ; localStorage ; sessionStorage ; IndexedDB ; les service workers ; les caches applicatifs lorsque c’est pertinent.Pour chaque cookie ou clé, relevez son nom, son domaine, sa durée, ses attributs et le moment où il apparaît. Les attributs Secure, HttpOnly et SameSite donnent des indications de sécurité, mais ils ne déterminent pas à eux seuls la finalité ou le besoin de consentement. Supprimez les données de site entre les scénarios. Sinon, un identifiant posé pendant un test « acceptation » peut fausser le test « refus ». 4. Comparer les déclenchements avant et après le choix C’est l’étape qui révèle les erreurs de configuration les plus concrètes. Rechargez la même page dans chaque état et comparez :les domaines contactés ; le nombre de requêtes ; les cookies créés ; les événements envoyés ; les scripts différés ; les appels déclenchés par une interaction.Un tag peut être absent au premier chargement puis se déclencher au scroll, au clic ou à l’ouverture d’un composant. Testez donc les interactions principales, pas seulement le chargement initial. Pour les outils de session replay, de chat ou de personnalisation, vérifiez aussi le masquage et les zones exclues. Le plan de marquage minimaliste constitue un bon point de comparaison : une collecte utile doit rester reliée à une décision, pas à la possibilité technique de tout enregistrer. 5. Inspecter les données réellement transmises Ouvrez plusieurs requêtes et examinez :l’URL complète ; les paramètres de requête ; le corps de la requête ; les en-têtes ; le referrer ; les identifiants persistants ; les propriétés d’événement.Cherchez en priorité les données qui ne devraient jamais circuler dans une URL analytics :adresse e-mail ; numéro de téléphone ; nom ; identifiant client ; jeton de réinitialisation ; token de session ; contenu libre d’un formulaire ; requête de recherche sensible ; référence de dossier.Les URL sont souvent copiées dans les journaux, historiques, outils de monitoring et systèmes de support. Une donnée placée dans la query string peut donc se propager bien au-delà de l’outil analytics. 6. Relier la technique à la gouvernance L’onglet Réseau ne vous dira pas tout. Complétez l’audit avec la documentation fournisseur et les paramètres du compte :durée de conservation ; localisation et sous-traitants ; transferts éventuels ; réutilisation des données par le fournisseur ; options de partage ; rôles et accès ; exports ; suppression ; journaux d’audit ; configuration multi-sites.Pour une mesure d’audience susceptible d’entrer dans un cadre sans consentement en France, la configuration réelle compte. La CNIL exige notamment une finalité strictement limitée à la mesure pour le compte de l’éditeur et des statistiques anonymes, sans recoupement ni suivi global entre sites. Notre décryptage du cadre CNIL détaille ces conditions et leurs limites. 7. Transformer l’inventaire en plan d’action Classez les constats selon quatre niveaux simples :Critique : donnée sensible ou identifiant exposé, tag marketing déclenché malgré un refus, token présent dans une URL. Élevé : fournisseur inconnu, absence de propriétaire, session replay sur une zone sensible, rétention non maîtrisée. Moyen : durée excessive, doublon de tags, paramètre inutile, documentation incomplète. Faible : optimisation de nommage, nettoyage de test, amélioration d’un commentaire ou d’une preuve.Chaque action doit avoir un responsable, une échéance et un test de validation. « À revoir » n’est pas une action exploitable. Un audit rapide en 90 minutes Pour un site simple, une première passe peut tenir dans un atelier court : 20 minutes : cartographier Listez les pages critiques, les outils attendus et les états de consentement. 30 minutes : observer Inspectez réseau et stockage sur trois à cinq pages, en état initial, refus et acceptation. 20 minutes : rapprocher Comparez les domaines observés avec la bannière, la politique de confidentialité, le gestionnaire de tags et les contrats fournisseurs. 20 minutes : décider Supprimez les composants sans propriétaire, créez les tickets prioritaires et planifiez les tests plus profonds. Cette passe ne remplace pas un audit complet, mais elle détecte souvent les écarts les plus coûteux : scripts oubliés, tags en double, données personnelles dans les URL et déclenchements trop précoces. Les erreurs fréquentes Confondre inventaire automatique et conclusion Un scanner aide à découvrir des domaines et cookies. Il ne connaît pas toujours la finalité, le contexte d’un événement ou la configuration contractuelle. Son résultat doit être vérifié manuellement. Ne tester que l’acceptation globale Le scénario le plus important est souvent celui du refus. Il permet de vérifier que les choix sont réellement respectés. Ignorer les requêtes first party Le fait qu’une requête parte vers votre domaine ne garantit pas qu’elle reste dans votre infrastructure ni qu’elle ne contienne pas de données indésirables. Auditer la production une seule fois Un gestionnaire de tags, une intégration marketing ou un changement de CMS peut modifier la collecte sans changement visible de l’interface. Un contrôle trimestriel léger et un audit avant les lancements importants sont plus utiles qu’un grand exercice ponctuel. Produire un tableau sans propriétaire Un inventaire sans décision, responsable ni date devient rapidement obsolète. La gouvernance est ce qui transforme l’audit en réduction de risque. Le livrable minimal à conserver Conservez quatre éléments :le tableau d’inventaire ; les preuves principales, captures ou exports réseau ; le registre des décisions, avec justification ; la liste des actions et le résultat des retests.Versionnez le document. Pour une équipe multi-sites, ajoutez une colonne « propriété web » et séparez ce qui est commun de ce qui varie localement. Conclusion L’objectif n’est pas de déclarer le site parfait. Il est de pouvoir expliquer, à une date donnée, ce qui a été observé, pourquoi chaque composant existe et comment les écarts sont traités. FAQ Un site sans cookies a-t-il besoin d’un audit de traceurs ? Oui. Des pixels, requêtes réseau, stockages locaux ou techniques d’identification peuvent fonctionner sans cookie HTTP. L’audit doit porter sur les échanges et les finalités, pas uniquement sur la liste des cookies. Les outils de scan automatique suffisent-ils ? Non. Ils accélèrent l’inventaire, mais ne remplacent pas la vérification manuelle des déclenchements, des données envoyées, des paramètres de compte et des responsabilités internes. Faut-il auditer chaque page du site ? Pas nécessairement. Il faut sélectionner un échantillon représentatif des gabarits, intégrations, parcours et états de consentement, puis approfondir les zones sensibles. À quelle fréquence refaire l’audit ? Après toute modification importante de la stack, avant un lancement sensible et selon un rythme régulier adapté au volume de changements. Pour une petite équipe, une revue trimestrielle légère est souvent plus réaliste qu’un audit annuel massif. Un audit technique prouve-t-il la conformité RGPD ? Non. Il documente les faits techniques et facilite l’analyse. La conformité dépend aussi des finalités, bases juridiques, contrats, informations fournies, droits des personnes et règles nationales applicables. Sources Sources vérifiées le 21 juin 2026.CNIL, « Cookies et traceurs : que dit la loi ? » CNIL, « Cookies : solutions pour les outils de mesure d’audience » CNIL, consultation sur le rejeu de session, 25 février 2026 EDPB, Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive Chrome for Developers, Network panel reference OWASP, Information exposure through query strings in URL

Session replay et CNIL : ce que les équipes doivent vérifier après la consultation 2026

Session replay et CNIL : ce que les équipes doivent vérifier après la consultation 2026

Le 25 février 2026, la CNIL a ouvert une consultation publique sur un projet de recommandation consacré aux outils de session replay. La consultation s'est clôturée le 22 avril 2026. À la date de publication de cet article, les équipes doivent donc traiter ce projet comme un signal de cadrage fort, tout en suivant la publication de la recommandation finale. Les outils de session replay ne sont pas de simples solutions de mesure d'audience. Ils peuvent enregistrer des interactions détaillées : défilement, clics, comportement de formulaire, hésitations dans l'interface et parfois du contenu saisi si le masquage est incomplet. Ce niveau de détail crée un profil de risque différent de celui de statistiques de trafic agrégées. La conséquence pratique est simple : les équipes produit, marketing et support ne devraient pas activer le session replay comme une option de tableau de bord anodine. Il faut un objectif documenté, des réglages de minimisation, du masquage, un contrôle d'accès, une durée de conservation courte et une décision claire sur les conditions dans lesquelles l'enregistrement est autorisé. Pourquoi le session replay est sensible Le session replay peut aider à diagnostiquer des bugs, des formulaires bloquants ou des parcours difficiles à comprendre. Mais un enregistrement peut aussi révéler des données personnelles, des champs sensibles, un contexte de compte ou des comportements que l'équipe n'avait pas prévu de collecter. Une configuration trop large peut donc capter davantage d'informations que nécessaire. C'est pour cette raison que le projet de recommandation de la CNIL insiste sur la proportionnalité et les garanties. La bonne question n'est pas de savoir si un outil est populaire. Elle est de vérifier si votre configuration limite réellement ce qui est capté, qui peut le consulter et combien de temps l'information reste disponible. Checklist de lancement Avant d'activer un outil de session replay, passez en revue ces points :définissez l'objectif exact : diagnostic UX, investigation support, contrôle qualité ou autre besoin documenté ; désactivez l'enregistrement par défaut sur les pages sensibles et les espaces authentifiés, sauf justification validée ; masquez les champs de formulaire, les zones de texte libre, les données de compte et tout champ susceptible de contenir une donnée personnelle ou sensible ; limitez l'échantillon de sessions enregistrées plutôt que d'enregistrer toutes les visites ; réservez l'accès à des rôles nommés et auditez les consultations ; fixez une durée de conservation courte et supprimez les enregistrements quand le besoin opérationnel disparaît ; documentez l'outil, le fournisseur, les transferts et la conservation dans vos supports privacy ; vérifiez que l'état d'enregistrement respecte votre dispositif de consentement ou de gestion des préférences ; conservez une procédure de rollback pour couper rapidement l'enregistrement en cas de fuite ou de pic anormal.Différence avec l'analytics Pomelo Le positionnement de Pomelo est volontairement différent. Le modèle par défaut est cookieless, minimal et orienté reporting. Il sert à répondre à des questions opérationnelles avec des données agrégées, pas à rejouer des parcours individuels. Cette distinction compte. Le session replay peut être utile dans un workflow de diagnostic limité, mais il ne doit pas être confondu avec une mesure d'audience privacy-first. Pour la plupart des PME, SaaS B2B et équipes multi-sites, la base analytics doit rester plus légère qu'un outil d'enregistrement. Que faire maintenant Si vous utilisez déjà Hotjar, Microsoft Clarity, FullStory ou un outil similaire, lancez un audit court avant le prochain cycle de mise en production :listez les pages où l'enregistrement est actif ; inspectez les vingt derniers enregistrements pour détecter une capture accidentelle de données personnelles ; revoyez les règles de masquage avec un interlocuteur non technique ; confirmez la conservation et les contrôles d'accès ; décidez si l'outil est nécessaire en continu ou seulement pendant des fenêtres de recherche limitées.Si l'équipe ne peut pas expliquer pourquoi les enregistrements sont nécessaires, il est préférable de les désactiver jusqu'à ce que l'objectif et les garanties soient documentés. Sources Sources vérifiées le 9 mai 2026.CNIL, "Rejeu de session : la CNIL lance une consultation publique sur son projet de recommandation", 25 février 2026 CNIL, "Cookies et autres traceurs : la CNIL publie des recommandations pour les outils de mesure d'audience" Hotjar, "Privacy and security" Microsoft Clarity, "Privacy overview"

Mesure d'audience RGPD : le cadre CNIL à connaître avant de choisir un outil

Mesure d'audience RGPD : le cadre CNIL à connaître avant de choisir un outil

La mesure d'audience est devenue un sujet de gouvernance, pas seulement un choix d'outil. Une PME peut vouloir suivre ses pages, ses sources et ses conversions simples sans transformer son site en stack marketing lourde. C'est raisonnable. Mais il faut éviter deux raccourcis : croire qu'un outil privacy-first règle tout, ou promettre un statut juridique générique dès l'installation. Le cadre publié par la CNIL est plus précis. Il décrit des conditions permettant, dans certains cas, de mettre en œuvre une mesure d'audience strictement limitée avec une charge de consentement réduite. Ce cadre reste conditionnel : il dépend de la finalité, de la configuration, de la durée de conservation, de l'absence de recoupement, du rôle du fournisseur et de l'information donnée aux visiteurs. Autrement dit, la bonne question n'est pas "quel outil dispense de tout arbitrage ?". La bonne question est : est-ce que ma configuration réelle reste dans un périmètre de mesure d'audience minimale, documentée et vérifiable ? Ce que dit le cadre CNIL La CNIL rappelle que les statistiques de fréquentation ou de performance peuvent être nécessaires à la fourniture d'un service. Elle décrit donc un périmètre limité pour des traceurs de mesure d'audience, à condition que la finalité reste strictement centrée sur l'audience du site ou de l'application, pour le compte exclusif de l'éditeur. Le cadre exclut notamment les usages qui recoupent les données avec d'autres traitements, transmettent des données non anonymes à des tiers, ou suivent globalement une personne entre plusieurs sites et applications. La CNIL recommande aussi d'informer les utilisateurs, de limiter la durée de vie des traceurs, de plafonner la conservation des informations collectées, et de réexaminer régulièrement ces durées. Elle met par ailleurs à disposition un outil d'auto-évaluation pour aider les fournisseurs à documenter leur analyse. Cette nuance est essentielle : l'auto-évaluation ne vaut pas certification, et ne préjuge pas de l'analyse que la CNIL pourrait mener lors d'un contrôle. Un éditeur de site doit donc conserver une lecture prudente et documentée. Les critères qui doivent guider le choix Avant de choisir une solution analytics, vérifiez ces points dans l'ordre. 1. Finalité strictement limitée La collecte doit servir à comprendre la fréquentation, les performances, les contenus consultés ou des problèmes de navigation. Dès que l'outil sert aussi au retargeting, à l'activation publicitaire, au profilage ou à l'enrichissement CRM, vous sortez du cadre minimal. 2. Pas de réutilisation fournisseur Le fournisseur doit traiter les données pour votre compte. S'il réutilise les données pour ses propres services, de la publicité, du benchmark global ou de l'amélioration produit non encadrée, le risque augmente. 3. Pas de suivi multi-sites Un identifiant partagé entre plusieurs éditeurs ou domaines pour suivre la navigation globale d'une personne est incompatible avec une mesure d'audience minimale. 4. Données statistiques et conservation limitée La logique doit rester agrégée et proportionnée. Les durées de vie et de conservation doivent être limitées et réexaminées. Les données brutes ou pseudonymisées ne doivent pas devenir une archive marketing permanente. 5. Information claire Même quand le cadre permet une collecte plus légère, l'information des visiteurs reste nécessaire. La politique de confidentialité doit expliquer ce qui est collecté, pourquoi, combien de temps, par qui, et comment exercer ses droits. Strict et Extended : une séparation utile Pour un produit analytics privacy-first, la séparation entre un mode minimal et un mode enrichi est plus lisible qu'un grand interrupteur flou. Un mode Strict doit couvrir les besoins de base : pages vues, sources lisibles quand elles sont disponibles sans enrichissement, volumes, tendances et conversions simples. Il doit minimiser les champs collectés et éviter les données dont la finalité n'est pas nécessaire. Un mode Extended doit être explicite. Il peut servir à des besoins plus riches : campagnes UTM détaillées, événements avancés, objectifs, contexte technique, segmentation ou lecture multi-sites. Ces usages peuvent être légitimes, mais ils doivent être assumés comme des choix de configuration, pas comme le défaut silencieux. Cette distinction aide l'équipe produit, le DPO, le marketing et les clients à parler de la même chose. La checklist avant publication Avant de présenter votre dispositif analytics comme prêt pour le lancement, documentez au minimum :la finalité exacte de la mesure ; les champs collectés en mode Strict ; les champs ajoutés en mode Extended ; les durées de conservation ; l'absence de recoupement avec d'autres traitements ; les transferts éventuels et leur base contractuelle ; la politique de confidentialité mise à jour ; l'analyse interne ou fournisseur appuyée sur les sources CNIL ; la procédure de changement de mode ; le responsable qui valide les évolutions de collecte.Cette documentation ne remplace pas une analyse juridique, mais elle évite de transformer une promesse marketing en dette opérationnelle. Ce que Pomelo doit promettre publiquement Le bon positionnement n'est pas une promesse absolue. Il tient en quatre idées :cookieless by default ; collecte minimale ; documentation claire de ce qui est collecté ; configuration Extended explicite quand l'équipe veut plus de détails.C'est plus solide qu'un slogan. Les équipes digitales multi-sites, les SaaS B2B et les PME européennes n'ont pas seulement besoin d'un outil léger. Elles ont besoin d'un dispositif compréhensible, gouvernable et stable dans le temps. Sources Sources vérifiées le 9 mai 2026.CNIL, Cookies : solutions pour les outils de mesure d'audience CNIL, outil d'auto-évaluation relatif à la mesure d'audience, juillet 2025 Article 82 de la loi Informatique et Libertés

Sanctions CNIL : ce que les équipes analytics doivent retenir avant le lancement

Sanctions CNIL : ce que les équipes analytics doivent retenir avant le lancement

Les sanctions CNIL sont utiles parce qu'elles montrent des schémas, pas seulement des montants. Pour les équipes analytics, la leçon est claire : le risque vient rarement du fait de mesurer l'audience en soi. Il vient de finalités floues, de traceurs déclenchés avant un choix valide, de collecte excessive, d'information insuffisante, de rétention mal cadrée et de relations fournisseurs que personne n'a revues. Cet article ne cherche pas à prédire une amende. Il donne une checklist de lancement fondée sur la liste publique des sanctions CNIL et la doctrine cookies. Les risques analytics récurrents 1. Les traceurs démarrent trop tôt Si des scripts publicitaires, de personnalisation ou de suivi avancé se déclenchent avant l'enregistrement d'un choix valide, le problème est immédiat. Les équipes doivent vérifier le comportement dans le navigateur, pas seulement dans un schéma de tag management. 2. La finalité est trop large "Analytics" peut recouvrir plusieurs finalités : mesure d'audience, attribution publicitaire, retargeting, product analytics, support, personnalisation ou enrichissement CRM. Ces finalités n'ont pas le même niveau de risque. Elles doivent être séparées dans la configuration et la documentation. 3. Les données sont conservées trop longtemps La durée de conservation apparaît régulièrement dans les décisions de la CNIL. Les équipes doivent définir une rétention pour les événements bruts, les rapports agrégés, les exports et les sauvegardes. La réponse ne peut pas être "aussi longtemps que l'outil le permet". 4. Le rôle des fournisseurs est mal compris L'éditeur du site reste responsable de comprendre ce que fait son fournisseur. Les conditions de traitement, l'hébergement, les transferts, les sous-traitants et les clauses de réutilisation doivent être revus avant lancement. 5. L'explication publique est trop vague Une politique de confidentialité qui dit seulement "nous utilisons des cookies pour améliorer l'expérience" n'est pas suffisante pour une stack analytics moderne. Il faut expliquer l'outil, la finalité, les catégories de données, la durée de conservation et le mécanisme de choix avec des mots concrets. Réduire le risque avant lancement Faites ce contrôle pratique :ouvrir un profil navigateur propre et inspecter les scripts déclenchés avant tout choix ; rattacher chaque tag à une finalité et à un responsable ; supprimer les tags que personne ne sait justifier ; séparer le reporting d'audience minimal du suivi marketing enrichi ; documenter la rétention et les règles d'export ; revoir les conditions fournisseur et les mécanismes de transfert ; mettre à jour la politique de confidentialité avec les noms réels des outils ; conserver la preuve du test dans la checklist de release.Pour Pomelo, cela signifie garder une promesse publique prudente : cookieless by default, collecte minimale, documentation claire, Strict d'abord et Extended par configuration explicite. Pourquoi c'est important pour les PME Les PME pensent souvent que les contrôles visent seulement les grandes plateformes. La liste des sanctions CNIL montre aussi des organismes plus petits, notamment via la procédure simplifiée. Les montants changent, mais la leçon opérationnelle reste la même : même une petite équipe doit conserver de la traçabilité, de la minimisation et un processus de lancement propre. Une bonne gouvernance analytics n'est pas de la bureaucratie. Elle évite qu'un lancement de dernière minute se transforme en incident vie privée. Sources Sources vérifiées le 9 mai 2026.CNIL, liste des sanctions, mise à jour le 14 avril 2026 CNIL, Cookies et autres traceurs CNIL, Cookies : solutions pour les outils de mesure d'audience

Checklist RGPD analytics : 10 vérifications avant d'installer un outil de mesure

Checklist RGPD analytics : 10 vérifications avant d'installer un outil de mesure

Installer un outil analytics est facile. Le gouverner correctement l'est moins. Un script peut être en ligne en cinq minutes, mais l'équipe doit encore savoir ce qu'il collecte, pourquoi, pendant combien de temps et quel choix est présenté aux visiteurs. Utilisez cette checklist avant d'ajouter ou de modifier un outil de mesure. Elle ne remplace pas une analyse juridique. Elle donne un cadre pratique pour aligner produit, marketing, engineering et privacy. 1. Définir la finalité Écrivez la finalité en une phrase. "Comprendre l'audience et la performance du site" n'est pas la même chose que l'attribution publicitaire, le retargeting, l'analyse comportementale produit ou l'enrichissement CRM. Séparez les finalités avant de choisir l'outil. 2. Séparer collecte minimale et collecte enrichie Définissez ce qui relève du reporting d'audience minimal et ce qui relève du suivi enrichi. Paramètres de campagne, événements détaillés, objectifs, contexte technique et segmentation multi-sites doivent être des choix de configuration explicites. 3. Lister les champs collectés Regardez le payload, pas seulement le dashboard. Vérifiez URL, référent, user agent, langue, données écran, paramètres de campagne, identifiants, événements et propriétés personnalisées. Supprimez les champs qui ne servent pas la finalité déclarée. 4. Vérifier le moment de déclenchement Utilisez un profil navigateur propre et inspectez les scripts déclenchés avant tout choix visiteur. Faites-le sur l'accueil, les landing pages, les formulaires, les parcours d'achat ou d'inscription et les zones authentifiées. 5. Fixer les règles de rétention Définissez la rétention des événements bruts, rapports agrégés, exports et sauvegardes. Une rétention longue doit être justifiée par un besoin opérationnel réel, pas par un réglage par défaut. 6. Revoir les conditions fournisseur Confirmez le rôle du fournisseur, le lieu d'hébergement, les sous-traitants, les transferts, les accès support et les clauses de réutilisation. Conservez l'accord de traitement à jour avec le dossier de lancement. 7. Mettre à jour l'information publique La politique de confidentialité doit nommer l'outil, décrire la finalité, lister les grandes catégories de données, expliquer la rétention et pointer vers le mécanisme de choix ou d'opposition pertinent. 8. Tester Strict et Extended Si votre produit sépare Strict et Extended, testez les deux modes dans le navigateur et dans le stockage. Strict ne doit pas persister de champs enrichis. Extended doit être explicite et documenté. 9. Contrôler les accès et exports La donnée analytics circule vite via CSV, captures d'écran et dashboards partagés. Limitez les accès aux personnes qui en ont besoin et définissez une règle pour les exports. 10. Conserver les preuves Gardez le test navigateur, la revue payload, les liens fournisseur, la mise à jour privacy et le responsable de release dans votre checklist de lancement. Les preuves comptent quand une décision doit être réexpliquée. Lecture pour le lancement Pomelo Pour Pomelo, cette checklist se traduit par une doctrine simple : Strict par défaut, Extended par configuration, aucune mutation de profil depuis les rapports, et des explications claires dans le dashboard quand la disponibilité des données dépend du mode de collecte. SourcesCNIL, Cookies et autres traceurs : https://www.cnil.fr/fr/cookies-et-autres-traceurs CNIL, Cookies : solutions pour les outils de mesure d'audience : https://www.cnil.fr/fr/cookies-solutions-pour-les-outils-de-mesure-daudience EDPB, Guidelines 05/2020 on consent under Regulation 2016/679 : https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en EDPB, Guidelines 07/2020 on controller and processor concepts : https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en

Changement d'offre Piwik PRO : ce que les anciens utilisateurs Core doivent vérifier

Changement d'offre Piwik PRO : ce que les anciens utilisateurs Core doivent vérifier

Selon l'annonce publiée par Piwik PRO en juillet 2025, l'économie de l'offre Core a changé et les plans Business et Enterprise sont devenus les routes payantes mises en avant pour les usages professionnels hébergés. Pour les équipes qui avaient choisi Core parce qu'il était gratuit, la bonne réponse n'est pas la panique. C'est une revue de migration structurée. Au 9 mai 2026, il faut vérifier les prix et conditions directement sur les pages officielles de Piwik PRO avant toute décision. Les tarifs éditeurs changent vite, et une migration analytics coûte cher quand elle est menée dans l'urgence. La décision porte sur la gouvernance, pas seulement sur le prix Le repositionnement d'un plan gratuit généreux oblige à poser une question utile : qu'est-ce que vous payez vraiment ? Si Piwik PRO reste le bon produit, le budget peut se justifier par la gouvernance, le support, l'hébergement, la rétention et les contrôles enterprise. Si l'équipe veut surtout un reporting de trafic lisible, un SaaS privacy-first plus léger ou un outil auto-hébergé peut être plus adapté. L'erreur serait de comparer uniquement les prix mensuels. Le coût réel inclut la mise en place, la rétention, les accès, la documentation, l'analyse juridique, l'adoption du reporting et le temps nécessaire pour expliquer le tableau de bord à des non-spécialistes. Checklist de migration Avant de changer d'outil, exportez et documentez :les sites, domaines et scripts actuellement en place ; les réglages de rétention et l'historique à conserver ; les dashboards ou rapports utilisés par la direction, les clients ou le marketing ; les objectifs, événements et paramètres de campagne encore utiles ; les accords de traitement et le rôle des fournisseurs ; les accès et utilisateurs à migrer ; la politique de confidentialité et le registre interne ; la période pendant laquelle l'ancien et le nouvel outil tourneront en parallèle.Quand c'est possible, faites fonctionner les deux outils pendant une courte période. Cela permet de comparer les tendances et d'éviter d'interpréter une migration comme une baisse soudaine de trafic. Comment comparer les alternatives Pour une PME européenne, un SaaS B2B ou une équipe digitale multi-sites, utilisez cinq critères :L'outil répond-il aux questions que l'équipe pose chaque semaine ? La collecte sépare-t-elle clairement l'analytics minimal du suivi enrichi ? Les prix, la rétention et les limites utilisateurs sont-ils lisibles ? Les rapports sont-ils compréhensibles sans formation lourde ? La documentation vie privée est-elle assez précise pour votre revue juridique ?Plausible, Fathom, Simple Analytics, Matomo et Pomelo peuvent tous être pertinents selon les réponses. Le meilleur choix est celui qui correspond à votre fonctionnement, pas celui dont le tableau comparatif est le plus agressif. Où se situe Pomelo Le positionnement de lancement de Pomelo est volontairement plus resserré : cookieless by default, Strict d'abord, Extended par configuration explicite, et des dashboards pensés pour les équipes qui veulent du reporting actionnable plutôt qu'une administration analytics. Cela n'en fait pas un remplacement universel de Piwik PRO. Cela en fait un candidat cohérent quand l'équipe veut une collecte minimale, une lecture multi-sites et un produit qui documente la différence entre données de base et données enrichies. Sources Sources vérifiées le 9 mai 2026.Piwik PRO, Introducing the new Piwik PRO Core and updated pricing, 3 juillet 2025 Piwik PRO, Business plan Piwik PRO, Pricing Matomo, Pricing Plausible, subscription plans

Plausible vs Fathom vs Simple Analytics : comparatif pratique 2026

Plausible vs Fathom vs Simple Analytics : comparatif pratique 2026

Plausible, Fathom et Simple Analytics appartiennent à la même famille : des outils de mesure web légers, privacy-first, pensés pour les équipes qui ne veulent pas la complexité de GA4 ou d'une suite analytics enterprise. Ils ne sont pourtant pas interchangeables. Le bon choix dépend de votre volume, de votre modèle d'équipe, de vos attentes de reporting, de l'hébergement et de votre revue vie privée. Les prix et packages changent souvent. Ce comparatif s'appuie sur les pages publiques des éditeurs consultées le 9 mai 2026. Vérifiez toujours les pages officielles avant d'acheter. La version courte Choisissez Plausible si vous voulez un produit open source établi, un dashboard clair, une option self-hosted et une documentation détaillée sur les plans. Choisissez Fathom si vous voulez un SaaS payant simple, avec une surface fonctionnelle volontairement réduite et une logique multi-sites lisible. Choisissez Simple Analytics si vous voulez un produit basé aux Pays-Bas, avec un positionnement vie privée marqué, des rapports simples et une entrée gratuite selon les limites affichées par l'éditeur. Choisissez Pomelo si votre priorité est le reporting multi-sites pour PME européennes, SaaS B2B et agences, avec une collecte Strict par défaut et une collecte Extended seulement quand elle est configurée explicitement. Tableau comparatifCritère Plausible Fathom Simple AnalyticsUsage principal Équipes qui veulent open source et rapports simples Équipes qui veulent un SaaS compact Équipes qui priorisent une posture vie privée documentéeModèle prix Plans par usage Plans par pages vues Plan gratuit ou payant selon limites d'usageSelf-hosting Community Edition disponible Pas le modèle principal Pas le modèle principalMulti-sites Supporté Supporté Selon planReporting Dashboard minimal, événements, objectifs, campagnes Dashboard minimal, événements, campagnes Dashboard minimal, objectifs, référentsRisque à vérifier Limites de plan, maintenance self-hosted, import historique Adéquation du plan et profondeur fonctionnelle Limites de plan et comptage vues/événementsLa posture vie privée dépend de la configuration Les trois éditeurs se positionnent sur une analytics privacy-first, mais une promesse éditeur ne remplace pas votre configuration réelle. Votre équipe doit encore documenter :ce que le script collecte ; si les événements ou paramètres de campagne ajoutent du contexte personnel ou sensible ; les durées de conservation ; le rôle du fournisseur et les conditions de traitement ; les transferts et le lieu d'hébergement ; si d'autres traceurs présents sur le même site changent l'analyse.C'est là que le modèle Strict/Extended de Pomelo est utile. Strict doit couvrir le reporting d'audience de base. Extended doit être un choix explicite pour les campagnes, événements, objectifs ou contextes techniques plus riches. Le dashboard doit expliquer l'impact de ce réglage, pas le cacher dans une promesse marketing. Comparez les prix à votre volume réel Ne comparez pas uniquement les prix d'entrée. Modelez le coût avec vos pages vues mensuelles, le nombre de sites, le nombre d'utilisateurs, la rétention, les exports et l'API. Un outil moins cher à 10 000 pages vues peut devenir plus coûteux à 500 000. Une option self-hosted peut réduire l'abonnement mais ajouter du coût d'infrastructure, de sauvegarde et de maintenance. Un plan généreux en nombre de sites peut être plus rentable pour une agence qu'un plan facturé par site. La qualité du reporting compte plus que le nombre de fonctions Le meilleur outil est celui que l'équipe lit vraiment. Avant d'acheter, demandez à la personne qui utilisera le dashboard chaque semaine de répondre à trois questions dans un compte d'essai :quelles sources d'acquisition fonctionnent ? quels contenus ou pages méritent une action ? quelles conversions ont changé depuis la période précédente ?Si l'outil ne permet pas de répondre vite à ces questions, ajouter plus de rapports ne résoudra pas le problème. Sources Sources vérifiées le 9 mai 2026.Plausible, subscription plans Plausible, data policy Fathom, pricing Fathom, features Simple Analytics, pricing Simple Analytics, what we collect

Pourquoi l'ère de la « Data Obésité » paralyse les petites entreprises (et comment s'en sortir)

Pourquoi l'ère de la « Data Obésité » paralyse les petites entreprises (et comment s'en sortir)

On nous a vendu un rêve. Celui du "Big Data". Depuis dix ans, la promesse faite aux dirigeants de PME, aux équipes SaaS et aux responsables marketing est la même : « Plus vous collecterez de données sur vos visiteurs, mieux vous vendrez. » Le résultat en 2025 ? C'est souvent l'inverse. Les outils sont devenus des usines à gaz, les données s'accumulent sans être lues, et les décisions sont plus lentes qu'avant. C'est ce qu'on appelle la data obésité : l'accumulation de données qui ne servent pas à décider, mais qui coûtent en temps, en argent, en conformité et en performance. En résumé :Trop de données tue la décision : l'excès d'information surcharge les tableaux de bord et paralyse l'action. Le piège des "Vanity Metrics" : on suit des courbes flatteuses au lieu de se concentrer sur ce qui génère réellement du chiffre d'affaires. Un coût triple : technique (site lent), juridique (RGPD), et confiance (visiteurs qui refusent le suivi). La solution existe : l'analytics frugale mesurer moins, décider mieux.1. Le syndrome du « tableau de bord qu'on ne regarde plus » Ouvrez votre outil d'analytics actuel. En moins de 10 secondes, pouvez-vous dire :si votre semaine a été bonne ? quelle page a généré le plus de prospects ? quelle source de trafic performe le mieux ?Si la réponse est non, vous n'êtes pas seul. Vous êtes même dans l'écrasante majorité. Le Big Data ne concerne pas les PME La publication Digitalisation in Europe d'Eurostat rappelle que l'adoption numérique avancée reste un objectif 2030 : 75 % des entreprises européennes devraient utiliser le cloud, pratiquer l'analyse Big Data ou utiliser l'intelligence artificielle. La même source montre l'écart de taille : en 2022, 98 % des grandes entreprises atteignaient un niveau de digital intensity au moins basique, contre 69 % des PME. → Source : Eurostat – Digitalisation in Europe, technology uptake in businesses Pourtant, ces mêmes PME se retrouvent avec des outils conçus pour des équipes data de 20 personnes. GA4 propose des centaines de rapports, des dizaines de dimensions, des explorations personnalisables. Pour une équipe marketing de 2 personnes (ou un dirigeant seul), c'est comme recevoir le tableau de bord d'un Airbus quand on a besoin de celui d'une voiture. Le choix qui paralyse L'abondance d'options, de rapports et de dimensions finit par fatiguer les utilisateurs. C'est un phénomène bien documenté en sciences comportementales : le choice overload (surcharge de choix). Plus on a d'options, moins on est capable de choisir et plus on est insatisfait de son choix quand on en fait un. → Source : The Decision Lab – Choice Overload Bias Appliqué à l'analytics : plus d'informations ≠ meilleure décision. Au contraire, trop de données entraîne l'inaction. On ferme l'onglet, et on pilote à l'aveugle.2. La course aux « Vanity Metrics » Dans de nombreuses petites structures, les métriques qui occupent le haut des dashboards sont aussi celles qui aident le moins à décider :pages vues (sans savoir lesquelles convertissent), nombre total de sessions (sans distinction entre prospects et robots), taux de rebond (métrique ambiguë, souvent mal interprétée), visiteurs par pays (rarement actionnable pour une TPE locale).Ces indicateurs flattent l'ego "on a eu 10 000 visites ce mois !" mais ils ne disent rien sur la performance réelle d'un site. Le test des 3 questions Pour une TPE/PME, un tableau de bord utile devrait tenir en trois questions :Combien de personnes découvrent mon site ? (acquisition) Quelles pages génèrent le plus de demandes ou ventes ? (performance) Combien cela représente-t-il chaque semaine ? (résultat)Si votre outil ne permet pas d'y répondre immédiatement, il vous éloigne de votre objectif principal : comprendre ce qui fonctionne pour développer votre activité. Nous avons détaillé les indicateurs à retenir (et ceux à ignorer) dans notre guide La méthode "5 KPIs".3. Le coût caché de la complexité La data obésité ne coûte pas seulement du temps. Elle a trois coûts concrets que la plupart des entreprises sous-estiment. 3.1 Le coût technique : un site plus lent Les outils d'analytics traditionnels embarquent souvent des scripts lourds qui dégradent les Core Web Vitals les métriques de performance web que Google utilise comme critère de classement. Un audit indépendant de Bejamas montre que les scripts tiers (analytics, chat, pixels marketing…) peuvent fortement ralentir le chargement, avec le script d'analytics souvent en tête des contributeurs au temps de blocage du thread principal. → Source : Bejamas – How Popular Scripts Slow Down Your Website Le script de GA4 pèse environ 45 KB compressé selon les mesures citées. Les alternatives frugales se situent souvent entre 1 et 6 KB. Comme nous l'expliquons dans notre article sur le SEO sans Google Analytics, alléger les scripts tiers peut contribuer aux Core Web Vitals, même si le résultat dépend toujours de l'ensemble de la page. Moins de vitesse = moins de conversions = moins de chiffre d'affaires. 3.2 Le coût juridique : le risque RGPD Plus on collecte de signaux géolocalisation fine, navigation inter-pages, identité technique, durée de session par page plus le risque juridique augmente. Chaque donnée collectée est une donnée à protéger, à documenter dans le registre de traitement, à justifier devant un contrôle. La CNIL décrit un cadre étroit dans lequel certains outils de mesure d'audience peuvent entrer dans le périmètre d'une exemption de consentement, sous conditions strictes. La bonne lecture n'est pas "pas de bannière par défaut", mais plutôt : collecte minimale, configuration documentée et finalité strictement limitée réduisent la charge de conformité. → Source officielle : CNIL – Cookies et outils de mesure d'audience C'est probablement l'argument le plus sous-estimé en faveur de l'analytics frugale : collecter moins réduit la surface à documenter et peut simplifier la revue. Cela ne supprime pas l'analyse des finalités, de l'information fournie aux visiteurs, du consentement éventuel ni des autres traceurs présents sur le site. Pour les critères formels, référez-vous à la page CNIL et documentez votre propre configuration. 3.3 Le coût de confiance : les visiteurs qui refusent Un autre effet pervers de l'analytics classique : les bannières cookies. D'après le bilan 2023 de la CNIL, les pratiques de refus de cookies se sont considérablement développées depuis la mise en œuvre de son plan d'action : près de 40 % des visiteurs refusent le dépôt de cookies sur les sites ayant mis en conformité leurs bannières. → Source : CNIL – Évaluation de l'impact du plan d'action cookies Dans certains secteurs, une partie des visiteurs utilise aussi un bloqueur de publicités ou de scripts, ce qui amplifie encore l'écart. Résultat : votre tableau de bord peut sous-représenter une partie de l'audience mesurable. L'ampleur dépend du consentement, des bloqueurs, du navigateur, du pays et de la stack de traceurs. Un outil cookieless par défaut réduit la dépendance de la couche de mesure d'audience aux taux d'acceptation. Votre UI de consentement finale dépend toujours de l'ensemble des traceurs présents sur le site, notamment pixels publicitaires, personnalisation ou session replay.4. La solution : l'analytics frugale L'analytics frugale ne consiste pas à mesurer moins par manque d'ambition ou par idéologie. Elle consiste à mesurer mieux, en se concentrant sur ce qui :aide concrètement à décider, respecte la vie privée des visiteurs, ne ralentit pas le site, limite certaines frictions de revue juridique.Ce que ça change concrètementAvant (Data Obésité) Après (Analytics Frugale)200+ métriques disponibles 5-7 KPIs actionnablesDashboard ouvert 1x/mois (et refermé aussitôt) Dashboard consulté chaque semaine, compris en 30 secondesUI de consentement tirée par une stack de traceurs large Socle audience cookieless par défautScript lourd, effet possible sur les Core Web Vitals Script plus léger, impact à mesurer dans le contexte réelConformité RGPD complexe (CMP, registre, proxyfication) Collecte minimale et revue plus lisibleReporting mensuel de 40 pages Reporting de 10 lignes orienté résultatsL'analytics frugale, c'est l'équivalent de la cuisine de saison : moins d'ingrédients, mieux choisis, mieux préparés. Le résultat est meilleur que l'accumulation. Les principes fondamentauxCollecter uniquement ce qui sert à décider. Si une donnée ne change pas votre façon d'agir, ne la collectez pas. Simplifier pour démocratiser. Un dashboard que le dirigeant comprend a plus de valeur qu'un rapport que seul le data analyst peut interpréter. Respecter par conception. La conformité ne doit pas être un ajout ("on proxyfie GA4 pour réduire le risque") mais un prérequis : choisir une collecte dont les limites sont claires, minimales et documentables. Mesurer la performance, pas les personnes. Les tendances agrégées (pages populaires, sources de trafic, taux de conversion) sont plus utiles et moins risquées que le suivi individuel.5. Par où commencer ? Si vous êtes convaincu que votre analytics actuel est trop complexe, voici les trois premières étapes. Étape 1 : Identifiez vos 5 KPIs. Utilisez la méthode des 5 KPIs pour définir les seuls indicateurs qui comptent pour votre activité. Si un indicateur ne passe pas le test "est-ce que je changerais ma façon de travailler si ce chiffre bougeait ?", supprimez-le. Étape 2 : Évaluez votre outil actuel. Comparez-le honnêtement aux alternatives. Notre comparatif des solutions d'analytics détaille les forces, faiblesses et prix de chaque famille (GA4, Matomo, frugal). Étape 3 : Testez. La plupart des solutions frugales s'installent rapidement avec un script court et offrent un essai gratuit. Faites tourner les deux outils en parallèle pendant un mois. Comparez : lequel vous donne une réponse plus vite ?Conclusion : mettez votre analytics au régime L'époque où l'on collectait des données "juste au cas où" est derrière nous. La réglementation, les performances web et le bon sens convergent vers le même constat : moins de données, mieux choisies, c'est mieux pour tout le monde pour l'entreprise, pour les visiteurs, et pour le web. Pour 2026, la meilleure stratégie pour une PME n'est pas d'ajouter des dashboards, mais d'en retirer. Moins de bruit. Moins de friction. Plus de décisions concrètes. L'analytics frugale, c'est remettre la donnée au service du business, pas l'inverse.FAQ : comprendre l'analytics frugale Qu'est-ce que l'analytics frugale ? Une approche de la mesure d'audience qui limite la collecte au strict nécessaire pour prendre une décision business. Elle repose sur trois principes : collecter uniquement ce qui sert à décider, privilégier les données agrégées aux profils individuels, et choisir des outils aux limites de collecte claires (sans cookies de mesure, sans profils utilisateurs). Quels indicateurs garder absolument ? Visiteurs uniques, sources de trafic, top pages, événements clés (clics CTA, formulaires), et conversions. Ces 5 métriques suffisent pour piloter la performance d'un site vitrine, d'un blog ou d'un petit e-commerce. Tout le reste est du bonus ou du bruit. Peut-on faire de l'analytics frugale avec GA4 ? Techniquement oui, mais cela nécessite une expertise avancée : désactiver la collecte granulaire, configurer le consentement, réduire certains risques de transfert ou de collecte, et créer des rapports personnalisés limités aux KPIs essentiels. Pour la majorité des PME, c'est plus simple de choisir un outil nativement frugal, puis de documenter la configuration réelle. L'analytics frugale est-elle suffisante pour un e-commerce ? Pour un petit e-commerce (moins de 1 000 commandes/mois), oui. Les 5 KPIs essentiels couvrent l'acquisition, l'engagement et la conversion. Pour un e-commerce avec des besoins d'attribution multi-canal, de retargeting, ou de segmentation avancée, un outil plus complet (Matomo, GA4) sera nécessaire mais le principe de frugalité reste applicable : commencez par les KPIs essentiels, et n'ajoutez de la complexité que si elle est justifiée. Combien d'entreprises utilisent réellement le Big Data ? Les données Eurostat Digitalisation in Europe montrent un écart durable de digital intensity : en 2022, 98 % des grandes entreprises atteignaient un niveau basique, contre 69 % des PME. La plupart des petites équipes n'ont ni les personnes, ni les outils, ni le besoin d'exploiter des masses de données. L'analytics frugale est l'approche adaptée à cette réalité. SourcesEurostat, Digitalisation in Europe : technology uptake in businesses CNIL, Cookies : solutions pour les outils de mesure d'audience CNIL, évaluation de l'impact du plan d'action cookies Google Search Central, Core Web Vitals et résultats Google Search