Comment configurer PostHog pour respecter le RGPD, le CCPA et les lois sur la vie privée dans le monde

De nombreuses entreprises souhaitent utiliser PostHog pour leurs analyses web, mais se heurtent à un casse-tête réglementaire : faut-il un bandeau de consentement ? Que faire du RGPD européen, du CCPA californien, de la LGPD brésilienne ou de la PIPEDA canadienne ? Un guide récent expose deux méthodes propres pour intégrer PostHog sans compromettre ni la conformité ni la qualité des données.

Deux approches selon les besoins

La première méthode, dite « cookieless » (sans cookie), consiste à activer le mode sans cookie de PostHog. Dans ce mode, le SDK ne stocke rien dans le navigateur du visiteur. Les utilisateurs uniques sont comptés via un hachage côté serveur, renouvelé quotidiennement, à partir de l'adresse IP, de l'agent utilisateur et du nom d'hôte. Ce hachage n'est pas réversible et ne constitue pas une donnée personnelle. Cette approche est adaptée si l'on a seulement besoin de pages vues, de statistiques de base (référents, pages populaires, taux de rebond) et d'événements personnalisés ne contenant pas de données utilisateur.

La seconde méthode, dite « avec consentement », est nécessaire dès que l'on souhaite utiliser des fonctionnalités avancées : identification des utilisateurs (identify()), rejeu de session, enquêtes, indicateurs de fonctionnalités (feature flags) avec mise en cache, parcours utilisateur sur plusieurs jours ou appareils, enrichissement par géolocalisation ou profils de personnes. Dans ce cas, PostHog est exécuté normalement, mais uniquement après avoir obtenu le consentement approprié du visiteur. Le bandeau de cookies doit alors adapter son mode (opt-in ou opt-out) en fonction de la réglementation applicable au visiteur, déterminée par son pays.

Le bandeau de consentement reste indispensable

Une idée reçue courante est que le mode sans cookie de PostHog permet de supprimer le bandeau de consentement. C'est faux. Ce mode supprime seulement PostHog de la liste des outils qui nécessitent un consentement préalable. Le bandeau reste obligatoire pour tous les autres éléments du site qui stockent des informations : polices web, vidéos intégrées (YouTube, Vimeo), widgets de support, outils de suivi d'erreurs, pixels publicitaires, etc. Le bandeau doit être configuré par catégories et être sensible à la réglementation.

Les réglages clés dans PostHog

Pour que le mode sans cookie fonctionne, il ne suffit pas de l'activer dans le SDK. Il faut également, dans les paramètres du projet PostHog (Project Settings → Web Analytics), activer le « Cookieless server hash mode ». Sans cela, le hachage n'est pas calculé et les tableaux de bord afficheront zéro utilisateur pour les visiteurs en mode sans cookie.

L'initialisation du SDK doit se faire avec l'option cookieless_mode: "always" et respect_dnt: true. Il est impératif de ne jamais initialiser PostHog — ni de placer un cookie non essentiel — avant que le bandeau n'ait déterminé la réglementation applicable et le consentement existant du visiteur. Pour cela, il faut attendre un événement spécifique (comme probo-ready) qui signale que le bandeau a résolu ces points.

Gérer les événements personnalisés et le consentement existant

Les événements personnalisés qui contiennent des données utilisateur (comme un email ou un identifiant) doivent être conditionnés à une vérification de consentement. Il ne faut pas se fier au SDK pour nettoyer automatiquement les informations personnelles.

Le guide insiste sur un point important : si un visiteur a déjà exprimé son choix (acceptation ou refus) lors d'une visite précédente, cette décision préexistante doit être respectée, quelle que soit la réglementation par défaut. Le cookie probo_consent (strictement nécessaire, donc exempté de consentement) permet de mémoriser cette décision.

Adapter l'approche à chaque surface

En pratique, de nombreuses entreprises ont besoin des deux méthodes, mais sur des surfaces différentes : un site web public (marketing) peut se contenter du mode sans cookie (pages vues agrégées, pas de données par utilisateur), tandis qu'une application web authentifiée aura besoin du mode avec consentement (identification, rejeu, indicateurs). Dans ce cas, il est recommandé d'utiliser un bandeau distinct pour chaque surface (un identifiant pour le site, un autre pour l'application), avec des inventaires de cookies et des listes de catégories différents, pour une piste d'audit plus claire.

Les réglementations prises en compte

Le guide mentionne explicitement que le bandeau de cookies doit adapter son mode selon la réglementation du visiteur : opt-in pour le RGPD (UE), le RGPD UK, la directive ePrivacy, la LGPD (Brésil), la FADP (Suisse), la POPIA (Afrique du Sud), la PIPL (Chine), la PIPA (Corée du Sud), la DPDP (Inde) et la PDPL (Arabie Saoudite) ; opt-out pour le CCPA/CPRA (Californie), la PIPEDA (Canada), la LFPDPPP (Mexique) et l'APPI (Japon). Cela évite aux équipes de développer et maintenir une table de correspondance pays par pays dans leur code.

Limites du mode sans cookie

Le mode sans cookie présente plusieurs limitations, documentées par PostHog : pas de identify(), pas de rejeu de session, pas d'enquêtes, pas de mise en cache des indicateurs de fonctionnalités, pas d'enrichissement par géolocalisation, pas de détection des robots, et des mesures hebdomadaires/mensuelles d'utilisateurs actifs gonflées (car le sel de hachage change chaque jour). Des collisions de hachage sont également possibles sur les réseaux d'entreprise.

Conclusion

Le choix entre les deux méthodes dépend d'une seule question : a-t-on besoin de fonctionnalités analytiques avancées allant au-delà du simple comptage de visiteurs uniques et de pages vues ? Si oui, il faut opter pour la configuration avec consentement et un bandeau de cookies adaptatif. Sinon, le mode sans cookie offre une solution de conformité plus simple, mais le bandeau reste nécessaire pour les autres outils du site.