Méthode MoSCoW : définition, exemple et comment prioriser en équipe

Dans presque tous les projets, tout finit par devenir prioritaire : chaque service défend ses demandes, la liste s’allonge, et l’équipe découvre trop tard qu’elle ne pourra pas tout livrer à la date prévue. La méthode MoSCoW sert à trancher avant qu’il ne soit trop tard. Elle oblige un groupe à dire, élément par élément, ce qui doit absolument être livré, ce qui devrait l’être, ce qui pourrait l’être et ce qui ne le sera pas cette fois. Voici sa définition, son origine, ses quatre catégories, la règle des 60 % que l’on oublie souvent, un exemple chiffré, la manière d’animer un atelier de priorisation en groupe, ses limites et sa place parmi les autres matrices de priorisation.

Méthode MoSCoW : définition

La méthode MoSCoW est une technique de priorisation qui classe les éléments d’un périmètre (exigences, fonctionnalités, livrables, tâches, actions d’un plan) selon leur caractère indispensable pour une échéance donnée. Son nom est un acronyme formé à partir des initiales de ses quatre catégories : Must have, Should have, Could have et Won’t have. Les deux « o » minuscules n’ont aucune signification : ils servent seulement à rendre le mot prononçable. La méthode n’a donc aucun rapport avec la capitale russe.

Ce qui la distingue d’un simple classement « haute, moyenne, basse priorité », c’est que chaque catégorie porte une promesse précise. Un Must sera livré, un Should devrait l’être, un Could le sera si tout se passe bien, un Won’t ne le sera pas dans la période. Le groupe ne se contente pas d’exprimer des préférences : il s’engage sur ce qui est garanti et sur ce qui ne l’est pas. C’est l’une des matrices de priorisation les plus simples à comprendre, et l’une des plus exigeantes à appliquer honnêtement.

La méthode suppose toujours une contrainte : une date fixe, un budget fixe ou une capacité d’équipe limitée. Sans échéance, prioriser n’a pas de sens, puisqu’on pourrait tout faire en attendant assez longtemps.

D’où vient la méthode MoSCoW ?

La méthode est attribuée à Dai Clegg, spécialiste du développement logiciel, qui la met au point en 1994 alors qu’il travaille chez Oracle au Royaume-Uni. Elle répond à un problème très concret des projets de développement rapide d’applications (RAD, pour rapid application development) : les délais sont courts et fixes, il faut donc décider très tôt ce que l’on sacrifiera si le temps manque. Dai Clegg décrit cette approche avec Richard Barker dans Case Method Fast-Track: A RAD Approach (Addison-Wesley, 1994).

La méthode est ensuite apportée au DSDM (Dynamic Systems Development Method), une méthode de gestion de projet agile née au Royaume-Uni en 1994 sous l’égide d’un consortium d’entreprises, le DSDM Consortium. Le principe du DSDM est de fixer le temps, le coût et la qualité, et de faire varier le périmètre : MoSCoW en devient l’une des techniques centrales, à côté du découpage en périodes de durée fixe (timeboxes). Le consortium, devenu l’Agile Business Consortium en 2016, reste aujourd’hui la référence sur les règles de la méthode.

Née dans l’informatique, la méthode s’est largement diffusée au-delà : gestion de projet classique, conception de produit, cahiers des charges, feuilles de route, et même organisation d’un séminaire ou d’une liste de tâches personnelle.

Les 4 catégories de la méthode MoSCoW

Le cœur de la méthode est la définition de chaque catégorie. Sans définitions partagées, chacun met ce qu’il veut derrière « indispensable », et le classement ne vaut rien. Le tableau ci-dessous reprend les règles du DSDM et propose pour chaque catégorie une question test à poser au groupe.

Catégorie	En français	Ce que cela signifie	Question test
Must have	Indispensable	Sans cet élément, livrer à la date prévue n’a aucun sens : la solution serait inutilisable, illégale ou dangereuse. Les Must forment le minimum utilisable que l’équipe garantit.	Si cet élément manque la veille de la livraison, repousse-t-on la livraison ?
Should have	Important	Important mais pas vital. Son absence serait pénible, mais un contournement existe : une procédure manuelle, un outil existant, un peu d’inefficacité acceptée temporairement.	Existe-t-il un moyen de s’en passer, même inconfortable ?
Could have	Souhaitable	Utile ou agréable, mais avec un impact plus faible s’il manque. C’est la première réserve dans laquelle on puise quand le délai est menacé.	Si on le retire, combien de personnes s’en apercevront vraiment ?
Won’t have this time	Pas cette fois	Élément que le groupe a explicitement décidé de ne pas livrer dans cette période. Il est écrit noir sur blanc, ce qui évite qu’il revienne discrètement par la petite porte.	Sommes-nous d’accord pour le reporter, et quand le reverrons-nous ?

Deux précisions comptent. D’abord, le DSDM lit aussi « MUST » comme l’acronyme anglais de Minimum Usable SubseT, le plus petit ensemble utilisable : c’est une bonne façon de rappeler que la catégorie doit rester courte. Ensuite, classer un élément en Should ou en Could ne signifie pas qu’il ne sera pas fait. Cela signifie seulement que sa livraison n’est pas garantie. Dans un projet bien piloté, l’essentiel des Should et une partie des Could sont livrés.

La frontière entre Should et Could est la plus subjective. Le DSDM conseille de la fixer avant de classer, avec un critère objectif : le nombre de personnes concernées, un montant de gain ou de coût, un risque client. Par exemple : « tout ce qui touche plus de cinquante collaborateurs est au moins un Should ».

La règle des 60 % : l’équilibre entre les catégories

C’est la partie de la méthode que l’on oublie le plus souvent, et c’est pourtant elle qui la rend efficace. Si tout est Must, il n’y a plus aucune marge : au premier imprévu, l’équipe rate sa promesse. Le DSDM recommande donc de limiter l’effort consacré aux Must à 60 % environ de la capacité de la période, et de prévoir une réserve de Could d’environ 20 % de l’effort. Les Should occupent le reste.

Trois points à retenir pour l’appliquer correctement :

• On compte en effort, pas en nombre d’éléments. Six Must sur vingt éléments peuvent représenter 80 % du travail s’ils sont lourds. Il faut donc une estimation, même grossière, en jours ou en points.
• Les Won’t sont exclus du calcul. Ils ne font pas partie de la période, ils ne consomment donc pas de capacité.
• Dépasser 60 % est un risque, pas une interdiction. Le DSDM admet davantage de Must quand les estimations sont fiables, la démarche bien connue, l’équipe rodée et l’environnement peu exposé aux imprévus. Dans la plupart des projets en entreprise, ces quatre conditions sont rarement réunies.

Un exemple de méthode MoSCoW, chiffré

Prenons un exemple fictif mais réaliste. Une ETI de services veut lancer un programme d’intégration des nouveaux arrivants le 1er mars. L’équipe projet, composée de deux personnes des ressources humaines et de trois managers, dispose d’environ 40 jours de travail cumulés d’ici là. La liste de départ compte dix éléments. Au premier tour, sept d’entre eux sont proposés en Must, pour 31 jours d’effort, soit près de 78 % de la capacité : le projet n’a presque aucune marge.

L’animatrice repose alors la question test sur chacun d’eux : « si cet élément n’est pas prêt le 28 février, reporte-t-on le lancement ? ». Le livret d’accueil, le parrainage et le point à 30 jours passent en Should, puisqu’il existe un contournement (le livret actuel, un accompagnement informel par le manager, un point fixé au cas par cas). Voici le résultat :

Élément	Effort estimé	Catégorie	Justification
Poste de travail et accès prêts le premier jour	5 jours	Must	Sans cela, le nouvel arrivant ne peut pas travailler : le programme n’a pas de sens
Accueil sécurité et formations obligatoires	6 jours	Must	Obligation réglementaire, aucun contournement possible
Programme de la première semaine, par métier	9 jours	Must	C’est l’objet même du projet
Parrainage par un collègue	6 jours	Should	Très utile, mais le manager peut accompagner à titre transitoire
Point d’étape à 30 jours avec une trame	3 jours	Should	Peut être organisé au cas par cas les premiers mois
Livret d’accueil mis à jour	3 jours	Should	L’ancien livret reste utilisable quelques semaines
Vidéo de bienvenue de la direction	5 jours	Could	Agréable, faible impact si elle arrive plus tard
Petit-déjeuner mensuel des nouveaux	3 jours	Could	Simple à lancer après coup
Plateforme numérique d’intégration	(non estimé)	Won’t	Projet à part entière, reporté au second semestre
Parcours avant l’arrivée (pré-intégration)	(non estimé)	Won’t	Dépend de la plateforme, revu en juin

Le nouvel équilibre : 20 jours de Must (50 %), 12 jours de Should (30 %) et 8 jours de Could (20 %). Ce que le groupe en retire va au-delà du tableau :

• La promesse devient tenable. Les Must restent sous les 60 % : si un manager tombe malade ou si l’informatique prend du retard, l’équipe peut sacrifier la vidéo et le petit-déjeuner sans compromettre le lancement.
• Les désaccords changent de nature. On ne débat plus de savoir si le parrainage est « important » (tout le monde est d’accord), mais de savoir si l’on reporterait le lancement sans lui. La réponse est non, la discussion est close en deux minutes.
• Les Won’t protègent l’équipe. La plateforme numérique, que la direction évoquait régulièrement, est désormais écrite comme reportée, avec une date de revue. Elle ne viendra pas s’ajouter en cours de route.

Appliquer la méthode MoSCoW en 6 étapes

1. Fixer l’échéance et la capacité. Quelle est la date de livraison, ou la durée de la période ? Combien de jours de travail l’équipe peut-elle y consacrer ? Sans ces deux chiffres, il n’y a pas de priorisation possible.
2. Lister et découper les éléments. Un élément trop gros est presque toujours classé Must, alors qu’il contient souvent une partie indispensable et une partie confortable. Le découper en deux ou trois éléments débloque la plupart des débats.
3. Se mettre d’accord sur les règles avant de classer. Définition de chaque catégorie, critère qui sépare Should et Could, personne qui tranche en cas de désaccord. Écrites et affichées, ces règles évitent de les renégocier à chaque ligne.
4. Classer, en partant des Won’t. Le DSDM suggère de considérer d’abord chaque élément comme un Won’t, puis de justifier pourquoi il mérite mieux. Cette inversion de la charge de la preuve limite l’inflation des Must.
5. Estimer l’effort et vérifier l’équilibre. Additionner l’effort des Must, le rapporter à la capacité, et rétrograder des éléments tant qu’on dépasse 60 % environ.
6. Consigner les Won’t et revoir les priorités. Les priorités changent : un Could d’aujourd’hui peut devenir un Must de la période suivante. On les revoit au minimum à la fin de chaque période, et chaque fois qu’un nouvel élément arrive.

Comment animer un atelier MoSCoW en groupe

La technique tient en quatre mots ; la difficulté est humaine. Chaque participant arrive avec ses demandes et la conviction qu’elles sont indispensables. Trois risques guettent : que le plus haut placé ou le plus insistant impose son classement, que tout finisse en Must par lassitude, et que le groupe reparte sans que personne ait réellement tranché. Les principes suivants y répondent. Ce sont ceux que l’on travaille dans notre formation Lancer des projets collaboratifs.

• Faire classer chacun seul avant l’échange. Quelques minutes de classement individuel et silencieux, sur une fiche, donnent l’avis réel de chacun avant que les premiers à parler n’influencent les autres. On ne discute ensuite que les éléments sur lesquels les avis divergent.
• Séparer ouvrir et décider. D’abord compléter la liste et découper les éléments, sans juger ; ensuite seulement classer. Mélanger les deux revient à défendre chaque idée au moment où elle apparaît. C’est la logique du diamant de la participation.
• Poser la question test plutôt que débattre de l’importance. « Reporterait-on la livraison sans lui ? » fait avancer là où « c’est vraiment important » fait tourner en rond.
• Annoncer qui tranche, et comment. La méthode classe, elle ne décide pas à la place du groupe. Dire dès l’ouverture si le classement final se fait par consentement, par vote ou par arbitrage du commanditaire évite bien des frustrations. Notre article sur la manière de décider en groupe détaille ces options.
• Faire parler le manager en dernier. Si le responsable du projet donne son classement en premier, le groupe s’aligne sans le vouloir. Mieux vaut qu’il s’exprime après les autres, ou que l’atelier soit animé par une personne neutre sur le fond.
• Rendre les Won’t visibles. Une colonne « pas cette fois » bien en vue, relue à voix haute en fin de séance, rassure ceux dont la demande est reportée : elle n’est pas oubliée, elle est datée.

La Trame d’atelier MoSCoW NextStart en 90 minutes

La Trame d’atelier MoSCoW NextStart est issue de notre pratique d’animation d’ateliers de cadrage et de feuille de route. Elle convient à un groupe de 5 à 12 personnes, en salle ou à distance, avec une liste de 15 à 40 éléments préparée à l’avance. Elle se recopie facilement dans un conducteur d’atelier minute par minute.

Temps	Séquence	Ce que fait l’animateur	Ce qui en sort
0 à 5 min	Ouverture	Rappelle l’échéance, la capacité disponible et qui tranche en dernier ressort	Un cadre partagé
5 à 15 min	Règles du jeu	Présente les quatre catégories et leur question test, fait fixer le critère qui sépare Should et Could	Des règles écrites et affichées
15 à 25 min	Inventaire	Fait relire la liste, découper les éléments trop gros et ajouter les oublis, sans classer	Une liste complète et au bon niveau de détail
25 à 35 min	Classement individuel	Fait classer chaque élément en silence, sur une fiche personnelle	Des avis indépendants
35 à 55 min	Mise en commun	Place les éléments en quatre colonnes, en commençant par les Won’t ; ne fait débattre que les écarts, avec la question test	Un premier classement collectif
55 à 70 min	Équilibre	Additionne l’effort des Must, le compare à la capacité, fait rétrograder jusqu’à 60 % environ	Des Must tenables
70 à 80 min	Les Won’t	Relit à voix haute les éléments reportés et fixe pour chacun une date de revue	Un périmètre clair, des reports assumés
80 à 90 min	Validation	Fait valider la liste par la personne ou la règle de décision annoncée, fixe la prochaine revue	Une liste priorisée et validée

Deux conseils pour que la trame tienne dans le temps. Préparez la liste et une première estimation de l’effort avant la séance : estimer quarante éléments en direct prendrait l’atelier entier. Et si la mise en commun s’enlise sur un élément, notez-le comme « à arbitrer » plutôt que de laisser la discussion dévorer le temps des autres.

MoSCoW, Eisenhower, RICE, Kano : quelle matrice de priorisation choisir ?

MoSCoW est souvent présentée à côté d’autres outils de priorisation. Ils ne répondent pas à la même question, et se combinent souvent.

Outil	Ce qu’il classe	La question qu’il pose	Quand le préférer
Méthode MoSCoW	Les éléments d’un périmètre à livrer dans un délai fixe	Qu’est-ce qui doit absolument être livré à la date ?	Projet à échéance fixe, arbitrage entre plusieurs demandeurs
Matrice d’Eisenhower	Les tâches d’une personne, selon l’urgence et l’importance	Que dois-je faire moi-même, maintenant ?	Organisation personnelle, plutôt que périmètre de projet
Vote par points	Les options produites par un groupe	Qu’est-ce que le groupe préfère ?	Trier vite les idées d’un brainstorming, sans contrainte de capacité
Matrice valeur / effort	Des idées placées sur deux axes	Où sont les gains rapides ?	Choisir des actions d’amélioration à lancer en premier
Score RICE	Des initiatives notées sur la portée, l’impact, la confiance et l’effort	Quel est le meilleur rapport entre valeur et effort ?	Portefeuille de produit, quand on dispose de données
Modèle de Kano	Des fonctionnalités selon leur effet sur la satisfaction des utilisateurs	Qu’est-ce qui est attendu, apprécié ou enthousiasmant ?	Conception d’un produit ou d’un service centrée sur l’usager

Un enchaînement fréquent en atelier : produire les idées avec un brainstorming, faire un premier tri par vote par points, puis passer les options retenues au crible de MoSCoW pour décider de ce qui entre dans la prochaine période. On retrouve l’alternance entre pensée divergente et pensée convergente : MoSCoW est un outil de convergence.

Quand utiliser la méthode MoSCoW

• Un projet à date fixe : lancement d’un service, déménagement, échéance réglementaire, événement. C’est son terrain d’origine.
• Un cahier des charges ou une expression de besoin, pour distinguer ce qui est exigé de ce qui est souhaité avant de consulter des prestataires.
• Une feuille de route sur plusieurs trimestres, en appliquant la méthode période par période : un même élément peut être un Could ce trimestre et un Must le suivant.
• La sortie d’une rétrospective ou d’un atelier d’idées, quand le groupe repart avec trop d’actions : une rétrospective d’équipe ou un speed boat produisent souvent dix pistes pour une capacité de deux.
• Un ordre du jour de séminaire trop chargé, ou même sa propre liste de tâches de la semaine.

Elle est en revanche peu utile quand il n’y a ni échéance ni contrainte de capacité, et mal adaptée pour comparer finement des options proches en valeur : elle range en quatre groupes, elle ne classe pas à l’intérieur de chaque groupe.

Les limites et les erreurs fréquentes

• L’inflation des Must. Chaque demandeur veut voir sa demande en Must. Sans la question test et sans la règle des 60 %, la catégorie devient une liste de souhaits et la méthode ne sert plus à rien.
• Compter les éléments au lieu de l’effort. Appliquer « 60 % de Must » au nombre de lignes donne une illusion d’équilibre. C’est l’effort estimé qui compte.
• Oublier l’échéance. Une priorisation MoSCoW sans date ni capacité n’engage personne. La première ligne de l’atelier doit toujours être : pour quand, et avec combien de temps ?
• Négliger les Won’t. Ne pas les écrire, c’est les laisser revenir en cours de projet. Les écrire sans date de revue, c’est décourager ceux qui les portent.
• Un classement figé. Les priorités d’une période ne valent que pour elle. Une liste MoSCoW jamais revue devient fausse au bout de quelques semaines.
• Prendre le classement pour une décision. La méthode éclaire, elle ne tranche pas. Si personne n’est désigné pour arbitrer les désaccords, le classement final reflète surtout le poids des personnes présentes.

Questions fréquentes sur la méthode MoSCoW

Pour approfondir. Dai Clegg et Richard Barker, Case Method Fast-Track: A RAD Approach, Addison-Wesley (1994) ; Agile Business Consortium, « MoSCoW Prioritisation », chapitre du manuel DSDM Agile Project Framework (règles des catégories et recommandation des 60 %). Sur le même blog : décider en groupe : choisir la bonne méthode et le diagramme d’Ishikawa et son animation en groupe.