Méthode · Priorisation

RICE vs MoSCoW
vs Kano.

Quel framework choisir.

Les 3 limites de chacun.

Comment prioriser un backlog produit en 2026. Forces et failles de RICE, MoSCoW et Kano. Notre stack maison RYADESIGN. Calculateur RICE gratuit à la fin.

Par Ramsi Ferkous 2026-06-19 8 min de lecture

Tu as 30 features candidates pour ton prochain trimestre. Tu ne peux en livrer que 6. Comment décider sans biais ?

3 frameworks dominent en 2026. Aucun n'est universellement supérieur — chacun excelle sur un type de décision. Voici comment je les utilise chez RYADESIGN après 50+ projets PM/PO.

RICE : le calcul rationnel

RICE = (Reach × Impact × Confidence) / Effort. Inventé chez Intercom en 2017, devenu le standard PM en 2023.

Forces :

Limites :

Pour quels cas : backlog homogène (toutes les features sont des candidats équivalents). Excellent pour priorisation trimestrielle, scoring d'idées features.

Tu peux calculer tes scores RICE gratuitement avec notre outil (export CSV inclus).

MoSCoW : la simplicité brutale

MoSCoW = Must / Should / Could / Won't. Inventé en 1994 (méthode DSDM). Simple, anti-bullshit.

Forces :

Limites :

Pour quels cas : MVP scoping initial (avant de tout chiffrer), atelier roadmap rapide, contexte fixé (budget fermé, deadline non-négociable).

Kano : l'angle utilisateur

Kano (Noriaki Kano, 1980s) classe les features en 5 catégories selon la satisfaction utilisateur perçue.

Catégories : Basic (table stakes), Performance (linéaire), Delighters (waouh effect), Indifferent (osef), Reverse (énerve les users).

Forces :

Limites :

Pour quels cas : design d'une expérience nouvelle, refonte produit, post-mortem features qui n'ont pas marché.

La stack maison RYADESIGN

Aucun framework seul n'est suffisant. Voici la combinaison que j'applique chez les clients (BNP, MAAF) :

  1. MoSCoW en atelier de cadrage (1 atelier 2h avec stakeholders pour ranger les 30 features candidates).
  2. Kano sur les "Should" pour détecter les delighters cachés (2-3 interviews users).
  3. RICE sur les "Must + Delighters" pour ordonner la roadmap (scoring chiffré).
  4. Confidence × Effort revoting chaque mois (le contexte change, les priorités aussi).

Cette combinaison combine la simplicité de MoSCoW, l'angle user de Kano, et la rigueur chiffrée de RICE.

Outils RYADESIGN

Pour t'aider à appliquer ces frameworks :

Et si tu veux qu'on calibre ta méthode sur ton produit : 30 min gratuit.

· Questions fréquentes
Quel framework choisir pour démarrer ?

MoSCoW si ton équipe est petite (< 5) et que le contexte est clair. RICE si tu as 20+ features à comparer et veux chiffrer. Kano si tu refais une expérience utilisateur et veux identifier les delighters. La meilleure approche : combine les 3 (atelier MoSCoW → Kano sur Shoulds → RICE sur Musts).

Combien de temps prend une priorisation RICE ?

Pour 20 features : 2-4h avec une équipe de 4-6 personnes (PM, design, eng lead, business). Pour 50 features : 1 journée complète. L'outil RICE Calculator automatise le calcul une fois les notes saisies.

RICE et OKR sont-ils compatibles ?

Oui, complémentaires. OKR donne le cap (objectifs trimestriels). RICE arbitre les features candidates pour atteindre chaque OKR. Workflow type : 1 OKR par trimestre → 10-20 features candidates → RICE → top 5-7 features → exécution.

Kano nécessite-t-il vraiment des interviews ?

Pour être rigoureux : oui, 5-8 interviews utilisateurs minimum. En version express : sondage Form (Likert 7 points) avec la question "comment vous sentiriez-vous SI cette feature existait ?" + "comment vous sentiriez-vous SI elle n'existait pas ?".

Comment éviter le biais "tout est Must" en MoSCoW ?

Règle d'or : maximum 60 % du backlog en "Must". Si l'équipe veut tout mettre en Must, force une contrainte : "on a 4 semaines, qu'est-ce qu'on retire ?". Cette question débloque les vrais arbitrages.

Travailler ensemble

On en parle ?