Retour au blog
Prioriser les fonctionnalités d'une application : 3 méthodes simples
Cadrage
Billel Loukit
En bref
Prioriser les fonctionnalités d'une application, c'est décider ce qui entre dans la première version et ce qui attend, avec une règle d'or : tout ce qui ne sert pas le parcours principal attend.
Le parcours principal d'abord : c'est l'enchaînement d'étapes qui permet à l'utilisateur d'obtenir ce pour quoi il a téléchargé l'app. Il passe avant tout le reste.
Méthode MoSCoW : chaque idée est classée en indispensable, importante, souhaitable ou « pas cette fois ».
Matrice valeur effort : on commence par ce qui apporte beaucoup aux utilisateurs pour peu d'effort.
Score RICE : un calcul simple pour départager une longue liste, surtout quand on a des chiffres d'usage.
Budget : une première version resserrée coûte moins cher et vous apprend plus vite ce qui compte vraiment.
Pourquoi prioriser les fonctionnalités de votre application ?
Parce que chaque fonctionnalité coûte du temps et de l'argent, et que beaucoup ne seront presque jamais utilisées. Selon le rapport 2019 de Pendo, un éditeur d'outils d'analyse, établi à partir des données d'usage de 615 de ses clients, 80 % des fonctionnalités d'un logiciel moyen sont rarement ou jamais utilisées.
Prioriser, ce n'est pas renoncer à vos idées. C'est choisir leur ordre, avec quatre bénéfices directs :
Vous lancez plus tôt. Moins de fonctionnalités, c'est moins de conception, de développement et de tests avant la sortie.
Vous dépensez au bon endroit. Le budget va à ce qui fait venir et revenir les utilisateurs, pas à des options que personne n'ouvre.
Votre app est plus simple à comprendre. Chaque bouton en plus est une décision de plus pour l'utilisateur. Une app qui fait une chose très bien se recommande facilement.
Vous apprenez de vrais utilisateurs. Une fois l'app en ligne, les données d'usage et les avis vous disent quoi construire ensuite, mieux que n'importe quelle réunion.
La règle d'or : tout ce qui ne sert pas le parcours principal attend
Le parcours principal est la suite d'étapes qui permet à l'utilisateur d'obtenir ce pour quoi il a téléchargé votre application. Tout ce qui le rend possible entre dans la première version, le reste attend.
Pour le trouver, complétez cette phrase : « Mon utilisateur ouvre l'app pour... ». Pour une app de réservation : réserver un créneau. Pour une app de fidélité : profiter de ses avantages. Pour un outil métier : faire une tâche plus vite qu'avant.
Écrivez ensuite ce parcours étape par étape, du premier écran au résultat. Puis, pour chaque idée de fonctionnalité, posez une seule question : sans elle, l'utilisateur peut-il aller au bout du parcours ?
Non : elle est indispensable.
Oui, mais moins bien : elle est importante, on l'étudie avec le budget.
Oui, sans différence : elle attend la version suivante.
Une exception : ce qui protège l'utilisateur ou vous met en règle ne se négocie pas. Connexion sécurisée, gestion des données personnelles, suppression du compte depuis l'app (exigée par Apple pour toute app qui permet d'en créer un) font partie du socle, même sans servir directement le parcours.
La méthode MoSCoW : classer vos fonctionnalités en quatre groupes
La méthode MoSCoW classe chaque fonctionnalité dans l'une de quatre catégories : Must have (indispensable), Should have (importante), Could have (souhaitable) et Won't have this time (pas cette fois). Elle est issue de la méthode agile DSDM, dont l'Agile Business Consortium donne les définitions de référence.
Catégorie | Définition | Le test |
|---|---|---|
Must have : indispensable | Le minimum utilisable que la version doit livrer | Sans elle, lancer l'app n'a pas de sens |
Should have : importante | Importante, mais pas vitale | Son absence est pénible, mais une solution provisoire existe |
Could have : souhaitable | Appréciée, avec moins d'impact si elle manque | C'est la première à sortir si le budget ou le calendrier se tend |
Won't have this time : pas cette fois | Écartée de cette version, d'un commun accord | On l'écrit noir sur blanc pour qu'elle ne revienne pas en douce |
L'Agile Business Consortium donne deux repères utiles : les fonctionnalités indispensables ne devraient généralement pas dépasser 60 % de l'effort prévu, et les souhaitables en représenter environ 20 %, qui servent de marge de sécurité. Si tout est « indispensable », c'est le signe qu'il faut revenir au parcours principal.
La catégorie « pas cette fois » est la plus sous-estimée. Elle rassure tout le monde : l'idée n'est pas perdue, elle est notée pour plus tard.
Matrice valeur effort et score RICE : départager les fonctionnalités
Quand MoSCoW laisse trop de fonctionnalités « importantes », deux outils aident à trancher : la matrice valeur effort, rapide et visuelle, et le score RICE, plus chiffré.
La matrice valeur effort
La matrice valeur effort croise ce qu'une fonctionnalité apporte, aux utilisateurs et à votre activité, avec ce qu'elle coûte à concevoir et à développer. Notez chaque idée de 1 à 3 sur les deux axes, puis placez-la dans l'une des quatre cases.
Valeur et effort | Effort faible | Effort élevé |
|---|---|---|
Valeur forte | À faire en premier : ce sont les gains rapides | À planifier, souvent en commençant par une version simple |
Valeur faible | Plus tard, s'il reste du temps et du budget | À écarter |
La valeur, c'est vous et vos utilisateurs qui l'estimez. L'effort, c'est l'équipe technique : une fonctionnalité qui paraît simple, comme « un petit chat entre client et pro », peut demander beaucoup de travail, et l'inverse est vrai aussi.
Le score RICE, expliqué simplement
Le score RICE a été présenté par Intercom, un éditeur de logiciels, dans un article de Sean McBride. Il note chaque fonctionnalité selon quatre critères :
Reach (portée) : le nombre de personnes touchées sur une période, par exemple par mois.
Impact : à quel point elle change l'expérience de chacune, de 0,25 (minime) à 3 (massif).
Confidence (confiance) : votre degré de certitude sur ces estimations : 100 %, 80 % ou 50 %.
Effort : le temps de travail nécessaire, compté en mois-personne chez Intercom.
Le calcul : portée × impact × confiance ÷ effort. Exemple fictif : une fonctionnalité utilisée par 400 personnes par mois, d'impact 2, avec 80 % de confiance et un effort de 2 obtient 400 × 2 × 0,8 ÷ 2 = 320. Une autre qui touche 1 000 personnes, d'impact 0,5, avec 50 % de confiance et un effort de 1 obtient 250. La première passe devant, alors qu'elle touche moins de monde.
RICE est surtout utile après le lancement, quand vous avez de vrais chiffres d'usage. Avant, la portée et l'impact restent des estimations : MoSCoW et la matrice valeur effort suffisent largement.
Exemple concret : l'indispensable d'une application comme Nowa
Pour Nowa, l'indispensable tient en un parcours : une cliente doit pouvoir réserver une prestation auprès d'une professionnelle disponible. Nowa permet de réserver une professionnelle de la beauté près de chez soi (coiffure, ongles, maquillage) : choix de la prestation, profil de la pro, réservation du créneau, le tout en quelques clics.
Ce parcours a deux côtés, et les deux doivent fonctionner dès le premier jour. Une cliente qui ne trouve aucune professionnelle disponible, ou une professionnelle qui ne peut pas proposer ses créneaux, et la promesse tombe.
Voici comment on applique MoSCoW à une application de ce type. La ligne « indispensable » reprend ce que fait Nowa ; les autres lignes sont des exemples courants pour illustrer la méthode, pas la feuille de route du projet.
Catégorie | Côté cliente | Côté professionnelle |
|---|---|---|
Indispensable | Choisir une prestation, consulter le profil de la pro, réserver un créneau | Présenter son profil et ses prestations, proposer ses créneaux, recevoir les réservations |
Important | Recevoir un rappel avant le rendez-vous | Gérer facilement son agenda et ses disponibilités |
Souhaitable | Laisser un avis, retrouver une pro déjà réservée | Statistiques sur son activité |
Pas cette fois | Programme de fidélité, parrainage | Outils de gestion avancés |
La question décisive, pour chaque ligne : sans cette fonctionnalité, une cliente peut-elle réserver sa prestation ? Si oui, elle peut attendre la version suivante, quand les premières réservations réelles montreront ce qui manque vraiment. Pour aller plus loin sur ce type de projet, lisez notre guide sur l'application de réservation.
Voir le projet Nowa dans notre portfolio.
La priorisation continue après le lancement. Pour NutriGenius, une app qui aide à bien manger avec ses contraintes alimentaires, nous avons aussi conseillé l'équipe sur sa feuille de route, c'est-à-dire l'ordre des fonctionnalités à construire ensuite. Voir le projet NutriGenius.
Comment prioriser en pratique, et tenir votre budget
En pratique, la priorisation se fait en une séance de travail, en cinq étapes.
Videz votre tête. Listez toutes les idées de fonctionnalités, sans filtre, y compris celles de vos associés, de vos clients et de vos équipes.
Écrivez le parcours principal. En une phrase, puis étape par étape. C'est votre filtre.
Classez avec MoSCoW. Une catégorie par idée, en gardant les indispensables sous la barre des 60 % de l'effort.
Départagez les « importantes ». Avec la matrice valeur effort, en faisant estimer l'effort par l'équipe technique.
Notez le reste dans une feuille de route. Les idées « pas cette fois » seront réévaluées après le lancement, avec les données d'usage et les avis.
Le résultat trouve sa place dans votre cahier des charges d'application, à la rubrique « parcours et fonctionnalités ». Il dessine aussi votre MVP, la première version minimale de votre application.
Ce que ça change sur le budget. Chez La Belle App, une application démarre à 5 000 € HT, design, développement et publication sur les stores inclus. Le prix dépend du type d'app, simple ou avec plusieurs profils d'utilisateurs (un côté client et un côté pro, par exemple), et de la complexité des fonctionnalités : paiement en ligne, recherche de professionnels à proximité, messagerie, connexion à vos outils. Chaque fonctionnalité reportée à la version suivante allège le premier devis. Notre guide sur le prix d'une application mobile détaille ce qui fait varier un budget.
C'est l'un des grands avantages du sur mesure : vous ne payez que ce qui sert votre parcours principal. Un logiciel du marché, lui, vous facture chaque mois des dizaines d'options dont vous n'avez pas besoin, tout en vous privant de celles qui font votre différence.
Votre liste de fonctionnalités dépasse votre budget ? Réservez un appel gratuit de 30 minutes : on identifie ensemble le parcours principal de votre app et ce qui peut attendre, et vous recevez un devis précis sous 48 h. Réserver mon appel
Questions fréquentes
Combien de fonctionnalités mettre dans la première version d'une application ?
Il n'y a pas de bon nombre : il faut toutes celles qui permettent d'aller au bout du parcours principal, plus les obligations légales et celles des stores. Repère utile de la méthode MoSCoW : les indispensables ne devraient généralement pas dépasser 60 % de l'effort prévu.
Quelle méthode de priorisation choisir ?
Pour une première version, MoSCoW suffit dans la plupart des cas, complétée par la matrice valeur effort pour départager les fonctionnalités importantes. Le score RICE devient utile après le lancement, quand vous disposez de vrais chiffres d'usage.
Qui doit décider des priorités ?
Le porteur de projet tranche, parce que c'est son budget et son activité. Les utilisateurs l'éclairent sur la valeur, l'agence sur l'effort et les risques techniques.
Que faire des fonctionnalités qui ne sont pas retenues ?
Notez-les dans une feuille de route, avec la raison de leur report. Après le lancement, réévaluez-les à la lumière des données d'usage et des avis : certaines deviendront prioritaires, d'autres perdront tout intérêt.
Peut-on ajouter des fonctionnalités après la sortie de l'application ?
Oui, c'est même le principe. Chaque mise à jour publiée sur les stores peut apporter de nouvelles fonctionnalités. Avec Flutter, une seule base de code sert l'iPhone et Android, donc chaque ajout profite aux deux.
Sources
Pendo, The 2019 Feature Adoption Report : part des fonctionnalités rarement ou jamais utilisées, à partir des données d'usage de 615 clients. Pendo est un éditeur d'outils d'analyse produit.
Agile Business Consortium, What is MoSCoW Prioritization? : définitions des quatre catégories et repères d'effort (60 % et 20 %).
Intercom, RICE: Simple prioritization for product managers (Sean McBride, janvier 2018) : critères, échelles et calcul du score RICE.
Apple Developer, App Review Guideline 5.1.1(v) Account deletion : suppression du compte depuis l'app.
La Belle App, projet Nowa : réservation d'une professionnelle de la beauté, entre clientes et professionnelles.
La Belle App, projet NutriGenius : accompagnement sur la feuille de route.
