Session replay privacy-first : l'alternative à Hotjar

Votre analytics vous dit ce qui s'est passé : cette page rebondit à 70 %, ce formulaire est abandonné, le tunnel perd des visiteurs à l'étape deux. Ce qu'il vous dit rarement, c'est pourquoi. Le session replay comble ce trou en vous laissant regarder des enregistrements anonymisés de vraies visites : vous voyez le clic dans le vide, le libellé qui embrouille, le champ que personne n'arrive à remplir.

Le problème, c'est que les outils de replay les plus connus, Hotjar et Fullstory, arrivent en général avec des cookies, une bannière de consentement, un prestataire de plus dans votre stack et un vrai risque d'aspirer des données personnelles. Ce guide explique ce qu'un session replay montre réellement, pourquoi le "privacy-first" change le calcul, ce qu'un bon outil de replay doit capter et masquer volontairement, et dans quels cas un outil lourd garde sa place.

Ce qu'un session replay montre vraiment

Un session replay est la reconstruction d'une visite : les pages vues, le scroll, les clics, la saisie (masquée), rejoués comme une vidéo. Ce n'est pas littéralement un enregistrement d'écran : l'outil capte les changements de la page et les rejoue, ce qui est plus léger et plus sûr.

Là où les métriques agrégées s'arrêtent, le replay commence. Une forte concentration sur une heatmap ou un pic de sorties vous dit que quelque chose cloche ; quelques enregistrements vous disent quoi. Vous voyez les rage clicks sur un élément qui n'est pas un bouton, le menu déroulant qui ne s'ouvre jamais sur mobile, le message d'erreur qui s'affiche sous la ligne de flottaison. C'est le moyen le plus rapide de transformer "les chiffres sont bizarres" en "voilà exactement ce qu'il faut corriger".

Le coût privacy des outils habituels

Le session replay classique a été conçu à une époque où tout tracker était normal, et ça se voit :

• Des cookies et une bannière de consentement. La plupart des outils de replay déposent des cookies, ce qui les fait tomber sous le régime du consentement : les enregistrements ne démarrent qu'après acceptation, et vous perdez tous ceux qui refusent (voir l'analytics sans bannière de consentement).
• Un prestataire de plus, un flux de données de plus. Un outil d'enregistrement séparé, c'est un second script, un second sous-traitant et un second endroit où le comportement de vos visiteurs est stocké.
• Un risque sur les données personnelles à configurer. Les outils sérieux masquent les champs de formulaire par défaut, mais les données personnelles affichées en texte dans la page (un email sur une page compte, un nom sur une confirmation de commande) peuvent quand même être captées sans configuration soignée. Plus un outil enregistre, plus vous avez de choses à verrouiller.

Rien de tout ça ne rend le replay mauvais. Ça rend la configuration par défaut lourde : plus de friction sur le consentement, une surface RGPD plus large, et un angle mort sur chaque visiteur qui dit non.

Ce que change un replay privacy-first

Le replay privacy-first inverse les réglages par défaut. Au lieu de tout enregistrer puis de vous demander de verrouiller, il enregistre le minimum nécessaire pour comprendre un comportement, masque les champs comme tout outil responsable devrait le faire, et laisse tomber ce qui crée du risque :

• Sans cookies. Quand l'outil ne dépose pas de cookie, il pèse beaucoup moins lourd côté consentement : vous captez le comportement sans qu'une bannière ne filtre chaque session.
• Intégré à votre analytics, pas un second prestataire. Quand le replay vit dans le même outil que vos métriques, il n'y a pas de script en plus, pas de sous-traitant séparé et pas de second endroit où le comportement de vos visiteurs est stocké.
• Hébergé en UE. Des enregistrements de visiteurs européens qui restent en Europe, c'est toute une couche de questions de transfert qui disparaît.

L'objectif n'est pas de voir moins pour le principe. C'est que vous n'aviez quasiment jamais besoin des parties sensibles pour trouver le bouton cassé, et que s'en passer supprime le casse-tête de conformité qui fait que les équipes évitent le replay tout court.

Ce qu'un bon replay enregistre (et ce qu'il évite volontairement)

C'est ici que l'honnêteté compte. Le session replay de Sublim est conçu pour être utile et privacy-first, pas pour être un outil forensique au pixel près. Il capte ce dont vous avez besoin pour diagnostiquer un problème :

• Capté : les changements de page, les clics, le focus et la sortie de champ, le scroll (échantillonné) et la structure de la page, de quoi voir où la visite a dérapé.
• Masqué : toutes les valeurs saisies sont masquées par défaut, et vous pouvez marquer n'importe quel élément pour le bloquer ou masquer son texte avec une simple classe CSS.
• Écarté volontairement : le suivi des mouvements de souris est désactivé, ce qui garde les enregistrements légers et évite de transformer le replay en surveillance.

Un mot sur le fonctionnement, parce que c'est ce qui rend le masquage fiable. Rien ne filme votre écran. L'outil stocke un instantané de la structure de la page, puis la liste horodatée de ce qui change : ce texte, cette classe, ce champ a reçu le focus, le visiteur a scrollé jusqu'ici. Le lecteur reconstruit la page à partir de ça et rejoue les changements à leur rythme d'origine, et c'est pour cette raison qu'un replay se regarde comme une vidéo sans jamais en être une.

Cette distinction compte pour la confidentialité : le masquage est structurel, pas cosmétique. Un champ masqué n'a jamais contenu sa valeur dans l'enregistrement, donc il n'y a pas d'image floutée avec la vraie donnée dessous. Ce qui n'a pas été enregistré n'existe tout simplement pas.

Voilà le compromis honnête : vous n'avez pas chaque pixel ni chaque frémissement de souris, et vous n'en avez pas besoin. Ce que vous avez, c'est le moment où la visite a basculé, sans une pile de données personnelles qu'il faudrait ensuite protéger.

Replay, heatmaps et analytics au même endroit

Un outil de replay autonome vous laisse jongler entre les onglets et réconcilier des chiffres. Le vrai gain d'un replay privacy-first intégré à votre analytics, c'est le contexte. Une métrique vous désigne une page à problème, une heatmap vous montre la zone, et un replay vous montre la visite individuelle, sans rien exporter vers un second prestataire. Comme les enregistrements sont à côté de votre trafic et de vos conversions, vous passez de "la conversion du tunnel a chuté" à "voilà trois enregistrements où elle échoue" dans le même outil. La source de trafic change d'ailleurs la façon de lire ces enregistrements, et c'est un sujet à part entière (voir pourquoi la source de trafic change vos session replays).

Sublim, Hotjar et Fullstory côte à côte

Réduit aux points qui comptent pour cette décision, voici où se situent les trois outils. Toutes les lignes ne sont pas à l'avantage de Sublim, et c'est le tableau honnête :

Le motif est assez clair : les poids lourds gagnent sur la fidélité et la recherche forensique, Sublim gagne sur le consentement, la juridiction et le contexte. Le côté du compromis qui vous intéresse dépend entièrement de l'usage que vous faites du replay.

Quand un outil de replay lourd reste pertinent

Soyons directs : si votre métier est la recherche UX approfondie, à plein temps, un outil plus lourd mérite ce qu'il coûte. Les cas où un outil haute fidélité comme Fullstory garde sa place :

• Le replay forensique au pixel près. Reconstituer chaque frémissement de souris et chaque micro-interaction pour des études d'utilisabilité détaillées.
• La QA et la chasse aux erreurs à grande échelle. Des équipes qui fouillent des milliers de sessions pour un rage click ou une erreur console précise, avec le filtrage avancé conçu pour ça.
• Les suites de product analytics dédiées. Quand le replay est le cœur du métier, pas le complément de votre analytics web.

Sublim ne prétend pas remplacer ces outils pour une équipe de recherche UX dédiée. Mais la plupart des sites n'ont pas besoin d'un microscope forensique et d'une bannière de consentement pour découvrir pourquoi leur formulaire échoue. Ils ont besoin de quelques enregistrements honnêtes, à côté des chiffres, sans le fardeau privacy.

Comment Sublim vous aide

Sublim intègre le session replay à votre analytics, au lieu d'en faire un produit séparé et gourmand en cookies. Les enregistrements sont sans cookies, les valeurs saisies sont masquées par défaut, et vous pouvez bloquer ou masquer n'importe quel élément avec une classe CSS : vous gardez la valeur diagnostique de regarder de vraies visites sans collecter les données que vous ne devriez pas conserver. Le replay est à côté de vos heatmaps, de votre trafic et de vos conversions, donc un enregistrement est à un clic de la métrique qui a éveillé votre curiosité. Il ne reconstituera pas chaque frémissement de souris, et pour la plupart des équipes c'est justement l'intérêt : vous voyez pourquoi la page échoue, et votre surface RGPD reste réduite.

En résumé

Le session replay est le moyen le plus rapide de transformer une mauvaise métrique en correction concrète, mais les outils classiques vous le font payer en cookies, en consentement et en second prestataire qui détient les données de vos visiteurs. Un session replay privacy-first change la donne : sans cookies, valeurs saisies masquées par défaut, hébergement en UE, et intégré à l'analytics que vous utilisez déjà.

Vous n'aviez quasiment jamais besoin des parties sensibles pour voir le bouton cassé. Enregistrez assez pour comprendre la visite, masquez le reste, et gardez le tout au même endroit. C'est un session replay que vous pouvez laisser tourner l'esprit tranquille.