BugDumpbeta
Retour au blog

La relecture de session sans la surveillance

rapports de bugDenis Povarov

La relecture de session a un problème de réputation, et il est largement mérité.

La catégorie a été définie par des outils d'analytics qui enregistrent chaque session de chaque utilisateur, en continu et pour toujours, pour qu'une équipe growth puisse parcourir le tunnel de paiement de quelqu'un au trimestre suivant. C'est de la surveillance avec une fonction de débogage en prime, et les utilisateurs ont raison de s'en méfier.

J'utilise quand même la relecture, parce que pour une catégorie de bugs, rien d'autre ne marche. Mais je l'utilise autrement.

Quand la relecture est le seul outil

La plupart des bugs se résolvent avec la console et le journal réseau. Une erreur, un 500, c'est réglé.

Et puis il y a l'autre type de bug. Console propre. Réseau propre. Toutes les requêtes ont renvoyé 200. Et l'utilisateur est absolument certain que quelque chose a cassé.

Il a presque toujours raison. Ce qui a cassé, c'est l'interaction : un clic tombé sur le mauvais élément, un formulaire qui s'est réinitialisé sans rien dire, une modale ouverte derrière un overlay, une transition d'état qui a laissé l'interface dans une configuration que vous n'aviez jamais prévue. Rien de tout cela ne produit d'erreur, parce que du point de vue du code, tout s'est bien passé.

Pour ces bugs-là, la relecture, c'est toute l'enquête. Vous regardez les douze secondes qui précèdent le rapport et vous voyez ce que l'utilisateur a réellement fait, ce qui, bien souvent, n'est pas ce qu'il a décrit.

Limitée à un rapport, pas à un utilisateur

La différence de fond : dans BugDump, la relecture est rattachée à un rapport de bug, pas à un profil utilisateur.

L'enregistrement existe pour expliquer un rapport précis, que quelqu'un a envoyé. Il ne construit pas un historique du comportement de qui que ce soit dans la durée. Il n'y a pas d'explorateur de sessions, pas de « regarder un utilisateur au hasard », pas d'analyse de tunnel. Si personne n'a signalé de bug, personne ne regarde rien.

C'est une fonctionnalité plus petite que la relecture des outils d'analytics. C'est tout l'intérêt. La version restreinte résout le problème du débogage sans la partie qui met les gens mal à l'aise.

C'est l'utilisateur qui tient l'outil de masquage

L'outil d'annotation des captures d'écran comprend un outil de floutage, et il fonctionne comme il le doit : le masquage a lieu dans le navigateur, avant l'envoi. Une zone floutée n'est pas floutée sur les serveurs de BugDump : elle ne les atteint jamais.

Cela inverse la logique habituelle. D'ordinaire, la confidentialité est une promesse de l'éditeur : il dit qu'il traitera vos données de façon responsable, et vous décidez de le croire ou non. Le masquage dans le navigateur n'est pas une promesse. Les pixels ne quittent pas la machine.

Concrètement, un utilisateur qui regarde une page pleine de noms de clients peut vous envoyer la capture dont vous avez besoin. Sans cela, les plus prudents n'envoient rien.

Désactivé par défaut, là où ça compte

captureNetworkBodies vaut false tant que vous ne l'activez pas.

Les corps sont utiles : parfois, le payload de la réponse, c'est tout le bug. C'est aussi là que se trouvent les jetons, les données personnelles et les informations de paiement. Le bon réglage par défaut est celui où l'activer est une décision que quelqu'un a prise délibérément.

La relecture elle-même se désactive en une ligne, globalement ou sur les routes qui ne doivent pas être enregistrées :

TypeScript 
Bugdump.init({
  apiKey: 'your-api-key',
  features: {
    sessionReplay: false,
  },
});

Toutes les fonctions de capture marchent ainsi : captures d'écran, enregistrement, relecture et pièces jointes se désactivent séparément. Vous pouvez faire tourner BugDump avec seulement une description et un log de console, si c'est ce qu'exigent vos contraintes de conformité.

La demande d'autorisation que j'ai choisi de garder

Les captures d'écran et les enregistrements passent par défaut par getDisplayMedia, qui affiche la boîte de dialogue d'autorisation du navigateur lui-même. J'aurais pu l'éviter complètement en utilisant par défaut le rendu du DOM.

Je l'ai gardée, pour deux raisons.

La fidélité est réelle : canvas, vidéo, iframes cross-origin et contrôles natifs sont capturés exactement tels qu'ils sont rendus, au lieu d'être approximés. Et la demande est honnête. C'est le navigateur, et non BugDump, qui dit à l'utilisateur que son écran va être capturé. Il peut refuser, et dans ce cas la capture se rabat sur le rendu du DOM : le rapport n'est pas perdu.

Une boîte de dialogue d'autorisation, c'est une friction. C'est aussi un consentement, donné par un tiers que ni vous ni moi ne contrôlons.

Où j'en arrive

La relecture est un outil puissant, et l'industrie de l'analytics a appris aux gens à s'en méfier. Cette méfiance est raisonnable, et l'outil mérite quand même sa place.

Ma réponse : limiter la relecture aux rapports plutôt qu'aux sessions, mettre l'outil de masquage entre les mains de l'utilisateur et l'appliquer avant l'envoi, désactiver par défaut la capture la plus risquée, et rendre chaque fonction désactivable en une ligne.

Vous obtenez les douze secondes qui expliquent le bug. Vous n'obtenez pas de système de surveillance, et moi non plus.

Pour aller plus loin