Vous connaissez ce message. Il arrive un vendredi après-midi.
« Salut, le site est cassé. »
Alors vous répondez. Quelle page ? Que faisiez-vous ? Quel navigateur ? Vous pouvez envoyer une capture d'écran ? Il y avait une erreur dans la console ? En fait, laissez tomber, je vais vous expliquer comment ouvrir la console.
Quatre messages plus tard, vous apprenez que c'était Safari sur un iPad, sur une page que vous n'avez jamais testée à cette largeur, et que l'« erreur » était un 502 qui s'était résolu tout seul vingt minutes plus tôt. L'information dont vous aviez besoin existait. Elle existait dans son navigateur, au moment où ça a cassé, puis elle a disparu.
Le fossé
Le signalement de bugs souffre d'une asymétrie permanente. La personne qui subit le bug a toutes les preuves et n'en reconnaît aucune. La personne qui peut corriger le bug les reconnaîtrait toutes et n'en a aucune.
Tout outil de signalement de bugs tente de combler ce fossé. La plupart le font en demandant à l'utilisateur de transporter les preuves de l'autre côté, ce qui échoue, parce que l'utilisateur ne sait pas ce qu'est une preuve.
Demander à un utilisateur de décrire un bug, c'est lui demander de faire la partie la plus difficile du débogage (décider de ce qui est pertinent) sans aucun des éléments de contexte qui la rendent possible. Il vous dit que le bouton ne marche pas. Il ne vous dit pas que la requête a renvoyé 500, parce qu'il ne l'a jamais vue.
Dans l'autre sens
Alors ne demandez pas.
Les preuves sont déjà dans le navigateur. La console contient l'erreur. Le journal réseau, la requête en échec. Le DOM, la mise en page à la largeur où elle a cassé. L'utilisateur se tient au milieu d'une scène de crime complète, sans pouvoir en voir quoi que ce soit.
Le principe de BugDump, c'est que le seul travail de l'utilisateur devrait être de cliquer sur un bouton et de dire, avec ses mots, ce qui n'a pas marché. Tout le reste est collecté sans rien demander :
Les logs de console, y compris ceux d'avant l'ouverture du widget
Les requêtes réseau, avec leur statut et leur timing
Une relecture de session du DOM
Ses clics, saisies et navigations, dans l'ordre
Le navigateur, l'OS, le viewport, l'URL de la page
Une capture d'écran qu'il peut annoter, et flouter avant qu'elle quitte sa machine
L'utilisateur écrit « le bouton ne marche pas ». Vous recevez cette phrase accompagnée d'une réponse 500, d'une stack trace et d'une relecture des douze secondes qui ont précédé son abandon.
Ce qui change
Le gain évident, c'est la vitesse. Des rapports qui demandaient quatre allers-retours pour devenir exploitables arrivent exploitables.
Le gain moins visible, c'est le volume. La plupart des bugs ne sont jamais signalés. Pas parce que les utilisateurs s'en moquent, mais parce que signaler coûte cher : remplir un formulaire, expliquer le contexte, répondre aux questions, et probablement ne jamais avoir de nouvelles. Les utilisateurs font un calcul rapide et décident que ça n'en vaut pas la peine. Ils arrêtent simplement d'utiliser la fonctionnalité cassée.
Quand signaler coûte un clic, ce calcul change. Vous entendez parler des bugs qui ne valaient jamais la peine d'être mentionnés, et ce sont souvent eux qui vous font perdre des utilisateurs sans bruit.
Boucler la boucle compte aussi. Un rapport envoyé dans le vide apprend aux gens à ne plus signaler. BugDump donne donc à chaque projet un portail public où les personnes qui ont signalé un bug voient leur tâche passer de Confirmé à Terminé. Quelqu'un qui voit son rapport corrigé signale le suivant.
La partie que je n'avais pas prévue
J'ai construit la couche de capture en premier, parce que c'était le problème évident. Puis autre chose est devenu évident.
Dès qu'un rapport contient une télémétrie complète et structurée, ce n'est plus seulement de la documentation pour un humain. C'est une entrée bien formée pour un agent IA.
Alors j'ai lancé un serveur MCP. Claude Code se connecte à BugDump et lit directement les tâches, les rapports et toute la télémétrie. Le workflow devient :
Regarde la tâche #42 dans BugDump et corrige-la.
L'agent récupère l'erreur de console, trouve la requête en échec, localise le code correspondant et propose un correctif. Vous n'ouvrez jamais le tableau de bord.
Ce n'est possible que parce que le rapport est complet. Un agent ne peut pas demander à un utilisateur quel navigateur il utilisait. Il n'a droit qu'à un seul essai avec les preuves, ce qui veut dire qu'elles doivent être là en entier : la propriété qui rend un rapport utile à un humain est celle qui le rend exploitable par une machine.
Où en est BugDump
BugDump v1.0 est en ligne. Une balise script, un tableau de tri, huit intégrations, des webhooks et le serveur MCP. L'offre gratuite est une vraie offre : 500 rapports par projet, pour toujours, sans carte bancaire.
Je développe BugDump en toute transparence. Le journal des modifications est public, la feuille de route est publique, et le tableau des retours est ouvert. S'il manque à l'outil quelque chose dont votre workflow a besoin, dites-le-moi, de préférence via le widget, comme ça je reçois aussi le log de la console.
Pour aller plus loin
BugDump, le signalement de bugs pour sites web en une balise script — ce que fait le widget et ce que contient chaque rapport, de la console à la relecture de session.
Anatomie d'un rapport de bug – ce que BugDump capture et pourquoi — chaque signal que collecte le widget BugDump, à quoi il sert et lesquels résolvent vraiment des bugs.
Votre agent IA devrait lire vos rapports de bug — comment Claude Code lit les tâches et la télémétrie via le serveur MCP, et corrige un bug à partir de son identifiant.