Méthode MoSCoW : prioriser son backlog produit sans se perdre dans les must-have

RICE (Reach, Impact, Confidence, Effort) et ICE (Impact, Confidence, Ease) sont les frameworks de priorisation les plus cités en product management. En pratique, ils posent un problème récurrent : ils demandent d'estimer des variables souvent floues.

Combien de personnes va toucher cette feature ? Quel impact sur la rétention, sur une échelle de 1 à 10 ? Ces scores donnent une illusion de rigueur. Si deux membres de l'équipe font le calcul séparément, ils obtiennent deux résultats différents — parce que les estimations sont subjectives, pas parce que la méthode est mauvaise.

MoSCoW ne prétend pas être plus précis. Il est plus honnête : il te demande de trancher, pas de calculer. C'est sa force — et sa limite. Il ne remplace pas une analyse d'impact approfondie. Il accélère la décision quand tu as déjà le contexte et que tu dois allouer une capacité limitée à un périmètre défini.

MoSCoW est un acronyme. Chaque lettre correspond à une catégorie de priorité. Voici la définition opérationnelle — pas la version Wikipedia.

Must have : le sprint échoue si ce n'est pas livré. Pas 'très important', pas 'urgent pour le client'. Échoue. Si tu hésites à mettre un item en Must, il n'est pas un Must. Exemple sur un SaaS de facturation : l'utilisateur peut envoyer une facture en PDF. Sans ça, le produit ne sert à rien.

Should have : haute valeur, mais le produit tourne sans. La livraison peut glisser d'un sprint sans catastrophe. Exemple : relances automatiques en cas de facture impayée. Important, pas bloquant.

Could have : nice to have. On le fait si le temps restant le permet, et seulement si les Must et Should sont bouclés. Exemple : export en format ODS en plus du CSV. Si ça prend 30 minutes, peut-être. Si ça prend 3 jours, non.

Won't have (this time) : explicitement hors scope pour ce cycle. Ce n'est pas une corbeille — c'est une décision documentée. Écrire Won't have, c'est dire à l'équipe : on a réfléchi, et on choisit de ne pas le faire maintenant. Ça évite que cet item ressurgisse à chaque réunion.

Exemple 1 — outil de gestion de devis pour freelances français. Équipe : une ou deux personnes. Backlog : une cinquantaine d'items dans Notion. Objectif du sprint : MVP envoyable à dix bêta-testeurs.

Must have : création de devis, export PDF, envoi par email, signature électronique basique. Sans ça, le devis ne sert à rien — pas de test possible.

Should have : historique des devis, relance automatique à J+7, personnalisation du template. Utile, pas bloquant pour le premier test.

Could have : multi-devises, devis récurrents, intégration de paiement en ligne. Intéressant, mais si le sprint est tendu, hors scope.

Won't have (this time) : application mobile, API publique, module comptabilité complet. Reporté explicitement — et écrit noir sur blanc dans le backlog.

Exemple 2 — SaaS B2B de suivi de campagnes pour agences marketing. Équipe : cinq personnes. Sprint de deux semaines. Objectif : améliorer la rétention des comptes existants.

Must have : corriger le bug de synchronisation Google Ads qui génère des données fausses. Un Must par définition — les clients se plaignent activement et ça érode la confiance.

Should have : nouveau tableau de bord avec graphiques comparatifs mois/mois. L'équipe CSM le demande depuis trois semaines.

Could have : dark mode. La demande existe, mais ça ne joue pas directement sur la rétention.

Won't have (this sprint) : refonte complète du module rapports. Trop gros, trop risqué sans spec propre. Reporté explicitement à Q3 avec la raison documentée.

MoSCoW ne fonctionne bien qu'avec une règle de base : définir l'objectif du sprint ou du trimestre avant de classer quoi que ce soit. Sans objectif clair, tout devient Must have. C'est l'erreur la plus fréquente — et elle rend le framework inutile.

En sprint planning avec Jira ou Linear : crée quatre colonnes ou quatre labels — Must, Should, Could, Won't. Avant de discuter de l'ordre, pose la question à l'équipe : quel est l'objectif de ce sprint en une phrase ? Ensuite, chaque item est classé collectivement. Règle pratique : si plus de 60 % de la capacité du sprint est occupée par des Must have, tu as un problème de scope. Soit tu réduis les Must, soit tu réajustes le périmètre.

Dans une roadmap Notion : ajoute une propriété Select avec les quatre valeurs MoSCoW à ta base de données backlog. Filtre ta vue par Must pour ne voir que ce qui compte vraiment. Ajoute une colonne 'Critère de décision' pour noter pourquoi un item est classé ainsi — ça évite de rouvrir les mêmes débats trois sprints plus tard.

Un point important : MoSCoW s'applique à un périmètre défini dans le temps. Ce qui est Won't have ce sprint peut devenir Must have le suivant. Reclassifie à chaque cycle. Ne traite pas le Won't have comme une poubelle permanente.

Si tu travailles seul sur un side-project, fais l'exercice par écrit. Prendre 20 minutes pour classer ton backlog en MoSCoW avant de coder te sauvera des heures de travail sur des fonctionnalités que personne n'utilisera.

Ces trois frameworks ne sont pas en compétition. Ils répondent à des situations différentes et peuvent coexister dans la même équipe.

Utilise MoSCoW quand tu dois trancher vite sur un sprint ou une release. Idéal en early stage, en équipe réduite, ou quand tu n'as pas de données suffisantes pour calculer un score RICE fiable. Le critère clé : est-ce que l'équipe a déjà aligné son objectif ? Si oui, MoSCoW est le plus rapide.

Utilise RICE quand tu compares des initiatives de taille très différente sur une roadmap longue durée. Le score aide à objectiver une décision entre, par exemple, développer une nouvelle intégration ou refondre l'onboarding. Mais sois honnête sur les estimations — un RICE avec des chiffres inventés est pire que pas de framework du tout.

Utilise ICE quand tu veux aller encore plus vite que RICE avec un score simple sur trois critères (Impact, Confidence, Ease). C'est souvent suffisant pour des expériences growth ou des tests A/B où la rapidité d'exécution compte plus que la précision.

En pratique, les équipes solides utilisent les deux niveaux : RICE pour la roadmap trimestrielle, MoSCoW pour le sprint planning. Ce ne sont pas des alternatives — ce sont deux niveaux de granularité différents qui se complètent.

Prioriser son backlog, c'est une compétence. Pas un instinct. Et comme toute compétence, ça s'apprend avec des cadres, de la pratique, et des retours sur ce qui a fonctionné — ou pas.

Si tu veux structurer ta gestion de projet de bout en bout — de la roadmap au sprint review, avec des outils concrets comme Notion et Jira, et des méthodes comme MoSCoW ou RICE appliquées à de vrais cas — la formation Gestion de Projet de Growth Loupe est faite pour ça. Pas de théorie abstraite : des process directement utilisables, que tu sois PM, fondateur ou freelance.