Feature prioritization

La feature prioritization (priorisation des fonctionnalités) est le processus par lequel une équipe produit décide quelles fonctionnalités construire en premier, lesquelles attendront et lesquelles ne seront jamais développées. Elle repose sur des critères explicites, impact attendu, effort, cohérence avec la stratégie, plutôt que sur l’ordre d’arrivée des demandes. C’est l’exercice qui transforme un backlog de deux cents lignes en une séquence de travail défendable.

En 2019, Pendo a analysé l’usage réel de 615 logiciels équipés de son outil depuis plus d’un an : 80 % des fonctionnalités étaient rarement ou jamais utilisées. Chacune a pourtant coûté des semaines de développement, puis de la maintenance et de la complexité d’interface. Prioriser, c’est d’abord éviter de construire ces 80 %.

Pourquoi prioriser les fonctionnalités est si difficile

Presque toutes les idées ont du mérite : l’intégration Slack que vingt clients réclament, le mode sombre demandé sur le forum, l’automatisation des workflows qui pourrait relancer l’engagement. Trier le bon du mauvais est facile. Classer des bonnes idées entre elles, avec une équipe qui n’en livre que trois par trimestre, ne l’est pas.

L’information est aussi incomplète. L’impact d’une fonctionnalité s’estime, il ne se connaît qu’après la mise en production, et les estimations d’effort sont imprécises par nature. La priorisation est donc un exercice de jugement outillé, pas un calcul. Les méthodes présentées plus bas rendent ce jugement explicite et discutable, elles ne le remplacent pas.

Les quatre critères de la feature prioritization

L’impact utilisateur. Combien de personnes sont concernées, et à quel point leur situation s’améliore ? Une fonctionnalité qui supprime une friction quotidienne pour la majorité des comptes pèse plus qu’une prouesse technique utile à une poignée d’entre eux. L’impact se formule idéalement en lien avec un KPI : activation, rétention, taux de conversion, temps gagné.

L’effort. Jours de design, de développement et de tests, mais aussi le risque technique : une fonctionnalité qui impose de retoucher l’architecture ou de rembourser de la dette technique au passage coûte bien plus que son estimation.

L’alignement stratégique. Une fonctionnalité peut avoir un impact immédiat et éloigner le produit de sa cible, par exemple en répondant au besoin très particulier d’un gros client atypique. La roadmap produit et les OKR du trimestre servent de filtre.

Le coût du délai. Que perd-on à livrer dans six mois plutôt que maintenant ? Une échéance réglementaire, un concurrent qui vient de sortir l’équivalent ou une fonctionnalité qui en débloque trois autres changent la réponse. L’urgence ne doit pas écraser l’impact, mais elle compte.

Les méthodes de priorisation des fonctionnalités

La matrice impact/effort

Quatre quadrants : impact fort et effort faible (à faire en premier), impact fort et effort élevé (à planifier comme un vrai projet), impact faible et effort faible (quand il reste du temps), impact faible et effort élevé (à abandonner). Elle se construit en une heure sur un tableau blanc et suffit à la plupart des équipes de moins de dix personnes. Sa limite est connue : tout le monde place ses propres idées en haut à gauche.

RICE

Sean McBride a créé RICE chez Intercom pour comparer une petite amélioration qui touche tout le monde à une grosse qui touche quelques comptes. Quatre notes : la portée (Reach, en nombre d’utilisateurs ou d’événements par période), l’impact (de 0,25 pour minime à 3 pour massif), la confiance (100 % haute, 80 % moyenne, 50 % faible, en dessous « pur pari ») et l’effort (en personnes-mois). Le score multiplie les trois premières et divise par la dernière.

La note de confiance fait la valeur de RICE : elle oblige à distinguer ce que l’équipe sait de ce qu’elle suppose. McBride lui-même prévient que le score n’est pas une règle absolue et qu’il existe de bonnes raisons de lancer un projet moins bien noté.

MoSCoW

Créée en 1994 par Dai Clegg, alors chez Oracle, puis reprise dans la méthode DSDM, MoSCoW classe les éléments en Must have (sans quoi la livraison n’a pas de sens), Should have (important mais contournable), Could have (si le temps le permet) et Won’t have (exclu de ce périmètre). DSDM y attache une règle que presque tout le monde oublie : les Must have ne devraient pas dépasser 60 % de l’effort prévu, les 40 % restants servant de marge pour tenir la date quand une estimation dérape. Si tout est Must, la méthode ne sert à rien. Elle est à son meilleur pour cadrer une release, un sprint planning ou le périmètre d’un MVP.

Le modèle Kano

Publié par Noriaki Kano en 1984, le modèle classe les attributs d’un produit selon la satisfaction qu’ils produisent. Les fonctionnalités de base sont attendues : leur absence agace, leur présence ne rapporte rien. Les fonctionnalités de performance améliorent la satisfaction proportionnellement à leur qualité. Les fonctionnalités attractives surprennent et fidélisent sans que personne ne les ait demandées. Kano ajoute deux catégories souvent omises : les attributs indifférents, qui ne méritent pas d’être construits, et les attributs inversés, qui déplaisent à une partie des utilisateurs. Son enseignement le plus utile : les catégories glissent avec le temps. L’authentification à deux facteurs était différenciante il y a dix ans, c’est aujourd’hui un prérequis.

WSJF et coût du délai

Le Weighted Shortest Job First vient des travaux de Don Reinertsen sur le coût du délai (The Principles of Product Development Flow, 2009) et a été formalisé dans le framework SAFe. On divise le coût du délai (valeur business, criticité temporelle, réduction de risque) par la taille du travail, et on commence par les ratios les plus élevés. La formule complète convient aux grandes organisations ; la question qu’elle pose, « combien coûte chaque mois d’attente ? », vaut pour n’importe quelle équipe.

Shape Up, l’alternative sans backlog

Basecamp a documenté en 2019, dans Shape Up de Ryan Singer, une approche qui renonce au backlog. Toutes les six semaines, une « table des paris » réunit les dirigeants autour de projets cadrés en amont, avec un appétit fixé à l’avance (une à deux semaines, ou six). Ce qui n’est pas retenu disparaît. L’idée transposable ailleurs : décider d’abord combien de temps un sujet mérite, puis ce qu’on peut faire dans ce temps.

Choisir une méthode

Le choix compte moins que la régularité. Une matrice impact/effort revue chaque mois bat un RICE calculé une fois en séminaire puis oublié. Une méthode sert vraiment quand elle fait émerger un désaccord : deux personnes qui notent le même effort 2 et 8 ont une conversation utile à avoir.

Remonter de la demande au besoin

Quand un client dit « je veux une intégration Salesforce », il décrit une solution. Le besoin derrière est peut-être « ne pas ressaisir deux fois les mêmes informations ». Ce besoin a plusieurs réponses possibles, import automatique, connecteur générique, export planifié, dont certaines coûtent cinq fois moins cher que l’intégration demandée.

Teresa Torres a donné une forme à ce réflexe avec l’arbre opportunités-solutions (Continuous Discovery Habits, 2021) : partir d’un résultat visé, cartographier les opportunités (les besoins non couverts), et ne discuter de solutions qu’une fois celles-ci classées. Prioriser des besoins plutôt que des fonctionnalités évite de comparer des pommes et des tickets Jira. C’est le travail de la discovery produit, nourri par les retours utilisateurs, à condition de les lire comme des symptômes et non comme des spécifications.

Les outils de gestion des retours (Productboard, Canny, Dovetail) regroupent désormais automatiquement tickets de support, transcriptions d’appels et demandes en thèmes pondérés par segment. Cela change la matière première, pas la décision : cinquante comptes gratuits qui demandent une chose ne valent pas trois clients qui pèsent la moitié du revenu, et aucun regroupement sémantique ne tranche cela à votre place.

Qui décide

Le product manager ou le product owner porte la décision finale, mais ne la prend pas seul. Le responsable technique estime l’effort réel et signale les dépendances. Le support apporte les irritants récurrents, les commerciaux les objections des prospects, les développeurs les opportunités d’optimisation que personne d’autre ne voit. C’est le périmètre classique du product management.

Un bon processus est transparent : chaque partie prenante peut lire pourquoi une fonctionnalité passe devant une autre. Un « non » accompagné d’une raison et d’un critère de réexamen (« on y revient si plus de dix clients payants le demandent ») est accepté. Un « non » sans explication revient par un autre canal.

Les erreurs classiques de priorisation

Céder à la voix la plus forte. Le plus gros client menace de partir sans la fonctionnalité X. La pression est réelle, mais si X ne sert qu’à lui et mobilise l’équipe deux mois, elle ne passe pas devant ce qui améliore le produit pour tous les autres. Le poids de ce compte dans le revenu et dans le risque de résiliation permet de décider froidement.

Oublier la dette technique. Empiler des fonctionnalités sur un code fragile revient à construire des étages sur des fondations qui s’affaissent. Réserver 15 à 20 % de chaque sprint à la dette évite l’arrêt complet au bout d’un an.

Ne jamais réviser. Le marché bouge, les données d’usage surprennent, un concurrent sort une offre. Une priorisation figée six mois est périmée ; une relecture mensuelle suffit.

Confondre urgent et important. Les équipes qui ne font pas la distinction passent leur temps à éteindre des feux et ne construisent jamais ce qui compte.

Sur-noter. Débattre une heure de la différence entre un impact de 3 et de 4 est du temps perdu. Le bon niveau de rigueur est celui qui clarifie le choix sans paralyser l’équipe.

Ne jamais retirer. La priorisation porte aussi sur ce qu’on supprime. Une fonctionnalité utilisée par 1 % des comptes impose sa maintenance et sa complexité d’interface aux 100 %. Peu d’équipes ont un rituel pour retirer ce qui n’a pas trouvé son usage.

Prioriser avec les données sans s’y enfermer

Les analytics d’usage montrent quelles fonctionnalités sont ouvertes, lesquelles sont ignorées et où les utilisateurs décrochent. Elles ramènent une demande à sa taille réelle : une fonctionnalité prioritaire sur le papier devient secondaire quand le problème qu’elle résout touche 2 % des comptes.

Les données disent ce qui se passe, rarement pourquoi. Un faible usage peut signifier que la fonctionnalité est inutile, ou qu’elle est introuvable dans l’interface. Une dizaine d’entretiens font la différence, d’où l’intérêt de croiser systématiquement données quantitatives et observation.

FAQ feature prioritization

Quelle méthode de priorisation choisir quand on lance un produit ?

La matrice impact/effort, ou MoSCoW pour délimiter le périmètre de la première version. Avant d’avoir des utilisateurs, les données nécessaires à un RICE sérieux n’existent pas et la portée se résume à des hypothèses. RICE devient pertinent une fois le produit instrumenté, avec quelques centaines de comptes actifs.

Quelle différence entre RICE et MoSCoW ?

RICE produit un classement continu, utile pour ordonner un backlog entier. MoSCoW produit quatre catégories, utile pour fixer le contenu d’une livraison datée. Beaucoup d’équipes utilisent les deux : RICE pour ordonner les candidats, MoSCoW pour décider ce qui entre dans la prochaine release.

À quelle fréquence faut-il re-prioriser le backlog ?

Une relecture rapide avant chaque sprint planning, une révision de fond chaque trimestre quand la roadmap est revue. Entre les deux, une nouvelle demande se compare aux éléments déjà classés plutôt que de passer en tête parce qu’elle est récente.

Comment Polara Studio priorise les fonctionnalités avec ses clients

Chez Polara Studio, la priorisation commence avant la première ligne de code. Pour un produit en lancement, nous utilisons MoSCoW avec un test simple, décrit dans notre guide pour créer son MVP : si retirer la fonctionnalité n’empêche pas de vérifier l’hypothèse principale, elle attend la version suivante. Pour un produit en place, nous passons à un scoring de type RICE, alimenté par les données d’usage que nous installons dès les premiers sprints.

Notre apport dans ces séances est la lecture technique de chaque candidat : effort réel, impact sur l’architecture, dépendances cachées, et pour les fonctionnalités IA une dimension de risque que nous détaillons dans notre article sur l’intégration de l’IA dans un SaaS. Cette double lecture évite les fonctionnalités notées « effort faible » qui absorbent ensuite trois sprints.