Hotjar et RGPD : guide de conformité 2026
Hotjar et RGPD : consentement, masquage des sessions, migration Contentsquare et contrôles utiles avant la collecte.
- Identifier la plateforme réellement utilisée
- Recueillir un consentement qui décrit le rejeu
- Cas pratique : comprendre un blocage sans enregistrer le dossier client
- Masquer avant la transmission
- Séparer capture, questionnaires et pages ciblées
- Compléter le dossier au-delà du consentement
- Réaliser une recette avant d’inviter les visiteurs à participer
- Que faire si un nom apparaît dans une session ?
- Livrer une conclusion utile, puis réduire les traces
- Ce qu’il faut retenir
- FAQ
Rejouer une session permet de comprendre un blocage dans un formulaire, mais peut aussi exposer le contenu d’un compte ou d’un message. Vous pouvez utiliser Hotjar pour un besoin précis d’amélioration du site si le recueil du choix, le périmètre et le masquage sont maîtrisés avant la capture. Excluez les pages dont le contenu ne peut pas être suffisamment protégé. Une éventuelle migration vers Contentsquare impose de contrôler à nouveau les déclencheurs et les réglages applicables au compte.
Identifier la plateforme réellement utilisée
La documentation actuelle distingue les comptes sur insights.hotjar.com et les projets Contentsquare. Les menus et le périmètre des réglages peuvent différer. Commencez par relever la plateforme, le projet, le tag installé et les fonctions actives.
Pour les clients Hotjar dont un compte Contentsquare a été créé automatiquement, le guide de migration des réglages indique que des règles de masquage sont reprises, mais que les règles de déclenchement par événement ne sont pas migrées. Une configuration historique ne prouve donc pas que le nouveau projet commence à enregistrer au même moment.
Conservez les réglages avant et après migration et contrôlez le parcours réel. Ne supposez pas que tous les clients suivent exactement le même parcours de migration ou disposent des mêmes options.
Recueillir un consentement qui décrit le rejeu
Les opérations sur le terminal qui servent à reconstituer un parcours individuel dépassent l’exemption limitée de mesure d’audience. Elles doivent être conditionnées au consentement requis par l’article 82 de la loi Informatique et Libertés. La FAQ cookies de la CNIL précise les conditions de cette exemption.
Une catégorie « statistiques » trop vague peut mal décrire l’enregistrement des interactions. Expliquez la finalité et la nature du dispositif, permettez de refuser aussi facilement que d’accepter et organisez le retrait. La CMP doit commander le chargement et l’arrêt du dispositif concerné.
La CNIL a publié en février 2026 un projet de recommandation sur le rejeu de session, soumis à consultation jusqu’au 22 avril. Cette publication doit être citée comme un projet, sans la présenter comme une recommandation définitive. Les obligations existantes de licéité et minimisation s’appliquent indépendamment de cette consultation.
Cas pratique : comprendre un blocage sans enregistrer le dossier client
Une PME française fictive organise des ateliers de restauration de meubles. Elle constate des abandons entre le choix d’une date et la demande de réservation. La responsable du site souhaite voir où le parcours devient difficile. L’agence propose d’enregistrer toutes les pages, y compris les comptes clients et les demandes après-vente.
La décision retenue est plus étroite : observer, après accord valable, la sélection d’un atelier et d’un créneau. Les espaces clients, le paiement, les messages et les pièces jointes restent exclus. Le contenu personnel n’est pas nécessaire pour voir qu’un bouton est inaccessible ou qu’une sélection disparaît.
La responsable remplit le dossier suivant. Il s’agit d’un scénario proposé, sans essai réel de Hotjar :
| Zone du site | Décision | Résultat attendu du contrôle |
|---|---|---|
| Liste publique des ateliers | Capture limitée au besoin déclaré, après accord | Aucun démarrage lors du refus |
| Choix du créneau | Parcours inclus pour comprendre le blocage | Interface utile visible, contenu personnel absent |
| Coordonnées de réservation | Exclure les informations saisies et leurs réaffichages | Aucun nom ni contact dans les données transmises |
| Récapitulatif personnalisé | Exclure la page du projet | Aucun enregistrement du résumé client |
| Compte, paiement et après-vente | Exclure ces espaces | Aucun rejeu de dossier ou de document |
| Questionnaire de satisfaction | Projet séparé, non activé pour ce diagnostic | Pas de collecte supplémentaire présumée autorisée |
L’équipe cherche d’abord une cause technique simple dans son propre parcours de démonstration. Si cela suffit à corriger le défaut, elle n’a pas besoin de lancer une collecte sur les visiteurs. Si le rejeu reste justifié, le périmètre est limité au problème documenté, puis arrêté lorsqu’il n’est plus nécessaire. Le consentement n’autorise pas une observation indéfinie de tout le site.
Masquer avant la transmission
Pour insights.hotjar.com, la documentation de suppression des données décrit un masquage avant l’envoi du contenu de la page. Elle précise que modifier les règles n’agit pas rétroactivement sur les sessions déjà envoyées.
Examinez les textes affichés, images, champs, attributs et éléments dynamiques. Un message masqué pendant la saisie peut réapparaître dans un récapitulatif ou une notification. Le nom d’un patient dans un titre peut être plus révélateur qu’un formulaire correctement protégé.
Une règle de masquage ne doit pas être supposée couvrir tous les attributs et tous les composants. Utilisez des données fictives pour inspecter un parcours complet et consultez les limites correspondant à votre plateforme. Le guide du masquage des formulaires en rejeu de session détaille cette recette.
Pour les pages où une capture n’est pas nécessaire ou ne peut pas être suffisamment maîtrisée, excluez l’enregistrement. Ne collectez pas d’abord une information sensible en espérant la masquer ensuite.
Séparer capture, questionnaires et pages ciblées
Les réglages des sites sur insights.hotjar.com comportent un interrupteur de capture des sessions. La documentation précise que sa désactivation n’arrête pas la collecte des réponses aux questionnaires. Elle indique aussi que l’URL descriptive renseignée dans les informations du site ne détermine pas, à elle seule, les pages qui collectent des données.
Deux conséquences : cartographiez séparément les questionnaires et vérifiez l’installation du tag sur les pages. Un bouton général de capture n’est pas une commande universelle d’arrêt de tous les traitements.
Pour les enquêtes, limitez les questions et les textes libres. Une réponse à un questionnaire NPS peut identifier une personne même sans champ « nom ». Prévoyez sa durée et ses destinataires propres.
Compléter le dossier au-delà du consentement
Vérifiez le contrat de sous-traitance, les sous-traitants ultérieurs et les lieux de traitement correspondant au compte. Ne réutilisez pas sans examen une ancienne localisation d’hébergement comme description exhaustive des flux actuels.
L’Art. 5(1)(e) exige une conservation limitée au besoin. Les durées recommandées pour certains cookies de mesure exemptée ne deviennent pas un plafond légal universel pour tous les enregistrements. Fixez une durée utile, vérifiez les capacités du compte et organisez les suppressions nécessaires.
Limitez les accès et les exports de sessions. Évaluez aussi le risque au regard de l’Art. 35(1), notamment selon les publics et informations concernés. L’AIPD dépend du traitement envisagé ; elle ne découle pas automatiquement de la marque utilisée. Les principes du RGPD restent applicables même après un consentement valable.
Réaliser une recette avant d’inviter les visiteurs à participer
La recette utilise un dossier entièrement fictif, avec un nom, une adresse et un commentaire reconnaissables par l’équipe. L’objectif est de rechercher ces valeurs dans les informations envoyées et restituées, pas d’introduire des données réelles pour « voir si le masquage marche ».
Le développeur parcourt la sélection du créneau, l’erreur de formulaire, la correction et le récapitulatif. Il examine aussi les notifications et les éléments ajoutés après le premier affichage. Une protection correcte au chargement initial ne démontre pas que le contenu dynamique suit la même règle. Une information retirée visuellement peut encore subsister dans un attribut ou une URL.
L’administrateur contrôle ensuite le choix du visiteur : absence d’accord, refus, accord au rejeu et retrait. La réservation doit rester utilisable dans la version prévue sans rejeu. Le dossier indique précisément quelles opérations cessent après le retrait et ce qui arrive lors d’un changement de page. Si un questionnaire apparaît malgré son exclusion du projet, il faut rechercher son propre déclenchement plutôt que conclure que l’interrupteur de capture règle tout.
Après une migration, la même recette est reprise sur le projet réellement en service. Les captures des anciennes règles servent à comparer, pas à présumer leur effet. L’agence doit expliquer les écarts et les dépendances supprimées. Si elle ne peut pas démontrer quand la capture commence, le lancement reste suspendu.
Que faire si un nom apparaît dans une session ?
Dans notre scénario, le nom fictif est correctement caché dans le champ, mais apparaît dans le récapitulatif. La responsable arrête l’enregistrement du parcours concerné. L’agence corrige ou exclut cette page, recherche les autres réaffichages et reprend le parcours. Elle ne résout pas le problème en demandant aux analystes de ne pas regarder les noms.
Si des sessions réelles ont déjà été enregistrées, le responsable identifie la période et les pages touchées, restreint les accès, puis traite ces enregistrements séparément. Il recherche aussi les exports et partages. La nécessité d’une suppression et l’analyse d’une éventuelle violation sont documentées selon les faits ; améliorer le masque pour demain ne clôt pas l’incident d’hier.
Lorsque le masquage ne peut pas être garanti pour le composant utilisé, le périmètre reste exclu. L’équipe peut organiser une observation volontaire sur des scénarios fictifs ou exploiter des erreurs techniques limitées pour diagnostiquer le problème. Elle n’a pas besoin de reconstruire un dossier client complet pour comprendre un défaut d’ergonomie.
Livrer une conclusion utile, puis réduire les traces
Pour cette PME, le livrable attendu est une cause à corriger et un contrôle de la correction, pas une bibliothèque permanente de visiteurs enregistrés. La responsable prévoit l’examen des sessions pendant la période de diagnostic, les accès nécessaires et la suppression une fois leur utilité terminée. Elle doit rapprocher cette politique des moyens réellement disponibles sur son compte ; une durée inscrite dans un document sans exécution reste insuffisante.
Le compte rendu conserve les constats expurgés, les pages concernées et les décisions. Il évite de joindre des replays contenant des données personnelles à chaque ticket envoyé aux prestataires. La prochaine campagne d’observation fera l’objet d’un nouveau périmètre : l’accord à l’analyse du parcours annoncé ne couvre pas automatiquement toutes les nouvelles enquêtes ou finalités imaginées ensuite.
Ce qu’il faut retenir
- Vérifiez la plateforme et les effets d’une migration sur les déclencheurs.
- Décrivez clairement le rejeu dans le choix présenté au visiteur.
- Contrôlez le masquage avant envoi et les sessions déjà collectées.
- Traitez séparément captures, questionnaires, droits et conservation.
FAQ
Désactiver les captures arrête-t-il les questionnaires ?
Pas sur le périmètre décrit par la documentation d’insights.hotjar.com. Vérifiez les réglages des questionnaires séparément.
Un nouveau masquage corrige-t-il les anciennes sessions ?
Non. La documentation précise l’absence d’effet rétroactif. Les sessions déjà reçues demandent une mesure distincte selon leur contenu et les possibilités du service.
Faut-il renouveler tous les consentements à treize mois ?
Ce n’est pas une règle générale applicable à ce service. La durée d’un traceur, la mémorisation du choix et la conservation des sessions sont des sujets distincts.
Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.
Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.