Ce que « Privacy-First » Signifie Réellement dans Votre Stack Analytics

« Privacy-first » est devenu une expression marketing. Les outils qui l'utilisent vont de ceux qui ne stockent véritablement aucune donnée personnelle à ceux qui ont simplement déplacé leurs cookies vers un stockage côté serveur et se sont déclarés conformes. Pour évaluer cette affirmation, vous devez examiner trois éléments spécifiques : ce qui est collecté, comment c'est stocké et si cela peut être inversé.

Niveau 1 : Ce qui est collecté

Chaque outil analytics collecte quelque chose. La question est de savoir si l'un de ces éléments qualifie de donnée personnelle selon le RGPD, la LGPD ou le CCPA. Les éléments suivants sont généralement sûrs — ils sont agrégés ou non identifiables en eux-mêmes :

• URL et chemin de la page
• Domaine référent (pas l'URL complète)
• Pays (déduit de l'IP en périphérie, jamais stocké)
• Type d'appareil (mobile ou desktop, déduit de la largeur d'écran et de schémas User-Agent larges)
• Famille de navigateur (Chrome, Safari, Firefox, et autres familles grossières dérivées côté serveur depuis le User-Agent de la requête)

Ce qui rend ces éléments sûrs, c'est qu'aucun d'eux, individuellement ou combinés, n'identifie de façon fiable une personne spécifique. Un domaine référent vous indique que quelqu'un est venu de Hacker News — pas quel utilisateur de Hacker News il est.

La ligne est franchie lorsque vous commencez à stocker des adresses IP, des user agents complets, des empreintes d'appareil, ou tout type d'identifiant persistant — même haché, que vous conservez entre les sessions.

Niveau 2 : Comment les données sont stockées

Collecter des données en toute sécurité est différent de les stocker en toute sécurité. De nombreux outils affirment ne pas utiliser de cookies, puis stockent un identifiant visiteur dans une session côté serveur liée à une adresse IP. L'adresse IP est une donnée personnelle au regard du RGPD. Le fait que le cookie ait été déplacé côté serveur ne change pas ce qui est suivi.

Un stockage véritablement privacy-first contient uniquement ce qui est listé ci-dessus — et un identifiant visiteur qui ne peut pas être relié à un individu. L'approche de Monoid est un hachage quotidien à sens unique :

visitor_hash = SHA-256(IP + UA + SALT_SECRET + YYYY-MM-DD)

Trois propriétés rendent cela sûr :

À sens unique : SHA-256 n'est pas réversible. Vous ne pouvez pas récupérer l'adresse IP depuis le hachage. Salé : Le SALT_SECRET côté serveur signifie que le hachage ne peut pas être attaqué par table arc-en-ciel même si l'algorithme est connu. Quotidien : La date dans l'entrée signifie que le même visiteur produit un hachage différent demain. Il n'y a pas d'identifiant inter-sessions persistant.

Le hachage n'est pas utile pour suivre une personne dans le temps. Il n'est utile que pour dédupliquer les visiteurs au sein d'une seule journée, ce qui est la seule chose qu'il doit faire.

Niveau 3 : Peut-il être inversé ?

C'est le test qui distingue les véritables outils privacy-first des affirmations marketing. Si un adversaire suffisamment motivé — y compris un gouvernement avec une ordonnance légale — obtenait votre base de données analytics, qu'apprendrait-il ?

Avec le modèle de données de Monoid : il pourrait apprendre quelles pages ont été visitées, depuis quels pays, sur quels appareils, et à quelles dates. Il ne pourrait pas apprendre quel individu spécifique a visité quelle page spécifique. Le hachage ne lui dit rien sans l'IP d'origine, le user agent d'origine, le sel secret et la date correcte — qui ne sont jamais tous stockés ensemble.

Comparez cela aux données GA4 « anonymisées », qui conservent des client IDs (identifiants persistants basés sur cookies), des horodatages d'événements avec une précision à la milliseconde et des composants d'empreinte d'appareil. Ces données ne sont pas anonymes — elles sont au mieux pseudonymes, et reliables à des utilisateurs réels avec un effort modéré.

À quoi ressemble réellement la base de données

Un enregistrement de pageview Monoid contient : site_id, path, referrer, country, device, browser_family, visitor_hash (le hachage quotidien à sens unique), et un timestamp. C'est l'enregistrement complet. Il n'y a pas de colonne d'adresse IP, pas de chaîne User-Agent complète, pas de version de navigateur, pas d'identifiant utilisateur persistant, pas de jeton de session. Il n'y a rien dans le schéma qui se rattache à une personne réelle.

Voilà à quoi ressemble privacy-first au niveau du modèle de données. Tout le reste — tableaux de bord, comptages en temps réel, ventilations par pays — est calculé à partir de ces champs.

Pourquoi la distinction compte en pratique

Si votre outil analytics stocke des données personnelles, vous êtes un responsable de traitement RGPD avec des obligations : vous devez publier une base légale pour le traitement, tenir des registres des activités de traitement et répondre aux demandes d'accès des personnes concernées. Vous avez également besoin d'un mécanisme de consentement si votre base légale est le consentement.

Si votre outil analytics ne stocke que des données agrégées non personnelles, ces obligations ne s'appliquent pas — parce qu'il n'y a pas de donnée personnelle à contrôler. La surcharge juridique disparaît avec le bandeau de consentement.