Le bug triage est le processus de confirmation, de qualification et d'affectation des défauts nouvellement rapportés, afin que les ressources de développement limitées aillent d'abord aux problèmes à plus fort impact. Un processus de triage efficace garantit deux choses : chaque défaut est examiné dans un délai fixe, et une fois examiné, son sort est tranché (corriger, planifier, rétrograder ou fermer).
Pourquoi le triage existe
Les équipes sans mécanisme de triage montrent généralement l'une de deux pathologies :
- Loi du plus fort : celui qui se plaint le plus fort est servi en premier ; P0 et P2 se retrouvent dans la même file ;
- Trou noir : les défauts se dispersent dans les chats, e-mails et retours verbaux, et une bonne part n'a jamais été « tranchée » par quiconque.
Le triage donne à tous les défauts une entrée unique et un point de décision : chaque élément entrant est vérifié sous 24 heures, reçoit une gravité et une priorité, et trouve son propriétaire.
Les rôles du triage
| Rôle |
Responsabilité |
| Facilitateur du triage (généralement le QA lead) |
Anime la réunion de triage, maintient la file à zéro, pousse les décisions |
| QA / testeurs |
Vérifient la reproductibilité, complètent les étapes de reproduction, qualification préliminaire |
| Responsable dev |
Évalue l'impact technique, estime le coût de correction, accepte les affectations |
| Product owner (PM/PO) |
Fixe la priorité métier, tranche les désaccords « corriger ou non » |
Les petites équipes peuvent faire porter les deux casquettes au QA lead — mais les deux perspectives, jugement technique et jugement métier, doivent être présentes.
Le flux de triage standard (5 étapes)
1. Ingérer et dédupliquer
Les rapports de tous les canaux (tests internes, utilisateurs bêta, retours en production) atterrissent dans le même registre et sont fusionnés après déduplication par « module + symptôme ». Des entrées dispersées sont la racine de l'échec du triage — le bug signalé dans le chat et celui signalé dans l'outil doivent finir dans une seule table.
2. Valider
- Reproduisible ? Suivre les étapes du rapport ;
- Non reproduit : noter les informations d'environnement et renvoyer au rapporteur pour complément — les équipes dont les rapports portent le contexte d'environnement ne butent presque jamais ici (voir plus bas) ;
- Pas un défaut (comportement attendu / question d'usage) : convertir en question support ou amélioration de documentation, fermer, et le dire au rapporteur.
3. Qualifier (Sévérité × Priorité)
La sévérité (vision technique) et la priorité (vision métier) sont deux dimensions ; ne pas les confondre :
| Priorité haute |
Priorité basse |
| Sévérité haute |
Corriger immédiatement (page d'accueil blanche) |
Corriger ce sprint (une fonction de queue plante, sans contournement, mais presque personne n'y arrive) |
| Sévérité basse |
Corriger vite (bouton de connexion décalé, touche tous les utilisateurs) |
Au backlog (une coquille dans un coin de page) |
L'erreur courante est d'assimiler « sévérité = priorité » : une pile de problèmes « pas techniquement fatals mais gênants pour le business » reste alors éternellement à la famine.
4. Affecter et planifier
- P0 : correctif d'urgence ou rollback le jour même, notifier tous les concernés ;
- P2/P3 : au Product Backlog, triés comme d'habitude.
5. Redescendre et fermer
Après la correction : demander au rapporteur (surtout les testeurs externes) de revérifier → vérification passée → fermer et enregistrer la catégorie de cause racine (pour les statistiques de rétrospective). Le retour de statut aux rapporteurs externes décide directement s'ils signaleront à nouveau.
Comment mener la réunion de triage
- Fréquence : les équipes à itération rapide se réunissent tous les jours, 15 à 30 minutes, nouveaux éléments seulement ; les rythmes plus lents, 2 à 3 fois par semaine ;
- Forme : parcourir le tableau du registre, 3 à 5 minutes par élément ; ce qui ne se tranche pas en 5 minutes part en « en attente » et se règle en tête-à-tête avant la fin du jour ;
- Discipline : la réunion décide, elle ne conçoit pas de solutions techniques ; nouveaux éléments seulement, on ne rediscute pas ce qui est déjà qualifié.
Le prérequis d'un triage rapide : des rapports qui portent leur contexte
La scène la plus gaspilleuse d'une réunion de triage : la QA lit un rapport — « l'utilisateur dit que le bouton ne fait rien » — et tout le monde demande : quelle page ? quel navigateur ? des erreurs Console ? tu peux recliquer ? Un rapport qui devrait prendre 2 minutes à qualifier devient un polar de 15 minutes.
La cause racine : un rapport sans contexte. Comparons :
| Information |
Rapport manuel (l'utilisateur raconte de mémoire) |
Rapport collecté automatiquement |
| Étapes de reproduction |
« J'ai cliqué sur ce bouton et rien ne s'est passé » |
Capture/enregistrement annoté montrant l'endroit et l'action |
| URL de la page |
Souvent absente ou mal mémorisée |
Jointe automatiquement |
| Navigateur/appareil |
Généralement absente |
Jointe automatiquement |
| Erreurs Console / Network |
Quasi impossible |
Stack traces ERROR et requêtes en échec jointes |
La colonne de droite n'est pas de la fiction — c'est exactement ainsi que fonctionne BugCapturer : quand des utilisateurs (y compris des bêta-testeurs totalement non techniques) envoient un retour, le rapport emporte automatiquement la capture/l'enregistrement annoté, l'URL, l'environnement navigateur et les erreurs Console/Network (voir la fonction diagnostic). En réunion de triage, on parcourt le registre, 2 minutes pour qualifier chaque élément ; la part de « non reproductible » à la validation chute nettement. Les rapports sont poussés automatiquement dans un canal Slack / Microsoft Teams pour un suivi unifié — la déduplication et les statistiques gagnent une source unique de vérité.
Indicateurs d'auto-contrôle de la qualité du triage
| Indicateur |
Valeur saine |
Signification |
| Première réponse à un rapport |
< 24 h |
De la soumission à la décision de triage |
| Stock « en attente » |
< 5 % |
Des attentes qui durent = critères de qualification flous |
| Taux de rapports en doublon |
en baisse |
Le registre et la déduplication fonctionnent |
| Nombre de P0 |
en baisse |
Persistant haut = l'activité qualité en amont manque |
| Taux de revérification par les rapporteurs |
élevé |
Satisfaction et fidélité des testeurs externes |
Ces indicateurs alimentent aussi la rétrospective de sprint — voir « Appuyer la rétrospective sur des données » dans le guide de la sprint retrospective.
FAQ
Q : Qu'est-ce que le defect triage ?
R : Le processus de décision pour les nouveaux défauts : valider, dédupliquer, qualifier (sévérité × priorité), affecter. Généralement exécuté en réunion de triage à cadence fixe, avec la QA, le dev et le produit réunis.
Q : Bug triage vs bug tracking — quelle différence ?
R : Le tracking est l'outillage et le mécanisme d'enregistrement et de suivi de l'état des défauts ; le triage est le processus qui prend une décision de traitement par défaut. Le registre, c'est le tracking ; le triage est la couche de décision qui tourne sur le registre.
Q : Une petite équipe a-t-elle besoin d'un processus de triage ?
R : Oui, mais minimal : pas de réunion ; le QA lead consacre 15 minutes fixes par jour à parcourir le registre, qualifier et affecter. Ce qui compte : chaque défaut a été explicitement décidé.
Q : Le rapporteur n'est pas technique — comment garantir des rapports utilisables ?
R : N'exigez rien de technique des rapporteurs ; collectez automatiquement. Des outils comme BugCapturer joignent URL, environnement et erreurs Console/Network à la soumission — même les rapports de non-techniciens peuvent être triés directement.
Q : Quand sévérité et priorité se contredisent, qui l'emporte ?
R : La priorité est l'ordre d'exécution final, tranché par le product owner en réunion de triage ; la sévérité est un input technique qui éclaire la décision, pas un substitut.