Un replay est une reconstruction, pas une vidéo
Le malentendu le plus répandu au sujet du session replay est qu'il enregistrerait l'écran. Ce n'est pas le cas. Un replay capture le DOM — la structure de la page — ainsi que chacune de ses modifications, avec les clics, les défilements, les événements de saisie, les temps réseau et les erreurs de console. La lecture reconstruit la page à partir de ces données, dans votre navigateur.
Cette distinction fait tout. Parce qu'un replay est une donnée structurée et non des pixels, vous pouvez le parcourir par recherche, sauter à l'instant exact où une erreur s'est déclenchée et lire l'état du DOM à ce moment précis. Un enregistrement d'écran ne vous offre rien de tout cela, et coûte bien plus de bande passante.
Ce qu'il apporte et qu'une stack trace n'apporte pas
Un outil de suivi d'erreurs vous dit qu'un TypeError a été levé ligne 214. Il ne vous dit pas que l'utilisateur avait déjà soumis le formulaire deux fois, que la seconde tentative s'est faite sur une connexion lente, ni que le bouton est resté désactivé ensuite. Le replay fournit la séquence d'événements qui a produit l'état sur lequel votre code a buté.
En pratique, cela supprime la partie la plus lente du débogage : la reproduction. Au lieu de deviner les étapes à partir d'un rapport d'une ligne, vous regardez le chemin réellement emprunté par l'utilisateur.
Comment s'en servir quand un bug arrive
Remontez depuis la panne plutôt que de partir du début de la session. Trouvez l'erreur dans votre monitoring, ouvrez le replay associé et sautez à l'horodatage. Puis reculez de trente secondes : la cause se trouve presque toujours dans la demi-minute qui précède le symptôme, pas au début de la session.
Vérifiez trois choses dans cet ordre : ce que l'utilisateur a cliqué juste avant, si une requête a échoué ou est restée suspendue, et si ce qu'il voyait à l'écran correspondait à ce que vous pensiez afficher. La plupart des bugs se résolvent sur l'un de ces trois points.
Ce qu'il ne résoudra pas
Le replay montre ce qui s'est passé, jamais pourquoi la personne l'a fait. Si un utilisateur abandonne un formulaire, l'enregistrement indique le champ où il s'est arrêté — il ne peut pas dire si la question était confuse, intrusive ou simplement trop longue. Cette réponse s'obtient en la lui demandant.
Il est également médiocre sur les questions agrégées. Un enregistrement est une anecdote. Si vous devez savoir à quelle fréquence quelque chose se produit, c'est l'affaire d'un tunnel ou d'une requête d'événements ; servez-vous du replay pour expliquer la chute, pas pour la mesurer.
En choisir un spécifiquement pour déboguer
Si le débogage est l'objectif, pesez trois critères avant tous les autres. La capture console et réseau — sans elle, vous regardez un film muet. Le lien erreur vers replay, pour qu'une exception vous mène directement à la session qui l'a produite plutôt qu'à une liste à fouiller. Et des contrôles de confidentialité assez fins pour que l'outil reste utile : masquer tous les champs protège les utilisateurs mais peut cacher la valeur exacte à l'origine du bug ; cherchez donc des règles au niveau du champ plutôt qu'un interrupteur tout ou rien.