Quand on lance une application sur-mesure, les idées ne manquent pas. Le système de connexion, le tableau de bord, les notifications, l'export PDF... chaque fonctionnalité paraît indispensable quand on la décrit. Sauf qu'on ne peut pas tout faire en même temps, et surtout pas avec le même budget.
La méthode MoSCoW est là pour trancher. Elle force à classer chaque fonctionnalité dans l'une de quatre catégories, et surtout à assumer ce qui ne sera pas fait.
La méthode MoSCoW, c'est quoi ?
MoSCoW est un système de priorisation créé par Dai Clegg dans les années 1990. Le principe est simple : chaque fonctionnalité est classée dans l'une de ces catégories :
- Must Have : indispensable. Sans ça, le produit ne fonctionne pas.
- Should Have : important, mais le produit peut sortir sans.
- Could Have : ce serait bien, si le temps et le budget le permettent.
- Won't Have : on ne le fera pas. Point.
On l'utilise surtout sur des projets agiles, où les priorités bougent au fil des sprints. Mais le principe fonctionne pour n'importe quel projet qui a plus d'idées que de ressources (c'est-à-dire tous les projets).
Du cadrage au MVP, sans détours
Must Have : ce sans quoi rien ne tient
Les Must Have, ce sont les fonctionnalités sans lesquelles votre produit n'a pas de raison d'exister. Si vous construisez un site e-commerce, c'est le panier et le paiement. Si c'est un outil de gestion, c'est la connexion et l'accès aux données. Pas de Must Have livré = pas de livraison possible.
Should Have : la V2
Les Should Have sont les fonctionnalités qui apportent de la valeur, mais dont l'absence ne bloque personne. Un système de filtres avancés, un export CSV, un mode sombre. Le produit tourne sans, mais il serait meilleur avec. On les prévoit pour l'itération suivante.
Could Have : si on a le temps
Les Could Have, c'est la liste de souhaits. Des améliorations qui feraient plaisir mais qui ne changent pas grand-chose au produit. On les fait si le planning le permet, et on les coupe en premier quand il faut gagner du temps.
Won't Have : non
C'est la catégorie la plus utile et la plus sous-estimée. Dire explicitement qu'une fonctionnalité ne sera pas développée, ça évite les malentendus et les discussions qui reviennent en boucle. "On y avait pensé, on a décidé que non, voici pourquoi." C'est posé, tout le monde peut passer à autre chose.
Ce qui rend MoSCoW utile, c'est moins le classement en lui-même que la conversation qu'il provoque. Quand vous mettez toutes les fonctionnalités sur la table et que vous devez les trier, les désaccords sortent vite. Et c'est exactement ce qu'on veut : mieux vaut se disputer sur les priorités au début du projet qu'en plein développement.
Pourquoi ça marche
Tout le monde parle le même langage
Quand un client dit "c'est important" et qu'un développeur entend "c'est urgent", vous avez un problème. MoSCoW crée un vocabulaire partagé. Un Must Have, tout le monde sait ce que ça veut dire : sans ça, on ne livre pas. Ça coupe court aux interprétations.
Les ressources vont au bon endroit
En concentrant l'effort sur les Must Have d'abord, l'équipe ne s'éparpille pas. On ne perd pas trois jours sur un système de badges alors que l'authentification n'est pas terminée. Ça a l'air évident dit comme ça, mais sans cadre de priorisation, c'est exactement ce qui arrive.
Les priorités peuvent bouger
Votre liste n'est pas gravée dans le marbre. Un Should Have peut devenir un Must Have si les retours utilisateurs montrent qu'il manque quelque chose de fondamental. Un Must Have peut passer en Won't Have si une contrainte technique le rend irréaliste. Le classement vit avec le projet.
Le projet reste aligné avec la stratégie
Quand chaque fonctionnalité est classée, il devient plus facile de repérer celles qui ne servent pas vraiment les objectifs du produit. Ce filtre de priorisation évite de développer des choses "parce que le concurrent le fait" ou "parce que ce serait cool".
Comment mettre MoSCoW en place
Réunissez les bonnes personnes
Commencez par un atelier de priorisation. Mettez autour de la table les développeurs, le chef de projet et les personnes côté client qui connaissent le métier. Pas besoin de 15 personnes, mais il faut que ceux qui décident et ceux qui construisent soient dans la même pièce.
Listez tout, sans filtre
Faites une liste complète des fonctionnalités envisagées. Ne triez pas encore. Laissez chacun ajouter ses idées, y compris celles qui semblent accessoires. C'est en voyant tout sur la table qu'on prend de meilleures décisions.
Classez ensemble, et documentez pourquoi
Prenez chaque fonctionnalité et classez-la. Le débat va venir naturellement : quelqu'un dira "c'est un Must Have" et quelqu'un d'autre dira "non, c'est un Should Have". C'est normal et c'est sain.
Ce qui compte, c'est de noter les raisons derrière chaque classement. Dans trois mois, quand quelqu'un demandera pourquoi telle fonctionnalité n'a pas été développée, vous pourrez retrouver la décision et son contexte.
Utilisez un outil de suivi
Un tableau Kanban, un tableur, un outil de gestion de projet, peu importe la forme. L'idée, c'est que le classement soit visible par tout le monde et facile à mettre à jour. Si le classement vit dans la tête du chef de projet, il ne sert à rien.
Révisez régulièrement
La liste de priorités n'est pas un document qu'on écrit une fois et qu'on range. Reprenez-la à chaque fin de sprint ou à chaque jalon du projet. Les priorités bougent, les contraintes changent, les retours utilisateurs arrivent. Le classement doit suivre.
Les pièges à éviter
Tout mettre en Must Have
C'est le piège numéro un. Si tout est prioritaire, rien ne l'est. J'ai vu des projets où la colonne Must Have contenait 80% des fonctionnalités. À ce stade, le classement ne sert plus à rien.
Une solution qui fonctionne : limitez le nombre de Must Have par sprint. Forcez-vous à en choisir 3 ou 4 maximum. Si quelque chose doit entrer, autre chose doit sortir.
Laisser les opinions dominer les données
Chacun a ses préférences, et la position dans l'entreprise influence la perception des priorités. Le directeur commercial poussera les fonctionnalités de reporting, le CTO voudra refactorer l'architecture. Pour éviter que le classement devienne un rapport de force, appuyez-vous sur des données : retours utilisateurs, analytics, contraintes techniques documentées.
Croire que MoSCoW suffit
MoSCoW est un outil de tri, pas une méthode de gestion de projet complète. Il ne remplace pas les user stories, les estimations de charge, ou les rétrospectives. C'est une brique parmi d'autres. Utilisé seul, sans le reste de la mécanique agile, il perd une bonne partie de son intérêt.
La méthode MoSCoW ne va pas résoudre tous vos problèmes de priorisation. Mais elle pose un cadre qui oblige à faire des choix explicites. Et dans un projet applicatif, les choix explicites battent toujours les choix implicites.
