Session replay sans le côté glauque.

Le session replay est l'outil de debug le plus utile de la dernière décennie. C'est aussi le plus facile à mal utiliser. Le même enregistrement qui te montre un checkout cassé peut capter un email, un numéro de carte, ou un message privé.

La règle est simple : enregistrer l'interaction, pas l'identité.

Ce qu'il faut masquer par défaut

• Tous les champs de saisie — texte, email, mot de passe, recherche. Toujours.
• Tout ce qui est dans un formulaire de données personnelles.
• Photos de profil, avatars, fils de messages, soldes de compte.
• Tout ce qui vient d'un sous-domaine connecté que tu n'as pas explicitement autorisé.

Ce qui est vraiment utile à voir

Trajectoires de souris, profondeur de scroll, clics, rage clicks, dead clicks, erreurs réseau, erreurs console, temps par section. C'est là que se cachent les bugs. Rien de tout ça n'exige de savoir qui est la personne.

Un consentement qui ne ment pas

Sous le RGPD et ePrivacy, le replay n'est pas de l'analytics anonyme — il exige un opt-in explicite avant le début de l'enregistrement. Pas une case pré-cochée. Pas une bannière qui s'auto-accepte au bout de 5 secondes. Un vrai clic sur un vrai bouton.

Catch before they bounce est livré avec le mode consent-aware désactivé par défaut — tu l'actives le jour où tu es prêt, et le tracker ne fait simplement rien jusqu'à ce que le visiteur accepte. Aucun enregistrement rétroactif, aucun événement bufferisé.

La rétention fait partie de la vie privée

On garde les replays 30 jours sur la plupart des plans, 90 sur Pro, puis ils disparaissent. Une longue rétention n'est pas une fonctionnalité, c'est un risque. Si tu ne peux pas justifier de garder un enregistrement six mois, tu ne devrais pas le garder six mois.

Bien fait, le replay donne l'impression de regarder des tests d'utilisabilité que tu n'as pas eu à organiser. Mal fait, c'est de la surveillance avec un dashboard. La différence : tu serais-tu à l'aise de montrer l'enregistrement à la personne enregistrée ?