Voici un workflow qui était normal jusqu'à récemment.
Un rapport de bug arrive. Vous ouvrez le tableau de bord, vous le lisez, vous trouvez l'erreur de console, vous la copiez. Vous passez dans votre éditeur, vous la collez dans Claude Code, vous ajoutez un peu de contexte. L'agent demande ce que la requête a renvoyé. Retour au tableau de bord : vous trouvez le journal réseau, copiez la réponse, la collez. Et ainsi de suite.
Vous êtes un presse-papiers. L'agent raisonne, et vous transportez les données entre deux systèmes qui pourraient se parler directement.
Alors je les ai fait se parler.
Le serveur MCP
BugDump fournit un serveur Model Context Protocol. Connectez-le à Claude Code, et l'agent lit directement vos rapports de bug. Sept outils :
Outil | Renvoie |
|---|---|
| Le projet auquel cette clé est liée |
| Les tâches, pour en trouver une |
| Une tâche, par identifiant public ou par ID de tâche |
| L'historique d'une tâche |
| Les rapports rattachés à une tâche |
| Un rapport : console, réseau, captures d'écran |
| Toute la télémétrie, page par page |
Tout le workflow se résume à une phrase :
Regarde la tâche #42 dans BugDump et corrige-la.
L'agent lit la tâche, récupère les rapports rattachés, relie l'erreur de console à la requête en échec, trouve le code correspondant dans votre dépôt et propose un correctif. Vous n'ouvrez jamais le tableau de bord.
Pourquoi c'est mieux que le copier-coller
L'avantage évident, c'est que vous cessez d'être un presse-papiers. Il y en a deux moins évidents.
L'agent pose de meilleures questions que vous. Quand vous copiez une stack trace, vous avez déjà décidé de ce qui est pertinent, et vous l'avez décidé avant de comprendre le bug. Un agent avec un accès direct peut suivre les preuves : lire la console, remarquer une requête en échec, parcourir le journal réseau pour trouver son corps complet, vérifier si d'autres rapports sur la même tâche montrent le même échec. Cela fait beaucoup de petites recherches. Chacune est triviale à servir et fastidieuse à faire à la main, et c'est précisément pour ça que personne ne les fait.
Il compare les rapports entre eux. Demandez quels navigateurs sont touchés par la tâche #17, et l'agent lit chaque rapport rattaché puis vous répond. C'est un travail vraiment fastidieux, celui que saute la personne qui trie, et celui qui révèle en dix secondes au lieu d'un après-midi qu'un bug est propre à un navigateur.
Les choix de conception
Deux choix ont façonné le fonctionnement.
Les clés sont liées à un seul projet, définitivement. Aucun outil n'a de paramètre de projet. Une clé MCP reçoit son périmètre à la création et ne peut pas être élargie ensuite. Quand vous confiez une clé à un agent autonome, « cette clé ne pourra jamais voir qu'un seul projet » est une garantie bien plus forte que « on a dit à l'agent de ne regarder qu'un seul projet ».
Les clés MCP sont aussi en lecture seule et distinctes des clés du widget. La clé de votre frontend ne peut pas lire les rapports ; la clé qui lit les rapports ne s'approche jamais d'un navigateur.
Un résumé par défaut, toute la télémétrie sur demande. get_report renvoie les 50 dernières entrées de console, sans les corps réseau. Un rapport peut contenir des milliers d'entrées, et tout déverser dans une fenêtre de contexte à chaque recherche, c'est le meilleur moyen d'obtenir un agent qui a tout lu et rien compris.
Mais une troncature qui se cache est pire que pas de troncature du tout. Le résumé indique donc ce qui a été coupé, et get_report_telemetry parcourt tout l'historique (console, réseau avec les corps, actions) par tranches chronologiques, jusqu'à ce qu'il ne reste rien.
La règle qui compte : un résumé qui ne montre rien ne prouve pas qu'il n'y a rien.
Des prompts qui marchent
Regarde la tâche #42 dans BugDump et corrige-la.
Qu'ont en commun les tâches ouvertes dans BugDump ?
Lis les rapports de la #17 et dis-moi quels navigateurs sont touchés.
Vérifie la tâche #8 : est-ce le même bug que la #3 ?
C'est la dernière que je préfère. Décider si deux rapports décrivent le même bug demande de comparer en détail deux ensembles de télémétrie : exactement le travail que tout le monde saute, et exactement celui qui évite les tâches en double sur votre tableau.
Plus largement
J'ai construit la couche de capture en premier, parce que le problème, c'étaient les rapports de bug incomplets. Le serveur MCP n'était pas prévu ; il s'est imposé après coup.
Un rapport complet (console, réseau, actions, relecture, environnement) s'avère être une entrée bien formée pour un agent. Et un agent ne peut pas poser de question complémentaire. Il ne peut pas écrire à un utilisateur pour lui demander quel navigateur il utilisait. Il n'a droit qu'à un seul essai avec les preuves dont il dispose.
Autrement dit, la discipline qui rend un rapport utile à un humain est celle qui le rend exploitable par une machine : tout capturer, au moment où ça se produit, sans rien demander.
Bien faire cette partie m'a apporté un bénéfice que je n'avais pas prévu.
Mise à jour, octobre 2026 : l'accès MCP est désormais inclus dans tous les forfaits, y compris Gratuit, et Claude, ChatGPT et VS Code se branchent par simple connexion. Voir Connecter Claude, ChatGPT ou VS Code à BugDump.
Pour aller plus loin
Ce que j'ai appris en créant un serveur MCP pour un outil de développement — sept décisions de conception qui font qu'un agent utilise bien les outils dès le premier essai.
Pourquoi les agents IA ont besoin de jetons personnels sur un serveur MCP — pourquoi une clé partagée ne suffit plus dès qu'un agent peut déplacer des tâches et écrire des commentaires.
Déboguer les rapports de bug avec Claude Code et le serveur MCP de BugDump — connecter le serveur MCP à Claude Code ou Cursor pour que l'assistant lise la console, le réseau et la relecture d'un bug.