Le rejeu de session est la chose la plus intrusive qu'un site web ordinaire fasse à ses visiteurs, et la question du consentement qu'il pose est plus intéressante que celle que pose le simple fait de les compter. Deux règles distinctes s'appliquent, la plupart des outils n'en satisfont aucune par défaut, et satisfaire la première ne vous dispense pas de la seconde.

Voici comment les règles fonctionnent en pratique ; ce n'est pas un conseil juridique. Si vos pages affichent des données de santé, financières ou relatives à des enfants, consultez un professionnel qualifié.

Deux questions, pas une

Est-ce que cela stocke quelque chose sur l'appareil du visiteur ? C'est l'article 5, paragraphe 3, de la directive ePrivacy (en France, l'article 82 de la loi Informatique et Libertés, appliqué par la CNIL) et c'est la question à laquelle un bandeau de cookies répond. Elle porte sur le fait d'écrire sur l'appareil de quelqu'un ou d'y lire, quelle que soit la technologie : un cookie, localStorage, ou une empreinte.

Ce qui est capturé est-il une donnée à caractère personnel, et quelle est votre base légale ? C'est le RGPD, et il s'applique que quelque chose ait été stocké ou non. Le rejeu de quelqu'un en train de remplir un formulaire, de bouger sa souris et de faire défiler son propre historique de commandes est une donnée à caractère personnel le concernant, quelle que soit la lecture qu'on en fasse. Un outil peut donc être vraiment dépourvu de stockage et avoir quand même besoin d'une base légale pour l'enregistrement lui-même.

La plupart des discussions sur le sujet ne traitent que la première question, parce que c'est celle qui s'accompagne d'un bandeau.

La première question : ce que l'enregistrement stocke d'habitude

Pour assembler plusieurs pages vues en un seul rejeu, un outil doit reconnaître le même navigateur d'une page vue à l'autre. La façon habituelle est un identifiant dans un cookie ou dans localStorage, ce qui est du stockage sur l'appareil et exige un consentement dans l'EEE et au Royaume-Uni.

Ce n'est pas une obligation. L'identifiant peut être dérivé sur le serveur à partir de ce que la requête contient déjà, et changé pour qu'il ne survive pas à la journée, selon le même mécanisme que l'analytics sans cookie. Un rejeu assemblé de cette façon ne touche jamais l'appareil du visiteur, et l'article 5, paragraphe 3, n'a aucune prise.

Le coût est réel et mérite d'être dit : les enregistrements ne peuvent pas être rapprochés d'un jour à l'autre, si bien que « montre-moi tout ce que cette personne a fait la semaine dernière » n'est pas une question à laquelle cet outil peut répondre. Pour comprendre pourquoi un tunnel de commande perd des clients, cela n'a pas d'importance. Pour suivre tout l'historique d'un client précis, si.

La seconde question : une base légale, quoi que vous ayez stocké

L'enregistrement traite quand même des données à caractère personnel : au titre du RGPD, il vous faut donc une base légale pour cela. En pratique, c'est soit le consentement, soit l'intérêt légitime, et l'intérêt légitime veut dire réaliser et conserver une mise en balance, c'est-à-dire consigner par écrit pourquoi votre intérêt à améliorer la page l'emporte sur l'intérêt du visiteur à ne pas être filmé en train de s'en servir.

Cette appréciation devient d'autant plus difficile que le rejeu capture davantage, et c'est pourquoi ce qu'un outil enregistre par défaut compte plus que le bandeau :

  • Les champs de formulaire. Un rejeu qui capture la saisie capture les mots de passe, les numéros de carte, les réponses médicales et tout ce que quelqu'un tape d'autre. Aucune mise en balance ne survit à cela. Tout outil digne de ce nom masque le contenu des champs de saisie et n'en fait pas une option.
  • Les mots de la page. Autre chose que ce que les gens tapent, et plus facile à négliger. Une page de compte, une confirmation de commande ou un dossier patient affiche des données à caractère personnel au visiteur, et un rejeu qui vous les affiche est une copie de ces données dans un autre système.
  • Les catégories particulières. Santé, religion, orientation sexuelle, appartenance syndicale. Si une page peut afficher l'une de ces choses, le rejeu de cette page appelle une réflexion à part, et le plus souvent il faut le désactiver pour cette page.

Ce qu'il faut vérifier dans l'outil que vous utilisez

  1. Les champs de formulaire sont-ils masqués, et cela peut-il être désactivé ? La bonne réponse à la seconde moitié est non.
  2. Le texte de la page est-il capturé, et est-ce votre décision ? Un outil qui la prend pour vous a fait un choix juridique à votre place.
  3. Pouvez-vous exclure une page ou un élément ? Vous en aurez besoin pour au moins une page.
  4. Stocke-t-il un identifiant sur l'appareil ? Si oui, le bandeau n'est pas facultatif.
  5. Respecte-t-il le Global Privacy Control ? Le GPC est un signal d'opposition reconnu juridiquement dans plusieurs États américains, et il arrive sous forme d'en-tête de requête, que votre outil le lise ou non.
  6. Combien de temps les enregistrements sont-ils gardés, et pouvez-vous en supprimer un ?

Comment Skomi y répond

Le contenu des champs de formulaire n'est jamais enregistré, dans aucune configuration. Ce n'est pas un réglage par défaut dans l'enregistrement de session de Skomi ; il n'y a pas de réglage pour cela, dans aucun mode.

La quantité de texte de page capturée est un choix par site, et il y a trois réponses. « Strict » ne capture aucun texte : un rejeu montre alors la mise en page, la structure et l'interaction, sans mots. « Balanced » masque ce qui ressemble à une donnée à caractère personnel : les nombres et tout ce qui a l'allure d'une adresse e-mail. « Relaxed » capture le texte de la page et est le réglage par défaut, au motif qu'un rejeu sans mots dedans est très difficile à exploiter. Un site dont les pages affichent des données à caractère personnel a besoin de l'un des deux premiers, et c'est une décision que seul le propriétaire du site peut prendre.

Tout peut être exclu. Un attribut data-skomi-mask masque une zone et data-skomi-unmask en exempte une à l'intérieur, la classe skomi-block empêche complètement la capture d'un élément, et un site peut lister des sélecteurs CSS qui ne sont jamais enregistrés.

Le Global Privacy Control est respecté site par site, et il est désactivé tant que vous ne l'activez pas. Quand il est activé, rien n'est enregistré pour une requête portant Sec-GPC: 1. La vérification se fait sur le serveur, elle fonctionne donc pour tous les navigateurs, quoi que la page ait mis en cache. Cela s'applique aux enregistrements et aux cartes de chaleur seulement : la moitié analytics ne suit jamais un visiteur d'un site à l'autre, ce qui en fait un mauvais candidat pour un signal visant le suivi entre contextes.

Rien n'est stocké sur l'appareil du visiteur par défaut : avec le réglage par défaut, la première question ci-dessus ne se pose donc pas. La seconde se pose toujours : il vous faut encore une base pour enregistrer, et c'est à vous de l'avoir, pas à nous.

Les enregistrements expirent avant tout le reste. La durée dépend de votre forfait et c'est la plus courte des trois durées de conservation que Skomi applique.

Les cartes de chaleur sont la même question, en plus petit

Une carte de chaleur est construite à partir de la même capture (clics, mouvement et profondeur de défilement rapportés à une page), la question du stockage est donc identique. Ce qui diffère, c'est la seconde question : un agrégat de l'endroit où mille personnes ont cliqué est bien plus facile à justifier qu'une vidéo de l'une d'elles, et une carte de chaleur construite sans stockage sur l'appareil et sans texte de page est à peu près ce que la mesure comportementale fait de moins intrusif.

Si vous vous demandez s'il faut utiliser le rejeu tout court, c'est cette différence-là qui est utile : quand vous avez besoin des enregistrements de session, et quand non.

Dans Skomi, les deux fonctionnent dans Behavior, avec le masquage appliqué aux champs de saisie dans tous les modes plutôt que comme un réglage dont il faut se souvenir. Si vous comparez des outils précisément sur ce point, Microsoft Clarity documente une exigence de consentement qui lui est propre pour les visiteurs de l'UE, et ce qui se passe sans elle.