Le session replay enregistre et rejoue les interactions réelles d’un visiteur : mouvements, clics, hésitations, allers-retours. Il répond au « pourquoi » que la heatmap ne peut pas expliquer. Son usage efficace est filtré : on regarde les sessions d’un symptôme précis (abandon de formulaire, rage clicks) pour trouver une cause, pas au hasard. Et c’est une donnée personnelle sous RGPD : consentement préalable et masquage des champs sensibles sont obligatoires.
La heatmap montre où le comportement se concentre, en agrégat. Le session replay montre comment une personne réelle a vécu sa visite, hésitation par hésitation, clic par clic, retour en arrière par retour en arrière.
C’est l’outil du pourquoi : pourquoi cette personne a abandonné au champ téléphone (on la voit hésiter, le survoler, remonter lire quelque chose, puis fermer), pourquoi elle a cliqué trois fois sur un élément (il avait l’air cliquable, il ne l’était pas).
Là où la heatmap pose une question, le replay donne souvent le début d’une explication : la matière qualitative la plus riche de tout l’arsenal d’analyse comportementale.
Mais cette richesse est un piège si on l’utilise mal. Il y a deux manières de mal l’utiliser : une de méthode, une de droit.
La valeur est dans le filtrage. On part d’un symptôme identifié par les données quantitatives : c’est souvent l’analyse de l’entonnoir et du formulaire qui chiffre où ça décroche et qui indique quoi filtrer. On sélectionne uniquement les sessions qui ont abandonné le formulaire, celles avec des rage clicks, celles qui ont bouclé sur une page ou quitté à une étape clé. Puis on en regarde une poignée en cherchant la cause récurrente : le moment qui revient, le geste de friction partagé.
Dix replays filtrés sur un abandon précis apprennent plus que cent sessions au hasard. Le replay n’est pas un outil d’exploration tous azimuts : c’est un outil de diagnostic ciblé. On l’ouvre avec une question, pas par curiosité.
Voici le front que beaucoup négligent, et qui peut coûter cher. Un session replay capture des données personnelles : il enregistre ce qu’une personne identifiable fait sur votre site, parfois ce qu’elle saisit.
À ce titre, il relève pleinement du RGPD, et c’est l’une des catégories d’outils les plus sensibles côté conformité. Trois exigences en découlent.
Le consentement préalable (opt-in). L’enregistrement de session nécessite le consentement de la personne. Il ne va pas de soi du seul fait qu’elle visite votre site.
Le masquage des données sensibles. Mots de passe, coordonnées bancaires, données personnelles saisies dans les formulaires doivent être masqués à la capture. Un replay ne doit jamais rejouer un numéro de carte ou une adresse mail complète.
Le piège technique majeur. Beaucoup d’outils, par défaut, démarrent l’enregistrement dès le chargement de leur script, donc avant que le visiteur ait consenti. C’est précisément là que se crée l’exposition : vous croyez être en règle parce que vous avez une bannière de consentement, mais l’outil enregistrait déjà avant le clic. Il faut vérifier que rien ne se capture avant le consentement, point de configuration souvent ignoré.
Le cadre juridique exact relève de votre conseil (DPO, juriste), pas de cette page. Et il bouge : la CNIL a ouvert en 2026 une consultation publique spécifiquement sur les outils de session-replay, ce qui annonce un encadrement possiblement plus strict.
La limite honnête de cette page : nommer le risque et les bonnes pratiques de base (consentement, masquage, pas d’enregistrement avant accord). La conformité de votre implémentation doit être validée par quelqu’un dont c’est le métier.
Un outil de CRO ne vaut rien s’il vous met en infraction.
Filtrage, consentement, masquage PII : on remet l’outil dans les rails.
Réserver un appelParlons de vos objectifs