Un guide pratique de Comment créer des analyses de site Web

Ce guide explique Comment créer des analyses de site Web de manière pratique, avec un accent sur les décisions d'analytics respectueuses de la vie privée.

Les analyses sans cookies ne sont pas automatiquement conformes à GDPR. Il s’agit d’une direction de conception, pas d’une étiquette magique.

Un outil peut éviter les cookies tout en collectant des données personnelles. Il peut hacher les adresses IP de manière à ce qu'elles restent liées. Il peut prendre des empreintes digitales sur les appareils. Il peut stocker des parcours d’événements détaillés qui identifient les personnes. Pour créer des analyses véritablement axées sur la confidentialité, vous devez réduire à la fois le stockage et l’identifiabilité du navigateur.

Commencez par les deux niveaux juridiques

L’analyse européenne touche généralement deux régimes liés mais distincts.

Le ePrivacy Directive, mis en œuvre par les lois nationales, réglemente le stockage d'informations sur l'équipement terminal d'un utilisateur ou l'accès à des informations à partir de celui-ci. Les Lignes directrices 2/2023 relatives à l'article 5, paragraphe 3 finales de EDPB indiquent clairement que le champ d'application est plus large que les cookies classiques.

Le GDPR régule le traitement des données personnelles. Une configuration peut éviter les cookies mais traiter quand même les données personnelles si elle collecte des adresses IP, des IDs uniques, une localisation granulaire, des empreintes digitales de l'appareil ou un comportement détaillé permettant d'identifier ou de distinguer une personne.

L’objectif de l’architecture est donc double :

• éviter le stockage non essentiel du navigateur et l'accès aux appareils
• minimiser ou anonymiser les données personnelles dans le pipeline d'analyse

Ce qu'il ne faut pas faire

Ne remplacez pas simplement les cookies par des empreintes digitales. La combinaison de l'adresse IP, de l'agent utilisateur, du fuseau horaire, de la taille de l'écran, des polices, de la langue et des propriétés de l'appareil pour créer un identifiant stable est toujours en cours de suivi. Cela peut être pire car les utilisateurs ne peuvent pas facilement le voir ou le supprimer.

Ne présumez pas que le hachage équivaut à l’anonymisation. Un hachage d'une adresse IP et d'un agent utilisateur peut toujours être une donnée personnelle si la même entrée produit la même sortie et que le contrôleur peut lier l'activité au fil du temps. Le guide GDPR du EDPB traite les données pseudonymisées comme des données toujours personnelles lorsque la réidentification reste raisonnablement possible.

N'envoyez pas de URL complète sans désinfection. Les chaînes de requête contiennent souvent des données personnelles, des jetons, des adresses e-mail, des termes de recherche ou un clic publicitaire IDs.

Ne réutilisez pas les données analytiques à des fins publicitaires. Les guides de mesure d'audience de CNIL traitent les analyses exemptées de manière étroite : objectif limité, pas de suivi intersites, pas de combinaison avec d'autres données et pas de divulgation à des fins sans rapport.

Une meilleure architecture sans cookies

Un événement d’analyse axé sur la confidentialité doit être de petite taille :

{
  "type": "pageview",
  "path": "/pricing",
  "referrer_host": "example.com",
  "utm_source": "newsletter",
  "utm_medium": "email",
  "country": "DE",
  "device": "desktop"
}

Évitez d'envoyer :

• adresses brutes IP pour le stockage à long terme
• agents utilisateurs complets si une catégorie de navigateur/appareil grossière suffit
• chaînes de requête complètes
• e-mails, noms, compte IDs, adresses de portefeuille ou client IDs
• champs de formulaire libre
• géolocalisation précise

Utilisez l'adresse IP uniquement de manière transitoire, si nécessaire, pour dériver un pays ou une région de manière grossière. Jetez-le avant le stockage persistant. Si vous avez besoin d'une détection de robots ou d'une limitation du débit, séparez ce pipeline des rapports d'analyse et appliquez une rétention courte.

Comptage des visites sans cookies

Compter les pages vues est facile sans identifiants. Compter les visites est plus difficile.

Un modèle courant de préservation de la confidentialité consiste à créer une clé de visite dérivée de courte durée à partir des attributs de la demande et d'un sel secret tournant. Par exemple, un serveur peut dériver une clé du préfixe IP, de l'agent utilisateur grossier, du site ID et d'un sel qui tourne quotidiennement ou plus souvent. Les entrées brutes ne sont pas stockées et la clé ne peut pas être utilisée sur de longues périodes.

Il s’agit toujours d’une approche exigeante. Il peut être pseudonyme plutôt qu'anonyme, en fonction de la mise en œuvre, de la conservation et de la capacité du contrôleur à recalculer ou lier les enregistrements. Traitez-le comme une technique de minimisation, et non comme une preuve que GDPR ne s'applique plus.

Si vous pouvez répondre à la question commerciale avec moins, faites-en moins. De nombreuses équipes n'ont besoin que de pages vues, de premières pages, de référents, de campagnes et de conversions. Le décompte des visiteurs uniques est utile, mais ne mérite pas un suivi invasif.

Analyses sans consentement : lorsqu'il s'agit de Plausible

L’analyse sans consentement est plus plausible lorsque :

• aucun cookie, localStorage ou identifiant similaire n'est utilisé
• aucune empreinte digitale de l'appareil n'est créée
• les données personnelles ne sont pas stockées ou sont anonymisées de manière rapide et irréversible
• les données ne sont utilisées que pour la mesure globale de l'audience
• les données ne sont pas partagées avec les réseaux publicitaires ni réutilisées entre les clients
• la rétention est courte
• les utilisateurs sont informés de manière transparente
• les pages et paramètres sensibles sont exclus

C'est pourquoi de nombreux outils axés sur la confidentialité sont plus simples que Google Analytics. La simplicité n'est pas une caractéristique manquante. C'est la stratégie de conformité.

Liste de contrôle de mise en œuvre

Avant le lancement, testez le site dans un profil de navigateur propre :

1. Ouvrez DevTools et confirmez qu'aucun cookie d'analyse n'est défini.
2. Vérifiez localStorage, sessionStorage, IndexedDB et l'utilisation du cache.
3. Inspectez les requêtes réseau et confirmez que les charges utiles d’analyse sont minimes.
4. Confirmez que les paramètres de requête sont sur liste blanche ou supprimés.
5. Vérifiez que GPC ou les choix de consentement désactivent toutes les balises publicitaires.
6. Confirmez que les paramètres de conservation correspondent à votre avis de confidentialité.
7. Documentez la base juridique et l'analyse ePrivacy avec un avocat si vous opérez sur des marchés réglementés.

Vérification de la réalité de la conformité

Ne considérez pas « sans cookie » comme une conclusion juridique. Avant le lancement, documentez chaque événement, la décision qu'il prend en charge, si un stockage ou un identifiant de périphérique est impliqué, quels fournisseurs reçoivent les données et quand les enregistrements bruts expirent.

Testez ensuite le site dans un profil de navigateur propre et comparez le résultat avec l'avis de confidentialité. Si le navigateur affiche toujours des appels tiers, des identifiants persistants ou des données de chaîne de requête non planifiées, l'histoire de conformité nécessite davantage de travail avant que la revendication marketing ne soit mise en ligne.

L'essentiel

Des analyses sans cookies alignées sur GDPR sont possibles, mais uniquement lorsque le système est conçu autour de la minimisation des données. Évitez le stockage des appareils, évitez les identifiants intersites, évitez la réutilisation des publicités et conservez les rapports agrégés.

La configuration d'analyse la moins risquée est celle qui répond à la question commerciale sans avoir besoin de savoir qui est le visiteur.