Classification des retours : bugs, demandes et questions
Classez les retours en Signalement de bug, Demande de fonction, Compliment ou Question. Distinguez une promesse non tenue d’un nouveau besoin.
L’aperçu gratuit est limité. Connectez-vous pour utiliser vos crédits et conserver un historique.
Votre prochaine décision commence ici.
Ajoutez un contexte ci-dessus ou commencez avec un exemple.
Classer le constat avant de fixer sa priorité
Les retours arrivent par le support, les entretiens et les messages dans le produit. Une même phrase peut décrire une capacité manquante ou une fonction promise qui échoue. Une définition cohérente du produit permet de les distinguer. Cet outil propose une catégorie, pas une décision de feuille de route. Conservez la source et la version du produit pour séparer les signalements répétés d’un incident des demandes indépendantes de nouvelle fonction.
Examiner des cas concrets
Exemples de saisie et pistes de vérification, sans résultats de modèle enregistrés. Lancez votre propre contexte pour examiner une décision.
Une confirmation manquante
Je clique sur Enregistrer et rien ne se passe. Il faudrait un message indiquant si cela a fonctionné.
Vérifiez si les données ont été enregistrées. Si l’action documentée échoue, examinez un Signalement de bug. Si l’enregistrement réussit mais qu’aucune confirmation n’a jamais été prévue, il peut s’agir d’une Demande de fonction. Le texte seul ne permet pas de reconstituer une promesse produit inconnue.
Un compliment apparent autour d’un échec
Génial, le tableau de bord a encore planté juste avant ma présentation.
Le mot « génial » ne suffit pas à classer ce retour comme Compliment. Le fait concret est un plantage récurrent. Gardez l’action et la version concernées, et incluez l’ironie dans vos cas d’évaluation au lieu de laisser les seuls mots de sentiment définir la catégorie.
Une question qui peut révéler un défaut
Comment exporter un PDF ? L’aide indique un bouton d’export, mais je ne le trouve pas.
La personne pose une Question, mais l’écart avec l’aide peut venir d’un bug, d’une permission ou d’une documentation dépassée. Ajoutez la formule et la disponibilité documentée si elles sont pertinentes. Gardez la question liée à l’enquête si les deux nécessitent une réponse.
Définir les frontières avant de classer
Ces règles proposent un cadre de vérification. Ajoutez les règles de votre équipe à la question ou au contexte lors de la décision.
| Choix | Quand l’utiliser | Limite à vérifier |
|---|---|---|
| Signalement de bug | Le comportement observé contredit une fonction prise en charge et documentée. | Une attente non promise ne suffit pas à établir un défaut. |
| Demande de fonction | Demande d’une nouvelle capacité ou d’un changement de comportement. | « J’aimerais que cela marche » peut décrire une fonction existante en panne. |
| Compliment | Évaluation favorable sans problème ni demande principale non résolue. | Des mots positifs peuvent être ironiques ou accompagner une plainte. |
| Question | Demande d’information sur l’utilisation ou la compréhension du produit. | Une question peut révéler un bug nécessitant un suivi lié. |
Les situations à examiner de près
Compter un incident comme de nombreuses nouvelles demandes
Gardez la version, le parcours concerné et la source. Repérez les doublons avant de comparer les volumes : une panne unique peut sinon donner une importance trompeuse à une catégorie.
Perdre la nuance entre les langues
Les retours multilingues, l’ironie et les abréviations locales nécessitent des exemples relus séparément. Si vous ajoutez une traduction, conservez l’original ; l’intention peut être modifiée par la reformulation.
Vérifier les catégories avant de croire la tendance
Pour les rapports, examinez un échantillon de chaque catégorie et les paires souvent confondues. Une confusion systématique entre bugs et demandes peut fausser la planification malgré le faible coût apparent d’une erreur isolée. Faites relire les cas incertains plutôt que d’imposer un seuil bas universel.
Séparez la gravité, les clients concernés et la valeur stratégique du score de classification. Un défaut d’accessibilité rare peut être plus important qu’une demande esthétique fréquente. Les volumes décrivent les retours reçus, ils ne décident pas de la feuille de route.
Un exemple d’API Jev pour votre prochaine intégration
Appelez l’API REST iajev avec cURL. Recevez un choix, des probabilités et un niveau de confiance en JSON.
curl https://iajev.com/api/v1/decisions/run \
-H 'Authorization: Bearer YOUR_API_KEY' \
-H 'Idempotency-Key: YOUR_UNIQUE_REQUEST_ID' \
-H 'Content-Type: application/json' \
--data '{
"state": {
"message": "Il serait utile de pouvoir exporter mes rapports hebdomadaires en PDF et les partager avec mon équipe."
},
"decision": {
"type": "choice",
"question": "De quel type de retour client s’agit-il ?",
"choices": [
"Signalement de bug",
"Demande de fonction",
"Compliment",
"Question"
]
}
}'Questions sur cet outil
Un message peut-il avoir deux catégories ?
Oui, même si cet outil retourne un seul choix. Séparez les observations indépendantes si votre processus exige deux catégories. Conservez leur source commune pour ne pas compter une question et son bug associé comme deux clients distincts.
Faut-il classer les retours anonymes séparément ?
Utilisez les mêmes définitions. Notez la provenance séparément pour repérer les doublons ou assurer le suivi. Connaître l’identité ne devrait pas changer la catégorie d’un même problème produit.
Utiliser iajev
Ajouter le contexte
Conservez les faits nécessaires à cette décision.
Vérifier les choix
Adaptez la question et les options à votre processus.
Lancer et vérifier
Examinez la distribution avant d’agir.
La confiance indique-t-elle la probabilité d’une bonne décision ?
Non. La confiance est une estimation distincte du modèle ; les probabilités décrivent la distribution entre vos choix. Aucun de ces indicateurs ne garantit une exactitude mesurée.
Puis-je comparer deux saisies ?
Modifiez le contexte et relancez la même question pour comparer les probabilités. Changer la question ou les choix démarre une nouvelle comparaison.