Priorisation des fonctionnalités : quoi construire d’abord

La fondatrice est arrivée au kickoff avec un tableur. Quarante et une lignes, une fonctionnalité par ligne, toutes marquées « indispensable ». Elle construisait un outil de réservation et de paiement pour une petite chaîne de salons de toilettage canin, elle avait une vraie demande, et elle avait un budget qui couvrait peut-être huit des quarante et une. Quand je lui ai demandé lesquelles huit, elle a dit qu’elles étaient toutes essentielles. C’est le moment où la priorisation des fonctionnalités commence vraiment, et c’est le moment où la plupart des founders se figent.

La priorisation des fonctionnalités, c’est décider quelles features construire d’abord, et lesquelles couper ou reporter, quand on ne peut pas tout construire d’un coup. Tout guide en première page de Google vous tendra un framework de scoring pour ça : RICE, MoSCoW, Kano, matrices pondérées. Ces frameworks sont réels et ils fonctionnent, mais ils ont été conçus pour des product managers qui ont déjà un produit, des données d’usage et une équipe. En tant que founder non technique au départ, vous avez une liste de souhaits, un budget fixe et aucune donnée encore. Votre problème n’est pas le calcul. C’est le figement.

Pourquoi les frameworks ne règlent pas votre vrai problème

Un framework de scoring prend une liste de features et les classe selon une combinaison de valeur et de coût. Le RICE, la méthode qu’Intercom a popularisée, multiplie portée, impact et confiance, puis divise par l’effort. Le MoSCoW range tout en indispensable, important, souhaitable et hors périmètre. Ils sont vraiment utiles une fois que vous avez les intrants dont ils ont besoin.

Le hic, c’est que les intrants sont la partie difficile, et qu’au départ vous ne les avez pas. Portée et impact sont des estimations du nombre d’utilisateurs qu’une feature touche et de combien elle fait bouger une métrique. Vous avez zéro utilisateur et aucun historique de métrique, donc chaque chiffre que vous saisissez est une supposition déguisée en arithmétique. Le framework blanchit alors votre supposition en un score d’allure assurée, et vous prenez une décision de build à six chiffres sur un nombre que vous avez inventé. C’est pire que pas de framework du tout, parce que ça paraît rigoureux.

Le vrai travail se fait donc avant la matrice. Prioriser au départ n’est pas un calcul. C’est une décision sur ce que vous êtes prêt à lancer sans. Tant que vous n’avez pas pris cette décision honnêtement, aucun framework ne vous sauvera, et une fois que vous l’avez prise, vous n’en avez presque plus besoin.

La méthode de priorisation du founder

Voici ce qu’on déroule réellement avec les founders avant que quiconque n’ouvre une feuille de scoring. Quatre questions, posées à chaque feature de la liste.

Première : est-ce que cette feature fait payer quelqu’un, ou fait rester quelqu’un ? Pas « c’est sympa ». Pas « un utilisateur aimerait ». Est-ce qu’elle pousse une personne à entrer une carte, ou à revenir la semaine suivante ? Le flux de réservation des salons faisait payer les gérants parce qu’il remplaçait un système de téléphone et de carnet qui perdait des rendez-vous. Le module de points de fidélité ne faisait ni l’un ni l’autre au lancement. L’un était du jour un ; l’autre pouvait attendre un an.

Deuxième : si vous la retiriez, le travail central casserait-il ? Tout produit fait un travail principal. Pour l’outil des salons, le travail était « prendre une réservation et être payé sans un coup de fil ». Retirez les paiements en ligne et le travail casse. Retirez le calendrier de disponibilité par intervenant et le travail casse. Retirez les reçus par e-mail personnalisables et le travail tient toujours, le reçu est juste plus simple. Les features qui cassent le travail central quand on les retire ne sont pas négociables. Tout le reste l’est.

Troisième : la demande est-elle réelle, ou est-ce le client le plus bruyant ? Les founders surpondèrent systématiquement le seul client qui envoie trois e-mails sur une feature précise. Ce client n’est pas votre roadmap. C’est une voix, souvent la moins représentative, et construire sa feature fétiche en premier, c’est ainsi qu’on se retrouve avec un logiciel à la forme de son client le plus exigeant plutôt qu’à celle de son marché. Demandez combien de personnes ont réclamé, spontanément, la même chose. Une, c’est du bruit. Huit, c’est un signal.

Quatrième : peut-elle attendre que les utilisateurs vous le disent ? La feature la moins chère est celle que vous ne construisez pas parce que l’usage réel a rendu évident que vous n’en aviez pas besoin. Si une feature n’est pas du jour un et ne casse pas le travail central, le bon mouvement est en général de lancer sans elle et de laisser les vrais utilisateurs vous dire si elle compte. Ils le diront, et ils seront plus honnêtes que votre tableur.

Passez ces quatre questions et les quarante et une lignes se rangent en trois piles : construire maintenant, construire plus tard et probablement jamais. La fondatrice de l’outil de toilettage a terminé avec neuf features dans la pile « construire maintenant », pas quarante et une, et les neuf étaient celles qui faisaient payer les gérants. On a lancé en dix semaines au lieu de huit mois, et le module de fidélité qu’elle avait marqué indispensable n’a jamais été construit, parce qu’une fois les gérants en ligne, aucun ne l’a réclamé.

Les quarante et une lignes, triées

Il est utile de voir la méthode tourner contre de vraies lignes, parce que la version abstraite fait sonner toute feature comme également importante et la version concrète, non. Six de ses items, et où chacun a atterri :

La réservation en ligne avec disponibilité en direct est allée en construire-maintenant. Elle faisait payer les gérants (c’était la raison de quitter le téléphone) et la retirer cassait le travail central. Le paiement par carte à la réservation : construire-maintenant, même logique, puisque « être payé sans un coup de fil » était la moitié du travail. Un calendrier avec des horaires par intervenant : construire-maintenant, parce qu’une réservation qui place deux clients sur le même intervenant est pire que pas de réservation.

Puis la ligne a bougé. Rappels automatiques par SMS : construire-plus-tard. Les gérants les voulaient et ils réduisent les absences, mais l’outil fonctionnait sans eux au lancement, et on pouvait voir les taux d’absence réels avant de dépenser pour ça. Reçus par e-mail personnalisés et à la marque : construire-plus-tard frôlant le jamais, parce qu’un reçu simple fait le travail et la personnalisation était du goût, pas du revenu. Le moteur de points de fidélité : probablement-jamais, l’item le plus cher de la liste, marqué indispensable par instinct, réclamé par aucun gérant réel une fois en ligne.

Le propos n’est pas que les points de fidélité soient mauvais. C’est que la fondatrice les avait classés au même poids qu’être payée, parce qu’une liste de souhaits aplatit tout en « envie ». Les quatre questions désaplatissent. Elles transforment quarante et une envies égales en neuf choses dont le produit a besoin pour faire son travail et trente-deux choses qui peuvent prouver leur importance plus tard.

Chaque oui est un non ailleurs

Si la priorisation est douloureuse, c’est que les founders la vivent comme une addition. Chaque feature est une chose qu’ils veulent, et la couper ressemble à une perte. Le recadrage qui aide, c’est de voir la priorisation comme une soustraction contre un nombre fixe.

Vous avez un budget. Que ce soit ce que coûte la construction de l’app ou les semaines de votre unique développeur, il est fini, et il achète une quantité fixe de build. Chaque feature à laquelle vous dites oui est une feature, ou une semaine, à laquelle vous avez dit non ailleurs. Le module de fidélité n’est pas gratuit même si vous l’adorez. Il coûte le flux d’onboarding que vous n’avez pas peaufiné, ou les trois semaines que vous n’avez pas passées sur ce qui fait vraiment payer les gérants. Quand un founder voit la liste comme un budget qui se dépense plutôt qu’une liste de souhaits qu’on accorde, les coupes deviennent plus faciles, parce qu’il troque, désormais, au lieu de perdre.

C’est aussi la discipline qui empêche le feature creep de dévorer le build. Le creep arrive quand de nouvelles features sont ajoutées sans que rien ne soit retiré pour les payer. Un founder qui priorise par soustraction a une réponse toute prête à la demande de « est-ce qu’on peut aussi ajouter » en plein build : bien sûr, et qu’est-ce qui sort pour faire de la place.

Il y a un dernier piège qui mérite d’être nommé, parce qu’il attrape les founders affûtés en particulier. Certaines features sont priorisées non pour un client mais pour un public : le dashboard léché qui rend bien dans une démo de levée, la feature d’IA ajoutée parce qu’un membre du board a demandé si vous en aviez une. Vouloir lancer quelque chose de crédible pour les investisseurs le trimestre prochain est une vraie pression, et parfois la feature de démo en vaut la peine. Mais passez-la par les mêmes quatre questions, honnêtement. Si une feature ne fait qu’opiner un investisseur et ne fait jamais payer ni rester un client, c’est un coût marketing déguisé en produit, et il faudrait la budgéter comme tel, pas la glisser en haut de la liste de build.

Quand les frameworks gagnent enfin leur place

Rien de tout cela ne veut dire que RICE et MoSCoW sont inutiles. Cela veut dire que ce sont des outils d’étape ultérieure, et que vous les saisissez au bon moment, pas au premier.

Le moment, c’est quand vous avez des utilisateurs. Une fois votre produit en ligne et utilisé, vous avez enfin les intrants pour lesquels les frameworks ont été conçus : portée réelle, impact observé, preuve au lieu de supposition. C’est là qu’une matrice de scoring cesse de blanchir vos suppositions et se met à organiser vos preuves. Un founder avec trois mois de données d’usage et un backlog de quarante demandes devrait absolument faire tourner RICE dessus. Un founder au kickoff sans utilisateurs devrait faire tourner les quatre questions et résister à l’envie d’habiller une supposition en score.

L’arc est simple. Avant le lancement, priorisez au jugement, contre le travail et le budget. Après le lancement, priorisez par les données, avec le framework qui convient à votre équipe. L’erreur, c’est d’utiliser la seconde méthode quand vous êtes encore dans la première situation. C’est la même discipline derrière le fait de lancer un vrai produit minimum viable et de savoir où dépenser le soin sur un minimum lovable product : décidez à quoi sert vraiment la première version, et laissez tout le reste attendre son tour.

Comment dire non sans perdre le client

La dernière peur que les founders soulèvent, c’est que couper des features leur coûtera le client qui les voulait. En général non, si vous gérez bien le non. « On ne va pas construire ça » tombe mal. « C’est sur la liste, et voici pourquoi ça vient après les choses qui vous mettent en ligne plus vite » tombe bien, parce que ça montre au client qu’il est dans une séquence, pas à la poubelle. Les gens acceptent d’être pour plus tard bien plus facilement que d’être ignorés, et un founder capable d’expliquer l’ordre du build sonne comme quelqu’un qui le maîtrise.

La fondatrice des salons a toujours ce tableur de quarante et une lignes. La majeure partie est dans les colonnes « plus tard » et « jamais » maintenant, annotée du client réel qui l’a demandée et du nombre de fois. C’est devenu une meilleure roadmap que l’originale, parce que chaque item y avait gagné sa place au lieu d’y commencer.

Foire aux questions

Qu’est-ce que la méthode de priorisation des fonctionnalités ? C’est le processus consistant à décider quelles features de produit construire d’abord, et lesquelles reporter ou couper, quand on ne peut pas tout construire d’un coup. Au départ, avant d’avoir des données d’usage, c’est un jugement contre le travail central du produit et votre budget, pas un exercice de scoring.

Quels sont les 4 niveaux de priorisation ? Le schéma à quatre niveaux le plus courant est MoSCoW : indispensable (le produit casse sans elle), important (utile mais pas vital au lancement), souhaitable (bien s’il y a de la place) et hors périmètre (explicitement écarté pour l’instant).

Quelles sont les quatre méthodes de priorisation ? Les méthodes très utilisées incluent RICE (portée, impact, confiance, effort), MoSCoW, le modèle Kano (features de base, de performance et d’enchantement) et une simple matrice valeur contre effort. Elles fonctionnent mieux quand vous avez de vraies données d’usage à leur donner.

Quel est l’objectif principal de la priorisation des fonctionnalités ? Dépenser un budget et un calendrier finis sur les features qui font vraiment payer ou rester un client, et reporter le reste, pour que la première version fasse bien son travail central au lieu de faire beaucoup de choses mal.