Guide d'intégration du consentement aux cookies pour les cartes thermiques et l'enregistrement de session Hotjar : le guide pratique 2026 pour les éditeurs
Hotjar occupe une place unique dans la pile d'outils. Ce n'est pas une plateforme d'analyse web comme Google Analytics, ni une plateforme d'analyse produit comme Amplitude ou Mixpanel, ni un gestionnaire de balises. C'est un outil de recherche sur l'expérience utilisateur qui existe spécifiquement pour enregistrer ce que les utilisateurs individuels font sur une page — où ils déplacent leur souris, ce sur quoi ils cliquent, où ils font défiler, où ils hésitent, et, dans le cas de l'enregistrement de session, exactement ce qu'ils ont tapé et vu affiché à l'écran. Cette granularité est le produit. C'est aussi pourquoi les régulateurs ont distingué la relecture de session comme l'une des catégories à plus haut risque de traitement comportemental, et pourquoi un déploiement Hotjar imprudent est l'un des moyens les plus faciles pour un site web par ailleurs conforme de tomber hors de conformité. La CNIL, le Garante et l'EDPB ont tous publié des orientations ciblant spécifiquement le comportement de relecture de session, et le groupe de travail sur les bandeaux de cookies 2026 de l'EDPB le traite comme une catégorie prioritaire. La bonne nouvelle est que Hotjar est l'un des outils les mieux conçus dans cette catégorie pour un déploiement axé sur le consentement — à condition que l'éditeur utilise réellement les contrôles qui existent.
Pourquoi Hotjar exige un consentement explicite
Le profil de collecte de Hotjar est ce qui déclenche les obligations de consentement dans chaque cadre qui compte. Lors d'une initialisation par défaut, le script de suivi Hotjar écrit au moins trois cookies propriétaires — _hjSessionUser_{siteId}, _hjSession_{siteId} et une série de cookies de suppression et de source entrante — dans le navigateur en quelques millisecondes après le chargement de la page. Le script commence ensuite à diffuser en continu un enregistrement des coordonnées du curseur, des coordonnées des clics, de la position de défilement, de la taille de la fenêtre d'affichage et, lorsque l'enregistrement de session est activé, du DOM complet rendu comparé à une ligne de base.
En vertu de l'article 5, paragraphe 3 de la directive ePrivacy, chacun de ces cookies est une opération de stockage et d'accès qui nécessite un consentement préalable, librement donné, spécifique, éclairé et non ambigu dans l'EEE, au Royaume-Uni, en Suisse et dans toute juridiction ayant importé la même norme. En vertu du GDPR, le flux comportemental constitue un traitement de données personnelles parce que la combinaison de la trace du curseur, de l'adresse IP, de l'empreinte digitale du dispositif et de l'identifiant de session est suffisante pour distinguer un individu. En vertu du CCPA et du CPRA, la même collecte compte comme une vente ou un partage, sauf si l'éditeur dispose du contrat de prestataire de services pertinent avec Hotjar — que Hotjar propose via son DPA conforme au CCPA, mais qui ne prend effet que lorsque l'intégration est correctement configurée. En vertu des orientations de l'EDPB sur la relecture de session, la barre est encore plus haute : la relecture doit être liée à un objectif de recherche UX spécifique et légitime, la durée de conservation doit être le minimum nécessaire, et la personne concernée doit être informée non seulement de l'existence des enregistrements, mais aussi que sa propre session peut être rejouée par un analyste.
Ce que Hotjar collecte avant le consentement — et ce qui doit être supprimé
L'erreur d'implémentation la plus courante est celle qui est livrée avec le démarrage rapide de Hotjar lui-même : coller le script de suivi directement dans le <head> de la page. Cela fonctionne, mais charge Hotjar avant même que le bandeau de cookies ait été rendu, ce qui signifie que les cookies sont définis et que l'enregistrement comportemental commence dès la toute première page vue — quelle que soit la décision de l'utilisateur par la suite. Chaque régulateur de l'UE qui s'est prononcé sur ce modèle a statué de la même manière : les cookies définis avant le consentement sont illicites, et l'éditeur est responsable.
Une intégration conforme doit donc empêcher le script Hotjar de se charger du tout jusqu'à ce que la catégorie de consentement pertinente ait été accordée. La façon la plus propre de le faire est d'envelopper l'extrait Hotjar à l'intérieur d'une balise <script> conditionnée par le consentement, que le CMP n'injecte qu'après que l'utilisateur a opté pour la catégorie d'analyse ou de recherche produit. Si le script est chargé via un gestionnaire de balises, l'équivalent consiste à définir le déclencheur sur un événement de consentement accordé plutôt que sur Toutes les pages. La propre documentation de Hotjar recommande désormais explicitement ce modèle, et la plateforme expose une API hj('consent', 'grant') pour les cas où le script doit être présent mais rester dormant jusqu'à ce que le consentement soit enregistré.
Cookies et stockage écrits par Hotjar
Le Hotjar Tracking Code 6.x écrit les identifiants suivants, tous non essentiels et nécessitant un consentement : _hjSessionUser_{siteId} avec une expiration de 365 jours contenant l'identifiant utilisateur ; _hjSession_{siteId} avec une expiration de 30 minutes contenant l'identifiant de session ; _hjFirstSeen ; _hjIncludedInSessionSample_{siteId} ; _hjAbsoluteSessionInProgress ; et un certain nombre de cookies d'attribution de campagne lorsque des enquêtes ou des widgets de commentaires sont actifs. Les enregistrements de session eux-mêmes sont stockés sur les serveurs de Hotjar et indexés sur l'identifiant de session — le retrait du consentement doit donc également déclencher une demande de suppression via l'API de Hotjar ou le flux de suppression d'utilisateur intégré au produit.
Cartographie de Hotjar dans les cadres de consentement
Hotjar ne s'intègre pas nativement avec l'IAB TCF ou l'IAB Global Privacy Platform. Ce n'est pas un fournisseur adtech et il n'était pas destiné à l'être. Cependant, il s'intègre avec Google Consent Mode v2 via le signal analytics_storage, et il expose sa propre API de consentement native à laquelle n'importe quel CMP peut se lier. Le modèle qui résiste à l'examen d'un régulateur traite chaque capacité de Hotjar comme une porte de consentement distincte.
- Les cartes thermiques et les cartes de clics se lient à la finalité d'analyse ou de recherche produit. En termes de 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 le Consent Mode, il s'agit de analytics_storage.
- L'enregistrement de session devrait se trouver derrière un signal plus strict et séparé. L'enregistrement capture le DOM rendu et tout champ non masqué, et une option d'adhésion explicite au niveau des préférences — et non un consentement analytique global — est la posture défendable en vertu des orientations de l'EDPB sur la relecture de session.
- Les enquêtes et les widgets de commentaires peuvent fonctionner sous la même porte de consentement que l'enregistrement de session lorsqu'ils collectent des données textuelles libres, ou sous la porte d'analyse lorsqu'ils ne collectent que des données d'évaluation.
- Les entonnoirs et le suivi des conversions se lient à la porte d'analyse ; si un identifiant d'utilisateur est propagé vers un CRM ou une plateforme publicitaire, la porte marketing s'applique également.
Le modèle d'intégration qui fonctionne
Le déploiement de référence comporte quatre parties : un CMP qui expose un événement de changement de consentement en temps réel, un chargeur de script différé qui n'injecte l'extrait Hotjar qu'après le déclenchement du consentement analytique, une couche de suppression d'enregistrement de session qui met l'enregistrement en mode hors par défaut jusqu'à l'ouverture d'une porte distincte, et une configuration de masquage des entrées qui supprime fermement tout champ qu'un régulateur considérerait comme sensible, même lorsque le consentement a été accordé. Le quatrième point est souvent négligé : le masquage des entrées n'est pas un substitut au consentement, mais c'est un substitut à la catastrophe lorsque le consentement est accordé pour une recherche légitime et qu'un utilisateur colle par inadvertance des données sensibles dans un champ de texte libre.
Implémentation web
Sur le web, le modèle le plus propre consiste à s'abonner à l'événement de changement de consentement du CMP, puis à injecter conditionnellement l'extrait Hotjar lorsque la finalité d'analyse passe de false à true. Utilisez document.createElement('script') pour injecter le code de suivi avec l'attribut async défini, et attachez un gestionnaire onload qui appelle hj('identify', userId, properties) uniquement si un identifiant d'utilisateur validé côté serveur existe. Lorsque le consentement est retiré, appelez hj('consent', 'revoke'), faites expirer tous les cookies _hj via document.cookie, et envoyez une demande de suppression via l'API de données Hotjar pour les enregistrements de session précédents de l'utilisateur. N'initialisez pas Hotjar paresseusement dans la même passe de rendu que le bandeau — le script doit attendre un accord explicite, et l'accord doit être enregistré avec un horodatage et une chaîne de consentement avant que le script ne se déclenche jamais.
Masquage des entrées et suppression des données sensibles
L'enregistreur de session de Hotjar est livré avec trois modes de masquage : Suppress mode, qui est le mode par défaut pour les champs de mot de passe et tout élément marqué avec l'attribut data-hj-suppress ; Whitelist mode, où seules les entrées explicitement acceptées sont enregistrées ; et Mask mode, où les frappes au clavier sont enregistrées sous forme d'astérisques. En vertu des règles sur les catégories spéciales du GDPR et de la définition des informations personnelles sensibles du CCPA, tout champ susceptible de capturer des informations sur la santé, 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 le Suppress mode quelle que soit la décision de l'utilisateur en matière de consentement. Définir data-hj-suppress au niveau du formulaire plutôt qu'au niveau du champ est le modèle le plus sûr — il supprime l'intégralité du formulaire même si un développeur ajoute ultérieurement un nouveau champ qu'il oublie de marquer individuellement.
Applications à page unique et changements de route
Pour les SPA (React, Vue, Angular, Svelte), l'extrait Hotjar se lie uniquement au chargement initial de la page par défaut. Pour suivre les transitions de page virtuelles, le bootstrap doit appeler hj('stateChange', newPath) à chaque changement de route. Cet appel respecte l'état de consentement que Hotjar détient à ce moment-là, de sorte que la logique de contrôle du CMP n'a pas besoin d'être dupliquée — mais le changement de route ne doit pas lui-même déclencher un nouveau chargement de script si le consentement a été retiré entre les pages vues.
Validation de l'intégration
L'étape de validation est ce que les régulateurs vérifient et ce que les éditeurs omettent le plus souvent. Un déploiement Hotjar correctement intégré doit réussir quatre tests dans l'ordre. Premièrement, une nouvelle session de navigateur avec le bandeau affiché mais sans choix effectué doit produire zéro requête vers static.hotjar.com, script.hotjar.com ou vars.hotjar.com, et zéro cookie _hj dans document.cookie. Deuxièmement, le refus de l'analyse doit maintenir cet état — pas de chargement de script, pas d'enregistrement, pas de cookies. Troisièmement, l'acceptation de l'analyse doit produire un chargement de script et les cookies _hjSessionUser et _hjSession attendus avec les attributs SameSite corrects, et un enregistrement de carte thermique doit apparaître dans le tableau de bord Hotjar dans les cinq minutes. Quatrièmement, le retrait du consentement après le fait doit immédiatement arrêter tout enregistrement ultérieur, faire expirer les cookies et déclencher une demande de suppression — un nettoyage différé est un constat.
La piste d'audit importe séparément. Les régulateurs s'attendent à ce que l'éditeur soit en mesure de prouver, pour tout enregistrement dans le compte Hotjar, que l'utilisateur qui l'a généré avait donné un consentement valide au moment de la capture. Le modèle standard consiste à intégrer la version et l'horodatage du consentement comme attribut personnalisé sur l'enregistrement utilisateur Hotjar via hj('identify', userId, { consent_version: 'v3', consent_ts: ts }). Cela rend tout enregistrement spécifique traçable jusqu'à une entrée de journal de consentement spécifique, ce qui est la norme fixée par l'EDPB et la norme que les éditeurs devraient adopter quel que soit leur lieu d'exploitation. Un déploiement correctement contrôlé, associé à un masquage des entrées qui supprime par défaut et à un chemin de suppression qui s'active au retrait, est ce qui fait de Hotjar une partie défendable d'une pile de recherche plutôt qu'une responsabilité en matière de conformité.