Tag : Cnil
Tous les articles du blog avec ce tag.
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
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
- 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"
- 13 Apr, 2026
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
- 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