Comment fonctionne le session replay et ce qu'il ne voit pas

Qu'est-ce que le session replay ?

En analytics web, le session replay est une technique qui reconstitue la visite d'un utilisateur sous forme de lecture regardable en enregistrant les changements du DOM et les événements de saisie plutôt qu'en filmant l'écran. L'enregistreur sérialise le DOM de la page une fois au chargement, puis diffuse chaque mutation, clic, défilement, frappe et changement de viewport suivants sous forme d'événement horodaté. Un lecteur applique ensuite ce flux d'événements à une copie reconstruite de la page dans une iframe isolée, ce qui explique que la lecture ressemble à une vidéo tout en pesant une fraction de celle-ci.

Cette distinction détermine tout le reste, de ce qu'un replay prouve à ce que son stockage coûte.

Comment le session replay enregistre-t-il une page sans vidéo ?

Un enregistreur de session replay capture un état, pas des pixels. Au chargement de la page, il parcourt l'arbre du DOM et sérialise chaque noeud dans une structure JSON, en attribuant à chaque noeud un id numérique stable. Cette première charge utile est l'instantané complet du DOM, et tout ce qui suit est un diff.

À partir de là, l'enregistreur attache un MutationObserver et un ensemble d'écouteurs d'événements. Chaque changement devient un petit enregistrement : le noeud 412 a gagné un enfant, le texte du noeud 205 a été remplacé, la fenêtre a défilé jusqu'à y=1,200 à la milliseconde 8,431. La bibliothèque open source rrweb a établi le format que suivent la plupart des éditeurs, y compris le modèle d'un id par noeud et la séparation entre instantané et incréments.

La lecture inverse le processus. Le lecteur construit un document à partir de l'instantané, le monte dans une iframe avec les scripts désactivés, puis applique les mutations dans l'ordre enregistré selon une horloge virtuelle. Rien ne s'exécute sur la page rejouée, et le curseur que vous regardez est un calque dessiné, pas un pointeur capturé.

Que peut capturer un session replay, et que rate-t-il ?

Un session replay capture tout ce qui est exprimé dans le DOM de la page enregistrée, et rien de ce qui vit en dehors. Comme l'enregistreur lit le même DOM que celui affiché par le navigateur, le contenu injecté par une extension de navigateur apparaît dans le replay exactement comme le visiteur l'a vu, ce qui explique les rapports de bug que personne dans l'équipe ne réussit à reproduire.

Les angles morts sont précis :

• Les surfaces canvas et WebGL s'affichent comme des cadres vides sauf si l'enregistreur est configuré pour les capturer, car leur contenu n'est pas constitué de noeuds du DOM.
• Le contenu des <video> et des <iframe> provenant d'une autre origine ne peut pas être lu, donc le replay montre le cadre de l'élément sans rien à l'intérieur.
• L'interface native du navigateur n'apparaît jamais : les listes de saisie automatique, les boîtes alert(), la feuille d'impression, la barre de téléchargement, les devtools.
• Tout ce qui se passe dans un autre onglet, une autre fenêtre ou le système d'exploitation est hors périmètre.
• L'état du serveur reste invisible. Le replay montre qu'un formulaire a renvoyé une erreur, pas quelle contrainte de base de données l'a rejeté.

Un mode de défaillance surprend les équipes des mois plus tard. Les images, les polices et les feuilles de style sont stockées sous forme d'URL, pas d'octets, donc un déploiement qui modifie une feuille de style fait s'afficher les anciens replays avec les nouveaux styles. Un replay d'il y a six mois est une trace de structure et de comportement, pas d'apparence exacte.

Comment le masquage protège-t-il les données personnelles dans un session replay ?

Le masquage remplace les valeurs sensibles à l'intérieur du navigateur avant l'envoi du moindre événement, si bien que le serveur ne reçoit jamais le texte d'origine. Un enregistreur applique des règles au moment où il sérialise chaque noeud : les champs de mot de passe sont supprimés par défaut, les éléments portant une classe comme .mask voient leur texte remplacé par des astérisques, et les éléments bloqués deviennent un cadre vide qui préserve la mise en page.

Deux politiques se comportent différemment sous pression. Une liste de blocage masque les champs que vous avez pensé à marquer, et laisse fuir le champ qu'un développeur ajoute au sprint suivant. Une liste d'autorisation masque tout par défaut et démasque les éléments que vous nommez, ce qui donne des replays plus laids et aucune surprise. Choisissez la liste d'autorisation pour toute surface touchant au paiement, à la santé, au compte ou au support.

Flowsery fonctionne sans cookies, est hébergé dans l'UE, est GDPR by design et livre un seul script de moins de 10 KB.

Liste de blocage contre liste d'autorisation pour le masquage

Liste de blocage

• Masque seulement les champs marqués aujourd'hui
• Laisse passer le champ qu'un développeur ajoute le sprint suivant

Liste d'autorisation

• Masque tout par défaut
• Ne démasque que les éléments nommés
• Replays moins soignés, mais sans surprise

De combien de stockage un session replay a-t-il besoin ?

Le stockage évolue avec le volume d'événements, pas avec la durée de la session en temps réel. Un visiteur qui lit un article pendant dix minutes produit presque aucune mutation ; un visiteur qui déplace des éléments dans une application canvas pendant quatre-vingt-dix secondes en produit des dizaines de milliers. L'estimation est :

monthly bytes = sessions recorded x events per session x compressed bytes per event

Prenons un exemple. Supposons 50,000 sessions enregistrées par mois, 4,000 événements par session et 200 octets compressés par événement :

4,000 x 200 = 800,000 octets, soit environ 800 KB par session. 800 KB x 50,000 = 40,000,000 KB, soit environ 40 GB par mois.

Les mêmes 50,000 sessions capturées en vidéo 720p atteindraient plusieurs téraoctets. Ce rapport explique pourquoi les outils de replay facturent au nombre de sessions et à la durée de rétention plutôt qu'au gigaoctet, et Flowsery fixe les limites de ses offres sous forme de quotas couvrant les sessions analytics, les enregistrements de session, les sessions analysées par IA et la rétention des replays en mois.

Faut-il échantillonner les sessions ou toutes les enregistrer ?

L'échantillonnage échange la couverture diagnostique contre du coût, et il échoue précisément sur les sessions dont vous avez besoin. Si un bug de paiement touche un visiteur sur 400 et que vous enregistrez 10 pour cent du trafic, vous capturez le bug une fois toutes les 4,000 sessions et vous ne pouvez pas confirmer un correctif sans attendre des semaines. Les événements rares sont la raison d'être du replay, et les événements rares sont ce que l'échantillonnage supprime.

Flowsery enregistre chaque session utilisateur sans échantillonnage de données et se connecte aux replays déjà enregistrés dans PostHog ou Amplitude sans réinstrumentation. Si un budget impose malgré tout une décision d'échantillonnage, gardez 100 pour cent des sessions qui touchent au paiement, à l'inscription et à tout parcours ayant émis une erreur JavaScript.

En quoi le session replay diffère-t-il de l'enregistrement d'écran et d'une heatmap ?

Le session replay, l'enregistrement d'écran et les heatmaps répondent à trois questions à partir de trois sources de données. L'enregistrement d'écran capture les pixels encodés de tout ce que voit une API de capture. Une heatmap agrège les coordonnées de nombreux visiteurs en une seule image et ne conserve aucun parcours individuel.

Question	Session replay	Enregistrement d'écran	Heatmap
Ce qui est stocké	Mutations du DOM et événements de saisie en JSON	Images vidéo encodées	Coordonnées et compteurs agrégés
Taille par session	Kilo-octets	Mégaoctets	Aucun artefact par session
Texte après capture	Vrai texte du DOM, sélectionnable	Pixels uniquement	Non conservé
Qui le déclenche	Le script de la page, automatiquement	Une personne, délibérément	Le script de la page, automatiquement
Périmètre	La page enregistrée seulement	Tout l'écran ou la fenêtre	La page enregistrée seulement
Montre le parcours d'une personne	Oui	Oui	Non, il fusionne tout le monde
Répond à	Pourquoi cette visite a échoué	Ce que cette personne a dit en le faisant	Où tout le monde clique

Servez-vous d'une heatmap pour décider où regarder, et d'un replay pour savoir ce qui s'y est passé. Une heatmap montre un CTA froid ; seul un enregistrement de session d'un visiteur qui l'a dépassé en défilant vous apprend que le bouton se trouvait derrière un en-tête fixe à ce breakpoint.

Où les équipes utilisent-elles le session replay en pratique ?

Les équipes utilisent le replay pour combler l'écart entre un rapport d'erreur et une reproduction. Une trace d'appels nomme la ligne qui a levé l'erreur ; le replay qui la précède montre les onze clics qui ont mis l'application dans cet état. Il en va de même pour les échecs silencieux, où rien n'est levé et la seule preuve est un visiteur qui clique six fois sur un bouton désactivé.

Regarder les replays un par un cesse de fonctionner au-delà de quelques centaines de sessions par jour, donc la détection compte plus que la lecture. Le session replay par IA de Flowsery détecte automatiquement les rage clicks, les dead clicks, les erreurs JavaScript, les abandons et les parcours cassés, regroupe les sessions correspondantes en un seul problème et classe les problèmes selon le nombre d'utilisateurs touchés. Chaque problème arrive dans Slack, Linear ou Jira avec le replay et les étapes de reproduction en pièce jointe, et mentionner @flowsery dans Slack ouvre une pull request en brouillon dans votre dépôt GitHub. Ces signaux de frustration transforment les enregistrements en une file classée par priorité.

Questions fréquentes

Le session replay est-il la même chose qu'un enregistrement d'écran ?

Non. L'enregistrement d'écran stocke des images vidéo encodées d'un écran ou d'une fenêtre, tandis que le session replay stocke des mutations du DOM et des événements de saisie et reconstruit la page à partir d'eux. Les conséquences portent sur la taille, kilo-octets contre mégaoctets, et sur le périmètre, puisque le replay ne voit que la page enregistrée.

Le session replay enregistre-t-il les mots de passe ?

Les enregistreurs suppriment par défaut les valeurs des champs de mot de passe, donc le champ apparaît masqué et la vraie valeur ne quitte jamais le navigateur. Les autres champs sensibles restent non protégés tant que vous ne les marquez pas, et c'est pourquoi une liste d'autorisation qui masque tout et démasque les éléments nommés vaut mieux que marquer les champs un par un.

Pourquoi les anciens replays paraissent-ils cassés ?

Les replays référencent les feuilles de style, les polices et les images par URL au lieu d'en stocker les octets. Un déploiement CSS ou un fichier CDN supprimé fait s'afficher les anciens replays avec les nouveaux styles ou avec des images manquantes. La structure du DOM et la chronologie des interactions restent exactes.

Le session replay peut-il voir à l'intérieur d'une iframe ?

Un enregistreur peut capturer les iframes de même origine en les instrumentant en même temps que le document principal. Les iframes d'origine différente sont bloquées par le modèle de sécurité du navigateur, donc un formulaire de paiement intégré ou un widget tiers d'un autre domaine apparaît comme un cadre vide à la lecture.

Combien de temps faut-il conserver les replays ?

La rétention doit correspondre à la fenêtre la plus courte pendant laquelle vous agissez sur les données, puisque chaque mois supplémentaire ajoute du coût et de l'exposition en matière de vie privée. Flowsery exprime la rétention des replays en mois dans le quota de l'offre.

Le session replay ralentit-il une page ?

Le coût de l'enregistreur vient de la sérialisation du DOM initial et de l'observation des mutations ensuite, donc les applications monopages lourdes aux grands arbres paient plus que les pages statiques. Le poids du script est la part que vous contrôlez à l'installation : Flowsery livre un seul script de moins de 10 KB.

Flowsery utilise-t-il des cookies pour enregistrer les sessions ?

Flowsery enregistre les sessions sans cookies, tourne sur une infrastructure hébergée dans l'UE et est conçu GDPR by design. Le script qui capture l'instantané du DOM et le flux de mutations pèse moins de 10 Ko, donc le pipeline d'enregistrement lui-même ne dépend d'aucun cookie.

Une extension de navigateur peut-elle apparaître dans un session replay ?

Oui, parce que le recorder lit le même DOM que celui rendu par le navigateur, et le contenu injecté par une extension fait partie de ce DOM. Cela explique les rapports de bug que personne dans l'équipe n'arrive à reproduire, puisque l'extension n'existe que dans le navigateur de cette personne.

Le session replay se connecte-t-il à des outils comme PostHog ou Amplitude ?

Flowsery se connecte aux replays déjà enregistrés dans PostHog ou Amplitude, si bien qu'une équipe n'a pas besoin de réinstrumenter un site qui envoie déjà des événements vers l'une de ces plateformes. Il enregistre chaque session sans échantillonnage, ce qui conserve les rares échecs de paiement ou d'inscription qu'une capture partielle manquerait.

Le session replay peut-il signaler des problèmes automatiquement sans regarder chaque enregistrement ?

L'AI session replay de Flowsery détecte les rage clicks, les dead clicks, les erreurs JavaScript, les abandons et les parcours cassés, regroupe les sessions similaires dans un seul issue et classe les issues selon le nombre d'utilisateurs touchés. Chaque issue arrive dans Slack, Linear ou Jira avec le replay et les étapes de reproduction, et mentionner @flowsery dans Slack ouvre un brouillon de pull request dans le dépôt GitHub connecté.