Dans ce guide
Deux mots sont sans cesse confondus. La gravité mesure à quel point le bug est mauvais pour l'utilisateur : ce qui casse. La priorité mesure à quelle vitesse tu le corriges : une décision qui dépend aussi du nombre de personnes touchées, de la facilité du contournement et de ta date de release. Un développeur solo a besoin des deux définies une fois pour toutes, pour qu'un même bug reçoive la même note le lundi et le vendredi.
Définitions de gravité (à copier et adapter)
S1 Critique L'app plante, des données sont perdues ou corrompues, un paiement
est mal facturé, ou un parcours clé ne peut pas être terminé.
Aucun contournement.
S2 Majeure Une fonction clé est cassée ou très difficile à utiliser, mais
un contournement existe.
S3 Mineure Une fonction secondaire se comporte mal, ou une fonction clé dans
un cas limite.
S4 Triviale Cosmétique : coquille, désalignement, petit défaut visuel.
Portée (combien de personnes sont touchées)
Beaucoup La plupart des utilisateurs, ou tous, sur un appareil / OS / parcours courant
Certains Un groupe clairement défini (une famille d'appareils, une langue, un type de compte)
Peu Conditions rares, ou un seul cas signalé
La matrice
Priorité selon la gravité (lignes) et la portée (colonnes) :
| Beaucoup | Certains | Peu | |
|---|---|---|---|
| S1 Critique | P0 : corriger tout de suite, bloquer la release | P0 : corriger tout de suite | P1 : corriger avant la release |
| S2 Majeure | P1 : corriger avant la release | P1 : corriger avant la release | P2 : release suivante |
| S3 Mineure | P2 : release suivante | P2 ou P3 | P3 : backlog |
| S4 Triviale | P3 : backlog | P3 : backlog | P3 : backlog, ou fermer |
Signification des priorités : P0 tout lâcher. P1 doit être corrigé avant la sortie de cette release. P2 à planifier pour la release suivante. P3 backlog, à corriger quand on passe à côté.
Modèle pour noter un bug (à copier-coller)
BUG : <titre>
Gravité : S<1-4> Portée : <beaucoup / certains / peu> Priorité : P<0-3>
Contournement : <oui : décrire / non>
Pourquoi cette note : <une phrase>
Décision : <corriger tout de suite / avant la release / release suivante / backlog> Date : <date>
Exemple (illustratif)
BUG : L'app plante à l'enregistrement avec un titre vide
Gravité : S1 Portée : Certains (seulement les utilisateurs qui sautent le champ titre) Priorité : P0
Contournement : saisir un titre
Pourquoi cette note : Crash avec perte de données sur l'action principale d'enregistrement ; un contournement ne supprime pas le crash.
Décision : corriger tout de suite Date : 2026-11-05
Comment l'adapter
- Dérogue avec une raison. Les règles valent pour les 90 pour cent ; note pourquoi tu en as enfreint une.
- Relève la priorité pour les risques hors matrice : problèmes de sécurité ou de confidentialité, erreurs de paiement, et tout ce qui pourrait enfreindre les règles des stores ne doit pas attendre. Vérifie les politiques en vigueur pour ce dernier point.
- Utilise des données réelles quand tu en as. Les rapports de crash montrent la portée ; voir [comment prioriser les rapports de crash et [comment prioriser les retours sur l'app.
- Quatre niveaux maximum. Plus de niveaux, c'est plus de discussions et pas de meilleures décisions.
- Dis aux testeurs ce que tu entends, pour que leurs estimations de gravité collent aux tiennes ; la décision finale reste la tienne.
Liens
- Hub : Hub des checklists de test d'app mobile
- [Liste des problèmes connus pour testeurs
- [Checklist go / no-go de release
Commencer gratuitement pour recueillir les rapports de bug de façon structurée, puis les noter avec cette matrice.