« Tout est prioritaire. » Je l'ai entendu assez souvent pour savoir ce que ça annonce : une liste de trente éléments dont vingt-huit sont marqués indispensables, et une équipe qui découvre trois semaines avant la livraison qu'il va falloir en couper la moitié. La matrice MoSCoW sert à avoir cette conversation au démarrage plutôt qu'à la fin.
Les quatre niveaux
MoSCoW est un acronyme. Les quatre majuscules portent le sens, les deux o minuscules ne sont là que pour rendre le mot prononçable.
- Must have, indispensable. Sans cet élément, la livraison n'a pas lieu. Pas de version dégradée, pas de report au mois suivant.
- Should have, important. Son absence fait mal, mais il existe un contournement que l'on peut tenir le temps d'une version.
- Could have, souhaitable. On le livre si le temps le permet. C'est la première chose qui saute quand le planning se tend.
- Won't have, hors périmètre. Explicitement exclu de cette livraison, et écrit comme tel.
La méthode vient de Dai Clegg, qui l'a formalisée chez Oracle en 1994, avant qu'elle ne soit reprise par DSDM puis par la plupart des approches itératives. Elle ne s'applique pas qu'aux projets logiciels : tout périmètre qui se découpe en éléments livrables indépendamment peut passer dedans.
La règle des 60 %, celle qui fait tout le travail
Classer en quatre colonnes ne sert à rien si trois colonnes restent vides. C'est pour ça que DSDM ajoute une contrainte chiffrée : les Must have ne doivent pas dépasser 60 % de la charge totale de la livraison, et il est recommandé de garder environ 20 % en Could have.
La logique est mécanique. Les Could have sont votre marge de manœuvre. Ce sont eux que vous sacrifiez quand une tâche prend deux fois plus de temps que prévu, quand un développeur tombe malade, quand le client ajoute une demande. Si votre liste est composée à 90 % de Must, vous n'avez aucune variable d'ajustement, et le premier imprévu vous met dans l'impasse.
C'est exactement la situation que décrit le triangle d'or quand les trois contraintes sont figées en même temps. Il faut bien que quelque chose absorbe. Si ce n'est pas le périmètre, ce sera la qualité ou l'équipe.
Les 60 % se calculent en charge, pas en nombre de lignes. Dix éléments marqués indispensables peuvent peser moins que deux gros chantiers classés important. Sans estimation, même grossière, la règle ne veut rien dire : estimer la durée de chaque tâche est donc un préalable, pas une étape d'après.
La question qui départage deux indispensables
Tout le monde bute au même endroit. Deux personnes défendent chacune leur élément, les deux disent indispensable, et la réunion s'enlise.
La question qui débloque n'est pas « est-ce important ». Elle est : que se passe-t-il exactement si on ne le livre pas le jour J ?
- « On ne peut pas ouvrir le service » ou « c'est une obligation réglementaire » : c'est un Must have.
- « Les utilisateurs devront passer par un export Excel pendant deux mois » : c'est un Should have. Il existe un contournement, il est pénible, il est tenable.
- « Ce serait quand même mieux » : c'est un Could have.
Le mot qui tranche, c'est contournement. Un Must have n'en a pas. Dès qu'une personne autour de la table décrit une manière, même laide, de s'en passer pendant quelques semaines, l'élément descend d'un cran.
Cette conversation se tient avec le commanditaire, pas entre membres de l'équipe. C'est lui qui assume les conséquences d'un report, donc c'est lui qui arbitre. L'équipe apporte la charge et les contournements possibles, elle ne décide pas seule de ce qui est indispensable.
Won't have, le niveau que tout le monde saute
C'est la colonne la plus utile et la moins remplie. Elle dit « pas cette fois-ci », et surtout pas « jamais ».
Son intérêt est entièrement défensif. Une demande écrite noir sur blanc comme exclue ne revient pas en semaine six sous la forme « mais je croyais que c'était prévu ». Elle est tracée, elle est datée, elle a été acceptée par quelqu'un. C'est l'un des rares gestes qui freine réellement la dérive de périmètre.
J'ajoute toujours une ligne à côté de chaque Won't have : la version où on le reprend. « Pas dans la V1, à rediscuter au cadrage de la V2. » Ça coûte dix secondes et ça transforme un refus en report, ce qui change complètement la façon dont il est reçu.
Ce que MoSCoW ne dit pas
Trois limites à connaître avant de s'appuyer dessus.
La priorité ne donne pas l'ordre d'exécution. Deux éléments classés Must have ne se traitent pas forcément dans n'importe quel ordre : si l'un conditionne l'autre, c'est la dépendance qui commande, pas la priorité. C'est le rôle du diagramme réseau et du chemin critique, pas celui de la matrice.
Une priorité vieillit. Un classement fait au lancement et jamais rouvert devient une décoration au bout de deux mois. Le marché bouge, le commanditaire change d'avis, un Could have devient urgent. La matrice se relit à chaque jalon, sinon elle ment.
Elle ne dit rien de la valeur relative à l'intérieur d'un niveau. Quinze Must have restent quinze éléments à ordonner entre eux. MoSCoW élimine le bruit, il ne construit pas la séquence.
Où elle s'insère dans un projet
La démarche pas à pas, séance comprise, est détaillée à part. Elle arrive après le découpage et avant le planning. Vous listez d'abord ce qu'il y a à faire, par exemple avec un WBS ou une carte mentale. Vous priorisez ensuite. Vous planifiez seulement une fois les deux faits.
Elle est particulièrement utile quand la date est imposée et ne bougera pas : c'est la mécanique centrale du rétroplanning agile, où l'on part de l'échéance et où l'on ajuste le contenu. La démarche pas à pas détaille comment enchaîner les deux.
Si vous préférez partir d'une grille déjà construite, notre modèle MoSCoW Excel reprend les quatre niveaux, calcule la part de charge de chacun, et signale les lignes qui ne respectent pas la règle.
Synthèse
MoSCoW ne hiérarchise pas des envies, il force une organisation à dire ce qu'elle accepte de ne pas livrer. Tout le reste en découle.
Trois gestes suffisent pour que ça tienne : écrire les quatre niveaux avec le commanditaire, vérifier que les Must have ne dépassent pas 60 % de la charge, et remplir la colonne Won't have au lieu de la laisser vide. Le cadrage est le bon moment pour les trois.
Dans Orchesia, le backlog d'un projet simplifié reprend ces quatre colonnes. Les éléments se déplacent d'un niveau à l'autre par glisser-déposer, et la colonne hors périmètre reste visible au lieu de disparaître dans un fichier annexe.
