Un bug est le mot courant pour un défaut ; un defect est le terme formel désignant tout écart où le logiciel ne satisfait pas à son exigence. Un issue est le terme parapluie qui couvre défauts, demandes de fonctionnalité, tâches et questions. En pratique, ils décrivent la même chose à des degrés de cérémonie différents — et c'est le mélange dans une même équipe qui crée la confusion. Les différences comptent moins en conversation qu'à trois endroits : ce que vous mesurez, ce que vous promettez par contrat, et ce que vous demandez à une personne qui signale. Cette page propose une séparation défendable, à mettre dans un glossaire pour arrêter d'en débattre.
La réponse courte
| Terme | Périmètre | Où on le voit |
|---|---|---|
| Bug | Mot courant pour défaut. Souvent quelque chose qui fonctionnait avant ou qui devrait clairement fonctionner | Mêlées, chat, « il y a un bug sur le paiement » |
| Defect | Terme formel : tout écart entre comportement réel et attendu, que cela ait déjà fonctionné ou non | Rapports QA, audits, contrats, métriques |
| Issue | Terme parapluie : tout ce qui exige une décision — défaut, demande, tâche, question | Trackers, identifiants de tickets, notes de version |
| Error | Une action humaine produisant un résultat incorrect | Analyse de cause racine, post-mortems |
| Fault | L'instruction ou la donnée erronée dans le logiciel qui provoque la défaillance | Discussion d'ingénierie, normes |
| Failure | L'événement observable : le système ne fait pas ce qu'il doit | Revues d'incident, supervision |
La chaîne : error, fault, failure
Le modèle classique, toujours utilisé dans les normes et utile en post-mortem :Pourquoi « issue » est le meilleur mot pour votre tracker
Un tracker contient plus que des défauts. Nommez l'objet issue — en gardant « bug » comme mot du quotidien — et vous obtenez un seul endroit pour :- les défauts (le comportement est faux),
- les demandes de fonctionnalité (le comportement manque volontairement),
- les tâches (du travail sans comportement associé),
- les questions (aucune modification de code attendue).
Là où la distinction rapporte de l'argent
1. Contrats et SLA. Un accord qui promet « défauts critiques corrigés en 24 heures » exige une définition écrite de défaut et de critique. Sans elle, chaque discussion devient une négociation. « Bug » dans un contrat est généralement trop vague pour être opposable. 2. Métriques. Densité de défauts, taux d'évasion et taux de réouverture n'ont de sens que si la population est stable. Si la moitié de vos « bugs » sont des demandes, aucun chiffre ne tient. 3. Audit et conformité. Les produits réglementés exigent souvent un dossier de défaut traçable avec sévérité, vérification et preuve de clôture. C'est un artefact formel — le mot défaut signale cette formalité.Bug ou demande de fonctionnalité ?
La frontière qui génère le plus de débats :| C'est un défaut si… | C'est une demande si… |
|---|---|
| Le comportement contredit une exigence écrite ou le design documenté | Aucune exigence n'existe et le comportement n'a jamais été promis |
| Les utilisateurs ne peuvent plus accomplir une tâche qu'ils accomplissaient | Ils peuvent l'accomplir, simplement pas comme ils préféreraient |
| L'état du système devient incohérent ou des données sont perdues | Le système est cohérent, la sortie n'est simplement pas souhaitée |
| Cela touche l'accessibilité, la sécurité ou l'intégrité des données | C'est une préférence de mise en page, de texte ou de parcours |
Bug ou « error » (le message à l'écran)
Un message d'erreur affiché n'est pas un défaut en soi. « Format d'e-mail invalide » est un comportement correct. Le défaut, c'est le cas où le message est faux, absent, ou affiché à tort. Et l'error de « Console error » désigne une exception journalisée par le runtime, qui peut être un défaut ou non (beaucoup d'erreurs journalisées sont attendues et gérées). C'est pourquoi un rapport doit joindre la sortie Console en texte plutôt qu'une capture : qui trie a besoin du texte, de la pile et de la fréquence, pas d'une image.Choisir un vocabulaire et l'écrire
La recommandation avec laquelle la plupart des équipes vivent :- Issue est l'objet dans le tracker. Tous les types vivent dessous.
- Defect est le type « comportement incorrect » et le mot des métriques, contrats et rapports.
- Bug reste le mot parlé. À bannir des tableaux de bord.
- Error / Fault / Failure uniquement en analyse de cause racine, dans cet ordre.
Ce que cela change pour le rapport
Quel que soit le nom, les champs dont la personne qui trie a besoin sont identiques :- la page ou l'endpoint exact,
- ce qui a été fait, l'attendu et le constaté,
- les preuves : capture, erreurs Console, requêtes en échec,
- l'environnement : navigateur, OS, viewport, horodatage.