La sévérité et la priorité sont deux dimensions distinctes d'un bug. La sévérité mesure à quel point le défaut endommage le système, tandis que la priorité mesure l'urgence avec laquelle il doit être corrigé par rapport au reste du travail.

Ce que signifie vraiment la sévérité

La sévérité mesure l'impact technique du bug. À quel point ce défaut endommage-t-il le système ? Perte de données, crash, flux de paiement cassé : haute sévérité. Un bouton légèrement décalé, une faute de frappe dans un tooltip : faible sévérité.

La sévérité appartient entièrement au domaine technique. Elle ne tient pas compte du calendrier de release, de la campagne marketing, ni du nombre de personnes qui verront le problème. Elle répond à une seule question : à quel point c'est cassé, objectivement ?

L'échelle classique à quatre niveaux utilisée par la plupart des équipes :

Critique : le bug rend quelque chose complètement non fonctionnel, corrompt des données, crée une vulnérabilité de sécurité, ou provoque un crash. L'utilisateur ne peut pas avancer. Il n'y a pas de contournement. Exemple : cliquer sur "Passer la commande" affiche un écran de succès, mais la commande n'est jamais enregistrée en base de données. Majeur : une fonctionnalité significative est cassée ou fortement dégradée. Un contournement existe, mais il est peu pratique ou pas évident. Exemple : l'export d'un rapport en CSV produit un fichier avec un encodage corrompu pour tout nom contenant un caractère non-ASCII. Mineur : la fonctionnalité fonctionne, mais quelque chose ne va pas d'une façon qui affecte l'expérience utilisateur sans bloquer la tâche. Exemple : l'e-mail de confirmation de réinitialisation de mot de passe dit "Votre mot de passe a été réinitialisé" avec une faute de frappe. Trivial : cosmétique, impact fonctionnel négligeable. Aucun utilisateur n'est bloqué. Exemple : l'année de copyright dans le pied de page affiche 2024 au lieu de 2026.

C'est vous, en tant que QA, qui définissez la sévérité. C'est votre jugement professionnel, et il doit être défendable sur la base de l'impact observable, pas de votre ressenti.

Ce que signifie vraiment la priorité

La priorité mesure l'urgence métier. À quelle vitesse ce bug doit-il être corrigé, par rapport à tout le reste dans le backlog ?

La priorité ne relève pas de vous seul. Un chef de produit, un responsable technique ou un product owner est généralement celui qui fixe la priorité. Cette décision nécessite une connaissance du calendrier de release, des engagements commerciaux et de la tolérance au risque que le QA n'a souvent pas pleinement en vue.

Cela dit, votre évaluation de sévérité influence directement leur décision de priorité. Si vous étiquetez mal la sévérité, vous injectez de mauvaises données dans une décision métier.

En pratique, les petites équipes brouillent ces frontières. Un QA lead peut fixer les deux sur un bug. C'est acceptable. L'essentiel est de garder le raisonnement séparé : "c'est techniquement grave pour ces raisons" versus "ça doit être livré vendredi pour ces raisons".

La matrice 2x2 : là où ça devient intéressant

Les cas évidents sont simples. Un crash sur le flux de paiement principal ? Haute sévérité, haute priorité, corrigez-le maintenant. Un pixel décalé sur une page d'administration que personne n'utilise ? Faible sévérité, faible priorité, ça peut attendre.

Les cas intéressants sont les deux coins que tout le monde rate.

Haute sévérité, faible priorité. Imaginez que vous testez une application d'entreprise avec une fonctionnalité d'import massif de données, utilisée par des administrateurs de base de données pour migrer des données legacy. Vous trouvez un bug : si le fichier d'import contient une colonne avec des valeurs null à une position spécifique, l'ensemble importé est corrompu.

C'est une sévérité Critique. La corruption de données est le pire qui puisse arriver.

Mais la fonctionnalité n'est utilisée qu'une fois lors de l'onboarding initial, par un unique utilisateur technique, toujours dans des conditions supervisées. Un contournement existe (retirer les valeurs null de cette colonne avant l'import). La prochaine release est dans un mois, et il y a cinq flux plus fréquentés avec des bugs actifs qui se disputent le temps des développeurs.

Priorité ? Moyenne, voire Faible pour ce sprint particulier.

La sévérité ne change pas. La corruption de données reste Critique. Mais la décision métier de la planifier après un bug Majeur dans le flux de checkout visible des utilisateurs est parfaitement rationnelle.

Faible sévérité, haute priorité. Votre entreprise vient de lancer un produit co-brandé avec un partenaire majeur. Sur la page d'accueil, le nom du partenaire est mal orthographié. Une lettre transposée.

Sévérité ? Triviale. Aucun utilisateur n'est bloqué. Aucune donnée n'est à risque. L'application fonctionne parfaitement.

Priorité ? Critique pour cette release. Les équipes légale, partenariat et marketing s'en préoccupent avant même que le chef de produit ait fini son café du matin. Ça passe en hotfix avant un bug Majeur dans un flux secondaire.

C'est le cas qui piège le plus souvent les QA juniors. Ils voient "Sévérité : Triviale" et supposent une faible priorité, puis sont déconcertés quand le bug est corrigé en deux heures pendant que leur bug Majeur reste intact.

Ne supposez jamais que la sévérité prédit la priorité. Ce sont des données indépendantes. Un bug Trivial peut être la priorité absolue de votre équipe cette semaine. Un bug Critique peut légitimement attendre jusqu'au prochain sprint.

Exemples concrets des quatre quadrants

Voici des scénarios concrets pour les quatre cases de la matrice.

Haute sévérité + Haute priorité : lors des tests de régression, vous découvrez que soumettre le formulaire de réinitialisation de mot de passe avec un e-mail valide retourne une erreur 500 et l'e-mail de réinitialisation n'est jamais envoyé. Les utilisateurs sont bloqués sans possibilité de récupérer leur accès. La livraison est lundi. Corrigez-le aujourd'hui. Haute sévérité + Faible priorité : l'export du journal d'audit de l'application, utilisé par les responsables conformité pour générer des rapports trimestriels, produit un fichier malformé si la plage de dates dépasse 18 mois. C'est réellement grave (risque d'intégrité des données), mais la prochaine fenêtre d'export est dans 10 semaines. Un contournement existe (lancer deux exports et les fusionner), et l'équipe conformité a été informée. Ça va dans le backlog du prochain sprint, pas de celui-ci. Faible sévérité + Haute priorité : trois semaines avant le lancement public de l'application, vous remarquez que la balise meta title de la page d'accueil affiche "Document sans titre". C'est un placeholder de template jamais mis à jour. Zéro impact fonctionnel. Mais il apparaîtra dans les résultats de recherche Google et les aperçus de partage social dès le jour du lancement. Le SEO, le marketing et le PDG s'en préoccupent. Corrigé cet après-midi. Faible sévérité + Faible priorité : le tooltip du panneau de filtres avancés dit "Cliquer pour ourvir" au lieu de "ouvrir". Il est là depuis six mois. Il sera corrigé lors d'une passe UI le trimestre prochain. Rien d'urgent ici.

Qui décide quoi, et pourquoi ça compte

La répartition des responsabilités mérite d'être formulée clairement.

Le QA fixe la sévérité. Vous avez observé le bug, testé l'impact, vous savez ce que le système est censé faire. Vous êtes le mieux placé pour juger à quel point quelque chose est techniquement cassé. Assumez ce jugement. Si un développeur conteste votre étiquette de sévérité, soyez prêt à expliquer votre raisonnement. Par exemple : "J'ai marqué ceci Critique parce que ça entraîne une perte de données dans le scénario affecté, ce qui, selon nos définitions de sévérité, le place dans ce tier."

Le product manager ou la direction fixe la priorité. Ils ont un contexte que vous n'avez pas : quels clients sont affectés, quels engagements existent, quelle est la pression concurrentielle, quelle est la capacité du sprint. Respectez que c'est leur décision.

Là où ça déraille : les QA qui mettent une Faible sévérité sur tout pour éviter le conflit, ou qui supposent que parce qu'ils ont trouvé un bug, il doit forcément être Critique. Ces deux schémas érodent la confiance. Une sévérité précise fait partie de votre production professionnelle : prenez-la au sérieux.

Comment défendre une priorité quand quelqu'un repousse

Vous avez logué un bug Majeur dans un flux utilisateur central. Le PM répond : "On regardera au prochain sprint." Vous pensez que ça doit partir cette semaine.

Comment défendre ce point : formulez l'argument en termes d'impact utilisateur et métier, pas d'orgueil technique.

Argument faible : "Mais c'est un bug Majeur, il doit être corrigé maintenant."

Argument solide : "Ce bug casse le flux d'export pour tout utilisateur avec plus de 500 éléments. Selon nos données utilisateurs, c'est environ 30 % des comptes actifs. Si on livre vendredi sans le corriger, on recevra des tickets de support. Je préfère le signaler maintenant plutôt que de gérer ça après la release."

Donnez au PM quelque chose à peser. Il fait un arbitrage de risques. Votre rôle est de mettre les bonnes informations sur la table, pas de prendre la décision finale. S'il entend l'argument métier et décide quand même de le reporter, c'est une décision produit légitime. Documentez que le bug était connu et trié, logguez-le, et passez à autre chose.

Quand vous rédigez un bug pour lequel vous pensez que la priorité devrait être plus haute qu'elle ne paraît, ajoutez une note "Impact métier" directement dans le ticket : "Affecte les utilisateurs qui [condition spécifique]. Estimation : [X % des utilisateurs actifs / segment spécifique] sont concernés." Cela expose les données dont le PM a besoin sans exiger une conversation séparée.

L'échelle à cinq niveaux vs l'échelle à quatre niveaux

Certaines équipes utilisent cinq niveaux de sévérité : Critique, Haute, Moyenne, Faible, Triviale. D'autres utilisent quatre (Critique, Majeure, Mineure, Triviale). Certaines utilisent trois (Haute, Moyenne, Faible).

L'échelle que vous utilisez compte moins que son application cohérente au sein de votre équipe. Le problème avec les grandes échelles n'est pas le nombre de niveaux. C'est que les équipes finissent par débattre si quelque chose est Haute ou Moyenne au lieu de trier les bugs. Si votre équipe passe 20 minutes à discuter si un bug est Mineur ou Trivial, l'échelle a plus de granularité que votre processus ne peut en supporter.

Pour la plupart des équipes, quatre niveaux fonctionnent bien. Cinq est approprié si vous avez une grande organisation QA où la sévérité alimente des minuteries SLA automatisées. Par exemple, les bugs Critiques doivent être pris en compte dans les 2 heures, les Hauts dans les 24 heures. Trois niveaux fonctionnent dans des équipes early-stage qui bougent vite et où la nuance est un luxe.

Choisissez une échelle, documentez ce que chaque niveau signifie avec des exemples concrets, et appliquez-la de façon cohérente. La cohérence compte plus que la précision.

Rédiger la sévérité dans un rapport de bug qui ne sera pas contesté

La raison pour laquelle la sévérité est discutée lors des réunions de triage est presque toujours la même : l'étiquette de sévérité est là, mais le raisonnement ne l'est pas.

"Sévérité : Critique" invite au débat. Ajouter que "cliquer sur Soumettre abandonne silencieusement la soumission du formulaire sans retour ; les utilisateurs croient que leur action a réussi, mais rien n'est sauvegardé" ne l'invite pas.

Rédigez la sévérité comme un bref verdict avec des preuves. Une ou deux phrases. Énoncez l'impact, expliquez pourquoi il tombe dans ce tier.

Voici le patron : [Niveau de sévérité] : [ce que le système fait de travers] [qui est affecté et comment] [pourquoi ce tier et pas un inférieur].

En pratique :

Mauvais : Sévérité : Majeure

Mieux : Sévérité : Majeure. Le flux de réinitialisation de mot de passe échoue pour tous les utilisateurs qui tentent de réinitialiser via un navigateur mobile. Les utilisateurs sont bloqués dans la récupération de compte sur mobile ; le desktop fonctionne encore, ce qui constitue le contournement.

Cette formulation fait trois choses : elle justifie l'étiquette par l'impact, elle délimite qui est affecté, et elle reconnaît ce qui en fait une Majeure plutôt qu'une Critique (un contournement existe). Quiconque lit le ticket comprend la décision de sévérité sans avoir à vous demander de l'expliquer.

Comment appliquer ça dès lundi matin

Quand vous loggez votre prochain bug, ralentissez sur les champs sévérité et priorité au lieu de cliquer sur la première option qui semble juste.

Demandez-vous : qu'est-ce qui se casse réellement ici, et pour qui ? Si un utilisateur tombe sur ce bug, peut-il accomplir son objectif d'une autre façon ? Cela affecte-t-il tous les utilisateurs ou un segment spécifique ? Cela corrompt-il des données ou gêne-t-il simplement quelqu'un ?

Cette réponse est votre sévérité. Rédigez une justification en une phrase à côté de l'étiquette.

Regardez ensuite le backlog. Qu'est-ce qui est livré ce sprint ? Qui est affecté par ce bug par rapport aux autres bugs en attente ? Rédigez une suggestion de priorité dans un commentaire, pas comme une exigence, mais comme une contribution : "Étant donné que ça affecte le flux de paiement central et que nous livrons vendredi, je suggère d'en faire une priorité de sprint."

Au fil du temps, cette pratique produit quelque chose de visible : vos décisions de triage cessent d'être remises en question. Les PMs arrêtent de modifier vos étiquettes. Les développeurs cessent de contester vos évaluations Critiques. Ce n'est pas de la chance. C'est parce que vous avez séparé deux concepts que la plupart des QA juniors confondent, et commencé à communiquer la distinction clairement.

C'est la compétence de triage qui se remarque.

→ See also: L'Anatomie d'un Rapport de Bug que les Développeurs Corrigent Vraiment | Comment Écrire un Cas de Test: Format, Exemples et Erreurs Courantes