Le tri des bugs, c'est le travail entre « un rapport est arrivé » et « quelqu'un le corrige ». La plupart des équipes ne sont pas lentes sur la décision elle-même. Elles sont lentes sur tout ce qui l'entoure.
Regardez une passe ordinaire. Ouvrir un rapport. Le lire. Revenir à la liste. Retrouver sa place. Ouvrir le suivant. Revenir encore. Chaque décision prend quelques secondes ; la navigation prend le reste des dix minutes. Pire, chaque aller-retour est un petit changement de contexte, et à force, le tri devient la corvée qu'on repousse jusqu'à ce que le backlog soit illisible.
Voici une méthode qui supprime la navigation au lieu de demander à qui que ce soit de réfléchir plus vite.
Ce qu'est vraiment le tri des bugs
Le tri pose trois questions à chaque rapport entrant :
Est-ce nouveau ? Ou bien le quarantième rapport d'un problème qui a déjà sa tâche.
Est-ce réel ? Reproductible, ou étayé par des preuves assez solides pour agir.
À quel point est-ce urgent ? Par rapport à tout ce qui est ouvert en ce moment, pas dans l'absolu.
Tout le reste (assigner, étiqueter, écrire les étapes de reproduction, faire venir la personne responsable de cette partie du code) découle de ces trois réponses. Une session de tri qui produit des réponses fonctionne. Celle qui produit une liste plus longue de choses à regarder plus tard ne fonctionne pas.
Le vrai coût, c'est l'aller-retour
Un rapport ne vaut la peine d'être lu que dans son contexte : la description, les erreurs de console autour, la requête en échec, le navigateur et le viewport, ce sur quoi l'utilisateur a cliqué dans les secondes avant que ça casse. Ce contexte se trouve sur une vue détaillée.
La boucle devient donc liste, détail, liste, détail. Chaque saut recharge une page, perd votre position de défilement et oublie sur quel élément vous étiez. Dix rapports, c'est vingt navigations, et au sixième vous avez arrêté de lire attentivement.
La solution n'est pas une page plus rapide. C'est de ne pas quitter la liste du tout.
Traiter une colonne à la fois
Avant d'ouvrir quoi que ce soit, réduisez le tableau à une seule file. Dans BugDump, cela veut dire filtrer sur une priorité, un navigateur ou une recherche textuelle, puis traiter une seule colonne de haut en bas.
Deux choses se produisent alors. La file a une fin précise, et c'est ce qui permet de terminer une session au lieu de la laisser ouverte. Et chaque tâche est comparable à la précédente, si bien que la priorité relative n'est plus une devinette : vous ne pesez plus en même temps un bug critique du paiement et une faute de frappe dans un texte.
Une colonne, c'est aussi la façon dont l'œil lit déjà un tableau. Travailler en travers des colonnes oblige à se réorienter sans arrêt.
Avancer pas à pas au lieu de naviguer
Ouvrez la première carte. Au lieu d'une nouvelle page, la tâche s'ouvre dans un panneau à côté du tableau : description, chaque rapport joint avec ses logs de console et réseau, commentaires, et les contrôles de statut, d'assigné et de priorité.
Puis lâchez la souris. J passe à la tâche suivante de la colonne. K revient en arrière. Lire, définir la priorité, assigner, déplacer, appuyer sur J. Le tableau ne se recharge jamais et ne perd jamais sa place : la boucle se réduit à une touche entre deux décisions.
Deux détails comptent plus qu'il n'y paraît :
Le pas à pas reste dans la colonne de départ. Il s'arrête aux extrémités au lieu de boucler ou de déborder sur la colonne suivante : finir une colonne devient un vrai événement, pas quelque chose qu'on remarque trois tâches plus tard.
Le pas à pas suit les filtres. Filtrez sur les bugs critiques, et « Tâche suivante » ne visite que des bugs critiques. La file que vous avez définie est celle que vous parcourez.
Les raccourcis s'effacent aussi pendant la saisie : un j dans un commentaire reste un j dans un commentaire.
Traiter par lots les décisions déjà évidentes
Une partie du tri ne demande aucune lecture. Un mauvais déploiement produit trente rapports de la même panne. Une vague de spam en produit vingt qui ne contiennent rien.
Ne les parcourez pas un par un. Sélectionnez les cartes directement sur le tableau (Cmd ou Ctrl + clic pour les choisir une à une, Maj + clic pour une plage) et déplacez ou supprimez toute la sélection d'un coup.
La règle empirique : si vous connaissez déjà la réponse avant d'ouvrir la tâche, elle va dans un lot. Le pas à pas est pour les rapports qui demandent du jugement, et l'intérêt des lots est que ceux-là reçoivent votre attention, pas ce qu'il en reste.
Regrouper d'abord les doublons est l'habitude la plus rentable du tri. Elle transforme régulièrement quarante éléments de la boîte de réception en six vraies tâches, et tout ce qui suit coûte moins cher. Le guide du workflow de tri décrit la routine quotidienne complète.
Passer la main avec un lien, pas une description
Le tri se termine quand le travail passe à quelqu'un d'autre, et c'est là que le temps gagné s'échappe d'habitude. Retaper un bug dans Slack (un demi-résumé, une repro approximative, une capture) prend plus de temps que le tri lui-même et en dit moins que le rapport que vous aviez sous les yeux.
Copiez plutôt le lien de la tâche. Un seul lien porte la description, chaque rapport joint, la sortie console, l'activité réseau, l'environnement et la discussion jusque-là. La personne qui le reçoit obtient ce que vous avez vu, pas votre souvenir de ce que vous avez vu.
Si votre équipe débogue avec un assistant IA, le même ID public suffit à passer la main : pointez Claude Code vers la tâche via MCP et il lit directement les rapports, les logs et les traces au lieu qu'on les lui raconte.
À quelle fréquence faire une passe
Dix à quinze minutes, une fois par jour. Deux ou trois fois par jour pendant une semaine de release.
La régularité compte plus que la durée. Le retard de tri s'accumule d'une façon précise : plus un rapport est vieux, plus il est difficile à reproduire, plus il est probable que la personne qui l'a signalé soit partie, et plus il est probable qu'il fasse doublon avec un rapport arrivé depuis. Un backlog que vous laissez de côté une semaine n'est plus le même une semaine plus tard : il est pire.
Les erreurs qui méritent d'être nommées
Trier dans l'ordre de la boîte de réception. L'ordre d'arrivée n'est pas l'ordre d'importance. Filtrez d'abord, puis traitez une file.
Tout lire avant de décider quoi que ce soit. Une passe où rien ne change de colonne n'a pas eu lieu.
Une colonne « Besoin d'infos ». Elle devient l'endroit où les tâches vont se faire oublier. Soit vous posez tout de suite la question à la personne qui a signalé le bug, soit vous fermez la tâche.
Tout est critique. Un backlog où chaque tâche est urgente contient exactement autant d'information qu'un backlog où aucune ne l'est.
Ne jamais rien fermer. L'erreur de tri la plus courante n'est pas une mauvaise priorisation, c'est un nombre de tâches ouvertes qui ne fait que grossir jusqu'à ce que le tableau ne décrive plus la réalité.
Essayez sur votre propre tableau
Si vous utilisez déjà BugDump, ce flux est disponible dès maintenant : filtrez le tableau, cliquez sur la première carte, et utilisez J et K pour parcourir la colonne. Voir Travailler avec les tâches et le tableau pour le reste des contrôles du panneau.
Pour aller plus loin
Comment rédiger un bon rapport de bug (avec checklist) — les détails qui manquent à la plupart des rapports de bug, et la checklist pour ne plus les oublier.
De 40 rapports à 6 bugs – comment le tri devrait fonctionner — regrouper les doublons pour que quarante rapports redeviennent les six bugs qu'ils sont vraiment.
Les métriques de suivi des bugs qui comptent vraiment — quatre chiffres qui disent si votre équipe suit le rythme, et une revue hebdomadaire de cinq minutes.