Il y a un tableur. Il compte 400 lignes, dont trois ont été lues ce trimestre, et ses colonnes s'intitulent « client », « demande » et « notes ». Quelque part dedans se trouve le seul problème qui, bien résolu, ferait bouger le renouvellement de tout un segment, et personne ne le trouvera jamais, parce que la file a été conçue pour stocker des demandes plutôt que pour y répondre.
Bien gérer les demandes de fonctionnalités, ce n'est pas en collecter davantage. C'est s'astreindre à trois disciplines peu glamour : retraduire chaque demande, d'une solution proposée vers le problème qui se cache derrière, savoir à quel point chaque canal de collecte est biaisé, et revenir vers la personne qui a demandé, au moment de décider comme au moment de livrer.
Ce guide couvre le pipeline complet, les biais de canal dont personne ne tient compte, ce qu'il faut faire de la grosse pile de demandes que vous ne développerez jamais, et pourquoi boucler la boucle est l'étape qui détermine si quelqu'un prendra encore la peine de vous dire quoi que ce soit au prochain trimestre.
Points clés
- Une demande est une solution proposée, pas un besoin. Le travail consiste à retrouver le problème sous-jacent avant qu'il n'atteigne une roadmap.
- Chaque canal est biaisé. Les demandes des commerciaux penchent vers les deals, celles du support vers les pannes, les tableaux publics vers ceux qui regardent le tableau.
- Le nombre de votes n'est pas une priorité. Il mesure l'engagement envers votre système de feedback, pas l'ampleur du problème.
- Un responsable, une file, un calendrier. Un tri qui appartient à tout le monde n'est fait par personne.
- Dites non vite et précisément. Le silence abîme la relation bien plus qu'un refus clair.
- Boucler la boucle au moment de livrer est l'étape la plus rentable. Elle transforme une demande en adoption et garde le pipeline alimenté.
Une demande de fonctionnalité est une solution proposée
La demande de fonctionnalité, en un paragraphe
Une demande de fonctionnalité, c'est un client ou un collègue qui demande qu'une capacité précise soit ajoutée ou modifiée. Ce qui les rend difficiles à gérer, ce n'est pas leur volume mais leur forme : les gens décrivent la solution qu'ils ont imaginée, pas le problème qu'ils ont rencontré. La demande est un encodage compressé et avec perte d'un besoin, et la compression élimine justement les informations dont vous avez besoin pour bien décider. Retrouver le besoin est la première étape de tout le processus, et celle qui a le plus de valeur.
L'exemple classique est la demande d'export. Six clients demandent un export CSV, et il existe une version de cette histoire où l'équipe développe l'export CSV, le livre et découvre que l'usage est quasi nul, parce que lorsqu'on finit par leur poser la question, les six voulaient autre chose.
Chaque colonne de droite suggère des solutions que la colonne de gauche ne suggère pas : un récapitulatif programmé, une correction de la saisie qui provoque sans cesse l'erreur, un thème qui s'adapte à la luminosité. C'est la même démarche que celle des jobs to be done : demander ce que la personne essayait d'accomplir et ce qu'elle a fait à la place quand ça n'a pas marché.
La question qui fait l'essentiel du travail. « Que faisiez-vous quand vous en avez eu besoin, et qu'avez-vous fait à la place ? » Elle se pose en une phrase, transforme une demande en une histoire avec du contexte, et révèle souvent que deux demandes classées sous des noms différents sont le même problème.
D'où viennent les demandes, et comment chaque canal vous trompe
Les demandes n'arrivent pas sous forme d'échantillon représentatif. Chaque canal surreprésente un type d'utilisateur et un type de problème particuliers, et traiter ce mélange comme une donnée sur votre base d'utilisateurs est l'erreur structurelle la plus courante dans la gestion des demandes de fonctionnalités.
| Canal | Ce qu'il surreprésente | Ce pour quoi il est vraiment utile | Biais |
|---|---|---|---|
| Tickets de support | Ce qui est cassé ou déroutant en ce moment | Les frictions qui vous coûtent des tickets aujourd'hui | Moyen |
| Appels commerciaux | Des exigences liées à un deal qui n'est pas encore signé | Les manques qui empêchent tout un segment d'acheter | Élevé |
| Revues customer success | Les comptes les plus gros et les plus bruyants | Un risque de non-renouvellement avec un nom dessus | Élevé |
| Tableau de vote public | Les utilisateurs qui suivent votre roadmap par passion | La transparence et la détection des doublons | Élevé |
| Invites in-app | L'écran sur lequel vous avez placé l'invite | Le contexte : vous savez exactement ce que la personne faisait | Plus faible |
| Enquêtes de churn et de départ | Les raisons que les gens donnent en partant | Ce qui manquait au point de faire perdre le compte | Moyen |
Le canal le moins biaisé est le canal in-app, pour une raison structurelle : il saisit l'utilisateur au moment du problème, sur l'écran où il s'est produit, sans exiger qu'il s'en soucie assez pour ouvrir un tableau ou écrire au support. Nos guides sur les sondages in-app et les enquêtes de départ en détaillent la mécanique ; ce qui compte ici, c'est qu'une demande capturée en contexte arrive avec la moitié du travail de clarification déjà faite.
Le problème de la majorité silencieuse. Les utilisateurs les plus enclins à déposer une demande sont ceux qui sont le plus investis dans votre produit, vos power users. Ce sont aussi ceux dont les problèmes sont déjà les plus petits, parce qu'ils ont appris les contournements. Un backlog construit uniquement à partir des demandes entrantes est donc une machine à surservir ceux qui ont le moins besoin de vous, ce qui est l'un des mécanismes derrière le feature bloat.
Le pipeline en quatre étapes
Un système qui fonctionne a quatre étapes et un seul responsable. Ce responsable ne décide pas de tout ; il répond du fait que la file avance, ce qui est un travail différent et plus rare.
Chaque canal aboutit dans une seule file, avec les mêmes champs. Pas de tableurs parallèles.
Transformer la demande en énoncé de problème, fusionner les doublons, indiquer qui et combien.
Maintenant, plus tard ou non, selon un calendrier, avec la raison écrite noir sur blanc.
Dire au demandeur ce que vous avez décidé. Le lui redire quand c'est livré.
Quatre étapes, une file, un responsable. La plupart des processus défaillants n'ont ni l'étape deux, ni l'étape quatre.
1. Collecter : une seule file, des champs cohérents
L'outil qui héberge la file importe peu. Ce qui importe énormément, c'est qu'il n'y en ait qu'une et que chaque entrée ait la même poignée de champs : la demande avec les mots du demandeur, qui l'a faite, son segment ou son offre, l'écran ou le workflow concerné, la date, et le canal par lequel elle est arrivée. C'est ce dernier champ qui vous permet ensuite de remarquer qu'une « demande prioritaire » correspond en réalité à huit personnes sur un tableau public et un seul client payant.
2. Clarifier : la réécrire comme un problème
Chaque semaine, à heure fixe, reprenez les nouvelles entrées et réécrivez chacune en une phrase de la forme « [qui] ne peut pas [faire quoi] parce que [pourquoi], donc actuellement il [contournement] ». Quand la demande est trop mince pour être réécrite, allez poser la question ; le demandeur répondra presque toujours, parce que quelqu'un a réellement lu ce qu'il a écrit. Ensuite, fusionnez : les demandes qui partagent un énoncé de problème ne forment qu'un seul élément, quelle que soit la façon dont elles ont été formulées. C'est là qu'une file de 400 lignes devient généralement 60 vrais problèmes, et c'est aussi le moment naturel pour mener une analyse structurée du feedback sur le texte que vous avez collecté.
3. Décider : maintenant, plus tard ou non
Trois issues seulement. « À l'étude » n'est pas un état, c'est une façon d'en éviter un, et une file qui en est pleine est ce que les clients finissent par lire comme de l'indifférence. Pesez quatre choses : combien d'utilisateurs sont touchés et avec quelle gravité, à quel point le problème correspond à la direction du produit, le vrai coût, y compris la maintenance et la chose de plus que chaque futur utilisateur devra apprendre, et ce qui se passe si vous ne faites rien. Le modèle de Kano est justement utile ici, car il sépare les demandes qui sont des attentes de base non satisfaites, dont l'absence crée un vrai mécontentement, des facteurs d'enchantement qui ont l'air passionnants et ne changent rien.
4. Boucler la boucle, deux fois
Une première fois au moment de la décision, pour que la personne sache qu'elle a été entendue et ce qui va se passer. Une seconde fois au moment de la livraison, pour que la personne qui a demandé il y a six mois découvre que la fonctionnalité existe. Ce second contact est celui que presque tout le monde saute, et celui qui a le plus de valeur ; voir la section suivante.
Boucler la boucle, c'est tout l'enjeu
Un système de demandes de fonctionnalités a sa propre boucle de rétroaction : les gens déposent des demandes à proportion de leur conviction que cela sert à quelque chose. Les équipes qui ne répondent jamais voient les soumissions se tarir, puis en concluent que les clients n'ont pas de feedback, alors que ces mêmes clients décrivent la même capacité manquante dans une enquête de churn huit mois plus tard.
La phrase la plus sous-utilisée du SaaS, c'est « vous l'avez demandé le trimestre dernier ; c'est disponible maintenant, et voici où le trouver ». Elle ne coûte rien, elle tombe sur quelqu'un qui vous a déjà dit vouloir la chose, et elle transforme une demande en usage réel plutôt qu'en une ligne dans un changelog que personne n'a lu.
l'argument en faveur des annonces cibléesLa version pratique comporte deux volets. D'abord, publiez correctement ce qui a été livré ; notre guide pour rédiger des release notes en détaille le format. Ensuite, et séparément, prévenez les personnes précises qui l'avaient demandé, dans le produit, sur l'écran où se trouve la nouvelle capacité. Une annonce générale touche tout le monde faiblement ; une annonce ciblée touche le demandeur au moment où il peut agir, et c'est toute la différence entre la notoriété et l'adoption. Notre méthode pour annoncer une nouvelle fonctionnalité détaille l'enchaînement.
Les demandes capturées in-app arrivent avec leur contexte, et le même canal peut servir à boucler la boucle plus tard.
La pile des « non » représente l'essentiel de la file
Tout produit en bonne santé refuse la grande majorité de ce qu'on lui demande, et bien le faire est une compétence. Trois pratiques tiennent la route :
- Refusez vite. Un non au bout d'une semaine est respecté. Un non après six mois de silence se lit comme du mépris, et à ce stade le client a généralement bricolé un contournement et perdu l'envie de vous dire quoi que ce soit d'autre.
- Donnez la raison, pas la règle. « Cela sort de ce que nous construisons cette année, parce que nous sommes concentrés sur X » est une raison. « Ce n'est pas dans la roadmap » est un mur. La première garde la conversation ouverte ; le second y met fin.
- Proposez la réponse d'aujourd'hui. La plupart des demandes refusées ont déjà un contournement partiel dans le produit. L'envoyer, idéalement sous forme de lien vers l'article d'aide pertinent ou vers un guide in-app sur le bon écran, transforme un non en petite victoire.
Une nuance à garder en tête : une demande que vous refusez reste une donnée. Dix demandes refusées qui partagent un énoncé de problème signalent un manque, même si aucune des dix solutions proposées n'était la bonne. Gardez les énoncés de problème consultables, car le groupe qui ressemble à du bruit ce trimestre est souvent l'élément de roadmap de l'an prochain.
Un mot sur les tableaux de vote publics
Les tableaux publics sont vraiment utiles pour deux choses : montrer aux clients que la file existe, et permettre aux gens de constater que leur demande a déjà été déposée. Ils sont mauvais pour ce à quoi on les destine en général, à savoir la priorisation. Les votes mesurent qui regarde le tableau : les utilisateurs individuels engagés votent, les acheteurs grands comptes pratiquement jamais, et une demande venant d'un segment qui représente l'essentiel de votre chiffre d'affaires peut se retrouver sous une demande portée par six passionnés.
Si vous en gérez un, traitez les votes comme un mécanisme de détection des doublons plutôt que comme un classement, faites le ménage sans pitié pour qu'il ne devienne pas une archive de demandes sans réponse, et gardez les vrais critères de priorisation (segment, chiffre d'affaires, gravité, adéquation stratégique) dans la file interne, là où ils ont leur place.
Six façons dont les processus de demandes de fonctionnalités échouent
- Stocker sans trier. Une file que personne n'entretient n'est pas un backlog, c'est une décharge, et l'effort passé à y collecter est perdu dès le premier jour.
- Classer au simple décompte. La fréquence est un critère parmi d'autres. Utilisée seule, elle confie votre roadmap à ceux qui sont le plus à l'aise pour ouvrir des tickets.
- Développer la demande au pied de la lettre. Livrer la solution proposée sans retrouver le problème produit des fonctionnalités utilisées une fois et maintenues pour toujours.
- Laisser le deal le plus bruyant fixer la roadmap. La liste d'exigences d'un gros prospect est au mieux un signal sur un segment, au pire une distraction. Demandez combien de clients existants ont le même problème avant de vous engager.
- Aucune réponse au moment de décider. Le moyen le plus rapide de ne plus recevoir de feedback, et il reste invisible jusqu'à ce que la file se tarisse en silence.
- Livrer en silence. Construire la bonne chose et ne jamais le dire à la personne qui l'a demandée est l'erreur la plus coûteuse de cette liste, car vous en avez payé tout le coût sans en récolter le moindre crédit.
Demandes de fonctionnalités : à faire et à éviter
✅ À faire
- Faire converger tous les canaux vers une file unique aux champs cohérents
- Réécrire chaque demande comme un énoncé de problème avant de décider
- Noter par quel canal chaque demande est arrivée
- Trier chaque semaine à heure fixe, avec un responsable nommé
- Refuser explicitement, avec une raison et un éventuel contournement
- Prévenir in-app les demandeurs d'origine quand c'est livré
❌ À éviter
- Classer au nombre de votes
- Utiliser « à l'étude » comme état permanent
- Développer la solution proposée sans demander à quoi elle devait servir
- Laisser un seul deal réécrire le trimestre
- Tenir des listes de demandes parallèles dans trois outils
- Supposer qu'une file silencieuse signifie des clients satisfaits
Collecter et boucler la boucle dans le produit
Tout ce qui précède est plus simple quand les deux extrémités de la boucle se trouvent là où est déjà l'utilisateur. La collecte est meilleure in-app parce que le contexte vient gratuitement : vous connaissez l'écran, le segment et ce que la personne venait de faire. Boucler la boucle est meilleur in-app parce que l'annonce apparaît sur l'écran où la nouvelle capacité existe réellement, plutôt que dans une boîte de réception deux jours plus tard.
C'est un travail no-code tout simple : un micro-sondage sur l'écran où un workflow ne cesse de bloquer, et une annonce ciblée vers le segment qui l'a demandé, publiée sans attendre une release. Ajoutez-y un court walkthrough de la nouvelle capacité, et une demande se transforme en adoption le jour même où elle devient une fonctionnalité livrée.
Demandez là où le problème survient. Répondez là où se trouve la solution.
Kompassify vous permet de lancer des sondages in-app pour capturer les demandes en contexte, puis d'annoncer ce que vous avez construit exactement aux utilisateurs qui l'avaient demandé, avec des infobulles, des walkthroughs et des annonces publiés par-dessus votre produit existant, sans aucun temps de développement. Gratuit jusqu'à 100 utilisateurs actifs mensuels, offres à partir de $129/mois, conforme au RGPD et hébergé dans l'UE.
Commencer gratuitement →La version en un paragraphe
Traitez chaque demande de fonctionnalité comme une solution proposée qu'il faut retraduire en problème, rappelez-vous que chaque canal de collecte surreprésente un type d'utilisateur différent, tenez une seule file avec un seul responsable et un tri hebdomadaire, décidez selon trois états plutôt que de laisser les choses en suspens indéfiniment, et revenez vers les personnes qui ont demandé, une fois quand vous décidez et une autre quand vous livrez. C'est cette dernière étape qui maintient la file en vie.
Questions fréquentes
Qu'est-ce qu'une demande de fonctionnalité ?
Une demande de fonctionnalité, c'est un client ou un collègue qui demande qu'une capacité précise soit ajoutée ou modifiée. Le plus important dans cette définition, c'est ce qu'elle laisse de côté : une demande est une solution proposée, pas l'expression d'un besoin. Quelqu'un qui réclame un export CSV a peut-être besoin d'un rapport programmé, d'une intégration, ou simplement d'un moyen de montrer un chiffre à sa manager. Bien gérer les demandes de fonctionnalités, c'est surtout s'astreindre à retrouver le problème sous-jacent avant que la solution proposée ne soit inscrite dans une roadmap.
Comment collecter les demandes de fonctionnalités ?
Collectez-les là où se trouve déjà l'utilisateur, et faites converger tous les canaux vers un seul endroit. Les invites in-app saisissent la demande au moment de la frustration, avec tout le contexte de ce que la personne était en train de faire ; les échanges avec le support capturent le problème avec les mots de l'utilisateur ; les appels des équipes commerciales et customer success font remonter des demandes liées au chiffre d'affaires. L'important n'est pas d'ajouter des canaux, mais de faire en sorte que chacun aboutisse dans une file unique avec les mêmes champs, car des demandes éparpillées entre un helpdesk, un tableur et trois canaux Slack ne peuvent être ni comptées, ni comparées, ni traitées.
Comment prioriser les demandes de fonctionnalités ?
Pas au nombre de votes. Mettez en balance le nombre d'utilisateurs touchés et la gravité du problème, l'adéquation de la demande avec la direction de votre produit, ce qu'elle coûte à construire et à maintenir, et ce que signifierait ne rien faire. La fréquence est un critère parmi d'autres, et un simple décompte est fortement biaisé en faveur des utilisateurs les plus bruyants et les plus engagés, ceux qui réussissent déjà avec le produit. Des cadres comme le modèle de Kano aident en classant une demande comme attente de base, amélioration de performance ou facteur d'enchantement, ce qui change la valeur de sa réalisation.
Faut-il un tableau public de demandes de fonctionnalités ?
Seulement si vous comptez l'entretenir. Un tableau public avec des votes visibles est excellent pour la transparence et très mauvais comme critère de priorisation : les votes mesurent qui regarde votre tableau, pas qui a le problème, et les clients grands comptes ne votent presque jamais. Il crée aussi une obligation : un tableau rempli de demandes vieilles de deux ans marquées 'à l'étude' est la preuve publique que vous n'écoutez pas. Si vous ne pouvez pas vous engager à répondre et à faire le ménage, une file interne avec un suivi proactif sert mieux vos clients.
Comment dire non à une demande de fonctionnalité ?
Vite, précisément, et en donnant la raison. La plupart des clients acceptent bien mieux un non que le silence, et ce qui abîme la relation, c'est une demande qui disparaît pendant six mois avant de mourir en silence. Nommez le problème que vous avez compris, dites ce que vous avez décidé et pourquoi (hors stratégie, déjà couvert par une capacité existante, trop spécifique pour votre base d'utilisateurs), et proposez le contournement qui existe aujourd'hui. Un non clair incite aussi les gens à continuer de soumettre des demandes, ce qui est précisément le résultat que vous cherchez.
Que veut dire boucler la boucle sur les demandes de fonctionnalités ?
Boucler la boucle, c'est revenir vers les personnes qui ont demandé, deux fois : une fois quand vous décidez, et une autre quand vous livrez. La plupart des équipes ne font ni l'un ni l'autre, et c'est pour cela que les clients cessent de signaler des problèmes. Le second contact est celui qui a de la valeur : dire à quelqu'un que ce qu'il a demandé le trimestre dernier est désormais disponible, dans le produit, au moment où il peut s'en servir, transforme une demande en adoption et en capital de sympathie. Une annonce in-app ciblée sur les demandeurs est le moyen fiable le moins coûteux d'y parvenir.
Qui doit être responsable des demandes de fonctionnalités ?
Une personne ou un rôle nommé doit être responsable de la file elle-même, en général un product manager, parfois un responsable product operations ou customer success, même si tout le monde y contribue. Être responsable, c'est répondre du fait que le tri a lieu selon un calendrier, que les champs sont remplis et que les réponses repartent vers les demandeurs. Une file de demandes dont la responsabilité est partagée finit immanquablement en backlog que personne ne lit, car le tri fait partie de ces tâches toujours un peu moins urgentes que tout le reste.
Combien de demandes de fonctionnalités faut-il vraiment développer ?
Beaucoup moins que vous n'en recevez. Une file est un intrant de la stratégie, pas un substitut, et une roadmap assemblée à partir des éléments les plus demandés dérive vers le feature bloat : une foule de capacités qui servent chacune un petit groupe, et qu'il faut toutes maintenir et expliquer à chaque futur utilisateur. La démarche la plus saine consiste à chercher le problème récurrent derrière des groupes de demandes et à le résoudre une bonne fois, ce qui satisfait souvent une douzaine de demandes avec un seul changement bien conçu.