On peut rejouer la navigation de vos visiteurs, seconde par seconde

Hier, sur un site qu'on gère, un visiteur est arrivé sur un formulaire. Il a tapé son numéro de téléphone, l'a effacé, l'a retapé, puis il a fermé l'onglet.

On peut rejouer la scène et vous montrer la seconde exacte où il a renoncé.

Dit comme ça, c'est assez inconfortable. Alors autant expliquer ce qui se passe réellement.

Au programme :

• Ce qu'un replay capture réellement, et ce qu'il ne capture pas
• À quel moment l'enregistrement démarre, et ce qui n'en sort jamais
• Pourquoi on s'en sert surtout pour déboguer, et où l'outil cesse d'être fiable

Le décor remonté à l'identique

Le malentendu vient de l'image : un replay ressemble à une vidéo, donc on suppose qu'un enregistreur d'écran tourne quelque part. Il n'y en a aucun.

L'outil qu'on utilise, OpenReplay, prend un instantané du DOM — la structure de la page telle que le navigateur la comprend. Puis il note chaque modification qui suit : les clics, les scrolls, les changements d'affichage, chacun avec son horodatage.

Au moment de la relecture, la séquence est rejouée et la page se remonte d'elle-même, comme un décor reconstruit à l'identique. Ce n'est donc pas votre visiteur qui est enregistré, c'est votre page, réanimée avec ses gestes. Au passage, ça pèse infiniment moins lourd qu'une vidéo, ce qui évite de stocker des téraoctets de gens en train de scroller.

En revanche, tout ce qui ne vit pas dans le DOM se reconstruit mal : une vidéo, un graphique dessiné dynamiquement, certains scripts tiers apparaîtront comme des zones vides.

Chez nous, OpenReplay tourne sur nos propres serveurs. Les sessions de vos visiteurs ne partent chez aucun éditeur : elles restent sur une infrastructure qu'on administre pour garder le contrôle sur les données.

Des astérisques, jamais des valeurs

Mais qu'est-ce qui sort réellement du navigateur ?

Rien ne démarre avant le consentement au suivi. Pas de consentement, pas de session à rejouer — et c'est vérifiable en trois clics dans les outils de développement de n'importe quel navigateur.

Les champs sensibles, eux, sont masqués avant le moindre envoi réseau. Mots de passe, numéros de carte, données personnelles. Ce qui arrive sur le serveur contient des astérisques, pas des valeurs. Le cadre réglementaire complet mérite son propre article, on y reviendra.

La fin du « chez moi ça marche »

Tout le monde présente ces outils comme des outils d'analyse marketing. C'est de loin l'usage le moins intéressant.

Prenez un script ajouté à la page qui échoue en silence. Ou une requête au serveur qui ne part pas. Votre visiteur continue tranquillement, aucune erreur ne lui est affichée, et en interne personne ne signale un bug dont personne n'a conscience. C'est le bug idéal : indolore, invisible, et il vous coûte des ventes depuis six mois.

À côté du replay, vous avez la console du navigateur — le journal de bord où s'inscrivent les erreurs techniques — et les erreurs réseau. Le tout sur la même timeline que l'interaction.

Vous ouvrez la session qui a mal tourné. Vous avancez jusqu'au clic. Vous lisez l'erreur déclenchée pile à cet instant.

C'est comme ça qu'on travaille sur les sites qu'on maintient : le replay ouvert à côté du code, pas un tableau de bord qu'on consulte une fois par mois.

Le voyant orange sans notice

Le replay ne sert pas qu'à traquer les bugs. Il rend aussi visibles des problèmes d'interface que personne ne vous signalera jamais.

Un visiteur qui bute sur un élément mal foutu n'écrit pas au support. Il clique trois fois, agacé, sur un texte qui ressemble à un lien sans en être un. Puis il s'en va. Le seul indicateur qu'il vous laisse, c'est un taux de rebond un peu moins bon — à peu près aussi utile qu'un voyant orange sans notice.

Le métier a un nom pour ça : le rage click. C'est le signal le plus lisible, mais tout se voit. Un champ rempli puis effacé. Un scroll qui s'arrête toujours au même endroit, très loin du contenu que vous aviez soigneusement placé en bas de page.

Rien de tout ça n'est propre à OpenReplay, d'ailleurs. Chaque outil de la famille est bon à quelque chose de différent.

L'aiguille dans une botte de foin qu'on ne sait pas reconnaître

Le vrai piège du replay, c'est qu'il est trop convaincant. Voir un visiteur galérer en direct marque bien plus qu'un tableau de chiffres. C'est aussi beaucoup moins fiable : une session reste une anecdote, et il faut retrouver le même motif sur assez de visiteurs pour en tirer quoi que ce soit.

Surtout, se promener dans les sessions sans hypothèse de départ ne mène nulle part. C'est chercher une aiguille dans une botte de foin sans savoir à quoi ressemble l'aiguille. Ce qui marche, c'est de partir d'un chiffre qui décroche, puis d'aller chercher les sessions correspondantes. Le replay explique une anomalie déjà repérée ; il la découvre rarement.

Enfin, il ne donne pas toujours le fin mot de l'histoire. Sur un bug, il localise l'endroit où ça casse sans forcément remonter jusqu'à la cause quand celle-ci est antérieure à la session. Et sur le comportement, on constate qu'un visiteur a hésité. Jamais ce qu'il avait dans la tête.

Ce qui est arrivé au visiteur du début

Le champ refusait les espaces. Sans le dire : aucun message d'erreur, juste un bouton d'envoi qui ne faisait rien. Il a cru s'être trompé, il a retapé, il est parti.

On ne l'a pas trouvé en fouillant des sessions au hasard. Le nombre de formulaires reçus avait chuté d'un coup, et c'est ce chiffre qui nous a fait ouvrir les replays de cette page.

Une semaine de demandes perdues, pour une validation trop stricte sur un champ. Aucun de ces visiteurs n'a écrit pour signaler que le formulaire ne marchait pas.

Voilà à quoi servent ces outils, une fois retombé le fantasme de la surveillance.