Pourquoi le titre compte plus que le reste du rapport
Un bon titre de bug = où c'est arrivé + ce que vous avez fait + ce qui a mal tourné + la condition de déclenchement. Si ces quatre éléments tiennent en une ligne, un développeur peut reproduire le problème sans vous poser de question. C'est toute la différence entre un bon et un mauvais titre. Vous trouverez ci-dessous 40 exemples en vis-à-vis, répartis sur sept scénarios — connexion, inscription, paiement, mobile, API, performance et interface — pour réécrire vos propres bugs.
Les développeurs lisent d'abord le titre, systématiquement. Un titre vague signifie soit une question supplémentaire, soit un ticket ignoré. Pire : un mauvais titre ne sera jamais sauvé par un bloc d'environnement bien rempli — personne n'ouvre un ticket intitulé « bouton cassé ».
Un titre réussit ou échoue sur quatre points : est-il précis (nomme le composant ou la page), est-il observable (des faits, pas « ça ne marche pas »), porte-t-il des conditions (navigateur, appareil, type de compte, moment) et permet-il de juger la portée (panne totale ou cas limite) ?
La formule de titre en 4 parties
[Composant/Page] + [Action] + [Résultat inattendu] + [Condition]
Comment remplir chaque bloc :
- Composant : page de paiement / modale de connexion / liste des commandes /
POST /api/orders - Action : cliquer, envoyer, téléverser, changer d'onglet, scanner
- Résultat inattendu : aucune réaction, 500 renvoyée, montant avec un chiffre en trop, statut non synchronisé, texte qui se chevauche
- Condition : Chrome 120, iOS 17.2, largeur <390px, comptes entreprise uniquement, après un timeout réseau
Sentence case, composant en premier, pas de mention de priorité. C'est la convention que la plupart des équipes adoptent — et la cohérence importe plus que le choix de la convention.
1. Connexion et comptes (7 exemples)
| Titre faible | Titre fort |
|---|---|
| Le bouton de connexion ne marche pas | Un clic sur « Se connecter » dans Chrome 120 ne déclenche rien ; la console renvoie TypeError: login is not a function |
| L'e-mail de réinitialisation n'arrive pas | Aucun e-mail de réinitialisation après un clic sur « Mot de passe oublié » avec une adresse Gmail (spam vérifié après 30 minutes) |
| Mauvaise redirection après connexion | Un utilisateur standard arrive sur /admin au lieu de /dashboard après connexion ; reproductible depuis la v5.3 |
| Le captcha échoue en boucle | Un captcha valide est refusé avec « Code invalide » — uniquement en fenêtre de navigation privée |
| Le compte se verrouille | Trois mots de passe erronés verrouillent définitivement le compte, alors que le message indique « réessayez dans 24 heures » |
| La session n'est pas invalidée | La connexion sur un second appareil n'invalide pas la première session, qui reste pleinement utilisable |
| La connexion SSO échoue | Le callback SSO renvoie « Invalid signature » depuis la rotation du certificat de l'IdP |
À retenir : sur les bugs de connexion, la condition (navigateur, type de compte, navigation privée) décide si quelqu'un peut reproduire. Ne l'omettez jamais.
2. Inscription et formulaires (7 exemples)
| Titre faible | Titre fort |
|---|---|
| Impossible de s'inscrire | L'inscription refuse les adresses contenant « + » (ex. user+test@x.com) avec « Format d'e-mail invalide » |
| La validation du téléphone ne marche pas | Un numéro complet à 11 chiffres déclenche encore « Saisissez un numéro à 11 chiffres » |
| L'indicateur de robustesse est faux | Un mot de passe de 8 caractères contenant déjà des chiffres affiche encore « doit contenir un chiffre » |
| La liste déroulante ne répond pas | La liste « Pays » ne peut plus être sélectionnée au clavier après un filtrage de 3 caractères |
| Le formulaire s'envoie deux fois | Appuyer sur Entrée dans le formulaire d'inscription envoie deux fois et crée deux comptes en double |
| Champ obligatoire non contrôlé | L'inscription aboutit sans cocher « J'accepte les conditions » et le compte est créé malgré tout |
| Mauvais fuseau horaire par défaut | Le fuseau est défini sur UTC+0 par défaut ; les utilisateurs en UTC+8 doivent le corriger à chaque inscription |
À retenir : remplacez la description par des valeurs d'entrée concrètes. Une vraie chaîne de caractères vaut dix phrases du type « la saisie ne marche pas ».
3. Paiement et commande (7 exemples)
| Titre faible | Titre fort |
|---|---|
| Le paiement échoue | Un total de 129,99 € s'affiche en 1 299,99 € au moment du paiement (un chiffre en trop) ; la page de paiement reprend le mauvais montant |
| Le code promo ne fonctionne pas | Un code expiré s'affiche encore comme « valide » ; son application renvoie une 500 et vide le panier |
| Le compteur du panier ne se met pas à jour | Le badge du panier en en-tête affiche encore « 1 » après suppression du dernier article, jusqu'au rechargement de la page |
| Double débit | Un nouvel essai de paiement après un timeout réseau débite deux fois la même commande (commande n° 10231) |
| Les informations de facturation ne sont pas enregistrées | Les informations de facturation de l'entreprise sont effacées après un retour en arrière puis un retour au paiement |
| Statut de remboursement désynchronisé | La commande affiche encore « Payée » côté client alors que le remboursement a été exécuté (commande n° 10388) |
| Moyen de paiement manquant | L'option carte bancaire est absente au paiement — uniquement pour les comptes sur l'ancien modèle de facturation |
À retenir : dès qu'il s'agit d'argent ou de numéro de commande, mettez le numéro dans le titre. Le temps de triage est divisé par deux.
4. Mobile et responsive (6 exemples)
| Titre faible | Titre fort |
|---|---|
| La mise en page casse sur mobile | Le bouton « Ajouter au panier » chevauche le prix sur iPhone 14 (iOS 17.2) en dessous de 390px de large |
| La page ne défile plus | L'ouverture d'une modale bloque le défilement sur mobile ; il reste bloqué après la fermeture |
| Le champ est masqué par le clavier | Le clavier d'Android Chrome masque le bouton « Envoyer », qui devient impossible à toucher |
| Mise en page paysage cassée | La barre de navigation passe à la ligne sur iPad en paysage (1024×768) et le logo chevauche le menu |
| Les images ne se chargent pas | L'image principale du produit est absente sur Safari iOS 16 ; la console renvoie 403 (signature CDN expirée) |
| Cible tactile trop petite | Les boutons de pagination sur mobile ont une cible de 12×12px, sous le minimum d'accessibilité de 44px |
À retenir : sur mobile, « mobile » n'est pas une condition. Indiquez le modèle exact, la version d'OS et la largeur de viewport.
5. Données, API et permissions (6 exemples)
| Titre faible | Titre fort |
|---|---|
| L'export échoue | L'export de plus de 10 000 commandes renvoie une 504 ; un export par lots fonctionne |
| Horodatages erronés | Les horodatages du rapport accusent 8 heures de retard — uniquement pour les utilisateurs du fuseau Asia/Shanghai |
| La recherche ne renvoie rien | La recherche « iPhone » renvoie 0 résultat alors que 12 enregistrements correspondants existent en base |
| Lignes dupliquées en paginant | La liste des commandes répète les 3 dernières lignes de la page 1 en tête de la page 2 |
| Erreur de téléversement | Un PNG de plus de 5 Mo renvoie 413, mais l'interface affiche « Téléversement terminé » avec un fichier vide |
| Élévation de privilèges | Un rôle en lecture seule peut appeler DELETE /api/projects/12 et supprimer un projet avec succès |
À retenir : pour les bugs d'API, mettez le code HTTP, le chemin d'endpoint ou le seuil dans le titre. C'est la moitié du travail de débogage fait d'avance.
6. Performance et chargement (3 exemples)
| Titre faible | Titre fort |
|---|---|
| La page est lente | Le LCP de la page d'accueil est de 8,2s en 4G, à cause de 2,1 Mo de JavaScript non compressé |
| Fuite mémoire | La mémoire passe de 120 Mo à 900 Mo après 20 changements d'onglet, puis l'onglet plante |
| L'API est lente | Le P95 de l'endpoint de liste produits est de 4,8s (base 300ms) — uniquement en pic de soldes |
À retenir : un bug de performance exige un chiffre et une base de référence, sinon personne ne peut juger s'il s'agit d'un défaut.
7. Textes et détails d'interface (4 exemples)
| Titre faible | Titre fort |
|---|---|
| Faute de frappe sur la page | « Parametres » doit s'écrire « Paramètres » sur la page de confirmation de commande |
| Icônes incohérentes | Deux des quatre icônes de la page de réglages sont en style linéaire, deux en style plein |
| Mode sombre illisible | En mode sombre, le texte de saisie est en #333 sur fond sombre, donc quasiment invisible |
| Message d'erreur inutile | Un téléversement échoué affiche seulement « Opération échouée », sans cause ni indication de nouvelle tentative |
À retenir : pour les bugs de texte et d'interface, écrivez « ce qui est affiché → ce qui devrait l'être ». C'est le coût de relecture le plus faible de tous les types de bugs.
7 habitudes qui dégradent les titres
Comment rédiger selon votre rôle
| Rôle | Méthode |
|---|---|
| QA / testeur | Formule complète en 4 parties, toutes les conditions (navigateur, appareil, compte, réseau) |
| Support ou ops qui escalade | Symptôme visible côté utilisateur + chemin reproductible + capture d'écran ; omettez la cause si elle est inconnue et notez « en attente de validation technique » |
| Relecteur UAT | Ancrez sur le critère d'acceptation : « Échoue au critère AC-3 : statut de commande non mis à jour en 5 secondes » |
| Chef de produit | Décrivez l'impact visible pour prioriser, sans remplacer le symptôme technique |
Quand un titre est traduit
| Titre en langue d'origine | Titre français |
|---|---|
| 结算页删除最后一件商品后购物车角标未更新 | Le compteur du panier n'est pas mis à jour après suppression du dernier article au paiement |
| Android Chrome 键盘遮挡提交按钮，无法点击 | Android Chrome : le clavier masque le bouton Envoyer, impossible de le toucher |
| 只读角色可删除项目（越权） | Un rôle en lecture seule peut supprimer des projets (élévation de privilèges) |
Trois règles lorsqu'un titre change de langue : conservez les noms de composants dans leur langue d'origine s'il s'agit de noms propres, traduisez littéralement le résultat observable, et ne traduisez jamais les messages de log ni les codes d'erreur. Une stack trace traduite est un bug impossible à reproduire.
FAQ
Quelle longueur pour un titre de bug ? Environ 60 caractères ou 10 mots au maximum, pour qu'il ne soit pas tronqué dans les listes. S'il ne tient pas, soit le symptôme principal n'est pas isolé, soit il s'agit de deux bugs.
Faut-il mettre la priorité ou la gravité dans le titre ? Non. La priorité est un champ à part qui évolue avec la planification. Une fois modifiée, le titre devient faux — et il pollue la recherche.
Puis-je écrire une hypothèse dans le titre si je ne connais pas la cause ? « Probablement causé par X » est acceptable, mais jamais comme conclusion. Justifiez-la dans le corps du ticket, sinon vous orientez mal le triage.
Un bug présent sur plusieurs navigateurs : plusieurs tickets ? Le titre porte le symptôme principal, les différences d'environnement vont dans le champ environnement ou notes. Ne séparez que si les chemins de correction diffèrent réellement, par exemple des chemins iOS et Android distincts.
Title Case ou sentence case ? Les deux fonctionnent, mais restez cohérent avec votre backlog existant. Sans historique, le sentence case se lit mieux et se parcourt plus vite.
Le titre reste à vous, le reste peut être automatique
Soyons clairs : BugCapturer n'écrit pas votre titre — cela demande votre jugement sur ce que vous avez observé. En revanche, les champs fastidieux et faciles à oublier peuvent se remplir seuls :
- Contexte technique automatique : URL, navigateur, système d'exploitation, résolution d'écran et taille de viewport sont capturés, donc les conditions du titre n'ont plus à être recopiées à la main.
- Données de diagnostic : les logs console de niveau erreur et les requêtes réseau en échec (HTTP ≥ 400) sont collectés, avec anonymisation automatique des paramètres sensibles (jetons, mots de passe, clés d'API).
- Captures annotées : sélectionnez la zone au glisser-déposer et ajoutez flèches, cadres et texte, pour fixer « où c'est faux » dans l'image.
- Enregistrement d'écran : capturez l'onglet courant et découpez le clip, pour transmettre aux développeurs une vidéo de 12 secondes qu'ils peuvent vérifier.
- Partage ou synchronisation en un clic : générez un lien de partage que des collaborateurs externes ouvrent sans inscription, ou poussez le rapport vers Feishu Bitable ou un webhook générique.
Ainsi, vous n'avez que cette seule ligne de titre à réussir, et l'outil remplit le reste.
Checklist à télécharger
Collez-la près de votre écran et vérifiez avant d'envoyer :
- Le composant ou la page est-il nommé ?
- Un fait observable remplace-t-il « ça ne marche pas » ?
- Le titre contient-il des conditions (navigateur / appareil / compte / réseau / largeur) ?
- Contient-il un chiffre vérifiable (code de statut, numéro de commande, montant, durée, seuil) ?
- Décrit-il exactement un seul symptôme ?
- La priorité et toute hypothèse non vérifiée sont-elles retirées ?
- Reste-t-il sous 60 caractères ou 10 mots environ ?
Les sept points validés, vos titres passeront avant 90 % du backlog.
Pour aller plus loin : modèle de rapport de bug (liste complète des champs et modèle à copier) · signaler les bugs efficacement · modèle de cas de test avec exemples · Format de rapport de bug · Rédiger les étapes de reproduction