Une liste de bugs connus indique aux testeurs ce que tu sais déjà, pour qu'ils consacrent leur temps aux choses que tu ne connais pas. Elle réduit les signalements en double et précise quels problèmes sont acceptés pour ce build et lesquels ne le sont pas.
Modèle à copier-coller
BUGS CONNUS : [Nom de l'app], build [version / numéro de build], [date]
Déjà connus, inutile de les signaler :
1. [Titre court] - [où ça arrive]. Contournement : [contournement ou « aucun »]. Statut : [corrigé dans le build X / accepté pour l'instant].
2. ...
Pas encore prêt, merci de passer :
- [Écran ou fonctionnalité] - [une ligne sur la raison]
Signale quand même :
- Tout ce qui plante ou fait perdre des données, même dans un domaine listé plus haut.
- Un bug connu qui se comporte autrement que décrit ici.
Comment signaler : [lien ou canal]. Indique l'appareil, la version d'OS et les étapes.
Exemple (fictif)
BUGS CONNUS : Pocket Budget, build 0.9.3 (42), 2026-10-17
Déjà connus, inutile de les signaler :
1. Mode sombre : les libellés des graphiques sont difficiles à lire sur l'écran Stats. Contournement : utilise le mode clair. Statut : corrigé dans le prochain build.
2. L'export CSV est lent au-delà de quelques centaines d'entrées. Contournement : aucun. Statut : accepté pour l'instant.
Pas encore prêt, merci de passer :
- Réglages > Sauvegarde - pas encore branché
Signale quand même :
- Tout ce qui plante ou fait perdre des données, même dans un domaine listé plus haut.
- Un bug connu qui se comporte autrement que décrit ici.
Comment signaler : réponds à ce message. Indique l'appareil, la version d'OS et les étapes.
Comment l'adapter
- Reste court. Si la liste dépasse une dizaine d'éléments, les testeurs arrêtent de la lire. Retire les points corrigés à chaque build.
- Indique le build. Une liste sans numéro de build est fausse une version plus tard.
- Décris les symptômes, pas les causes. Les testeurs reconnaissent ce qu'ils voient, pas tes noms de tickets internes.
- Garde les lignes « à signaler quand même ». Sinon les testeurs pensent qu'un domaine listé est hors limites, et tu rates de nouveaux plantages à cet endroit.
- Ne cache pas les problèmes graves. Un bug connu de perte de données doit figurer dans la liste, avec un avertissement, pas être passé sous silence.
- Utilise-la avec le build. Envoie la liste dans le même message que le build, et mets-la en lien dans tes notes de version.
Liens associés : checklist go / no-go de mise en production, checklist de hotfix, et le hub checklists de test d'apps mobiles.
Tu veux des testeurs qui signalent de façon structurée ? Commencer gratuitement.