Quelque part dans vos outils de support, il y a une réponse enregistrée qui dit : « Pourriez-vous appuyer sur F12, ouvrir l'onglet Console et nous envoyer une capture d'écran de tout ce qui est en rouge ? » Elle part plusieurs fois par semaine. Elle ne revient presque jamais avec quoi que ce soit d'exploitable, et chaque correctif qui en dépendait reste bloqué des jours pendant que la conversation s'éteint.
Cet article explique comment mettre cette réponse à la retraite. Pas en apprenant les DevTools aux utilisateurs, mais en faisant en sorte que la prochaine fois qu'un utilisateur dira « la page a planté », les erreurs de console et les requêtes en échec de sa session soient déjà dans le rapport.
Pourquoi demander d'ouvrir les DevTools ne marche jamais
La réponse enregistrée échoue pour des raisons qui n'ont rien à voir avec la bonne volonté de l'utilisateur :
La plupart des utilisateurs n'ont jamais vu les DevTools. Le raccourci clavier change selon la plateforme et le navigateur, l'onglet Console n'est qu'un onglet parmi une douzaine, et les stack traces rouges ressemblent à du bruit. Vous demandez à quelqu'un de manier un instrument professionnel, une seule fois, sans encadrement, par e-mail.
La preuve a déjà disparu. La sortie de la console vit exactement aussi longtemps que l'onglet. Quand votre réponse arrive, l'utilisateur a fermé la page, et l'erreur dont vous aviez besoin n'existe plus nulle part. Vous lui demandez alors de reproduire le bug sur commande, c'est-à-dire précisément ce que vous n'arrivez pas à faire vous-même.
Une capture d'écran n'est pas le bon format. Dans le meilleur des cas, vous recevez l'image d'une stack trace repliée, recadrée de façon à masquer la seule ligne qui comptait, sans horodatage ni contexte réseau. Impossible d'y chercher, de la déplier ou de la recouper avec quoi que ce soit.
Additionnez les allers-retours : cette demande coûte des jours d'attente pour obtenir, au mieux, une fraction de ce que le navigateur savait gratuitement au moment de la panne.
Inverser le sens : le navigateur rapporte, l'utilisateur décrit
La solution consiste à ne plus faire passer les preuves par la mémoire et les captures de l'utilisateur, et à les collecter là où elles existent déjà : dans son navigateur, au moment du bug.
C'est le rôle d'un widget de signalement de bugs. Une fois BugDump installé, la capture tourne avant même que quoi que ce soit ne casse : le SDK garde une fenêtre glissante des dernières entrées de console et de l'activité réseau pendant que l'utilisateur navigue. Quand il rencontre un problème, il clique sur le bouton de bug et tape une phrase avec ses propres mots. Cette phrase, c'est tout son travail. Tout ce que vous lui auriez demandé suit automatiquement :
Logs de la console : les 300 dernières entrées, avec les erreurs et les avertissements signalés, et une recherche dans BugDump. Les exceptions non interceptées et les rejets de promesse non gérés sont capturés aussi, y compris ceux que votre code n'a jamais loggés.
Requêtes réseau : les 150 dernières, avec la méthode, le code de statut et la durée ; les échecs sont mis en évidence. La 500 qui a précédé la panne visible est juste à côté.
Environnement : navigateur, OS, appareil, viewport et URL exacte de la page, pour ne plus jamais taper « vous êtes sur quel navigateur ? ».
Relecture de session : une reconstitution, que l'on peut parcourir, de ce que l'utilisateur a fait avant le rapport, pour les bugs dont la cause est la séquence de clics.
Tout repose sur l'ordre des opérations. Un dispositif qui commence à collecter après la décision de l'utilisateur de signaler a déjà raté l'erreur. Comme les buffers tournent en continu, le moment de la panne est capturé, alors que personne, et surtout pas l'utilisateur, ne savait qu'un bug allait se produire.
Lire un rapport : le diagnostic en deux minutes
Un rapport accompagné de sa télémétrie se lit dans un ordre précis, et vite :
Lisez la phrase de l'utilisateur : elle vous donne l'intention (« j'essayais de payer »).
Allez directement aux entrées signalées : l'exception non interceptée dans la console, la requête en échec dans la liste réseau.
Regardez ce qui s'est passé juste avant : la requête qui a renvoyé des données inattendues, l'avertissement déclenché par l'action précédente.
Si la séquence compte, parcourez la relecture pour voir sur quoi l'utilisateur a vraiment cliqué.
L'erreur de la console nomme le symptôme dans votre code ; le journal réseau nomme généralement la cause ; la relecture tranche les débats sur ce que veut dire « j'ai juste cliqué normalement ». La plupart des rapports passent de « ouvert » à « je sais quel fichier ouvrir » sans un seul message à l'utilisateur. L'aller-retour de clarification qui prenait des jours n'a tout simplement plus lieu.
La mise en place
L'installation tient en une ligne sur n'importe quel site, sans étape de build ni adaptateur de framework :
<script src="https://bugdump.com/sdk/latest.js" async data-api-key="your-api-key"></script>Deux ajouts valent la peine dès le premier jour. Si votre application a des utilisateurs connectés, appelez bugdump('identify', { email }) après la connexion pour que chaque rapport porte son auteur. Et si vos pages exécutent des scripts tiers bavards (balises d'analytics, interrogations de feature flags), définissez les options consoleFilter et networkFilter du SDK pour que les buffers contiennent l'activité de votre application et non le bruit des heartbeats. Les entrées filtrées ne quittent jamais le navigateur : les filtres protègent donc aussi la vie privée, en plus de faire le ménage. Les corps de requête et de réponse sont désactivés par défaut (captureNetworkBodies les active) ; laissez-les désactivés sauf raison concrète, et indiquez dans votre politique de confidentialité que les rapports de bug contiennent des logs de diagnostic.
Vérifiez ensuite la boucle de bout en bout : envoyez un rapport depuis votre propre site, ouvrez-le dans BugDump et contrôlez que les panneaux console et réseau montrent votre session. Ce test de deux minutes, c'est exactement ce que vivront vos utilisateurs.
Mettre la macro à la retraite
La réponse enregistrée ne disparaît pas complètement : elle raccourcit. « Pourriez-vous cliquer sur le bouton de bug de la page et envoyer un rapport ? » tient en une ligne, et un utilisateur peut vraiment le faire. Ce qui revient n'est pas une capture recadrée, mais la console, le journal réseau, l'environnement et la relecture du moment où ça a cassé.
Vous continuerez à lire des erreurs tous les jours. Simplement, vous les lirez dans BugDump, telles qu'elles sont apparues dans les navigateurs où les bugs se sont produits, au lieu de demander aux utilisateurs de décrire un texte rouge qu'ils n'étaient jamais censés comprendre.
Pour aller plus loin
Comment capturer les logs console et les requêtes réseau d'un utilisateur — comment instrumenter la console, les erreurs, fetch et XHR sans casser la page que vous surveillez.
La relecture de session pour voir ce que l'utilisateur a fait avant le bug — ce que capture la relecture de session et pourquoi elle va de pair avec les logs console et réseau.
Suivi des erreurs JavaScript pour une petite app web : ce dont vous avez vraiment besoin — les quatre choses à attendre d'un outil de suivi des erreurs, et le moment où il vous faut un vrai outil de monitoring.