Guide d'intégration du consentement aux cookies pour l'analytique produit Heap Auto-Capture : le manuel 2026 des éditeurs
Heap est inhabituel dans l'écosystème de l'analytique produit en raison de ce qu'il fait par défaut. Là où Mixpanel, Amplitude et PostHog demandent à l'éditeur d'instrumenter les événements importants, Heap capture tout automatiquement et laisse l'analyste définir les événements rétroactivement à partir du flux capturé. Ce modèle d'auto-capture est la fonctionnalité définitoire du produit et la raison pour laquelle les équipes le choisissent ; c'est aussi la raison pour laquelle un déploiement Heap par défaut porte l'une des surfaces de données comportementales les plus larges de tout outil qu'un éditeur est susceptible d'installer. Chaque clic, toucher, défilement, interaction de formulaire, transition de page et clic rageur est capturé contre un identifiant persistant en quelques millisecondes du chargement de la page — ce qui signifie que chacune de ces opérations engage une obligation de consentement. La bonne nouvelle est que Heap, depuis son acquisition par Contentsquare, est désormais livré avec l'une des API de consentement les plus granulaires de l'espace analytique produit ; le travail consiste à la câbler correctement à travers la surface d'auto-capture, la couche d'identité et le module de replay de session qu'ajoute l'intégration Contentsquare.
Pourquoi Heap exige un consentement — et pourquoi la réponse est plus large que l'analytique typique
Une initialisation Heap par défaut effectue plusieurs choses lors du premier rendu de la page. Elle place un cookie de première partie sous _hp2_id.{envId} contenant l'identifiant persistant de l'utilisateur, un cookie de session sous _hp2_ses_id.{envId} avec l'identifiant de session, un cookie de taux d'échantillonnage sous _hp2_props.{envId}, et un marqueur _hp2_loaded indiquant que le SDK s'est initialisé. Elle génère l'identifiant distinct s'il n'existe pas encore, capture la vue de page initiale avec le référent, les paramètres UTM et les identifiants de clic, et commence immédiatement à enregistrer chaque interaction ultérieure contre cet identifiant — clics, touchers, modifications de formulaire, changements de route, événements personnalisés et, lorsque l'intégration Contentsquare est activée, le diff DOM rendu complet pour le replay de session.
Chacune de ces activités engage une porte de consentement distincte. La persistance de l'identifiant utilisateur 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 l'EEA, au Royaume-Uni et dans toute juridiction ayant importé le même standard. La capture du flux d'événements en auto-capture constitue un traitement de données personnelles au titre du GDPR, car la combinaison de l'identifiant, de l'adresse IP et de la trace comportementale suffit à singulariser un individu. Le replay de session relève d'une catégorie distincte et plus stricte selon les orientations de l'EDPB sur le replay 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 analytique générique. Le CCPA et le CPRA traitent le même traitement comme une vente ou un partage à moins que l'éditeur ne dispose d'un contrat de prestataire de services avec Heap — que Heap propose, mais le contrat ne prend effet que lorsque l'intégration est configurée en mode prestataire de services.
Ce que Heap écrit avant le consentement — et ce qui doit être supprimé
Le démarrage rapide standard livré avec le tableau de bord Heap installe le snippet de suivi directement dans le <head> de la page. Cela fonctionne comme documenté et est la source de la défaillance de conformité la plus courante dans les déploiements Heap : le snippet s'exécute avant que la bannière de cookie soit rendue, les cookies _hp2_ sont écrits en quelques millisecondes, et le flux d'auto-capture commence à affluer vers heapanalytics.com indépendamment de ce que l'utilisateur décide par la suite. Chaque autorité de régulation européenne qui s'est prononcée sur ce schéma l'a fait de la même manière : les cookies définis avant le consentement sont illicites, et c'est l'éditeur qui en porte la responsabilité.
Une intégration conforme doit donc empêcher le snippet Heap de se charger jusqu'à ce que la catégorie de consentement pertinente ait été accordée. Les deux schémas qui fonctionnent en production sont l'injection conditionnelle de script — le snippet est ajouté au DOM uniquement après que la CMP a signalé le consentement — et le préchargement du snippet avec heap.load(appId, { disableTextCapture: true, secureCookie: true, autocapture: false }) comme bootstrap différé, puis l'appel de heap.startAutoCapture() une fois le consentement enregistré. Le schéma d'injection conditionnelle est plus propre et celui que la documentation Heap recommande désormais. Le schéma de bootstrap différé est le bon choix lorsque l'éditeur a besoin d'une référence globale stable pour la couture d'identité mais ne peut pas permettre à l'auto-capture de se déclencher avant le consentement.
Les cookies et le stockage que Heap écrit
Le snippet Heap écrit les identifiants suivants lors de l'initialisation, tous non essentiels et nécessitant un consentement : _hp2_id.{envId} avec une expiration de 14 mois contenant l'identifiant utilisateur, _hp2_ses_id.{envId} avec une expiration de session de 30 minutes, _hp2_props.{envId} pour la propagation du taux d'échantillonnage et des propriétés, et _hp2_loaded comme marqueur de chargement. Le module de replay de session intégré à Contentsquare ajoute un tampon d'enregistrement en mémoire qui se vide vers l'endpoint Heap toutes les quelques secondes et peut conserver séparément un petit identifiant de session de replay. Le retrait du consentement doit donc à la fois expirer les cookies _hp2_ et signaler une demande de suppression via l'API GDPR de Heap pour les enregistrements et le flux d'événements antérieurs de l'utilisateur.
Cartographier Heap sur les cadres de consentement
Heap n'implémente pas nativement l'IAB TCF ou l'IAB Global Privacy Platform — c'est une plateforme d'analytique produit de première partie, non un prestataire de technologie publicitaire — mais il s'intègre à Google Consent Mode v2 via un pontage côté éditeur, expose une API d'opt-in et d'opt-out native, et prend en charge une couche de rédaction des propriétés sensibles qui fonctionne indépendamment de l'état du consentement. Le schéma qui résiste à l'examen d'un régulateur traite chaque module Heap comme une porte distincte liée à un signal CMP spécifique.
- L'auto-capture et le flux d'événements de base sont liés à la finalité analytique. En termes TCF, il s'agit le plus souvent de la finalité 8 (mesurer la performance du contenu) combinée à la finalité 1 (stocker et/ou accéder à des informations). Pour Consent Mode, cela correspond à analytics_storage.
- Le replay de session via l'intégration Contentsquare est placé derrière une porte plus stricte et distincte car le replay capture le DOM rendu et tout champ de saisie non masqué, et les orientations de l'EDPB sur le replay de session le traitent comme une catégorie nécessitant un consentement explicite et granulaire distinct de l'analytique générique.
- L'identification de l'utilisateur via heap.identify() peut fonctionner avec un identifiant de session éphémère sur une base d'intérêt légitime lorsque l'utilisateur est anonyme, mais l'association de l'identification à un identifiant de première partie persistant entre les sessions nécessite le même consentement que l'analytique car c'est à ce moment que l'identifiant devient un point de données traçable au niveau utilisateur.
- La propagation d'identité inter-sites ou inter-produits via l'API d'identité nécessite la porte marketing car elle franchit la frontière entre l'analytique produit et l'attribution marketing au niveau utilisateur.
Le schéma 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 charge Heap avec l'auto-capture désactivée, un écouteur de consentement qui active l'auto-capture et démarre le tampon de replay de session lorsque les portes pertinentes s'ouvrent, et un chemin de retrait qui appelle heap.resetIdentity(), arrête l'auto-capture, fait expirer les cookies _hp2_, et envoie une demande de suppression via l'endpoint GDPR de Heap.
Implémentation web
Sur le web, le schéma le plus propre consiste à charger le snippet Heap de manière conditionnelle — la balise <script> n'est injectée qu'après que la catégorie analytique a été accordée. Abonnez-vous à l'événement de changement de consentement de la CMP. Lorsque la catégorie analytique passe à true, injectez le snippet Heap avec secureCookie: true, disableTextCapture: false pour l'auto-capture complète, et toute configuration spécifique à l'environnement. Lorsque le consentement au replay de session passe à true et que l'intégration Contentsquare est activée, le tampon de replay s'active automatiquement. Lorsqu'une porte est retirée, appelez heap.resetIdentity() suivi de la suppression de l'élément script Heap, faites expirer les cookies _hp2_ via document.cookie, et invoquez l'API de suppression GDPR pour l'identifiant de l'utilisateur.
Rédaction des propriétés sensibles
Heap est livré avec une couche de rédaction qui fonctionne indépendamment de l'état du consentement et que les éditeurs devraient utiliser même lorsque le consentement a été accordé. L'attribut data-heap-redact-text sur un champ de formulaire supprime le contenu textuel capturé ; l'attribut data-heap-redact-attributes supprime les attributs de l'élément. Selon les règles relatives aux catégories spéciales du GDPR et la définition des informations personnelles sensibles du CCPA, tout champ susceptible de capturer des informations sanitaires, des détails financiers, des identifiants gouvernementaux, des données biométriques, une géolocalisation précise ou le contenu de communications privées doit utiliser les attributs de rédaction indépendamment de l'état du consentement de l'utilisateur. La définition des attributs au niveau du formulaire est le schéma le plus sûr — elle supprime l'intégralité du formulaire même lorsqu'un développeur ajoute un nouveau champ qu'il oublie de marquer individuellement.
Sélection de la région : résidence des données EU vs US
Heap opère des endpoints d'ingestion EU et US distincts. Pour le trafic EEA et UK, l'endpoint EU est le bon choix par défaut ; il maintient l'ingestion, le traitement et le stockage à l'intérieur de l'EEA et réduit l'exposition Schrems II que tout déploiement analytique en région US implique. L'endpoint est défini via la configuration du snippet et ne peut pas être modifié rétroactivement — les données existantes restent là où elles ont été ingérées en premier. Pour les éditeurs qui planifient un déploiement Heap, il vaut donc la peine de confirmer la région avant de monter en charge, et de documenter ce choix dans l'avis de confidentialité afin que la chaîne de base légale soit propre de la collecte jusqu'au stockage.
Validation de l'intégration et de la piste d'audit
L'étape de validation est celle que les régulateurs vérifient et que les éditeurs omettent le plus souvent. Un déploiement Heap correctement intégré doit réussir quatre tests successifs. Premièrement, une session de navigateur propre avec la bannière affichée mais sans choix effectué doit produire zéro requête vers heapanalytics.com au-delà de la récupération du fichier SDK et zéro cookie _hp2_ dans document.cookie. Deuxièmement, le refus de l'analytique doit maintenir cet état — pas d'auto-capture, pas d'identifiant, pas d'enregistrement. Troisièmement, l'acceptation de l'analytique doit produire le cookie _hp2_id attendu avec les attributs SameSite corrects et un trafic d'événements affleurant vers l'endpoint de la région configurée. Quatrièmement, le retrait du consentement doit immédiatement arrêter l'auto-capture et le replay ultérieurs, faire expirer les cookies _hp2_, et déclencher une demande de suppression via l'API GDPR de Heap.
L'attente en matière de piste d'audit selon les lignes directrices 2023 de l'EDPB sur les bannières de cookies et les priorités renouvelées du groupe de travail 2026 est que l'éditeur puisse prouver, pour tout événement donné dans le projet Heap, que l'utilisateur qui l'a généré avait fourni un consentement valide au moment de la capture. Le schéma standard consiste à définir la version du consentement et l'horodatage comme propriétés utilisateur sur l'ID distinct via heap.addUserProperties({ consent_version: 'v3', consent_ts: ts }) afin que tout événement individuel soit traçable jusqu'à une entrée de journal de consentement spécifique. Un déploiement correctement cloisonné, associé à des attributs de rédaction qui suppriment par défaut les champs sensibles et à un chemin de suppression qui s'active lors du retrait, est ce qui transforme le modèle d'auto-capture de Heap d'un risque de concentration réglementaire en l'une des parties les plus puissantes et défendables de la pile d'analytique produit d'un éditeur.