Catégorie : Rgpd
Tous les articles du blog dans cette catégorie.
- 06 Jul, 2026
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
- 22 Jun, 2026
Politique de confidentialité analytics : les formulations utiles et celles à éviter
Une politique de confidentialité peut être juridiquement dense et techniquement fausse. Le cas est fréquent : le texte affirme que « seules des données anonymes » sont utilisées, tandis que le site transmet une URL complète, un identifiant de campagne et une adresse IP à plusieurs prestataires. À l’inverse, certaines politiques listent vingt catégories abstraites sans permettre au lecteur de comprendre ce que fait réellement l’analytics. La qualité ne vient pas du nombre de paragraphes. Elle vient de l’alignement entre :la collecte déployée ; les finalités ; les rôles des acteurs ; le consentement ou l’autre cadre applicable ; les durées ; les droits ; les mots utilisés.Le RGPD exige une information concise, transparente, compréhensible et aisément accessible. Les articles 12, 13 et 14 encadrent notamment le contenu de cette information. Une politique analytics utile doit donc rester lisible tout en décrivant les éléments importants avec assez de précision. Cet article propose une méthode éditoriale et opérationnelle. Il ne fournit pas une clause universelle et ne remplace pas une validation adaptée à l’organisation. Partir de la réalité, pas d’un modèle téléchargé Avant de rédiger, rassemblez quatre sources internes :l’inventaire des outils et traceurs ; le data collection summary ; les contrats, DPA et listes de sous-traitants ; la configuration du consentement et de la rétention.La politique doit être la vue publique de faits vérifiés. Elle ne doit pas servir à deviner le fonctionnement du site. Un modèle juridique peut aider à structurer les rubriques. Il ne peut pas savoir :si vous collectez l’URL complète ou seulement le chemin ; si l’adresse IP est stockée ; si un identifiant visiteur existe ; si le fournisseur réutilise des données ; si les événements contiennent du texte libre ; si une fonctionnalité étendue est activée après consentement ; si un export part vers un entrepôt ; si plusieurs sites partagent le même identifiant.Ces réponses doivent venir de l’audit. Utiliser une information en plusieurs niveaux Une politique unique de dix pages n’est pas toujours le meilleur point d’entrée. Une approche en couches améliore la lisibilité. Niveau 1 : information au moment pertinent À proximité du choix ou de la collecte, indiquez l’essentiel :finalité ; responsable ; caractère nécessaire ou optionnel ; lien vers le détail ; moyen d’accepter, refuser ou retirer lorsque le consentement s’applique.Pour une mesure strictement limitée ne nécessitant pas de consentement dans le contexte évalué, une mention courte peut renvoyer vers la section analytics de la politique. Niveau 2 : section analytics dédiée Cette section explique :ce qui est mesuré ; pourquoi ; comment les données sont réduites ; quel fournisseur intervient ; combien de temps les informations sont conservées ; comment exercer les droits ou poser une question ; quelles fonctionnalités dépendent du consentement.Niveau 3 : documentation approfondie Une page technique, une fiche fournisseur ou une documentation de collecte peut détailler les champs et transformations. Elle ne remplace pas l’information RGPD, mais permet aux lecteurs concernés de comprendre le système sans surcharger la première couche. Les niveaux doivent raconter la même histoire. Les rubriques à couvrir 1. L’identité du responsable de traitement Indiquez l’entité qui détermine les finalités et moyens du traitement, avec ses coordonnées. Lorsque le site appartient à un groupe, ne supposez pas que la marque visible est l’entité juridique responsable. Ajoutez les coordonnées du DPO lorsqu’il existe, ou un point de contact privacy clairement identifiable. Formulation utileLe responsable du traitement des données de mesure d’audience de ce site est [entité], joignable à [adresse ou formulaire]. Pour toute question relative à la protection des données, vous pouvez contacter [DPO ou contact].À éviterNous respectons votre vie privée.Cette phrase exprime une intention mais n’identifie personne. 2. Les finalités précises Séparez les finalités au lieu de tout regrouper sous « améliorer l’expérience ». Exemples :mesurer la fréquentation et les pages consultées ; détecter les erreurs de navigation ; comprendre les sources d’acquisition ; mesurer les demandes de démonstration ; produire des statistiques agrégées ; personnaliser des contenus ; mesurer des campagnes publicitaires.Les trois dernières ne relèvent pas nécessairement du même cadre. Si une mesure minimale fonctionne par défaut et une analytics étendue après consentement, dites-le clairement. Formulation utileNous utilisons une mesure d’audience limitée pour comprendre le volume de visites, les pages consultées et les principales sources de trafic. Les fonctionnalités d’attribution enrichie et [autre fonctionnalité] ne sont activées qu’après votre choix lorsqu’elles requièrent le consentement.À éviterNous collectons des données afin d’améliorer nos services et nos offres.La finalité est trop large pour être informative. 3. Les catégories de données et signaux La politique n’a pas besoin de reproduire chaque clé technique, mais elle doit donner une vision concrète. Selon la configuration :chemin de page ; heure de visite ; domaine référent ; paramètres de campagne autorisés ; type d’appareil et de navigateur réduit ; pays ou région approximative ; événement de conversion ; identifiant pseudonyme éventuel ; adresse IP reçue temporairement ; choix de consentement.Distinguez les données directement stockées des données utilisées seulement pour produire une information agrégée. Formulation utilePour chaque visite, nous enregistrons le chemin de la page, l’heure, le domaine référent lorsqu’il est transmis, une catégorie d’appareil et les paramètres de campagne autorisés. L’adresse IP est [décrire exactement le traitement]. Nous n’envoyons pas le contenu des formulaires à l’outil analytics.À éviterNous ne collectons aucune donnée personnelle.Cette affirmation est souvent trop absolue. Une adresse IP, un identifiant ou une combinaison de signaux peut relever des données personnelles selon le traitement. 4. La base légale et le cadre des traceurs Ne mélangez pas deux questions :l’opération de stockage ou d’accès sur le terminal au titre d’ePrivacy et du droit national ; la base légale du traitement de données personnelles au titre du RGPD.La checklist sur le consentement analytics décrit cette distinction. La formulation doit refléter l’analyse réelle. Elle peut mentionner, selon le cas :consentement ; intérêt légitime, après analyse adaptée ; mesure d’audience limitée entrant dans un cadre national d’exemption sous conditions ; fonctionnalité strictement nécessaire.N’utilisez pas la base légale comme un label marketing. Expliquez aussi comment le choix est recueilli ou comment l’analyse est documentée. À éviterNotre outil est conforme à la CNIL, aucun consentement n’est donc nécessaire.La CNIL précise que l’exemption dépend de la configuration et des conditions. Elle interdit également de présenter une solution comme « certifiée » ou « validée par la CNIL » sur la base de son auto-évaluation. 5. Les destinataires et fournisseurs Identifiez les catégories de destinataires et, lorsque cela améliore la transparence, les fournisseurs principaux. Précisez les rôles :équipes internes habilitées ; prestataire analytics ; hébergeur ; support technique ; agence ; entrepôt de données.« Partenaires de confiance » n’est pas une description suffisante. Pour chaque fournisseur, vérifiez s’il agit comme sous-traitant, responsable indépendant ou dans un autre schéma. La qualification dépend des faits et du contrat. 6. Les transferts internationaux Si des données sont accessibles ou transférées hors de l’Espace économique européen, expliquez les pays ou catégories de transferts, les mécanismes invoqués et les moyens d’obtenir plus d’informations, selon ce qui s’applique. Ne confondez pas :région d’hébergement ; siège du fournisseur ; lieux d’accès du support ; sous-traitants ; transfert juridique.Évitez d’écrire « données hébergées en Europe, donc aucun transfert » sans vérifier la chaîne complète. 7. Les durées de conservation Une durée vague telle que « aussi longtemps que nécessaire » doit être complétée par des critères ou périodes concrètes. Séparez :traceur ou identifiant ; événements bruts ; rapports agrégés ; logs de sécurité ; sauvegardes ; exports.Formulation utileLes événements analytics sont conservés pendant [durée]. Les statistiques agrégées sont conservées pendant [durée ou critère]. Les journaux techniques suivent une durée distincte de [durée]. Les exports manuels sont supprimés selon [procédure].Pour une mesure relevant du cadre français décrit par la CNIL, les recommandations de treize mois pour la durée de vie de certains traceurs et de vingt-cinq mois pour les informations collectées sont des repères à examiner. Elles ne doivent pas être copiées si votre configuration utilise une autre durée sans justification. 8. Les droits et moyens d’exercice Expliquez les droits applicables et fournissez un moyen simple de contact. Selon la base et le traitement, les droits peuvent inclure accès, rectification, effacement, limitation, opposition ou portabilité. Une analytics réellement anonyme peut ne pas permettre d’identifier une personne pour répondre à une demande individuelle. Dites-le avec précision, sans utiliser l’anonymat comme formule de dispense générale. Indiquez aussi la possibilité d’introduire une réclamation auprès de l’autorité de contrôle compétente. 9. Le retrait du consentement ou l’opposition Lorsque le consentement s’applique, fournissez un contrôle accessible pour le retirer aussi facilement qu’il a été donné, selon les règles applicables. Lorsque le traitement repose sur une autre base et qu’un droit d’opposition s’applique, expliquez la procédure. Le lien « gérer mes cookies » doit fonctionner sur mobile, rester visible et mettre à jour le comportement réel des tags. 10. La date et les changements Ajoutez une date de dernière mise à jour et un processus pour les modifications importantes. La politique doit être revue lorsqu’une équipe :ajoute un outil ; active une nouvelle finalité ; modifie un identifiant ; change la rétention ; ajoute un export ; change de fournisseur ; ouvre une propriété dans un nouveau pays ; modifie le consentement.Un historique concis des changements significatifs peut aider les lecteurs réguliers. Un exemple de section courte à adapter Le texte suivant est un squelette éditorial, pas une clause prête à publier.Mesure d’audience Nous utilisons [outil] afin de mesurer la fréquentation du site, les pages consultées et les principales sources de visite. Cette mesure nous aide à détecter les problèmes de navigation et à évaluer l’utilité de nos contenus. Selon notre configuration, les données traitées comprennent [liste concrète]. [Décrire le traitement de l’adresse IP et des identifiants]. Le contenu des formulaires et les paramètres d’URL non autorisés ne sont pas envoyés. [Fournisseur] intervient en qualité de [rôle] et traite les données dans [lieux et transferts pertinents]. Les données sont conservées pendant [durées par couche]. [Expliquer le cadre ePrivacy et la base RGPD retenus, avec les conditions et le fonctionnement du consentement le cas échéant]. Vous pouvez exercer vos droits ou poser une question à [contact]. Vous pouvez [retirer votre consentement / exercer votre opposition] via [moyen].Chaque crochet exige une réponse vérifiée. Les formulations qui fragilisent la crédibilité « Données totalement anonymes » Utilisez cette expression uniquement si l’équipe peut expliquer la méthode et démontrer que les données ne permettent plus raisonnablement d’identifier ou d’individualiser une personne. Sinon, préférez :données agrégées ; identifiants supprimés ; données pseudonymisées ; granularité réduite ; adresse IP non conservée dans les événements.Ces termes ne sont pas interchangeables. « Aucune donnée n’est partagée » Si un prestataire héberge ou traite la collecte, il reçoit des données en tant qu’acteur du traitement. La bonne phrase peut être « aucune donnée n’est vendue » ou « les données ne sont pas utilisées à des fins publicitaires », si c’est exact, mais pas « aucun partage » par réflexe. « Conforme au RGPD » Une conformité dépend du traitement, du responsable, de la configuration, du contrat et des opérations. Présentez les mesures concrètes plutôt qu’un verdict global. « Cookies nécessaires » Expliquez nécessaires à quoi. Un tracker publicitaire n’est pas nécessaire parce que l’équipe marketing le juge utile. « Nous pouvons modifier cette politique à tout moment » Cette clause n’explique ni l’information des personnes ni la gestion des changements significatifs. Ajoutez une date et un mécanisme raisonnable de notification lorsque nécessaire. Aligner la politique avec le produit Une incohérence apparaît souvent lorsqu’une équipe édite la politique une fois par an, alors que la stack change chaque semaine. Intégrez un contrôle dans le cycle de livraison :toute demande de nouveau tag indique finalité, données et fournisseur ; le propriétaire privacy ou analytics examine l’impact ; le data collection summary est mis à jour ; la politique et la CMP sont modifiées si nécessaire ; le déploiement est testé ; la preuve est conservée.Pour les paramètres d’URL, appliquez l’allowlist de collecte avant que le texte ne promette une collecte réduite. Audit éditorial en douze questions Relisez la section analytics et demandez :le responsable est-il identifiable ? les finalités sont-elles séparées ? les données sont-elles décrites concrètement ? la réception temporaire est-elle distinguée du stockage ? la base RGPD est-elle indiquée ? le régime des traceurs est-il expliqué sans raccourci ? les fournisseurs et rôles sont-ils clairs ? les transferts ont-ils été vérifiés ? les durées sont-elles concrètes ? les droits et moyens d’exercice sont-ils accessibles ? le retrait ou l’opposition fonctionne-t-il ? le texte correspond-il au réseau et à la configuration actuels ?Une réponse négative déclenche une correction de la stack ou du texte. Parfois des deux. Conclusion Une bonne politique de confidentialité analytics ne cherche pas à rassurer par des adjectifs. Elle donne des faits compréhensibles. Elle explique qui mesure, pourquoi, avec quels signaux, pour combien de temps, avec quels prestataires, sous quel cadre et avec quels contrôles pour les personnes. Le meilleur processus consiste à partir de l’inventaire technique, à rédiger en couches, à faire valider les qualifications nécessaires et à lier toute évolution de la stack à une mise à jour documentaire. La transparence n’est pas un exercice séparé du produit. C’est la description publique de sa gouvernance. FAQ Faut-il citer le nom de l’outil analytics dans la politique ? Le RGPD impose notamment d’informer sur les destinataires ou catégories de destinataires. Citer le fournisseur principal améliore souvent la clarté, mais la forme exacte dépend du traitement et de la structure de la notice. Peut-on écrire que les données sont anonymes ? Seulement si l’anonymisation est réellement démontrée. Une donnée pseudonymisée, agrégée ou privée d’adresse IP n’est pas automatiquement anonyme. La politique remplace-t-elle la bannière de consentement ? Non. La politique fournit l’information détaillée. Lorsqu’un consentement préalable est requis, le mécanisme doit permettre un choix valable avant le déclenchement des traceurs concernés. Faut-il lister chaque événement analytics ? Pas nécessairement dans la première couche. Décrivez des catégories concrètes et rendez une documentation plus détaillée accessible si elle est utile. Les événements sensibles ou inattendus doivent être explicitement analysés. Que faire lorsqu’un fournisseur change ses sous-traitants ? Évaluer l’impact sur les destinataires, transferts, contrats et risques, puis mettre à jour la documentation et l’information lorsque nécessaire. SourcesRèglement (UE) 2016/679, articles 12, 13 et 14 CNIL, RGPD : exemples de mentions d’information CNIL, Informer les personnes CNIL, Cookies : solutions pour les outils de mesure d’audience CEPD, Lignes directrices sur la transparence au sens du règlement 2016/679
Consentement analytics : ce qu’il faut vérifier avant de promettre « sans bannière »
« Analytics sans cookies » devient souvent, en une phrase, une promesse d’absence de consentement, puis de site sans bannière. Ces trois affirmations ne sont pas équivalentes. Un outil peut ne pas déposer de cookie tout en lisant ou écrivant une information sur le terminal par un autre mécanisme. Une solution peut proposer une configuration de mesure d’audience limitée, tandis que d’autres modules du même produit exigent une analyse différente. Et même si l’analytics respecte un cadre strict, un site peut charger des vidéos, formulaires, pixels publicitaires ou outils de support qui rendent une interface de consentement nécessaire. La bonne question n’est donc pas : « l’outil est-il cookieless ? » Elle est :Quels traitements et traceurs sont effectivement déployés sur ce site, dans cette configuration, pour quelles finalités et sous quelles conditions ?Cet article présente une grille de vérification. Il ne constitue pas un avis juridique et doit être adapté aux pays, aux usages et à la configuration du site. Trois couches à ne pas confondre 1. La technologie de stockage ou d’accès Le mot « cookie » décrit une technique parmi d’autres. Le cadre ePrivacy vise plus largement le stockage d’informations dans le terminal d’un utilisateur ou l’accès à des informations déjà stockées, selon les règles transposées dans chaque État. Des identifiants en local storage, certains pixels, SDK, mécanismes de fingerprinting ou autres accès au terminal peuvent donc poser la même question de consentement, même sans cookie HTTP traditionnel. Cookieless décrit une caractéristique technique. Ce n’est pas une qualification juridique complète. 2. Le régime ePrivacy des traceurs En France, l’article 82 de la loi Informatique et Libertés transpose le cadre relatif aux traceurs. Le principe est l’information et le consentement préalable pour les opérations concernées, avec des exceptions notamment lorsque le traceur est strictement nécessaire à la fourniture d’un service expressément demandé. La CNIL décrit aussi des conditions sous lesquelles certains traceurs de mesure d’audience peuvent entrer dans un périmètre d’exemption. Il s’agit d’un cadre étroit, pas d’une exemption générale pour toute analytics. 3. Le traitement de données personnelles au titre du RGPD Même lorsqu’une opération sur le terminal ne requiert pas de consentement ePrivacy dans une configuration donnée, le traitement peut rester soumis au RGPD s’il porte sur des données personnelles. Il faut alors documenter notamment les finalités, la base légale pertinente, l’information, la minimisation, la durée, les destinataires, les transferts, la sécurité et les droits. L’absence de bannière ne signifie donc ni absence de traitement, ni absence d’information. Les conditions françaises d’une mesure d’audience limitée La CNIL indique que, pour être limités à ce qui est strictement nécessaire à la fourniture du service et pouvoir être exemptés de consentement dans le cadre décrit, les traceurs doivent notamment :avoir une finalité strictement limitée à la mesure de l’audience du site ou de l’application ; être utilisés pour le compte exclusif de l’éditeur ; produire uniquement des données statistiques anonymes ; ne pas conduire à un recoupement avec d’autres traitements ; ne pas transmettre de données non anonymes à des tiers ; ne pas permettre un suivi global entre plusieurs sites ou applications.La CNIL recommande également l’information des utilisateurs, une durée de vie des traceurs limitée, par exemple treize mois sans prorogation automatique, une conservation des informations collectées limitée à vingt-cinq mois et un réexamen périodique de ces durées. Chaque terme compte. « Finalité strictement limitée » Mesurer les performances techniques, les contenus consultés ou les problèmes de navigation peut entrer dans la logique décrite. Constituer des audiences publicitaires, enrichir un profil CRM, personnaliser des annonces ou suivre une personne entre services relève d’autres finalités. Une même interface produit peut proposer les deux. C’est la fonctionnalité activée qui doit être auditée. « Pour le compte exclusif de l’éditeur » Le fournisseur ne doit pas transformer la collecte en ressource pour son propre ciblage, son profilage ou une mesure transversale non compatible avec le cadre considéré. Lisez le contrat, la documentation du produit et la liste des sous-traitants. Une affirmation commerciale ne suffit pas. « Statistiques anonymes » Le mot anonyme est exigeant. Supprimer un nom, tronquer une IP ou hacher un identifiant ne garantit pas automatiquement l’anonymat. Si un signal permet encore de distinguer ou relier une personne, l’analyse doit rester prudente. Demandez au fournisseur de décrire les transformations et les risques de réidentification. « Pas de suivi global entre sites » Un identifiant commun utilisé pour dédupliquer une personne entre plusieurs propriétés change le périmètre. Cette règle est particulièrement importante pour les groupes et agences qui souhaitent consolider leur audience. Le tableau de bord multi-sites peut agréger des indicateurs sans imposer un identifiant transversal. La checklist avant toute promesse « sans bannière » 1. Inventorier tous les composants du site Ne commencez pas par l’outil analytics. Commencez par le site complet :analytics ; gestionnaire de tags ; vidéos intégrées ; cartes ; chat et support ; formulaires ; anti-fraude ; A/B testing ; session replay ; publicité ; réseaux sociaux ; CDN et sécurité ; scripts des partenaires ; SDK mobiles éventuels.Réalisez un audit des traceurs avant et après chaque choix de consentement. Testez plusieurs pages et parcours. Une analytics stricte ne neutralise pas un pixel publicitaire chargé ailleurs. 2. Décrire les finalités réelles Pour chaque composant, écrivez ce qu’il permet réellement :statistiques agrégées de fréquentation ; analyse de campagne ; personnalisation ; publicité ; sécurité ; enregistrement d’interactions ; assistance ; expérimentation produit.Évitez la catégorie unique « amélioration du service ». Elle est trop large pour gouverner la configuration. 3. Vérifier les opérations sur le terminal Documentez :cookies déposés ou lus ; local storage ; session storage ; identifiants de cache ; SDK ; pixels ; accès à des caractéristiques du terminal ; mécanismes de consentement et de retrait.Le fait qu’aucun cookie n’apparaisse dans un outil de scan ne clôt pas l’analyse. 4. Vérifier les données collectées et les transformations Le data collection summary doit répondre à des questions concrètes :l’adresse IP est-elle reçue, utilisée et stockée ? l’URL complète est-elle transmise ? le user-agent est-il conservé brut ou réduit ? un identifiant visiteur est-il créé ? peut-il être stable entre des jours ou des sites ? les paramètres UTM sont-ils conservés ? des événements libres peuvent-ils contenir du texte ? quelles données sont agrégées ? à quel moment une donnée devient-elle non individualisable ?Un mode « anonyme » dont personne ne peut expliquer le fonctionnement n’est pas une preuve. 5. Vérifier l’usage par le fournisseur Demandez :le fournisseur agit-il uniquement comme sous-traitant pour cette collecte ? réutilise-t-il certaines données pour ses propres finalités ? combine-t-il les données entre clients ? fournit-il un benchmark à partir de données individualisées ? entraîne-t-il un modèle ou enrichit-il un autre produit ? quels sous-traitants reçoivent les données ? quels transferts internationaux s’appliquent ?Une fonctionnalité de benchmark peut parfois être conçue sur des données agrégées et séparées. Elle doit néanmoins être comprise, pas supposée. 6. Vérifier la configuration exacte La documentation peut indiquer « configurable pour respecter les critères ». Cela ne signifie pas que la configuration par défaut de votre compte les respecte. Conservez une preuve des réglages :capture ou export de configuration ; version du script ; paramètres de collecte ; modules désactivés ; domaines autorisés ; rétention ; options de partage ; date de vérification ; responsable.La CNIL invite les éditeurs à demander aux fournisseurs les documents permettant de justifier le cadre et ses modalités opérationnelles. 7. Examiner la rétention Distinguez :durée de vie d’un traceur ou identifiant ; rétention des événements bruts ; rétention des statistiques ; logs techniques ; sauvegardes ; exports.La suppression automatique doit être vérifiée. Une durée affichée dans le tableau de bord ne couvre pas nécessairement les exports créés par l’équipe. 8. Vérifier l’information des visiteurs Même lorsqu’un consentement n’est pas requis pour une mesure strictement encadrée, la CNIL recommande d’informer les utilisateurs de sa mise en œuvre, par exemple dans la politique de confidentialité. L’information doit expliquer, selon le contexte :la finalité ; les données ou catégories pertinentes ; le fonctionnement général ; la durée ; le fournisseur ; les destinataires ; les droits et moyens de contact ; les transferts pertinents.« Nous utilisons une analytics respectueuse de la vie privée » est trop vague. 9. Tester le refus et le retrait Lorsqu’une partie de la stack repose sur le consentement :aucun traceur concerné ne doit partir avant le choix ; le refus doit être aussi simple que l’acceptation selon les règles applicables ; le retrait doit produire un effet ; le signal doit atteindre tous les tags concernés ; les nouvelles pages et composants doivent respecter le choix.Testez le comportement, pas seulement l’apparence de la CMP. 10. Faire valider le périmètre La décision finale appartient au responsable de traitement, accompagné si nécessaire par son DPO ou son conseil. Conservez l’analyse :pays concernés ; finalités ; inventaire ; critères examinés ; documentation fournisseur ; configuration ; tests ; risques résiduels ; date et responsables ; déclencheurs de révision.Une conclusion peut être différente entre un site corporate français, une application authentifiée et un ensemble de propriétés internationales. Cookieless, Consent Mode et mesure sans bannière Cookieless Le terme peut signifier :aucun cookie persistant ; aucun cookie dans un mode précis ; stockage alternatif ; événement sans identifiant ; identifiant dérivé côté serveur ; simple absence de cookies publicitaires.Demandez une définition technique. Le mot seul ne suffit pas. Consent Mode Un mode de consentement transmet l’état du choix aux tags et peut modifier leur comportement. Selon le produit et la configuration, des signaux peuvent encore être envoyés sans cookie publicitaire. Ce mécanisme aide à appliquer une décision. Il ne décide pas à la place de l’éditeur si la collecte sans consentement est permise. Il ne transforme pas non plus une finalité publicitaire en mesure strictement nécessaire. « Pas de bannière » Cette phrase ne peut être évaluée qu’au niveau du site complet. Elle peut être raisonnable lorsqu’aucun composant non nécessaire n’est déployé avant consentement et que la mesure d’audience utilisée respecte effectivement le cadre applicable. Elle devient trompeuse si elle repose seulement sur l’absence de cookie analytics. Les formulations à utiliser ou éviter À éviterpromesse de conformité RGPD totale ; exemption valable dans tous les cas ; équivalence automatique entre absence de cookies et absence de bannière ; certification officielle par la CNIL ; validation officielle par l’autorité ; « aucune donnée personnelle » « aucune analyse juridique nécessaire »La CNIL précise qu’une solution ne peut pas se présenter comme certifiée ou validée par elle sur la seule base de l’auto-évaluation relative à la mesure d’audience. Formulations plus précises« cookieless par défaut » « conçu pour une collecte minimale » « peut être configuré pour une mesure d’audience limitée » « l’applicabilité d’une exemption dépend des finalités, de la configuration et du contexte » « les utilisateurs restent informés de la mesure mise en œuvre » « la stack complète du site doit être auditée »La précision protège la crédibilité autant que la conformité. Quand conserver une bannière Une bannière ou autre mécanisme de consentement reste généralement nécessaire lorsque le site active, selon le cadre applicable :publicité personnalisée ; retargeting ; partage avec des régies ; suivi inter-sites ; enrichissement de profils ; certains outils de session replay ; personnalisation non nécessaire ; intégrations tierces déposant des traceurs non essentiels ; analytics dépassant le périmètre d’une mesure limitée.L’article sur le session replay et la consultation CNIL montre pourquoi une fonctionnalité détaillée d’observation ne doit pas être assimilée à une statistique d’audience agrégée. Un processus de décision simple Cas A : mesure strictement limitée L’équipe utilise une collecte minimale, sans suivi transversal, sans réutilisation fournisseur, avec statistiques anonymes, rétention cadrée, information et documentation. Action : analyser et documenter l’applicabilité du cadre local, puis vérifier le reste du site. Cas B : analytics enrichie après consentement L’équipe veut des événements détaillés, de l’attribution avancée ou des identifiants plus persistants. Action : bloquer les fonctionnalités concernées avant consentement, transmettre le choix correctement et documenter le traitement. Cas C : stack mixte Une mesure minimale fonctionne par défaut, puis des modules étendus sont activés après consentement. Action : séparer techniquement les modes, éviter qu’un changement de rapport active silencieusement une collecte, et tester chaque transition. Cette séparation stricte est plus crédible qu’un réglage unique supposé convenir à tous les usages. Conclusion Une promesse « sans bannière » ne se déduit pas du mot cookieless. Elle résulte d’une analyse du site complet, de ses finalités, de ses opérations techniques et de sa configuration. Avant de communiquer, vérifiez :tous les composants ; les finalités ; les accès au terminal ; les données et identifiants ; les usages du fournisseur ; la configuration ; la rétention ; l’information ; le fonctionnement du consentement lorsqu’il s’applique ; la documentation de la décision.Le résultat peut être une stack sans bannière pour un périmètre strict, une stack avec consentement pour des usages étendus, ou une combinaison clairement séparée. La qualité vient de cette distinction, pas d’un slogan. FAQ Une analytics sans cookies est-elle automatiquement exemptée de consentement ? Non. Il faut examiner les autres opérations sur le terminal, les finalités, les données, les identifiants et le droit national applicable. Cookieless est une caractéristique technique, pas une conclusion juridique. La CNIL certifie-t-elle les outils analytics exemptés ? Non. La CNIL fournit un cadre et un outil d’auto-évaluation, mais précise qu’une solution ne peut pas se présenter comme « certifiée » ou « validée par la CNIL » sur cette base. Peut-on informer les visiteurs sans afficher une bannière ? Oui, lorsque le consentement n’est pas requis pour la collecte considérée, une information peut être fournie dans la politique de confidentialité ou un espace approprié. Son contenu doit rester clair et exact. Les UTM empêchent-ils une exemption ? Pas automatiquement, mais leur usage et leur combinaison doivent rester compatibles avec la finalité limitée, la minimisation et l’absence de suivi transversal. Ils ne doivent jamais contenir de donnée personnelle. Qui décide si le site peut fonctionner sans bannière ? Le responsable de traitement prend la décision et doit pouvoir la documenter, avec l’appui de son DPO ou conseil lorsque nécessaire. Le fournisseur seul ne peut pas garantir la conclusion pour tous les sites. SourcesCNIL, Cookies : solutions pour les outils de mesure d’audience CNIL, Cookies et traceurs : que dit la loi ? CNIL, Cadre de mesure d’audience à comprendre avant de choisir un outil Directive 2002/58/CE relative à la vie privée et aux communications électroniques CEPD, Lignes directrices 05/2020 sur le consentement CEPD, Lignes directrices 2/2023 sur le champ technique de l’article 5(3) ePrivacy
- 04 May, 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"
- 30 Mar, 2026
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
- 23 Mar, 2026
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