Un utilisateur écrit : « ajoutez un bouton pour dupliquer un projet ». La fonction existe déjà, dans un menu contextuel, à deux clics de là où il la cherchait.
Ce n'est pas une demande de fonctionnalité. C'est un signalement de découvrabilité, formulé dans le vocabulaire de la solution plutôt que dans celui du problème.
Nuance importante, et il faut la poser d'emblée : toutes les demandes ne sont pas des problèmes déguisés. Beaucoup décrivent un manque réel et légitime. La thèse de cet article est plus étroite : une part significative des demandes mérite une question de plus avant d'entrer dans le backlog, parce que la réponse change complètement le travail à faire.
Pourquoi les utilisateurs formulent des solutions
Ce n'est pas un défaut de leur part, c'est une conséquence de la façon dont on demande.
Un formulaire intitulé « demander une fonctionnalité » invite à décrire une fonctionnalité. Un utilisateur coopératif fait ce qu'on lui demande : il traduit sa gêne en proposition. Au passage, l'information la plus utile, à savoir ce qu'il essayait de faire, disparaît.
Le coût est réel. Vous construisez le bouton demandé, et le problème sous-jacent, s'il était ailleurs, reste entier.
Les cinq motifs à reconnaître
La fonction existe déjà
Le motif le plus fréquent, et le plus rapide à vérifier. Signal : la demande décrit précisément un comportement que votre produit a. Action : ce n'est pas du développement, c'est de la découvrabilité ou de la documentation.
Le parcours est trop long
L'utilisateur demande un raccourci. Signal : les formulations du type « sans avoir à passer par », « directement depuis ». Action : regarder le parcours réel, qui compte souvent plus d'étapes que vous ne le pensiez.
Une intégration manque
L'utilisateur demande une fonctionnalité que votre produit n'a pas vocation à couvrir, parce que l'outil qui la couvre n'est pas connecté au vôtre. Signal : la demande décrit un travail de recopie manuelle entre deux outils.
Le vocabulaire ne correspond pas
L'utilisateur cherche « archiver » et vous appelez cela « désactiver ». La fonction est là, le mot ne l'est pas. Signal : la demande utilise un terme métier absent de votre interface.
Le comportement surprend
Quelque chose fonctionne comme prévu par vous et pas comme attendu par lui. Signal : « ce serait bien que X fasse Y » alors que X fait déjà quelque chose de proche mais différent. C'est la frontière la plus floue entre demande et anomalie.
La question qui tranche
Une seule question suffit à séparer les cas, et elle se pose bien mieux à l'écrit dans le formulaire qu'a posteriori :
Qu'essayiez-vous de faire quand vous avez rencontré ce besoin ?
Cette formulation ramène l'utilisateur au contexte plutôt qu'à la solution. Les réponses distinguent immédiatement « je voulais dupliquer un projet et je n'ai pas trouvé comment » de « je voulais dupliquer un projet, il n'existe aucun moyen de le faire ».
Le premier cas se règle en une journée de travail sur l'interface. Le second entre dans le backlog.
Ce que cela change dans votre processus
Trois ajustements concrets :
Ajoutez le champ de contexte au formulaire. Facultatif, une ligne. Le gain d'information est disproportionné par rapport à la friction ajoutée.
Créez une catégorie de triage distincte. « Découvrabilité » n'est ni un bug ni une fonctionnalité. Sans catégorie propre, ces demandes se rangent par défaut dans le backlog produit et n'en sortent jamais.
Suivez le volume de cette catégorie. Une hausse après une refonte d'interface est un signal fort et immédiat, bien avant que les chiffres de rétention ne bougent.
Le contre-argument, et pourquoi il tient
On objecte parfois qu'il ne faut pas réinterpréter ce que disent les utilisateurs, sous peine de justifier l'inaction : « ils ne veulent pas vraiment cela » est une phrase confortable pour une équipe qui ne veut rien construire.
L'objection est fondée, et c'est pourquoi la démarche décrite ici repose sur une question posée à l'utilisateur, pas sur une interprétation faite à sa place. Vous ne décidez pas que sa demande cache autre chose : vous lui demandez le contexte, et il vous le dit.
Si le contexte confirme la demande, elle entre dans le backlog avec une justification plus solide qu'avant.
Ce que FlagUp fait ici
Le widget de feedback fait choisir une catégorie avant l'envoi, ce qui sépare d'emblée bug, demande et retour général. Les envois décrivant le même besoin sont regroupés automatiquement sur les forfaits payants, ce qui fait apparaître les motifs récurrents.
FlagUp ne détecte pas automatiquement qu'une demande décrit une fonction existante : cela suppose de connaître votre produit. Le regroupement rend simplement ces motifs visibles plus tôt, quand ils se répètent.
Questions fréquentes
Toutes les demandes cachent-elles un problème d'UX ?
Non, et le supposer serait une erreur symétrique. Beaucoup décrivent un manque réel. L'article porte sur la part qui mérite une question de plus.
Comment poser la question sans alourdir le formulaire ?
Un champ facultatif d'une ligne, placé après la description. Les utilisateurs les plus motivés le remplissent, et ce sont ceux dont le retour est le plus dense.
Que faire quand la fonction existe déjà ?
Répondre à la personne en indiquant où, puis ouvrir un ticket de découvrabilité. La réponse individuelle règle son cas ; le ticket règle celui des utilisateurs qui n'ont rien écrit.
Faut-il refuser publiquement ces demandes ?
Les requalifier plutôt que les refuser. Un refus sec sur une demande qui décrivait un vrai problème donne le sentiment de ne pas avoir été compris.
Ce tri prend-il beaucoup de temps ?
Le tri initial oui, la première fois. Ensuite, les motifs se répètent et deviennent reconnaissables en quelques secondes.
Pour aller plus loin
- La priorisation des fonctionnalités, pour l'étape suivante
- L'agrégation du feedback, pour faire remonter les motifs récurrents
- Les micro-sondages, pour capter le contexte au moment de l'usage