Méthode MoSCoW : le guide complet de priorisation
Guide complet de la méthode MoSCoW : Must, Should, Could, Won't, atelier pas à pas, règle des 60/20/20 et pièges à éviter pour cadrer un MVP ou un projet.
Par l’équipe RoadmapHero · Mis à jour le · 9 min de lecture
L’essentiel
- MoSCoW répartit les exigences en Must have, Should have, Could have et Won’t have (this time) par rapport à une échéance, une release ou un objectif, sans les classer entre elles.
- Un item n’est un Must have que si l’on annulerait le lancement sans lui ; si l’on sortirait quand même en corrigeant après, c’est un Should have.
- Appliquez la règle DSDM des 60/20/20 : les Must ne dépassent pas environ 60 % de l’effort, en laissant environ 20 % aux Should et 20 % aux Could comme marge.
- MoSCoW est un outil de cadrage, pas de séquencement : utilisez-la pour fixer le périmètre, puis un score quantitatif comme RICE pour ordonner le travail dans chaque catégorie.
La méthode MoSCoW répond mieux que tout autre framework à une question précise : « qu'est-ce qui est vraiment dans le périmètre ? ». Quand la deadline est fixe, quand un MVP doit sortir, quand chaque partie prenante défend sa fonctionnalité fétiche, MoSCoW force une décision partagée et explicite sur ce qui est non négociable, important, souhaitable — et exclu. Ce guide détaille les quatre catégories, l'animation d'un atelier MoSCoW pas à pas, la règle des 60/20/20 qui rend les plans honnêtes, et les limites de la méthode.
Qu'est-ce que la méthode MoSCoW ?
MoSCoW a été créée par Dai Clegg chez Oracle dans les années 1990, puis érigée en pratique centrale du framework agile DSDM. L'acronyme recouvre quatre catégories — Must have, Should have, Could have, Won't have (this time) — avec deux « o » ajoutés pour la prononciation. Son idée fondatrice : sur un projet à échéance et ressources fixes, le périmètre est la seule variable. MoSCoW rend cette variable explicite avant la pression, au lieu de la négocier en panique deux semaines avant le lancement. Contrairement aux frameworks de scoring comme RICE, MoSCoW ne classe pas les items entre eux : elle les répartit en catégories, relativement à un objectif, une release ou une date.
Les 4 catégories MoSCoW expliquées
Must have — sans lui, la release échoue
Un Must have est une exigence sans laquelle la release n'est pas viable : illégale, dangereuse, inutilisable ou sans objet. Le test décisif : « si cet item manque le jour du lancement, annule-t-on le lancement ? » Si la réponse honnête est « non, on sortirait quand même et on corrigerait après », ce n'est pas un Must. Exemples pour un MVP de paiement : encaisser une carte bancaire, la conformité PCI, la gestion des remboursements. Pas un Must : un beau dashboard sur ces paiements.
Should have — important, douloureux à omettre, survivable
Un Should have est important et attendu, mais la release lui survit — éventuellement avec un contournement (processus manuel, macro support, délai). Son absence pénalise l'adoption ou l'efficacité, pas la viabilité. Les Should sont les premiers candidats au report quand les Must débordent.
Could have — souhaitable si la capacité le permet
Les Could have forment la couche de confort : des améliorations plus petites, à l'impact réel mais limité, abandonnées en premier quand le planning glisse. Dans DSDM, ils constituent précisément la marge de contingence planifiée : du travail qu'on a l'intention de faire, et qu'on peut sacrifier sans rien renégocier.
Won't have (this time) — explicitement hors périmètre
La catégorie la plus sous-estimée. Les Won't have sont des décisions tracées et visibles : « pas dans cette release ». Les écrire tue l'ambiguïté qui nourrit le scope creep, et rassure les parties prenantes : « non » signifie « pas maintenant », pas « jamais ». Gardez les Won't au backlog — beaucoup deviennent candidats au cycle suivant, et une roadmap Now/Next/Later est leur destination naturelle.
Quand utiliser MoSCoW (et quand s'abstenir)
Cadrage de MVP : séparer « le produit n'existe pas sans ça » de « les investisseurs vont adorer » est exactement la frontière Must/Should.
Projets à deadline : conformité réglementaire, lancement sur un salon, livraison contractuelle — date fixe, périmètre variable.
Planification de release : s'accorder avec les parties prenantes sur ce que la prochaine version garantit vs ce qu'elle peut inclure.
Migration ou refonte : décider quels comportements historiques doivent être repris à l'identique et lesquels peuvent attendre.
Évitez en revanche MoSCoW comme seule méthode de priorisation continue d'un backlog produit : quatre catégories ne peuvent pas ordonner les 30 items du panier Should, et c'est précisément dans cet ordre que se logent les vraies décisions (voir la section limites).
Animer un atelier MoSCoW, pas à pas
Préparer (avant la réunion). Listez les items candidats avec une description d'une ligne et un effort approximatif. Diffusez la liste 48 h avant. Invitez les décideurs : PM, lead tech, design, plus le sponsor. Six à huit personnes maximum.
Poser le cadre (10 min). Énoncez l'objet du cadrage (« release 2.0, sortie le 31 mars ») et la définition de chaque catégorie, surtout le test du Must : « annulerait-on le lancement sans lui ? ». Affichez les deux au mur.
Première passe silencieuse (15 min). Chaque participant catégorise tous les items de son côté. La passe silencieuse évite l'ancrage sur la voix la plus forte.
Confronter et débattre (30–45 min). Révélez les votes. Les items consensuels sont classés immédiatement. Ne débattez que des divergences, en commençant par les désaccords Must/Should — la frontière qui compte le plus. Timeboxez chaque débat à 5 minutes ; en cas de blocage, l'item devient provisoirement Should et reçoit un responsable chargé d'apporter des preuves.
Vérifier l'équilibre d'effort (15 min). Additionnez l'effort par catégorie et confrontez-le à la règle des 60/20/20 ci-dessous. C'est à cette étape que la plupart des ateliers découvrent que leur plan est une fiction — et le corrigent.
Tracer et publier. Consignez chaque catégorisation, Won't compris, avec sa justification en une phrase. Partagez-la avec toutes les personnes concernées : une décision MoSCoW non publiée est renégociée dans le mois. Une bonne communication avec les parties prenantes représente la moitié de la valeur de l'exercice.
La règle des 60/20/20
La recommandation la plus opérationnelle de DSDM : sur l'effort total de livraison, visez approximativement
Catégorie | Part de l'effort | Rôle dans le plan |
|---|---|---|
Must have | ≤ 60 % | Le minimum garanti |
Should have | ~ 20 % | Attendu, premier à glisser |
Could have | ~ 20 % | Marge de contingence |
La logique : si les Must consomment 90 % de la capacité, un développeur malade ou une story sous-estimée casse le périmètre garanti — précisément ce que vous aviez promis de ne jamais casser. Maintenir les Must à 60 % permet d'absorber les imprévus en sacrifiant d'abord les Could, puis les Should, tout en livrant toujours 100 % des Must. Les équipes qui appliquent cette règle livrent « à l'heure avec un peu moins » ; les autres livrent « en retard avec des excuses ».
Pièges : quand tout devient Must
L'inflation de Must : l'échec classique. Les parties prenantes comprennent que Must = garanti, donc tout devient Must. Antidotes : le test « annule-t-on le lancement ? », le plafond de 60 % d'effort, et une justification écrite exigée par Must.
La catégorie au galon : les items du sponsor sont Must parce que le sponsor l'a dit. Imposez la passe silencieuse et jugez des arguments, pas des titres de poste.
Le panier Won't vide : une session MoSCoW qui n'exclut rien n'a rien décidé. Si Won't est vide, la liste était pré-filtrée ou le groupe évite le conflit.
La catégorisation gravée dans le marbre : les catégories sont relatives à une échéance. Quand la deadline ou le contexte change, rejouez l'exercice — un Should de mars peut être un Must de juin.
L'absence d'estimation : catégoriser sans effort, même approximatif, rend le contrôle 60/20/20 impossible et le plan invérifiable.
Limites pour un portefeuille produit continu
MoSCoW est un outil de cadrage, pas de séquencement. Trois limites structurelles apparaissent dès qu'on l'étire au-delà des releases :
Aucun ordre à l'intérieur des catégories : avec 25 Should have, lequel construire en premier ? MoSCoW est muette ; il faut un score.
Aucun arbitrage valeur/coût : un Must à 6 mois et un Must à 2 jours sont indiscernables. Rien dans la méthode ne récompense les items peu coûteux à forte valeur.
Relative à une deadline par construction : un produit continu n'a pas d'échéance unique, donc « Must pour quoi ? » perd son sens, et les catégories deviennent insidieusement des synonymes de « priorité haute/moyenne/basse » — exactement le flou que MoSCoW devait éliminer.
Pour un backlog vivant, utilisez MoSCoW aux frontières (ce qui entre dans le trimestre) et une méthode quantitative à l'intérieur — voir comment bien prioriser son backlog pour un comparatif complet des frameworks.
Combiner MoSCoW avec un scoring quantitatif
Les organisations les plus solides traitent MoSCoW et le scoring comme deux étages d'un même pipeline : MoSCoW décide ce qui entre, le scoring décide dans quel ordre. Concrètement : animez l'atelier MoSCoW pour figer le périmètre de la release, puis scorez les Must et les Should avec RICE ou un modèle pondéré pour séquencer le travail et révéler les mauvaises affaires cachées (un Should au score énorme doit faire questionner un Must médiocre). Dans RoadmapHero, les équipes modélisent cela directement : un champ personnalisé ou un label porte la catégorie MoSCoW, tandis que le HeroScore — score multi-critères configurable combinant valeur business liée aux OKR, valeur utilisateur issue du feedback Customer Voice, effort, risque et urgence — ordonne le backlog au sein de chaque catégorie. La vue roadmap se partage ensuite en un clic, avec des viewers illimités : la décision de périmètre et son séquencement restent visibles, au lieu de survivre en photo d'atelier. Essai gratuit, tarifs transparents en euros, sans engagement.
Questions fréquentes
Que signifie l'acronyme MoSCoW ?
MoSCoW signifie Must have, Should have, Could have et Won't have (this time). Les « o » minuscules ont été ajoutés pour rendre l'acronyme prononçable. La méthode vient des travaux de Dai Clegg chez Oracle et a été popularisée par le framework agile DSDM.
Combien d'items doivent être des Must have ?
DSDM recommande que les Must have ne consomment pas plus d'environ 60 % de l'effort de livraison, en laissant 20 % aux Should have et 20 % aux Could have. Au-delà de 60 %, le plan n'a plus de marge et le moindre imprévu se transforme en deadline manquée.
Quelle est la différence entre MoSCoW et RICE ?
MoSCoW répartit les items en quatre catégories selon leur nécessité pour un périmètre ou une échéance ; RICE calcule un score numérique à partir du Reach, de l'Impact, de la Confidence et de l'Effort pour classer les items. MoSCoW est plus rapide et lisible pour les parties prenantes ; RICE donne un ordre plus fin. Beaucoup d'équipes cadrent avec MoSCoW, puis séquencent avec RICE.
Un « Won't have » est-il définitivement abandonné ?
Non. Won't have signifie « pas dans cette release ou cette période ». C'est une décision explicite et tracée qui protège le périmètre tout en gardant l'idée au backlog pour un cycle futur — ce qui la rend beaucoup plus facile à accepter pour les parties prenantes.
MoSCoW est-elle encore pertinente pour une équipe produit agile ?
Oui, pour les décisions de cadrage : définition de MVP, planification de release, projet à deadline. Pour la priorisation continue d'un backlog produit vivant, ses quatre catégories sont trop grossières : la plupart des équipes la complètent avec un score quantitatif comme RICE, WSJF ou un score configurable comme le HeroScore de RoadmapHero.