Le rapport attend dans votre outil de suivi. L'utilisateur a vu le bug se produire, et vous le croyez, mais sur votre machine tout fonctionne, et vous avez déjà perdu une heure à le prouver. Et maintenant ?
La plupart des équipes n'ont qu'un seul réflexe ici : étiqueter le ticket « impossible à reproduire » et le fermer. Ce réflexe vous coûte deux fois, sans bruit. Le bug reste en production, où vos prochains utilisateurs le trouveront. Et l'auteur du rapport apprend que signaler des bugs ne sert à rien, si bien que le rapport suivant, celui qui aurait contenu le détail décisif, n'est jamais envoyé.
Comprendre pourquoi un bug se reproduit chez eux et pas chez vous est une discipline à part entière : la différence se cache toujours quelque part dans l'état, le timing, l'environnement ou les données. Cet article traite de l'autre moitié du travail, le processus. Ce que vous faites concrètement du ticket, aujourd'hui, quand la reproduction a échoué.
Remplacer « fermé » par une vraie décision
Un rapport non reproductible a trois issues honnêtes, et « fermé » n'en fait pas partie :
Corrigé quand même : les preuves désignaient une cause que vous avez pu corriger sans jamais voir le bug en direct.
En attente, instrumenté : vous n'avez pas trouvé, alors vous avez tendu un piège pour la prochaine occurrence et vous êtes passé à autre chose.
En observation : le rapport est un point de données ; vous attendez délibérément le deuxième.
Chaque étape ci-dessous mène à l'une de ces trois issues. Le but du tri n'est pas de reproduire le bug, mais d'amener le ticket à une décision que vous pouvez défendre.
Étape 1 : exploiter à fond le rapport existant
Avant de toucher à un navigateur, tirez du rapport tout ce qu'il contient :
Recoupez l'horodatage. Alignez l'heure du rapport sur vos logs serveur et votre historique de déploiements. « Ça a cassé à 14 h 02 » à côté de « on a déployé à 13 h 58 » a résolu plus de mystères que n'importe quel débogueur.
Cherchez les rapports frères. Même page, même texte d'erreur, même endpoint, dans votre outil de suivi et dans votre monitoring d'erreurs. Un rapport qui a l'air unique est souvent le troisième du genre, sous trois titres différents.
Lisez le symptôme à l'envers. Si le bouton « n'a rien fait », listez ce qui peut avaler un clic : un état désactivé, un return prématuré, un rejet non géré. Chaque hypothèse suppose une condition dans laquelle l'utilisateur a pu se trouver. Vous ne reproduisez pas encore, vous dressez une liste de suspects.
Étape 2 : une heure chronométrée pour reproduire comme eux
Les tentatives de reproduction échouent parce que les développeurs reproduisent en restant eux-mêmes : session neuve, réseau rapide, compte admin, grand écran. Passez une heure, et une seule, à vous mettre délibérément à la place de l'auteur du rapport. Son navigateur et son type d'appareil, son viewport, une connexion bridée, un compte avec son rôle et son volume de données, sa séquence d'actions plutôt que celle qui paraît logique.
Si l'heure ne donne rien, arrêtez. C'est avec des chasses à la reproduction sans limite qu'un bug moyen dévore un sprint. La méthode continue dans tous les cas.
Étape 3 : poser une question à l'auteur, pas cinq
Un questionnaire finit abandonné ; une seule question précise obtient une réponse. Choisissez celle dont la réponse coupe votre liste de suspects en deux (« ça arrive encore après un rafraîchissement ? », « ça arrive toujours sur le même enregistrement ? ») et n'envoyez que celle-là.
Encore une règle : demandez des faits, jamais du travail. « Quel navigateur ? » est un fait que les utilisateurs ne savent pas donner de façon fiable et qu'un outil capture automatiquement ; le demander, c'est dépenser la bonne volonté de l'auteur pour une chose qu'une balise script aurait dû faire.
Étape 4 : mettre en attente correctement
Mettre en attente n'est pas fermer. Un ticket mis en attente correctement contient trois choses :
Les preuves jointes : tout ce qui vient de l'étape 1, plus les hypothèses que vous avez éliminées, pour que personne ne refasse la même heure le mois prochain.
Un piège tendu : ajoutez la ligne de log, le breadcrumb, l'assertion qui se déclenchera quand ça recommencera. Si votre outil de signalement capture la sortie de la console, un
console.errorbien placé dans le chemin suspect transforme le prochain rapport en diagnostic.Un déclencheur de réouverture : le ticket se rouvre quand un rapport frère arrive, au lieu de compter sur quelqu'un qui se souviendrait de son existence.
Étape 5 : voir dans le deuxième rapport la percée de l'enquête
Les bugs non reproductibles reviennent : c'est la seule chose fiable à leur sujet. Et le deuxième rapport change la donne : un rapport est une anecdote, deux font une comparaison, cinq forment un jeu de données. Demandez-vous ce que les occurrences ont en commun (le navigateur ? le rôle ? un enregistrement précis ? l'heure de la journée ?) et ce qui les distingue. Les variables communes sont votre cause ; le reste est du bruit.
C'est pour ça que les rapports en double doivent s'empiler sur une seule tâche au lieu d'être fermés comme doublons : sur ce type de bug précisément, la pile est l'analyse. C'est aussi là qu'un assistant IA aide vraiment : connecté à vos rapports par le serveur MCP de BugDump, Claude Code ou Cursor parcourt tous les rapports d'une tâche et fait ressortir le point commun plus vite qu'une personne qui visionne cinq relectures de session.
Tenir l'auteur au courant
Deux phrases, à deux moments : quand vous mettez le ticket en attente (« nous n'avons pas encore trouvé la cause, nous avons ajouté une surveillance et gardé votre rapport ouvert ») et quand il est corrigé (« votre rapport de mars nous a permis de résoudre le problème, merci »). La première préserve la relation ; la seconde est l'investissement le moins cher qui soit dans une culture du signalement. Les gens qui voient que leurs rapports comptent en envoient de meilleurs.
Réparer le circuit, pas seulement le bug
Tout ce que cette méthode contourne (l'environnement manquant, la séquence manquante, les erreurs manquantes) existait dans le navigateur de l'auteur au moment de la panne. Ça n'a simplement pas été capturé. La solution durable est là : un rapport envoyé via BugDump arrive avec le buffer de la console (erreurs signalées), les requêtes réseau récentes (échecs mis en évidence), le navigateur, l'OS, l'appareil, le viewport, l'URL de la page et une relecture de session de ce que l'utilisateur a réellement fait. Ajoutez un appel à identify, et vous savez quel compte inspecter au lieu d'en deviner un qui lui ressemble.
Avec ce circuit en place, l'essentiel de cette méthode devient inutile : l'étape 1 est déjà faite, l'étape 2 part de faits, la question de l'étape 3 a généralement déjà sa réponse. « Impossible à reproduire » ne disparaît pas complètement, mais cesse d'être une résolution et devient ce qu'il aurait toujours dû être : un état rare et temporaire entre un rapport et un correctif.
Pour aller plus loin
Ça marche chez moi – guide pratique des bugs non reproductibles — les huit différences entre deux machines qui expliquent un bug non reproductible, et l'empreinte que laisse chacune.
De 40 rapports à 6 bugs – comment le tri devrait fonctionner — pourquoi séparer les rapports des tâches, et pourquoi les doublons sont un atout pour déboguer.
La relecture de session pour voir ce que l'utilisateur a fait avant le bug — comment fonctionne la relecture de session, ce qu'elle capture et pourquoi l'associer aux logs console et réseau.