BugDump est un widget de rapport de bug pour sites web. Vous ajoutez une balise script, un bouton flottant apparaît dans le coin de votre application, et à partir de là vos utilisateurs peuvent signaler des bugs qui arrivent avec le contexte dont vous avez vraiment besoin pour les corriger : logs de console, requêtes réseau, relecture de session, détails de l'environnement et capture d'écran annotée.
Cet article explique ce que fait BugDump, à quoi ressemble un rapport et où l'outil s'insère dans votre workflow.
Le problème qu'il résout
La plupart des rapports de bug envoyés par de vrais utilisateurs ressemblent à ceci : « La page ne marche pas. » Pas d'URL, pas de version de navigateur, pas d'étapes, pas de message d'erreur. Vous répondez pour demander des détails, l'utilisateur est passé à autre chose, et le bug reste en place jusqu'à ce que quelqu'un de votre équipe tombe dessus par hasard.
Les informations dont vous aviez besoin existaient au moment du bug : dans la console, dans l'onglet réseau, dans le DOM. Elles n'ont simplement pas été capturées. Le rôle de BugDump est de les capturer automatiquement, pour qu'une plainte d'une ligne devienne un dossier complet.
Comment se passe l'installation
L'installation tient en une ligne de HTML :
<script src="https://bugdump.com/sdk/latest.js" async data-api-key="your-api-key"></script>Le script s'initialise tout seul à partir de l'attribut data-api-key : pas d'appel au SDK, pas d'étape de build, aucun framework requis. Il fonctionne avec React, Vue ou du JavaScript pur, parce qu'il ne touche pas du tout au code de votre application. Si vous préférez une dépendance dans votre bundle, il existe un paquet npm (@bugdump/sdk) avec des types TypeScript complets, et un mode d'initialisation manuelle pour piloter le widget par le code.
Le widget s'affiche dans un Shadow DOM : ses styles ne débordent jamais sur votre application, et votre CSS ne casse jamais le widget. Vous pouvez choisir le thème (clair, sombre ou celui du système), changer l'icône du bouton, déplacer ou masquer complètement le bouton, et remplacer chaque texte de l'interface, utile si votre produit n'est pas en anglais.
Ce que contient un rapport
Quand un utilisateur clique sur le bouton, décrit le problème et l'envoie, le rapport qui arrive dans BugDump contient automatiquement :
Logs de console : les 300 dernières entrées (2 000 pendant un enregistrement), erreurs et avertissements mis en évidence, avec recherche.
Requêtes réseau : les 150 dernières requêtes (1 000 pendant un enregistrement) avec leurs codes de statut ; les requêtes en échec sont signalées. Les corps de requête et de réponse peuvent être inclus si vous l'activez.
Relecture de session : des instantanés du DOM basés sur rrweb, qui montrent ce que l'utilisateur a fait avant le bug et se parcourent comme une vidéo.
Environnement : navigateur, OS, appareil, taille d'écran, viewport et URL de la page.
Métriques de performance : TTFB, FCP, temps jusqu'au DOM prêt, temps de chargement et utilisation du heap JS.
En plus du contexte automatique, les utilisateurs peuvent joindre une capture d'écran (avec des outils d'annotation : flèches, rectangles, dessin à main levée, texte et floutage pour masquer les données sensibles), un enregistrement d'écran, une note vocale ou des fichiers. Rien de tout cela n'est obligatoire : le rapport minimal tient en une phrase et un clic, et la télémétrie suit quand même.
Si votre application a des utilisateurs connectés, bugdump('identify', { email }) associe l'identité de la personne au rapport : vous savez qui a rencontré le problème sans lui demander de taper son e-mail.
Du rapport au correctif
Les rapports arrivent dans BugDump, où ils deviennent des tâches sur un tableau kanban. À partir de là :
Les intégrations transmettent les bugs aux outils que vous utilisez déjà : Telegram, Slack, Discord, GitHub Issues, Jira, Asana et d'autres, sur les forfaits payants. Sur le forfait gratuit, les nouveaux rapports vous parviennent par e-mail et dans l'application.
Le serveur MCP connecte votre projet à Claude Code, Cursor ou n'importe quel client compatible MCP : un assistant IA lit alors tout le contexte d'un bug (rapports, console, réseau, captures d'écran) et enquête dessus en langage naturel.
Un portail public (facultatif) donne aux personnes qui signalent les bugs un accès aux rapports, et vous pouvez publier à côté une feuille de route et un journal des modifications.
Combien ça coûte
Le prix dépend du nombre de rapports que vous collectez, pas du nombre de membres de l'équipe, et il n'y a pas de forfait « contactez les ventes ».
Gratuit — 0 $ à vie : 500 rapports par mois et par projet, 1 Go de stockage, 3 projets, notifications par e-mail, le serveur MCP pour Claude Code et toute la capture (capture d'écran, relecture, console, réseau).
Pro — 4,99 $/mois : 10 000 rapports par mois et par projet, 10 Go de stockage, 20 projets, toutes les intégrations, les webhooks, et l'option pour retirer la marque BugDump du widget.
Ultra — 9,99 $/mois : 100 000 rapports par mois et par projet, 50 Go de stockage, 100 projets et les limites de requêtes les plus élevées, pour les produits à fort volume et les agences qui gèrent beaucoup de sites clients.
Les prix sont hors taxes ; Paddle, qui gère la facturation, ajoute les taxes dues au moment du paiement. Le forfait gratuit ne demande pas de carte bancaire : vous pouvez évaluer tout le parcours (widget, rapport, application) avant de payer quoi que ce soit.
Pour qui
BugDump est volontairement pensé pour les petites structures. Si vous avez un projet perso, un SaaS indépendant ou une petite équipe produit, vous n'avez sans doute pas envie de configurer un gros outil de suivi des tickets juste pour apprendre qu'un bouton ne marche plus. Une balise script et un tableau kanban, c'est tout le système.
Il convient aussi aux agences et aux équipes qui mènent des programmes bêta : les personnes non techniques qui signalent des bugs ne voient jamais de formulaire qui demande la « version du navigateur » ou les « étapes pour reproduire ». Elles cliquent sur un bouton, écrivent une phrase, et le widget rassemble pour elles la moitié technique du rapport.
Par où commencer
Créez un compte gratuit, créez un projet et collez la balise script dans votre site. Le bouton apparaît immédiatement, et le premier rapport que vous vous envoyez est le moyen le plus rapide de voir à quoi ressembleront ceux de vos utilisateurs. Si vous voulez creuser, le SDK gère l'activation et la désactivation des fonctionnalités, des filtres contre le bruit des scripts tiers trop bavards, des traductions personnalisées et le pilotage par le code, mais la configuration par défaut est pensée pour être celle que la plupart des sites gardent.
Pour aller plus loin
Pourquoi j'ai créé BugDump – « ça ne marche pas » n'est pas un rapport de bug — l'histoire derrière le produit, et pourquoi un rapport doit arriver avec son contexte technique.
Anatomie d'un rapport de bug – ce que BugDump capture et pourquoi — chaque élément qu'un rapport BugDump contient, et la raison de sa présence.
Comment ajouter un bouton de signalement de bug à votre site — les étapes pour installer le widget sur votre site, de la balise script au premier rapport.