Dans presque tous les projets, la liste des souhaits grandit plus vite que le temps et le budget disponibles. Le client veut « tout, tout de suite », chaque membre de l’équipe a ses idées, et à la fin personne ne sait plus ce qui est vraiment essentiel. La méthode MoSCoW est une technique de priorisation simple qui aide à trancher : elle classe chaque exigence dans l’une de quatre catégories, de l’indispensable à ce qui attendra.
Dans cet article, vous découvrirez ce que signifie chaque catégorie, comment appliquer la méthode étape par étape, un exemple concret et les pièges les plus courants.
D’où vient la méthode MoSCoW ?
La méthode a été proposée dans les années 1990 par Dai Clegg, alors chez Oracle au Royaume-Uni, et elle a été largement diffusée par DSDM, une méthode de développement agile. Son nom est un acronyme formé par les initiales de quatre expressions anglaises : Must have, Should have, Could have et Won’t have. Les deux « o » ont simplement été ajoutés pour rendre le mot prononçable, ce qui évoque au passage la ville de Moscou.
Les quatre catégories
| Catégorie | Traduction | Signification | Question test |
|---|---|---|---|
| Must have | Indispensable | Sans cette exigence, le livrable n’a pas de sens, est illégal ou dangereux. | « Peut-on livrer sans ? » Si la réponse est non, c’est un Must. |
| Should have | Important | Exigence importante, mais il existe une solution de contournement temporaire. | « Est-ce pénible mais supportable de s’en passer un temps ? » |
| Could have | Souhaitable | Amélioration appréciable, à faible impact si elle manque. | « Est-ce un plus agréable plutôt qu’un besoin ? » |
| Won’t have (this time) | Pas cette fois | Exigence explicitement exclue de cette version ou de cette période. | « Peut-on la reporter sans regret ? » |
La dernière catégorie est souvent sous-estimée. Dire clairement ce qui ne sera pas fait évite les malentendus et protège l’équipe contre l’ajout incessant de nouvelles demandes. « Won’t have » ne signifie pas « jamais » : l’exigence pourra être réévaluée lors d’une prochaine version.
Exemple : l’application d’une boulangerie
Une boulangerie de quartier souhaite lancer une application de commande en ligne avec un budget limité et une date de lancement fixée avant les fêtes. Voici comment ses besoins pourraient être classés :
- Must have : consulter les produits du jour, passer une commande, choisir un créneau de retrait, payer en ligne de façon sécurisée.
- Should have : recevoir une confirmation par e-mail, modifier ou annuler une commande.
- Could have : enregistrer ses produits favoris, voir la photo de chaque produit.
- Won’t have (cette fois) : livraison à domicile, programme de fidélité, version multilingue.
Grâce à ce classement, l’équipe sait exactement ce qui doit être prêt au lancement. Si le temps manque, elle sacrifiera d’abord les « Could », puis éventuellement certains « Should », sans jamais mettre en danger le cœur de l’application.
Appliquer la méthode étape par étape
- Fixez le cadre. Précisez l’horizon concerné : une version, un sprint, une phase du projet. Une priorité n’a de sens que dans un périmètre donné.
- Listez toutes les exigences. Rédigez-les de façon claire et vérifiable, sans encore les classer.
- Réunissez les parties prenantes. Client, utilisateurs, équipe technique : la priorisation doit être partagée pour être respectée.
- Commencez par les Must. Soyez exigeant : pour chaque élément, demandez ce qui se passerait s’il n’était pas livré.
- Classez le reste en Should, Could et Won’t.
- Vérifiez l’équilibre. Comparez l’effort estimé des Must avec la capacité de l’équipe. La méthode DSDM recommande, par exemple, que les Must ne dépassent pas environ 60 % de l’effort total, afin de garder une marge de sécurité.
- Réévaluez régulièrement. Les priorités évoluent ; la liste doit être revue à chaque étape importante.
Les erreurs fréquentes
- Tout classer en Must. C’est l’erreur la plus répandue. Si tout est indispensable, rien ne l’est vraiment, et la méthode perd son intérêt.
- Confondre urgence et importance. Une demande pressante d’un interlocuteur influent n’est pas forcément essentielle au produit.
- Oublier les Won’t. Ne rien exclure explicitement laisse la porte ouverte aux attentes irréalistes.
- Prioriser seul. Un classement imposé par une seule personne sera contesté à la première difficulté.
- Ne jamais revoir la liste. Une priorisation figée devient vite déconnectée de la réalité du projet.
Avantages et limites
Le principal atout de MoSCoW est sa simplicité : quatre catégories compréhensibles par tous, sans calcul ni outil particulier. Elle facilite le dialogue avec des interlocuteurs non techniques et s’intègre bien aux approches agiles, où le temps et le budget sont fixes et le périmètre s’ajuste.
Ses limites sont tout aussi réelles. Elle ne classe pas les éléments à l’intérieur d’une même catégorie : deux « Should » restent au même niveau. Elle repose aussi sur le jugement des participants, ce qui peut introduire des biais. Pour aller plus loin, on la combine parfois avec d’autres outils, comme la matrice valeur/effort, qui compare l’intérêt d’une fonctionnalité à son coût de réalisation.
MoSCoW au-delà du logiciel
Même si elle est née dans le développement informatique, la méthode s’applique à de nombreux contextes : préparation d’un événement, rénovation d’un logement, organisation d’un déménagement ou même planification de ses révisions avant un examen. Dès qu’il faut choisir entre plusieurs tâches avec des ressources limitées, MoSCoW aide à se concentrer sur l’essentiel.
Conclusion
La méthode MoSCoW transforme une longue liste de souhaits en un plan d’action clair : ce qui est indispensable, ce qui est important, ce qui est un bonus et ce qui attendra. Bien utilisée, avec des Must réellement essentiels et des Won’t assumés, elle réduit les conflits, sécurise les délais et aide toute l’équipe à avancer dans la même direction.
Pour approfondir la planification, le suivi des risques et les méthodes agiles, découvrez les cours gratuits de Gestion de projet proposés sur Cursa.
