Priorisation agile (MoSCoW)

  • Concept
  • Intermédiaire
  • IA générative
  • Toujours utilisé

En bref

La méthode MoSCoW classe les tâches d'un projet agile en quatre catégories : indispensables, importantes, souhaitables, ou à ne pas faire cette fois.

Définition complète

La priorisation agile MoSCoW est une méthode qui classe les tâches ou fonctionnalités d’un projet en quatre catégories, dont les initiales forment le mot MoSCoW : « Must have » (indispensable), « Should have » (important), « Could have » (souhaitable) et « Won’t have this time » (pas cette fois).

Par exemple, pour le développement d’un site internet, la page d’accueil peut être classée « Must have », un moteur de recherche interne « Should have », un chat en ligne « Could have », et une fonctionnalité de traduction automatique en dix langues « Won’t have this time », faute de temps et de budget suffisants pour ce projet.

Attention : classer trop d’éléments en « Must have » revient à ne rien prioriser du tout, ce qui va à l’encontre de l’objectif même de cette méthode.

À quoi ça sert

Cette notion sert à décider, dans un projet où le temps et le budget sont limités, ce qui doit absolument être fait en premier et ce qui peut attendre ou être abandonné pour cette fois.

Elle aide les équipes à se mettre d’accord collectivement sur les priorités, en évitant les débats sans fin sur l’importance relative de chaque tâche.

Elle permet enfin de communiquer clairement, à une direction ou à un client, ce qui sera livré en priorité et ce qui pourra être envisagé plus tard, si le temps ou le budget le permettent.

Cas d'usage typiques

– Classer : dans quelle catégorie MoSCoW placer chaque tâche ou fonctionnalité d’un projet ? / clarifier les priorités avant de démarrer le travail.
– Décider : que faire en cas de retard de planning, quelles tâches peuvent être reportées en premier ? / s’appuyer sur le classement MoSCoW pour ajuster rapidement le périmètre.
– Comparer : un projet priorisé avec MoSCoW face à un projet où tout est jugé indispensable ? / illustrer l’intérêt de distinguer clairement les priorités.
– Communiquer : comment expliquer à un client pourquoi certaines fonctionnalités ne seront pas incluses dans cette version du projet ? / justifier les choix de priorisation de façon transparente.
– Vérifier : la catégorie « Must have » ne contient-elle pas trop d’éléments par rapport au temps disponible ? / éviter une priorisation qui ne priorise en réalité rien.
– Réévaluer : les priorités MoSCoW doivent-elles être ajustées en cours de projet selon les nouvelles informations ? / garder une méthode vivante plutôt que figée dès le départ.

Ce que tu sauras faire

Savoir classer les tâches d'un projet selon la méthode MoSCoW afin de prioriser clairement ce qui doit être fait en premier dans un contexte de temps ou de budget limité.

Mises en situation

Situation 1 : une équipe qui juge tout indispensable

Contexte : Dans une entreprise, l’équipe projet considère que toutes les fonctionnalités demandées pour un nouveau site internet sont indispensables, ce qui rend le planning intenable.

Application : L’équipe applique la méthode MoSCoW pour reclasser les fonctionnalités, en acceptant que certaines soient seulement souhaitables et non indispensables.

Résultat attendu : Le projet devient réalisable dans les délais impartis, en se concentrant d’abord sur les fonctionnalités réellement essentielles.

Situation 2 : un client déçu de ne pas tout obtenir dès la première version

Contexte : Un client s’attend à recevoir toutes les fonctionnalités demandées dès la première livraison d’un projet informatique, ce qui n’est pas réaliste avec le budget alloué.

Application : L’équipe présente au client le classement MoSCoW des fonctionnalités, en expliquant pourquoi certaines seront livrées en priorité et d’autres reportées.

Résultat attendu : Le client comprend et accepte mieux les choix effectués, car ils sont justifiés par une méthode claire plutôt que par une décision arbitraire.

Situation 3 : un projet qui prend du retard en cours de route

Contexte : Un projet agile prend du retard à mi-parcours, et l’équipe doit décider rapidement quelles tâches abandonner pour respecter la date de livraison finale.

Application : L’équipe se réfère au classement MoSCoW établi au départ pour reporter en priorité les tâches classées « Could have » et « Won’t have this time ».

Résultat attendu : Le projet est livré dans les délais avec les fonctionnalités essentielles, tandis que les tâches secondaires sont reportées à une version ultérieure.

Application guidée : classer des tâches selon la méthode MoSCoW

Contexte : Pour le lancement d’une application mobile de réservation de rendez-vous, l’équipe doit classer les tâches suivantes : la prise de rendez-vous en ligne, les notifications par message, l’affichage d’avis clients, et la possibilité de payer directement dans l’application.

Question : Comment répartir ces quatre tâches dans les catégories MoSCoW ?

Résultat attendu : La prise de rendez-vous en ligne est un « Must have », car c’est la fonction principale de l’application ; les notifications par message sont un « Should have », car elles améliorent fortement l’expérience sans être vitales dès le lancement ; l’affichage d’avis clients est un « Could have », agréable mais non essentiel ; le paiement direct dans l’application peut être un « Won’t have this time », s’il demande un développement trop long pour la première version.

Application guidée : ajuster le classement MoSCoW après un imprévu

Contexte : À mi-parcours d’un projet, l’équipe découvre qu’une tâche classée initialement « Should have » prend en réalité beaucoup plus de temps que prévu, ce qui menace la date de livraison finale.

Question : Comment ajuster le classement MoSCoW face à cet imprévu ?

Résultat attendu : L’équipe peut reclasser cette tâche en « Could have » ou « Won’t have this time » pour cette version, afin de préserver les délais sur les tâches réellement indispensables, tout en informant clairement le client ou la direction de ce changement et de ses raisons.

Pour bien le retenir

L'analogie

Quand vous faites vos courses avec un budget limité, vous priorisez : le pain et le lait, ce sont les indispensables (Must have) ; les fruits et légumes sont importants (Should have) ; les bonbons seraient sympas mais pas indispensables (Could have) ; et le caviar n’est pas pour cette fois (Won’t have this time). La méthode MoSCoW applique ce même raisonnement aux tâches d’un projet.

« Le pain et le lait d'abord, le caviar pour une prochaine fois. »

Moyen mnémotechnique

MoSCoW : Must, Should, Could, Won't, à retenir comme les quatre lettres capitales du mot.

Pièges à éviter

À ne pas confondre avec

Une confusion fréquente consiste à classer trop de tâches en « Must have », ce qui revient en pratique à ne rien prioriser, puisque tout devient soi-disant indispensable.

Une autre erreur est de considérer le classement MoSCoW comme définitif dès le début du projet : il doit pouvoir être réajusté si de nouvelles informations apparaissent en cours de route.

Enfin, certains oublient d'expliquer clairement au client ou à la direction pourquoi certaines tâches sont classées « Won't have this time », ce qui peut créer de l'incompréhension si cela n'est pas anticipé et justifié.

Évolution historique

Apparition : Années 1990 à 2000

Quels changements depuis l’arrivée de l’IA ?

Avant

Le classement des tâches selon MoSCoW se faisait entièrement lors de réunions d’équipe, sur des tableaux physiques ou des documents partagés mis à jour manuellement.

Aujourd’hui

Des outils numériques de gestion de projet, parfois assistés par l’intelligence artificielle, peuvent suggérer un premier classement MoSCoW à partir de la description des tâches, ou signaler automatiquement si trop d’éléments sont classés « Must have » par rapport au temps disponible. La décision finale reste toutefois toujours humaine, car elle dépend souvent d’enjeux propres au projet que l’outil ne connaît pas entièrement.

Évolution historique

Années 1990 : la méthode MoSCoW est formalisée dans le cadre du développement de logiciels utilisant des méthodes de développement rapide.

Années 2000 : avec la diffusion des méthodes agiles, la priorisation MoSCoW s’intègre naturellement à ces nouvelles façons de gérer les projets.

Années 2010 : la méthode se répand bien au-delà de l’informatique, dans la gestion de projets marketing, événementiels ou associatifs.

Aujourd’hui : MoSCoW reste une méthode de priorisation simple et largement enseignée, utilisée aussi bien par de petites équipes que par de grandes organisations.