Le MCP BugHerd est un connecteur qui expose les tickets BugHerd à un agent IA via le protocole MCP (Model Context Protocol). En clair, un développeur ou une équipe support peut demander à Claude (ou Cursor, ou Claude Desktop) de récupérer un ticket, son screenshot, son sélecteur CSS, l'URL et le navigateur du reporter, puis de qualifier le problème, proposer un fix, ou enchaîner sur un autre outil. C'est l'un des cas d'usage les plus concrets d'agent IA supervisé en agence WordPress aujourd'hui, et chez WPHelp247 on l'a intégré à notre workflow de recette depuis quelques semaines.

Pourquoi BugHerd colle au workflow WordPress

BugHerd est un outil de QA visuel. Le client (ou le testeur) clique sur n'importe quel élément d'une page WordPress en préprod, ajoute un commentaire (« le bouton est trop à droite », « le formulaire n'envoie pas l'email »), et BugHerd capture automatiquement le sélecteur CSS, l'URL, le navigateur, l'OS et un screenshot annoté. Pour la recette d'un site WordPress avant mise en prod, ou pour le triage de bugs visuels en run, c'est l'outil le plus efficace qu'on ait trouvé. Aucun reporter n'a besoin de connaître HTML, CSS ou DevTools : il clique, il commente, le ticket est créé.

Avant le MCP : un workflow qui consommait trop de temps

Avant l'arrivée du MCP BugHerd (fin 2024), le triage d'un ticket prenait classiquement 5 à 15 minutes selon la complexité. Le détail :

  1. Le client crée un ticket dans BugHerd.
  2. Notre équipe se connecte à BugHerd, lit le ticket, ouvre le sélecteur CSS dans une console DevTools, va voir le code source du thème WordPress dans un éditeur séparé.
  3. On rédige une réponse, on copie-colle entre BugHerd, le code et les notes internes, on bricole un fix dans un autre onglet.
  4. Retour BugHerd pour mettre à jour le statut, taguer la résolution.

Sur un projet de recette avec 30 à 50 tickets en quelques jours, le coût agrégé devient significatif. Et la qualité du triage dépend fortement de la fraîcheur cognitive de la personne qui le fait : à la trentième relecture de tickets cosmétiques entre 18 h et 20 h, on rate des choses.

Avec le MCP BugHerd : ce qu'on a gagné

Le MCP expose les opérations BugHerd via une API standardisée que Claude peut appeler directement, sans copier-coller ni switch d'onglets. Les tools les plus utilisés chez nous :

  • list_my_tasks, list_project_tasks, list_all_tasks : lister les tickets selon le contexte
  • get_task_details : récupérer le détail d'un ticket (screenshot, sélecteur CSS, URL, navigateur, OS, commentaires)
  • update_task : changer le statut, la priorité, la description
  • add_comment : ajouter un commentaire de diagnostic ou de résolution
  • update_task_assignees et update_task_tags : organiser les tickets par responsable et catégorie
  • prepare_attachment_upload et update_task_attachments : pour les médias associés au ticket

Le workflow est devenu plus direct. On demande à Claude (via Claude Code en CLI, Cursor pour le code, ou Claude Desktop pour le triage) : « récupère les tickets BugHerd non assignés du projet X, qualifie-les par criticité et propose un plan d'action ». Claude appelle list_project_tasks puis get_task_details en cascade, lit le code WordPress concerné via un autre MCP (filesystem ou git), et propose une analyse structurée. On valide humainement, on déclenche le fix, on marque le ticket comme résolu via update_task avec un commentaire explicatif posté via add_comment.

Gain mesuré chez nous sur les tickets simples (alignement CSS, copywriting, contraste, espace) : 3 à 5 minutes au lieu de 10 à 15. Sur les tickets complexes (formulaire JS, comportement de cache, requête lente), le gain est plus modeste mais le diagnostic est plus standardisé : un agent IA produit un rapport structuré (URL concernée, hypothèses de cause, fichiers à inspecter) qui sert de base à la revue humaine.

Cas d'usage 1 : recette d'un site en refonte

Sur un projet de refonte WordPress récent, le client a déposé 14 tickets BugHerd en 48 heures pendant la phase de recette. Sans MCP, ça aurait pris une demi-journée à triage. Avec MCP, la séquence ressemble à ça :

  • 3 minutes : Claude liste les 14 tickets, les regroupe par composant (header, footer, formulaire, layout, copywriting), et indique la criticité présumée.
  • 10 minutes : on revoit la liste à l'écran, on ré-arbitre les priorités (critique / cosmétique / nice-to-have), on retire les faux positifs.
  • 30 minutes : on enchaîne les fix simples (CSS layout, copywriting, alignements) directement depuis Claude Code en lisant les screenshots et en éditant les fichiers thème.
  • 1 heure : on traite les bugs plus complexes en revue manuelle (formulaire, comportement JS, problèmes de cache).

Au total, environ deux heures au lieu d'une demi-journée, pour un résultat équivalent ou meilleur (parce que la trace de raisonnement est meilleure : chaque décision est commentée dans le ticket BugHerd).

Cas d'usage 2 : triage des bugs en prod côté WPHelp247

Sur les sites sous bundle WPHelp247, un bug visuel signalé par le client final atterrit dans BugHerd s'il est lié à un changement visuel (régression suite à mise à jour, problème d'affichage mobile, élément qui disparaît). Le matin, on demande à Claude de faire le triage des tickets de la nuit. Il classifie par sévérité (régression bloquante vs cosmétique), suggère un coupable probable (plugin récemment mis à jour, modif de thème, problème de cache CDN), et propose un plan de réparation. La décision finale et l'application du fix restent humaines, mais la phase de qualification descend de 20 minutes à 5 par lot de tickets.

Garde-fous : pourquoi l'humain reste dans la boucle

Le MCP BugHerd donne à l'agent IA un accès en lecture et en écriture sur les tickets BugHerd. C'est puissant, et c'est aussi pourquoi on a des règles internes strictes :

  • L'agent ne ferme jamais un ticket de manière autonome — il propose un statut, un humain valide avant l'update_task.
  • Aucun ticket de criticité critique ou bloquante n'est traité sans revue manuelle complète du diagnostic IA.
  • Les commentaires postés via add_comment sont relus par un humain quand ils concernent un client externe (vocabulaire, ton, factualité).
  • Les opérations sur d'autres MCP (filesystem, git, WP-CLI) déclenchées en réaction à un ticket BugHerd nécessitent une revue de plan préalable.

Cette discipline ralentit un peu (10 à 15 % du temps gagné est repris en validation), mais elle évite les dérives classiques d'un agent qui croit comprendre un contexte alors qu'il lui manque un signal. Pour le détail de notre approche MCP au sens large (pas juste BugHerd), voir notre page MCP WordPress chez WPCraft, qui explique comment on combine plusieurs MCP avec des garde-fous d'accès.

Limites actuelles du MCP BugHerd

Pour rester honnête, voici ce qui nous manque ou ce qu'on aimerait voir évoluer :

  • Les vidéos d'écran capturées par BugHerd Pro côté client ne sont pas encore exposées via le MCP. Or beaucoup de bugs comportementaux sont mieux décrits par une vidéo qu'un screenshot.
  • Les annotations multi-éléments sur un même screenshot ne sont pas toujours bien parsées dans le contexte texte transmis à l'agent.
  • Pas de webhook MCP en temps réel : on interroge BugHerd à intervalles réguliers, mais on aimerait que BugHerd notifie l'agent quand un nouveau ticket arrive.
  • Les filtres avancés (par tag, par priorité, par fenêtre temporelle) sont possibles mais pas toujours bien documentés dans le schéma MCP.
  • La pagination des grandes listes de tickets est encore manuelle ; sur un projet à 200 tickets, l'agent doit faire plusieurs appels successifs.

Aucune de ces limites n'est bloquante. Toutes sont logiques pour un produit lancé fin 2024 et qui itère vite. Elles seront probablement adressées au fil des versions, et l'équipe BugHerd vient justement de nous solliciter pour comprendre comment on utilise le MCP au quotidien, ce qui est un signe d'écoute produit rare dans l'écosystème SaaS.

Et la suite

Notre prochaine étape côté outillage : un agent qui prépare un rapport quotidien de tickets BugHerd, croisé avec les logs serveur et le monitoring WPHelp247, pour ressortir les corrélations utiles (par exemple « les 4 tickets cosmétiques de ce matin sur Safari iOS correspondent à la mise à jour du plugin de cache de la nuit »). On y travaille, on partagera quand ce sera utilisable.

Si vous lancez un projet WordPress avec une phase de recette à industrialiser, notre studio sœur WPCraft propose un cadrage refonte qui intègre BugHerd + MCP par défaut depuis 2026. Pour un suivi régulier des bugs en prod sur un site déjà en ligne, voir nos bundles WPHelp247 qui combinent hébergement et heures de maintenance, ou un pack d'heures pour intervention ponctuelle.