Pourquoi PostHog requiert un consentement — et pourquoi la réponse n'est pas la même pour chaque module

Le SDK web PostHog n'est pas un tag de page passif. Lors d'une initialisation par défaut, le SDK définit une ou plusieurs entrées de persistance first-party — par défaut, un schéma combinant cookie et localStorage indexé sous ph_{projectKey}_posthog — génère un identifiant distinct stable, capture la page vue initiale avec le référent, les paramètres UTM et les identifiants de clic, et ouvre un canal d'événements de longue durée vers l'hôte d'ingestion configuré. Si l'enregistrement de session est activé au niveau du projet, le SDK commence en outre à diffuser un enregistrement continu du DOM rendu, des coordonnées de la souris et des événements d'entrée. Si des feature flags sont configurés, le SDK les évalue par rapport à l'identifiant distinct, persiste les décisions pour la session et émet un événement $feature_flag_called pour chaque évaluation.

Chacune de ces activités correspond à une porte de consentement différente. Persister un identifiant distinct est une opération de stockage et d'accès au titre de l'article 5(3) de la directive ePrivacy et requiert un consentement préalable, librement donné, spécifique, éclairé et non ambigu dans tout l'EEE, au Royaume-Uni et dans toute juridiction ayant importé le même standard. La capture d'événements comportementaux constitue un traitement de données à caractère personnel au titre du GDPR, car la combinaison de l'identifiant, de l'adresse IP et de la trace comportementale est suffisante pour distinguer un individu. L'enregistrement de session se situe dans une catégorie distincte et plus stricte au titre des directives de l'EDPB sur l'enregistrement de session — le replay capture le DOM rendu et tout champ de saisie non masqué et requiert un consentement explicite et granulaire distinct du consentement analytics générique. L'évaluation des feature flags est la plus subtile : une vérification de flag qui renvoie un booléen ne requiert pas en soi de consentement, mais persister l'attribution de flag d'un utilisateur sur un identifiant stable entre les sessions l'exige, car c'est ainsi que l'expérimentation basée sur les flags crée des données traçables au niveau de l'utilisateur.

Ce que PostHog écrit avant le consentement — et ce qui doit être supprimé

Le SDK Browser PostHog par défaut écrit ce qui suit lors de l'initialisation : une entrée de cookie combiné et de localStorage sous ph_{projectKey}_posthog contenant l'identifiant distinct, l'identifiant de session et les décisions de feature flag, plus, lorsque l'enregistrement de session est activé, un tampon d'enregistrement en mémoire supplémentaire qui se vide vers le point de terminaison d'ingestion toutes les quelques secondes. Le SDK envoie également un événement $pageview immédiat et, si la capture automatique est activée, chaque clic, interaction de formulaire et rage-click sur la page.

Le pattern recommandé consiste à initialiser PostHog avec opt_out_capturing_by_default: true et disable_session_recording: true, puis à basculer les deux flags dès que la bannière de consentement renvoie un signal positif. C'est la posture d'intégration que la documentation PostHog recommande désormais, et c'est la posture qui résiste à l'examen d'un régulateur, car elle inverse le comportement par défaut : rien n'est capturé jusqu'à ce que le consentement soit enregistré, et le SDK fournit une transition propre plutôt qu'une mise à jour a posteriori avec état.

Les cookies, entrées localStorage et identifiants que PostHog persiste

Le SDK Browser 1.x écrit une entrée de persistance par projet, indexée sous ph_{projectKey}_posthog, avec une expiration de 365 jours par défaut. L'option d'initialisation persistence contrôle le mécanisme sous-jacent : cookie uniquement, localStorage uniquement, localStorage+cookie (valeur par défaut), sessionStorage ou memory. Pour un déploiement consent-first, la persistance memory est la valeur par défaut appropriée lorsque le consentement n'a pas encore été accordé — elle garantit qu'aucun identifiant ne survit à la session de page — avec une transition vers localStorage+cookie une fois que le consentement bascule. Le SDK écrit également un marqueur d'opt-in ou d'opt-out sous __ph_opt_in_out_{projectKey} pour mémoriser le choix de l'utilisateur entre les visites ; ce marqueur est lui-même un cookie strictement nécessaire car il persiste une décision de consentement.

Mapper les modules PostHog aux cadres de consentement

PostHog n'implémente pas nativement l'IAB TCF ou la plateforme de confidentialité mondiale IAB, et n'est pas conçu comme un fournisseur adtech. Il s'intègre cependant à Google Consent Mode v2 via un pont côté éditeur, expose une API native d'opt-in et d'opt-out, et respecte l'en-tête Do Not Track via l'option d'initialisation respect_dnt. Le pattern qui fonctionne en production traite chaque module PostHog comme une porte distincte liée à un signal CMP spécifique.

• Les événements d'analytics produit sont liés à la finalité analytics. En termes TCF, il s'agit le plus souvent de la finalité 8 (mesurer les performances du contenu) combinée à la finalité 1 (stocker et/ou accéder à des informations). Pour Consent Mode, cela correspond à analytics_storage.
• L'enregistrement de session se trouve derrière une porte plus stricte. L'enregistrement de session de PostHog capture le DOM rendu et tout champ de saisie non masqué ; une opt-in de niveau préférences ou recherche, distincte de l'analytics, est la posture défendable au titre des directives de l'EDPB.
• Les feature flags et l'expérimentation peuvent fonctionner avec une évaluation éphémère, en mémoire, sur la base d'un intérêt légitime lorsque l'objectif est uniquement de varier la page rendue. L'attribution persistante de flag liée à un identifiant stable entre les sessions requiert le même consentement que l'analytics, car c'est là que le flag devient un point de données traçable au niveau de l'utilisateur.
• Les sondages et le feedback sont liés à la même porte que l'enregistrement de session lorsqu'ils collectent des saisies en texte libre, ou à la porte analytics lorsqu'ils ne collectent que des notes ou des réponses à sélection unique.

Le pattern d'intégration qui fonctionne

Le déploiement de référence comporte quatre parties : une CMP qui expose un événement de changement de consentement en temps réel, un bootstrap différé qui initialise PostHog avec la capture et le replay désactivés, un écouteur de consentement qui bascule opt_in_capturing et le commutateur d'enregistrement lorsque les portes pertinentes s'ouvrent, et un chemin de retrait qui appelle opt_out_capturing, arrête le tampon de replay et efface les identifiants persistants via l'API de réinitialisation du SDK.

Implémentation web

Le pattern le plus propre consiste à charger le SDK PostHog sur chaque page mais à appeler posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) comme bootstrap initial. Abonnez-vous à l'événement de changement de consentement de la CMP. Lorsque la catégorie analytics passe à true, appelez posthog.set_config({ persistence: 'localStorage+cookie' }) suivi de posthog.opt_in_capturing() ; cela réactive la capture d'événements et la transition de persistance commence à écrire l'identifiant distinct. Lorsque la catégorie session-replay passe à true, appelez posthog.startSessionRecording(). Lorsqu'une porte se retire, appelez posthog.opt_out_capturing() pour la porte analytics ou posthog.stopSessionRecording() pour la porte replay, faites expirer les entrées de persistance pertinentes via posthog.reset(), et envoyez une demande de suppression via l'API GDPR de PostHog si l'utilisateur a invoqué son droit à l'effacement.

Sélection de région : PostHog Cloud US vs EU vs auto-hébergé

PostHog opère deux régions cloud — US (us.posthog.com) et EU (eu.posthog.com) — et prend en charge les installations auto-hébergées sur l'infrastructure propre du client. Pour le trafic EEE et UK, le cloud EU est la valeur par défaut appropriée ; il maintient l'ingestion, le traitement et le stockage à l'intérieur de l'EEE et réduit l'exposition Schrems II que tout déploiement d'analytics en région US comporte. L'option d'initialisation api_host fixe la région. PostHog auto-hébergé déplace toute la pile vers l'infrastructure propre de l'éditeur, ce qui constitue la posture de résidence des données la plus solide, mais ne supprime pas les obligations de consentement — la base juridique suit les données, pas l'opérateur. Quelle que soit l'option choisie, elle doit être reflétée dans la politique de confidentialité et dans le registre des traitements du responsable du traitement.

Capture côté serveur

PostHog prend en charge l'ingestion d'événements côté serveur via les SDK Python, Node, Go, Ruby et PHP. Les événements côté serveur ne sont pas exemptés du consentement — la base juridique suit les données — mais l'ingestion côté serveur donne à l'éditeur un contrôle total sur les champs émis et le moment de leur émission. Un pattern courant consiste à capturer un ensemble minimal d'événements essentiels côté serveur sur la base d'un intérêt légitime, puis à enrichir ces événements de détails comportementaux côté client uniquement après que l'utilisateur a accordé son consentement pour l'analytics. Les événements côté serveur et côté client se rejoignent sur le même identifiant distinct une fois le consentement basculé ; avant le consentement, les événements côté serveur sont émis avec un identifiant anonyme et éphémère qui est réinitialisé à chaque session.

Valider l'intégration et la piste d'audit

L'étape de validation est celle que les régulateurs vérifient et que les éditeurs passent le plus souvent à la trappe. Un déploiement PostHog correctement intégré doit passer quatre tests dans l'ordre. Premièrement, une session de navigateur propre avec la bannière affichée mais aucun choix effectué doit produire zéro requête vers l'api_host configuré au-delà du téléchargement du fichier SDK, zéro cookie ph_ dans document.cookie et zéro entrée ph_ dans localStorage. Deuxièmement, le refus de l'analytics doit maintenir cet état — pas de capture, pas d'enregistrement, pas d'identifiant persistant. Troisièmement, l'acceptation de l'analytics doit produire un événement $opt_in immédiat, l'entrée de persistance ph_{projectKey}_posthog attendue avec les attributs SameSite corrects, et du trafic d'événements vers l'hôte configuré. Quatrièmement, le retrait du consentement après coup doit immédiatement arrêter toute capture et tout replay supplémentaires, faire expirer les identifiants persistants et déclencher une demande de suppression via l'API GDPR de PostHog si l'utilisateur a invoqué l'effacement.

L'attente en matière de piste d'audit au titre des directives 2023 de l'EDPB sur les bannières cookies et des priorités renouvelées du groupe de travail 2026 est que l'éditeur soit en mesure de prouver, pour tout événement donné dans le projet PostHog, que l'utilisateur qui l'a généré avait fourni un consentement valide au moment de la capture. Le pattern standard consiste à définir la version du consentement et l'horodatage comme propriétés de personne sur l'ID distinct via posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }), de sorte que tout événement individuel soit traçable jusqu'à une entrée de journal de consentement spécifique. Un déploiement correctement cloisonné, associé à une sélection de région correspondant à l'audience, à une persistance définie par défaut sur memory et à un chemin de suppression activé lors du retrait, transforme PostHog d'un risque de concentration réglementaire en un centre défendable de la pile d'analytics produit.