Un nom d’entreprise mal orthographié sur la page d’accueil et un crash dans une fonctionnalité d’export rarement utilisée : que corrigez-vous en premier ? Des arguments comme celui-ci expliquent pourquoi les équipes de test séparent gravité et priorité. L’un décrit le dommage technique et l’autre décrit l’urgence commerciale.

Sans cette distinction, chaque bug est étiqueté « critique », les étiquettes perdent leur sens et les développeurs cessent de leur faire confiance. Ce guide vous donne des définitions et des exemples clairs, ainsi qu’un processus simple pour prendre ces décisions. Les exemples sont illustratifs et les échelles exactes diffèrent selon les équipes et les outils.

La réponse courte

Réponses Gravité : dans quelle mesure ce bug affecte-t-il le produit ? Un crash ou une perte de données est grave, alors qu’un problème esthétique ne l’est pas.

Réponses prioritaires : dans combien de temps devons-nous résoudre ce problème ? Cela dépend des clients concernés, des délais, des revenus, de l’exposition juridique et de la réputation de la marque.

Pensez à un hôpital. La gravité correspond à la gravité de l’état du patient. La priorité est l’ordre dans lequel les patients sont traités, qui dépend également d’autres facteurs, tels que ceux qui peuvent attendre en toute sécurité et quelles ressources sont disponibles.

Gravité et priorité côte à côte

Niveaux de gravité

La plupart des équipes utilisent environ quatre ou cinq niveaux. Voici une échelle commune :

Niveaux de priorité

Notez ce que chaque niveau signifie pour votre équipe, idéalement avec un temps de réponse cible pour chacun. “P1 signifie que quelqu’un commence dans l’heure” est bien plus utile que “P1 signifie très important”.

Les quatre combinaisons, avec exemples

La façon la plus claire de comprendre cela est d’examiner chaque combinaison :

Gravité élevée, priorité élevée

Le paiement échoue pour tout le monde, l’entreprise perd de l’argent de minute en minute et il n’existe aucune solution de contournement. C’est le cas évident : laissez tout tomber et réparez-le.

Gravité élevée, priorité faible

L’application plante lors de l’exportation vers un format existant. Techniquement, c’est un sérieux échec. Mais si seulement une infime partie des utilisateurs touchent à cette fonctionnalité et qu’un format moderne fonctionne correctement, il peut attendre une sortie programmée.

Faible gravité, haute priorité

Le nom de l’entreprise est mal orthographié sur la page d’accueil. Rien n’est cassé et aucune donnée n’est en danger. Pourtant, chaque visiteur le voit, cela nuit à la confiance, et si un lancement majeur est prévu demain, il doit être réparé aujourd’hui.

Faible gravité, faible priorité

Une petite faute de frappe dans un article d’aide rarement consulté. Réparez-le quand cela vous convient. Si votre carnet de commandes en est rempli, envisagez de les regrouper en une seule tâche de nettoyage.

Un bug, deux priorités différentes

Un même défaut peut mériter des priorités différentes selon le contexte. Supposons qu’un e-mail de confirmation de commande soit envoyé avec le mauvais logo.

La gravité n’a pas changé, car l’impact sur le système est le même. Mais la situation des affaires l’a fait. Le temps peut aussi changer les choses. Un bug qui est P3 aujourd’hui peut devenir P1 la semaine précédant la mise en service d’un client majeur.

Qui décide de la gravité et de la priorité ?

• Les testeurs proposent généralement la gravité, car ils ont vu le comportement et comprennent l’impact sur le système.
• Les propriétaires ou gestionnaires de produits décident généralement des priorités, en tenant compte des clients, des revenus et de la feuille de route.
• Les développeurs ajoutent des informations sur la cause, le risque d’un correctif et le temps que cela prendra.
• Les équipes d’assistance apportent des preuves du nombre de clients concernés et de leur gravité.

Les sources et les équipes varient en fonction de ces responsabilités, et dans une petite startup, une seule personne peut tout faire. Ce qui compte, c’est que tout le monde sache qui prend la décision finale, afin que les désaccords se terminent par une décision.

Comment évaluer un bug

En cas de doute, répondez à ces questions.

Pour la gravité :

1. Perd-il ou corrompt-il des données, ou expose-t-il des informations privées ?
2. Est-ce que cela empêche une fonction principale de fonctionner ?
3. Existe-t-il une solution de contournement et un utilisateur normal pourrait-il la trouver ?
4. Dans quelle mesure la fonctionnalité est-elle affectée ?

En priorité :

1. Combien d’utilisateurs sont concernés et lesquels ?
2. Est-ce que cela coûte de l’argent ou crée un risque juridique ou de conformité ?
3. Une sortie, une démo ou une vente est à venir ?
4. Dans quelle mesure est-il visible et cela pourrait-il nuire à votre réputation ?
5. Est-ce que cela bloque d’autres travaux, comme les tests ?

Exécution du tri des bogues

Le triage est la réunion régulière au cours de laquelle une équipe examine les nouveaux bugs et décide de la suite des événements. Un format simple fonctionne bien :

1. Préparer. Le testeur s’assure que chaque nouveau bug comporte des étapes, des preuves et une gravité proposées claires.
2. Confirmer. Vérifiez qu’il est reproductible et qu’il ne s’agit pas d’un doublon.
3. Décidez. Convenez de la gravité, définissez une priorité et attribuez un propriétaire.
4. Bouclez la boucle. Rejetez, reportez ou planifiez chaque bug et enregistrez la raison.

Soyez bref et fréquent. Au cours des derniers jours précédant une sortie, un tri quotidien de 15 minutes est courant. La gravité et la priorité influencent également votre décision de publication, alors convenez dès le départ de règles, telles que “pas de bogues S1 ou S2 ouverts à la sortie”, dans le cadre de vos critères de sortie.

Gravité et priorité dans un rapport de bug

Une entrée courte et claire aide chacun à prendre une bonne décision :

Title:    Checkout returns error 500 when a coupon is applied
Severity: S1 - blocks purchase, no workaround
Priority: P1 proposed - sale starts Friday
Build:    2.14.0, production
Reach:    All customers using a coupon (around 30% of orders)
Steps:    1. Add an item  2. Apply SAVE10  3. Click Pay
Result:   Error 500 and no order is created
Expected: Order is created with the discount applied

Ces chiffres sont des exemples. Dans un rapport réel, utilisez les chiffres mesurés à partir de vos journaux et expliquez votre raisonnement. Apprenez-en davantage dans notre guide sur comment rédiger un rapport de bug. Il est également utile de connaître la signification des codes d’erreur, alors gardez notre aide-mémoire des codes d’état HTTP à portée de main.

Erreurs courantes

• Les traiter comme le même champ. Si les deux correspondent toujours, vous perdez des informations utiles.
• Gonfler la sévérité pour attirer l’attention. Une fois que tout est critique, rien ne l’est.
• Laisser les testeurs définir seuls les priorités. Ils ont rarement une vision complète de l’entreprise.
• Ne jamais examiner l’arriéré. Les priorités deviennent obsolètes, alors revérifiez régulièrement les anciens bugs.
• Pas de définitions écrites. Sans elles, les gens appliquent les étiquettes différemment et vous finissez par débattre des mots.
• Ignorer les empilements de faible gravité. Cinquante problèmes mineurs peuvent donner l’impression qu’un produit est cassé, même si aucun n’est grave à lui seul.

Pour conclure

Séparez les deux questions : à quel point la situation est-elle grave et dans combien de temps faut-il y remédier ? Convenez de définitions écrites pour chaque niveau et indiquez clairement qui décide. Dans l’étape suivante, prenez les dix bugs les plus anciens de votre tracker et réévaluez-les à l’aide des questions ci-dessus. Vous en trouverez probablement quelques-uns qui devraient bouger et quelques-uns qui devraient être fermés.

Questions fréquentes

Continuez à apprendre