Toutes les agences connaissent cet e-mail. Objet : « problème site web ». Message : « le formulaire de la page contact ne marche pas sur mon ordinateur ». Expéditeur : le client, avec son assistant en copie, transféré deux fois. Pas de navigateur, pas d'URL à part « la page contact », pas d'erreur, et une capture d'écran d'un document Word qui contient une capture d'écran. Deux heures facturables plus tard, vous découvrez que c'était une extension du navigateur.
Les bugs signalés par les clients font partie du quotidien d'une agence : pendant le développement, pendant la recette et tout au long de chaque contrat de maintenance. C'est le canal par lequel ils arrivent qui décide s'ils coûtent quelques minutes ou des après-midi entiers.
Pourquoi l'e-mail est le pire canal possible
L'e-mail supprime tout le contexte technique dès la source. Le client décrit ce dont il se souvient, depuis un environnement que vous ne voyez pas, à propos d'une page que vous devez deviner. Et c'est là que les vrais coûts commencent :
La boucle de clarification. « Quel navigateur ? Vous pouvez m'envoyer le lien exact ? Sur quoi avez-vous cliqué en premier ? » Chaque aller-retour fait perdre une journée et entame un peu la bonne volonté du client.
Aucun état partagé. Le client ne sait pas si vous avez vu l'e-mail, si quelqu'un s'en occupe, ni pourquoi ce qu'il a signalé le mois dernier n'est toujours pas corrigé. Alors il relance, et les relances demandent aussi des réponses.
Aucune frontière entre les projets. Dix clients en maintenance, ce sont des rapports de bug de dix sites mélangés dans une seule boîte de réception, qu'il faut chacun aiguiller, recopier dans votre outil de suivi et suivre à la main.
Le schéma à retenir : on demande au client de faire le travail d'un ingénieur QA (observer, documenter, contextualiser), alors qu'il n'en a ni les moyens ni l'obligation. La solution, c'est d'arrêter de lui demander.
Le modèle du widget
Placez le mécanisme de signalement sur le site du client lui-même. Un petit bouton flottant sur chaque page : le client clique, écrit une phrase, entoure éventuellement le problème sur une capture d'écran, et envoie. L'outil capture tout le reste au même moment : l'URL de la page, le navigateur, l'OS, l'appareil, le viewport, les logs de la console avec les erreurs signalées, les requêtes réseau avec les échecs mis en évidence, et une relecture de session de ce qu'il a fait avant le rapport.
Avec BugDump, l'installation tient en une balise script par site :
<script src="https://bugdump.com/sdk/latest.js" async data-api-key="site-specific-key"></script>Les détails qui comptent pour une agence :
Un projet par site client. Chaque projet a sa clé, son tableau et son historique de rapports. Rien ne se mélange. Le forfait Ultra accepte jusqu'à 100 projets, précisément pour ce type d'usage.
Marque blanche. Sur les forfaits payants, la marque BugDump disparaît du widget : il fait partie du site que vous avez construit, ce n'est pas un module tiers greffé dessus.
Accordé au site. Le thème (clair, sombre, auto), l'icône du bouton, sa position et chaque texte de l'interface sont configurables, traduction complète comprise, pour les clients dont le site n'est pas en anglais.
Pendant la recette, invitez les rapports. Une bulle d'accroche à côté du bouton (« Un problème ? ») change les tours de relecture : au lieu d'un PDF de captures annotées, vous recevez des rapports structurés à traiter un par un.
Pour le client, tout se résume à voir le problème, cliquer, taper une phrase, et c'est fini. Pas de connexion, pas de formulaire, et plus jamais de « vous utilisez quel navigateur ? ».
Ce qui change de votre côté
Les rapports arrivent prêts à diagnostiquer. L'erreur de la console et la requête en échec sont dans le rapport. La fausse alerte due à une extension se révèle en quelques minutes, et pas après une reconstruction du site. Les « impossible à reproduire » disparaissent presque, parce que vous lisez la panne au lieu de la recréer.
Le tri devient un état visible. Les rapports de chaque projet arrivent sur un tableau kanban : nouveau, en cours, terminé. Quand le client appelle au sujet du problème de la semaine dernière, la réponse est sous vos yeux, pas au fond de la boîte de réception. Les rapports en double s'empilent sur la même tâche, ce qui sert aussi d'indicateur de gravité.
Les bugs rejoignent votre chaîne de production. Les intégrations transmettent les rapports là où votre équipe travaille déjà : Slack ou Discord pour être au courant, GitHub Issues, Jira ou Asana pour ceux qui deviennent des tickets. Pas d'étape de recopie, pas de bug perdu entre la boîte de réception et le backlog.
La première lecture peut être confiée à un assistant. Le serveur MCP de BugDump donne à Claude Code ou Cursor accès aux rapports d'un projet, contexte console, réseau et relecture compris. Pour un contrat de maintenance, « résume les rapports de cette semaine sur le site Meridian et signale tout ce qui ressemble à une régression » est une vraie requête du lundi matin.
Gérer la passation
Pour une agence, tout se joue sur des fins de projet propres. Deux pratiques :
Limitez l'accès par projet. Les clés sont propres à chaque projet : un prestataire qui aide sur le site d'un client ne voit que ce projet. Les clés MCP se renouvellent instantanément depuis les paramètres si quelqu'un quitte la mission.
Décidez clairement qui assure la maintenance. Si le client reprend le site, transférez-lui un projet à son nom ou retirez la balise lors de la passation. Un widget qui envoie des rapports vers un compte que personne ne surveille est pire que pas de widget du tout : fixez les attentes dans le contrat.
Ce que ça change pour les contrats de maintenance
Un widget de signalement de bugs améliore discrètement la rentabilité des contrats de maintenance. Le temps de diagnostic baisse, parce que le contexte arrive avec le rapport. Les échanges avec le client se réduisent, parce que l'état vit sur un tableau et non dans des fils de discussion. Et l'historique des rapports devient un livrable en soi : la trace de tout ce qui a été trouvé et corrigé, utile au moment du renouvellement comme une archive d'e-mails ne l'est jamais.
Les coûts sont faibles et prévisibles : une balise script par site, et une tarification au volume plutôt que par utilisateur. Toute votre équipe, et celle du client, peut suivre les rapports sans calcul de licences.
L'e-mail arrivera encore de temps en temps. Mais « cliquez simplement sur le bouton de bug de la page et envoyez » tient en une ligne, et le rapport qui revient est un rapport que vous pouvez vraiment corriger.
Pour aller plus loin
Signaler des bugs en QA et en recette avec des testeurs non techniques — comment organiser une recette pour que des testeurs non techniques envoient des rapports exploitables sans questions de suivi.
Comment ajouter un bouton de signalement de bug à votre site — trois façons d'installer le widget (balise script, paquet npm, initialisation par code) et les pièges à éviter.
Localiser un widget intégré : langue de la page ou du navigateur ? — l'ordre que j'ai retenu pour le widget de BugDump, pourquoi la page passe en premier et ce qui a cassé en route.