Méthode MoSCoW : définition, exemple et mode d'emploi

La méthode MoSCoW est une technique de priorisation qui aide une équipe à décider ce qui sera livré, et ce qui ne le sera pas, dans un délai et un budget fixés. Elle sert aussi bien à cadrer la création d’un site internet qu’à ordonner le backlog d’un produit en mode agile. Voici sa définition, la règle d’effort recommandée par le cadre DSDM, un exemple chiffré, son articulation avec les user stories et les outils pour l’appliquer.

Réponse courte : la méthode MoSCoW classe chaque exigence d’un projet en quatre catégories : Must have (indispensable), Should have (important mais contournable), Could have (souhaitable) et Won’t have this time (exclu de cette échéance). Imaginée par Dai Clegg en 1994 et formalisée par la méthode agile DSDM, elle s’applique à un délai fixe. Le DSDM recommande que les Must have ne dépassent pas 60 % de l’effort et qu’environ 20 % de l’effort soit placé en Could have, qui servent de marge si le planning dérape.

Qu’est-ce que la méthode MoSCoW ?

MoSCoW est une méthode de priorisation des exigences : fonctionnalités d’un site, user stories d’un produit, livrables d’un projet ou tâches d’une équipe. Au lieu d’un classement 1, 2, 3, 4 qui provoque des débats sans fin sur des éléments d’importance voisine, elle impose quatre niveaux aux définitions précises. Chaque partie prenante sait ainsi ce qui est garanti, ce qui est probable et ce qui est exclu.

L’Agile Business Consortium, qui maintient le cadre DSDM, juge qu’une simple numérotation 1, 2, 3, 4 traite mal les éléments d’importance voisine, alors que les libellés MoSCoW indiquent clairement ce qui est attendu pour chaque élément.

Que signifie MoSCoW ?

MoSCoW est un acronyme formé des initiales de Must, Should, Could et Won’t. Les deux « o » minuscules n’ont aucun sens : ils ont été ajoutés pour rendre le mot prononçable, d’où la graphie particulière. Le nom n’a donc rien à voir avec la ville de Moscou. Le DSDM précise même que MUST peut se lire comme l’acronyme de Minimum Usable SubseT, le sous-ensemble minimum utilisable que le projet garantit de livrer.

D’où vient la méthode ?

Selon Wikipédia, la méthode a été développée par Dai Clegg en 1994 pour le développement rapide d’applications (RAD), puis utilisée de façon extensive avec la méthode DSDM à partir de 2002. Elle est souvent associée au timeboxing : quand l’échéance est fixe, on ajuste le périmètre plutôt que la date.

Les quatre catégories MoSCoW en détail

Must have : le minimum indispensable

Ce sont les exigences sans lesquelles la livraison n’a pas de sens, ou dont l’absence rendrait la solution illégale ou dangereuse. Le test proposé par l’Agile Business Consortium est simple : « que se passe-t-il si cette exigence n’est pas satisfaite ? ». Si la réponse est « on annule, il est inutile de livrer sans elle », c’est un Must have. S’il existe un contournement, même manuel et pénible, c’est un Should have ou un Could have.

Should have : important mais contournable

Ces exigences apportent une valeur réelle et sont attendues, mais leur absence temporaire ne bloque pas la mise en service : une solution de repli existe. Elles peuvent être aussi importantes qu’un Must have, sans être aussi critiques dans le temps. Pour départager un Should d’un Could, le DSDM conseille de mesurer la gêne causée par l’absence de l’exigence, en valeur métier ou en nombre de personnes concernées.

Could have : souhaitable si le temps le permet

Ce sont les améliorations appréciables, au plus faible impact si elles manquent. Elles forment la principale réserve de sécurité du projet : quand l’échéance est menacée, ce sont elles que l’on retire en premier.

Won’t have this time : exclu de cette échéance

Ces exigences ont été explicitement écartées pour la période en cours. Les noter n’est pas un détail : cela clarifie le périmètre, évite qu’elles reviennent par la petite porte et alimente la feuille de route suivante. Le « this time » compte : une idée en Won’t have n’est pas abandonnée, elle est reportée et sera réévaluée.

La règle des 60 % du DSDM

C’est le point que la plupart des présentations de MoSCoW oublient. Classer des exigences ne suffit pas, encore faut-il que la répartition soit tenable. Le cadre DSDM, tel que décrit par l’Agile Business Consortium (page consultée le 19/10/2026), recommande :

• de limiter les Must have à 60 % au maximum de l’effort de réalisation, niveau auquel l’équipe peut s’engager avec confiance ;
• de constituer une réserve de Could have représentant environ 20 % de l’effort ;
• d’exclure les Won’t have du calcul.

Au-delà de 60 % de Must have, le risque d’échec augmente, sauf si l’équipe connaît parfaitement le sujet, que les estimations sont fiables et que rien d’imprévu ne peut survenir. Ces pourcentages s’entendent en effort (jours de travail), pas en nombre d’exigences : dix petites fonctionnalités Must have peuvent peser moins qu’une seule intégration complexe.

Comment faire une analyse MoSCoW

Fixer l’échéance et réunir les bonnes personnes

MoSCoW n’a de sens qu’avec une contrainte claire : une date de mise en ligne, un sprint, une version, un budget. Réunissez ensuite les personnes qui décident et celles qui réalisent, pour que les priorités soient à la fois souhaitables et faisables.

Partie prenante	Rôle dans la priorisation MoSCoW
Dirigeant ou sponsor	Valide les priorités et arbitre selon les enjeux business
Chef de projet ou product owner	Anime les ateliers de priorisation et challenge les choix
Experts métiers	Apportent leur connaissance des processus et des besoins
Utilisateurs finaux	Donnent leur avis sur la valeur de chaque besoin
Équipe technique	Évalue la faisabilité et estime l’effort de chaque exigence

Lister toutes les exigences

Inventoriez de façon exhaustive les fonctionnalités, contenus et tâches envisagés, chacun formulé de manière assez précise pour être estimé. Une exigence floue (« un beau site ») ne peut pas être priorisée ; « une page produit avec photos, prix, stock et ajout au panier » le peut.

Classer chaque élément dans une catégorie

Appliquez la question test du Must have à chaque élément. Une pratique utile consiste à faire classer chaque participant individuellement avant d’en discuter, pour éviter que la première opinion exprimée n’oriente tout le groupe. Les désaccords sont ensuite arbitrés par la personne qui porte la responsabilité métier.

Vérifier la répartition de l’effort

Additionnez les estimations par catégorie. Si les Must have dépassent 60 % de l’effort total, il faut soit rétrograder certains éléments, soit découper les plus gros, soit desserrer la contrainte de délai ou de budget.

Valider, puis réviser à chaque étape

Faites valider la liste par le décideur et partagez-la. Les priorités ne sont pas figées : à la fin de chaque sprint ou incrément, les exigences non livrées sont reclassées. Un Could have non réalisé peut devenir un Won’t have pour l’incrément suivant, ou remonter si le contexte change.

Exemple concret de priorisation MoSCoW

L’exemple ci-dessous est illustratif : il ne décrit pas un projet réel, et les estimations en jours sont des ordres de grandeur choisis pour montrer le calcul. Le cas : la création du site e-commerce d’un artisan, avec une mise en ligne fixée dans trois mois.

Exigence	Catégorie	Pourquoi	Effort estimé
Catalogue et fiches produits	Must have	Sans produits, rien à vendre	12 jours
Panier et paiement en ligne	Must have	Sans paiement, pas de vente	15 jours
Calcul des frais de livraison	Must have	Indispensable pour expédier	6 jours
CGV, mentions légales, politique de confidentialité	Must have	Obligations légales	3 jours
Compte client	Should have	Achat possible en invité en attendant	6 jours
Recherche interne	Should have	Le menu suffit avec un petit catalogue	5 jours
Avis clients	Should have	Rassure, mais peut arriver après les premières ventes	4 jours
Blog	Could have	Utile au référencement, non urgent	6 jours
FAQ	Could have	Les questions peuvent passer par le formulaire de contact	4 jours
Inscription à la newsletter	Could have	Bonus pour fidéliser	2 jours
Version anglaise, programme de fidélité, application mobile	Won’t have	Reportés à une prochaine version	Hors calcul

Lecture : 36 jours de Must have sur 63 jours d’effort hors Won’t have, soit environ 57 %, sous le plafond de 60 %. Les Could have pèsent 12 jours, soit environ 19 %, proche des 20 % de réserve recommandés. Si le paiement se révélait deux fois plus long à intégrer que prévu, l’équipe saurait d’avance quoi retirer : le blog, la FAQ et la newsletter, sans toucher à la date.

MoSCoW en agile et avec les user stories

Prioriser un backlog Scrum ou une version

MoSCoW s’utilise couramment avec des approches agiles comme Scrum ou DSDM. Pour une version de produit, on peut classer les epics (des user stories de haut niveau) : l’ensemble des epics Must have dessine alors le produit minimum viable. Si la charge reste trop lourde pour la capacité de l’équipe, on applique la même méthode aux user stories de chaque epic. Le DSDM recommande de prioriser à deux niveaux : sur l’ensemble du projet, puis pour chaque timebox, un Must have du projet pouvant être un Should have du premier incrément.

Prioriser des user stories avec MoSCoW

Une user story exprime un besoin sous la forme « En tant que…, je veux… afin de… ». Le « afin de » donne l’argument qui justifie la catégorie : c’est lui qu’on discute quand deux personnes ne sont pas d’accord sur une priorité.

Catégorie MoSCoW	Exprimée sous forme de user story
Must have	« En tant que client, je veux payer en ligne par carte afin de finaliser mon achat »
Should have	« En tant que prospect, je veux lire des avis clients afin d’être rassuré avant d’acheter »
Could have	« En tant que visiteur, je veux zoomer sur les photos afin de voir les détails des produits »
Won’t have	« En tant que revendeur, je veux un espace dédié afin de passer des commandes en gros »

Avantages et limites de la méthode MoSCoW

Avantages

• Simplicité : quatre catégories compréhensibles par tous, sans formation.
• Langage commun entre métiers, technique et direction.
• Gestion du risque de délai : la réserve de Could have protège la date de livraison.
• Périmètre explicite : les Won’t have documentent ce qui ne sera pas fait.
• Adaptée à l’agile comme à un projet au forfait.

Limites

• Aucun ordre à l’intérieur d’une même catégorie : entre dix Should have, MoSCoW ne dit pas lequel faire en premier.
• La frontière entre Should et Could reste subjective, et chacun a tendance à classer ses propres demandes en Must have.
• Ambiguïté du Won’t have : exclu pour cette version, ou pour toujours ? Il faut le préciser.
• Risque de privilégier les nouvelles fonctionnalités au détriment de la dette technique, moins visible.

Comment limiter ces biais

Mettez-vous d’accord, avant l’atelier, sur des critères objectifs : nombre d’utilisateurs concernés, chiffre d’affaires en jeu, obligation légale, risque technique. Appliquez systématiquement la question test du Must have, contrôlez la règle des 60 %, et désignez à l’avance qui tranche en cas de désaccord. Pour ordonner les éléments d’une même catégorie, complétez MoSCoW par un score (valeur sur effort, par exemple).

MoSCoW, Eisenhower, RICE ou Kano : laquelle choisir ?

Ces méthodes ne répondent pas à la même question. Atlassian, éditeur de Jira, présente plusieurs frameworks de priorisation courants, dont RICE, Kano et MoSCoW.

• MoSCoW : décider du périmètre d’une livraison à date fixe, avec plusieurs parties prenantes.
• Matrice d’Eisenhower : organiser ses propres tâches en croisant urgence et importance (faire tout de suite, planifier, déléguer, abandonner). Elle sert à la gestion du temps plus qu’au cadrage d’un projet.
• RICE : comparer des idées de produit par un score combinant portée, impact, confiance et effort. Plus fin, mais plus long à renseigner.
• Modèle de Kano : classer les fonctionnalités selon leur effet sur la satisfaction client (attendues, de performance, enthousiasmantes). Utile pour comprendre la valeur, pas pour tenir un délai.

En pratique, MoSCoW se combine bien avec un score de type valeur sur effort ou RICE pour ordonner les éléments d’une même catégorie.

Outils pour appliquer la méthode MoSCoW

Post-its et tableau blanc

Pour un premier atelier, rien ne vaut quatre colonnes sur un mur : une tâche par post-it, une couleur par catégorie, et des éléments que l’on déplace au fil de la discussion. La version en ligne se fait sur un tableau blanc collaboratif.

Un tableur

Un tableau à colonnes suffit pour garder une trace et calculer la répartition de l’effort. Ajoutez une colonne d’estimation en jours, et la part des Must have se calcule automatiquement.

Exigence	Catégorie	Effort (jours)	Responsable
Exigence 1	Must have
Exigence 2	Should have
Exigence 3	Could have
Exigence 4	Won’t have	Hors calcul

Trello : une étiquette par catégorie

Dans Trello, la méthode la plus simple consiste à créer quatre étiquettes nommées Must, Should, Could et Won’t. La documentation de Trello indique qu’une étiquette peut recevoir une couleur et un nom, et qu’une carte peut en porter plusieurs. On peut aussi créer une liste par catégorie et y glisser les cartes.

Jira : un champ personnalisé MoSCoW

Dans Jira, une solution simple consiste à créer un champ personnalisé de type liste à quatre options (Must, Should, Could, Won’t). La procédure officielle passe par le panneau d’administration et nécessite des droits d’administrateur Jira ; il est ensuite possible de filtrer le backlog et les tableaux sur ce champ.

Miro : des modèles de matrice MoSCoW

Miro propose une galerie de modèles de matrice MoSCoW prêts à l’emploi, publiés par Miro et par sa communauté, utiles pour animer un atelier à distance.

Pour aller plus loin dans le choix d’un outil, consultez notre comparatif des logiciels de gestion de projet agile ou celui des outils Kanban.

Questions fréquentes

Qu’est-ce que le principe de MoSCoW ?

Le principe est de classer chaque exigence d’un projet en quatre niveaux, Must have, Should have, Could have et Won’t have, pour garantir la livraison de l’indispensable dans un délai fixe et savoir d’avance quoi retirer si le planning dérape.

C’est quoi un MoSCoW ?

Dans le jargon des équipes projet, « faire un MoSCoW » désigne l’atelier ou le tableau qui répartit les fonctionnalités dans les quatre catégories. Le résultat est une liste priorisée, souvent appelée matrice MoSCoW.

Que signifie MoSCoW en français ?

Must have : doit avoir ; Should have : devrait avoir ; Could have : pourrait avoir ; Won’t have this time : n’aura pas cette fois. On garde généralement les termes anglais, l’acronyme ne fonctionnant pas en français.

Faut-il écrire MoSCoW ou Moscou ?

MoSCoW, avec cette casse : c’est un acronyme (Must, Should, Could, Won’t) et non le nom anglais de la capitale russe. Les « o » minuscules servent seulement à le rendre prononçable.

Quelle est la méthode pour prioriser les tâches ?

Il n’y en a pas une seule. Pour ses tâches personnelles, la matrice d’Eisenhower (urgent et important) est la plus répandue. Pour le périmètre d’un projet à date fixe, MoSCoW. Pour comparer des idées de produit, un score comme RICE. Le bon choix dépend de la décision à prendre.

Quels sont les 3 niveaux de priorité ?

L’échelle la plus courante est haute, moyenne et basse. MoSCoW en ajoute un quatrième, le Won’t have, pour rendre visible ce qui est exclu, et remplace les termes abstraits par des définitions testables (que se passe-t-il si ce n’est pas livré ?).

Quel est un outil efficace pour prioriser les tâches ?

Un tableau à quatre colonnes suffit : post-its, tableur, ou outil en ligne comme Trello, Jira ou Miro. L’efficacité vient moins de l’outil que de la règle appliquée : estimation de l’effort, plafond de 60 % de Must have et révision à chaque étape.

Comment utiliser la matrice d’Eisenhower ?

On place chaque tâche dans un des quatre quadrants : urgente et importante (à faire tout de suite), importante mais pas urgente (à planifier), urgente mais peu importante (à déléguer), ni urgente ni importante (à abandonner). Elle complète MoSCoW pour l’organisation quotidienne, une fois le périmètre du projet fixé.

Comment utiliser MoSCoW concrètement, et sur quelle échelle ?

L’échelle comporte quatre niveaux, sans notes intermédiaires. Concrètement : on fixe l’échéance, on liste les exigences, on les classe avec la question test, on vérifie que les Must have restent sous 60 % de l’effort, puis on révise à chaque incrément.

Qu’est-ce qu’une epic et une user story en agile ?

Une user story décrit un besoin du point de vue de l’utilisateur, assez petit pour être réalisé dans un sprint. Une epic est un besoin plus large, découpé en plusieurs user stories. MoSCoW s’applique aux deux niveaux : d’abord aux epics d’une version, puis aux stories de chaque epic.

Quelles sont les techniques de priorisation en agile ?

Les plus citées sont MoSCoW, RICE, le modèle de Kano, la matrice valeur sur effort, le coût du retard (et sa variante WSJF), le story mapping et le vote par points. Atlassian en présente plusieurs dans sa page dédiée aux frameworks de priorisation.

Pour aller plus loin

• La méthode Waterfall
• Tout comprendre sur le rôle de sponsor d’un projet
• Comment utiliser la matrice RACI
• Qu’est-ce qu’un chef de projet ?
• Les meilleurs outils de rétroplanning
• Les meilleurs outils de wiki
• Les meilleurs outils de Gantt
• Les meilleurs outils de gestion de projet en association
• Les formations en lean management