« Qu'est-ce que vous avez fait juste avant que ça casse ? » Chaque développeur pose cette question, et presque aucun utilisateur ne sait y répondre précisément. On ne se souvient pas du deuxième bouton cliqué, ni si la page avait fini de charger, ni qu'on a appuyé sur « Retour » au milieu d'un formulaire. La relecture de session répond à la question sans la poser : un enregistrement de ce qui s'est réellement passé dans le navigateur de l'utilisateur, qu'on parcourt à volonté, joint au rapport de bug.
Comment fonctionne vraiment la relecture de session
La relecture de session moderne n'est pas de la vidéo. Enregistrer des pixels produirait des fichiers énormes, serait lent et resterait aveugle à la structure de la page. Des outils comme rrweb, le moteur open source sur lequel repose la relecture de BugDump, prennent plutôt un instantané du DOM, puis enregistrent les mutations : nœuds ajoutés et supprimés, changements d'attributs, valeurs saisies, défilements, mouvements de souris, clics.
La lecture reconstruit la page à partir de ces données, comme on rejoue une partie d'échecs à partir de sa notation au lieu de filmer l'échiquier. Le résultat est compact, et comme il est structurel plutôt que visuel, vous pouvez le parcourir et voir exactement avec quel élément l'utilisateur a interagi, pas seulement où se trouvait son curseur à l'écran.
Conséquence pratique : la relecture coûte assez peu pour tourner en continu en arrière-plan, si bien que les moments qui précèdent la décision de signaler un bug sont déjà capturés quand l'utilisateur clique sur le bouton de rapport. C'est ce que les parcours façon vidéo, du type « enregistrez votre écran maintenant », ne pourront jamais vous donner : le bug a déjà eu lieu quand quelqu'un lance l'enregistrement.
Ce que la relecture vous dit et que les logs ne disent pas
Les logs de console et réseau vous disent ce qu'a fait le code. La relecture vous dit ce qu'a fait l'utilisateur. Les bugs vivent dans l'écart entre les deux, et certaines catégories sont presque impossibles à diagnostiquer sans le côté utilisateur :
Bugs de séquence : la modale ne casse que si on l'ouvre, la ferme et la rouvre. Aucune ligne de log ne le dit ; la relecture le montre en dix secondes.
Conditions de concurrence : l'utilisateur a cliqué avant la fin d'une requête. La relecture horodate le clic, le log réseau horodate la réponse ; ensemble, ils font le diagnostic.
Une saisie « erronée » qui ne l'est pas : l'utilisateur a collé une valeur avec une espace à la fin, ou le remplissage automatique a complété un champ inattendu. La relecture montre l'état réel du formulaire.
Confusion sur l'état de l'interface : l'utilisateur était sur une vue filtrée, dans un onglet périmé ou au milieu d'une modification non enregistrée. L'état du DOM à chaque instant est sous vos yeux.
L'inverse est tout aussi vrai : une relecture sans logs vous montre que la page a cassé, mais pas pourquoi. L'exception non capturée est dans la console ; la 500 est dans l'onglet réseau. C'est pourquoi la relecture est plus utile comme l'un des panneaux d'un rapport complet que comme outil isolé.
La relecture dans un workflow de rapport de bug
Le terrain traditionnel de la relecture de session, c'est l'analytics : enregistrer tout le monde, puis échantillonner des sessions pour étudier l'UX. Ce modèle est puissant mais lourd : on stocke des milliers de sessions pour en regarder une de temps en temps.
Le rapport de bug inverse la logique. BugDump collecte la relecture en arrière-plan et la joint quand un utilisateur envoie un rapport, avec le buffer de la console (jusqu'à 300 entrées, 2 000 pendant un enregistrement), le buffer réseau (150 requêtes, 1 000 pendant un enregistrement, échecs signalés), les détails de l'environnement et les métriques de performance. Vous obtenez des relectures précisément pour les sessions où quelque chose a mal tourné et où un humain l'a signalé : les sessions les plus riches en signal qui soient.
Le rapport arrive comme un dossier complet : lisez la description en une phrase de l'utilisateur, parcourez la relecture pour voir l'action, cherchez dans la console l'exception qu'elle a déclenchée, et trouvez la requête en échec dans le log réseau. Pour beaucoup de bugs, cette séquence remplace toute la conversation sur les « étapes pour reproduire ».
Questions de confidentialité
Un enregistrement du DOM peut contenir tout ce qu'une page affiche, y compris ce que les utilisateurs tapent. Prenez-le au sérieux :
Décidez de ce qui est enregistré. La relecture devrait être une option activée délibérément pour chaque projet, pas un réglage par défaut invisible que vous avez oublié. BugDump l'expose sous la forme d'un feature flag (
features.sessionReplay) que vous contrôlez.Filtrez le trafic sensible. Si vous capturez les données réseau, utilisez des filtres pour garder entièrement hors des buffers les endpoints tiers ou sensibles : ils sont écartés avant d'être stockés, pas masqués après coup.
Laissez la personne qui signale masquer ce qu'elle veut. Avec l'outil de floutage de l'annotation de capture d'écran, l'utilisateur cache lui-même son numéro de compte avant l'envoi. Le masquage par la personne qui sait ce qui est sensible vaut mieux que le masquage par regex.
Dites-le. Votre politique de confidentialité devrait indiquer que les rapports de bug peuvent inclure un enregistrement de la session de la personne qui signale. Les utilisateurs qui envoient un rapport sont en général contents que les données l'accompagnent, mais ils doivent le savoir.
Quand la relecture est superflue
Tous les projets n'ont pas besoin de la relecture dès le premier jour. Un site de contenu sans état interactif tire l'essentiel de sa valeur des captures d'écran et des logs de console. La relecture gagne sa place quand votre application a des parcours (formulaires en plusieurs étapes, éditeurs, tunnels de paiement, tableaux de bord) où le chemin compte autant que la destination. Si vos cinq dernières conversations sur un bug contenaient la phrase « d'accord, mais vous avez cliqué sur quoi juste avant ? », la relecture se rentabilise immédiatement.
Mieux vaut aussi savoir quel type d'« enregistrement » vous obtenez. Le widget BugDump propose à la fois l'enregistrement d'écran explicite (l'utilisateur commente un problème pendant qu'il capture son écran) et la relecture de session en arrière-plan (automatique, jointe aux rapports). Le premier est un outil de communication ; le second, un outil d'investigation. Ils se complètent au lieu de se remplacer.
Ce que la relecture change
La relecture de session comble le plus vieil écart du rapport de bug : la différence entre ce que les utilisateurs disent s'être passé et ce qui s'est passé. Associée aux logs de console, aux données réseau et aux détails de l'environnement, et collectée automatiquement au moment où un vrai utilisateur rencontre un vrai problème, elle fait d'« impossible à reproduire » une rareté plutôt qu'un motif de clôture.
Pour aller plus loin
La relecture de session sans la surveillance — enregistrer ce qui sert au débogage sans transformer le widget en outil de surveillance.
Comment capturer les logs console et les requêtes réseau d'un utilisateur — récupérer la console et le réseau du navigateur d'un utilisateur, et ce qu'il faut filtrer.
Que faire d'un rapport de bug impossible à reproduire — la marche à suivre quand un bug refuse de se reproduire chez vous.