Méthode MoSCoW pour arbitrer : tout projet finit par se heurter au même mur : il y a plus de demandes que de temps disponible. La tentation est alors de tout accepter en espérant que cela rentrera, puis de découvrir trois semaines avant l’échéance que rien n’est prêt. La méthode MoSCoW, née dans les milieux du développement logiciel à la fin des années 1990, propose une alternative : arbitrer explicitement, dès le départ, entre ce qui est vital et ce qui est souhaitable. Son nom est un acronyme des quatre niveaux de priorité qu’elle distingue.
Les quatre catégories de la méthode
MoSCoW classe chaque exigence, fonctionnalité ou tâche dans l’une de quatre catégories. Must have désigne ce qui est indispensable : sans cela, la livraison n’a aucun sens. Should have regroupe ce qui est important mais dont l’absence est contournable. Could have rassemble ce qui apporte du confort sans être nécessaire. Won’t have, enfin, désigne ce qui est explicitement exclu de cette livraison.
La force du modèle tient à sa quatrième catégorie, souvent négligée. La plupart des méthodes de priorisation se contentent de classer par ordre décroissant, ce qui laisse une queue de liste floue que chacun espère secrètement voir traitée. En nommant explicitement ce qui ne sera pas fait, MoSCoW supprime cette ambiguïté et les malentendus qu’elle produit systématiquement en fin de projet.
Une nuance importante : les lettres o de l’acronyme ne signifient rien, elles servent uniquement à rendre le mot prononçable. Le classement n’est donc pas un continuum mais quatre paliers nettement séparés, ce qui est précisément l’intérêt.
Must have : le critère du renoncement
Un élément est Must have si son absence rend la livraison inutilisable, illégale ou dangereuse. Le test le plus fiable consiste à poser la question à l’envers : que se passe-t-il si nous livrons sans ? Si la réponse est « nous ne livrons pas », c’est un Must. Si la réponse est « ce sera moins bien », ce n’en est pas un.
Ce test paraît évident et pourtant il révèle presque toujours des surprises. Dans un atelier de priorisation typique, les participants classent d’abord soixante à quatre-vingts pour cent des éléments en Must have. Après application du test du renoncement, la proportion tombe généralement entre trente et quarante pour cent. Cet écart mesure exactement le niveau d’illusion collective sur lequel le projet allait s’engager.
La règle de terrain la plus utile consiste à plafonner les Must have à environ soixante pour cent de la charge estimée. Au-delà, il ne reste plus aucune marge d’ajustement, et le projet perd sa capacité à absorber le moindre imprévu.
Should have : important mais contournable
Un Should have fait une vraie différence, mais il existe une solution de contournement acceptable, au moins temporairement. Un export automatique de données est un Should have si une extraction manuelle reste possible pendant quelques semaines.
Cette catégorie est la plus inconfortable politiquement, parce qu’elle contient souvent des demandes portées par des personnes influentes. C’est aussi la plus utile : elle constitue la réserve dans laquelle on puise quand le planning se tend. Un projet sans Should have est un projet qui n’a aucune souplesse et qui échouera bruyamment plutôt que discrètement.
Documenter le contournement associé à chaque Should have est une pratique qui change tout. Elle transforme un arbitrage subi en décision assumée : le demandeur sait ce qui se passera si l’élément n’est pas livré, et il l’a validé en amont.
Could have : ce qui saute en premier
Les Could have sont les éléments qui améliorent l’expérience sans être nécessaires : un raffinement d’interface, un rapport supplémentaire, une automatisation de confort. Ils entrent dans le périmètre uniquement si le temps le permet.
Il faut les traiter avec honnêteté. Annoncer un Could have à un client ou à une direction équivaut à créer une attente, même en précisant qu’il est optionnel. Beaucoup d’équipes préfèrent ne pas les communiquer du tout et les livrer comme une bonne surprise si l’occasion se présente — ce qui produit un effet nettement plus positif que l’annonce d’un retrait en fin de parcours.
En pratique, les Could have représentent la variable d’ajustement principale. Sur un projet sain, ils occupent environ vingt pour cent de la charge estimée, ce qui donne au chef de projet une marge de manœuvre réelle sans compromettre l’essentiel.
Won’t have : la catégorie qui crée le plus de valeur
Contrairement à ce que son nom suggère, Won’t have ne signifie pas « jamais ». Il signifie « pas cette fois ». La distinction est capitale : elle permet de refuser sans fermer la porte, ce qui rend le refus politiquement supportable.
Écrire noir sur blanc la liste de ce qui ne sera pas fait produit un effet immédiat sur les projets. Elle transforme les non-dits en décisions traçables, elle protège l’équipe des ajouts de dernière minute, et elle sert de base à la discussion sur la livraison suivante. La plupart des conflits de fin de projet naissent d’éléments que personne n’avait jamais explicitement écartés.
Une bonne pratique consiste à relire cette liste au démarrage de la phase suivante. Certains éléments seront devenus des Must have, d’autres auront perdu tout intérêt — et constater qu’une demande jugée essentielle six mois plus tôt n’intéresse plus personne est un excellent rappel de la valeur de l’arbitrage.
Animer un atelier de priorisation MoSCoW
L’atelier fonctionne mieux avec l’ensemble des parties prenantes réunies, y compris celles qui ont des intérêts divergents. Faire arbitrer séparément puis consolider produit des résultats bien plus fragiles, parce que personne n’a entendu les arguments des autres.
Le déroulé tient en quatre temps : lister les éléments sur des cartes, faire un premier classement individuel silencieux, confronter les écarts en groupe, puis appliquer le test du renoncement sur tous les Must have. Réservez deux heures pour une trentaine d’éléments — au-delà, l’attention chute et les arbitrages se dégradent.
Le rôle de l’animateur est de faire respecter le plafond de charge. Quand les Must have dépassent la capacité disponible, la question n’est pas « peut-on faire plus ? » mais « lequel de ces éléments accepte-t-on de déclasser ? ». Poser la question dans ce sens change complètement la dynamique du groupe.
Les pièges les plus fréquents
Le premier piège est l’inflation des Must have, déjà évoquée : sans plafond de charge, la méthode ne prioritise rien du tout. Le deuxième est l’absence de révision : un classement MoSCoW figé six mois devient faux, car les contraintes évoluent. Prévoyez une revue à chaque jalon.
Le troisième piège consiste à appliquer MoSCoW à des éléments trop gros. Classer « le module de facturation » en Must have ne veut rien dire, car il contient à coup sûr des fonctions vitales et des raffinements accessoires. Découpez jusqu’à obtenir des éléments dont on peut réellement dire qu’ils sont indispensables ou non.
Le dernier piège est d’utiliser la méthode comme un outil de reporting plutôt que comme un outil de décision. MoSCoW n’a de valeur que si quelqu’un accepte, à la fin de l’atelier, de renoncer à quelque chose.
En résumé
MoSCoW est moins une technique de classement qu’un dispositif qui force la conversation difficile au bon moment — avant l’engagement, plutôt qu’à trois semaines de l’échéance. Retenez les deux règles qui font l’essentiel de son efficacité : appliquez systématiquement le test du renoncement à chaque Must have, et plafonnez-les à soixante pour cent de votre capacité. Le reste de la méthode découle naturellement de ces deux disciplines.