Articles

Cadre de notation RICE : comment prioriser votre backlog produit

Équipe produit réunie autour d'un tableau blanc couvert de notes autocollantes colorées, triant et classant les éléments pour décider quoi construire ensuite Chaque équipe produit rencontre le même problème : trop d'idées et pas assez de temps. Les parties prenantes poussent des priorités contradictoires, les ingénieurs veulent rembourser la dette technique, et les clients ne cessent de demander des fonctionnalités. Sans une méthode claire pour classer ce qui compte le plus, c'est la voix la plus forte dans la salle qui l'emporte. RICE est un cadre de notation développé par l'équipe produit d'Intercom qui tente de résoudre ce problème. Il évalue les fonctionnalités selon quatre dimensions (Portée, Impact, Confiance et Effort) et produit un nombre unique que vous pouvez utiliser pour comparer n'importe quoi dans votre backlog.

Comment fonctionne la notation RICE

Voici la formule : Score RICE = (Portée × Impact × Confiance) / Effort Chaque composant mesure quelque chose de différent :

Composant	Ce qu'il mesure	Comment le noter
Portée	Combien de personnes cela affecte sur une période définie	Nombres réels (ex. : 2 000 utilisateurs/trimestre)
Impact	À quel point chaque personne est affectée	3 = massif, 2 = élevé, 1 = moyen, 0,5 = faible, 0,25 = minimal
Confiance	À quel point vous êtes sûr de vos estimations	100 % = appuyé par des données, 80 % = quelques preuves, 50 % = principalement des suppositions
Effort	Temps total de l'équipe requis	Personnes-mois (incluez conception, dev, QA, docs)

Le résultat est « l'impact total par temps travaillé », ce que vous devriez optimiser pour décider quoi construire ensuite.

Un exemple rapide

Supposons que votre équipe envisage d'ajouter des recommandations de produits personnalisées :

• Portée : 2 000 clients par trimestre
• Impact : 2 (élevé, affecte directement la conversion)
• Confiance : 80 % (vous avez des données de test A/B d'un concurrent)
• Effort : 3 personnes-mois

Score RICE = (2 000 × 2 × 0,8) / 3 = 1 067 Comparez cela aux autres éléments du backlog et vous obtenez un classement basé sur les données. Essayez de saisir vos propres fonctionnalités dans notre Calculateur de score RICE gratuit pour voir comment elles se classent.

Bien noter chaque composant

La formule est simple. Obtenir des données précises est la partie difficile.

Portée : utilisez des nombres réels, pas des pourcentages

La portée doit être un décompte concret d'utilisateurs ou d'événements sur une période fixe. « Tous nos utilisateurs » n'est pas une estimation de portée. Vérifiez vos analyses. Si vous construisez une nouvelle page de paramètres, ne supposez pas que tous les 10 000 utilisateurs actifs la toucheront. Les données historiques pourraient montrer que seulement 1 200 utilisateurs visitent les paramètres au cours d'un trimestre donné. Utilisez ce nombre.

Impact : forcez une distribution

La plus grande erreur que font les équipes avec l'Impact est de tout noter 2 ou 3. Si chaque fonctionnalité a un « impact élevé », le score perd son sens. Établissez une règle : pas plus de 20 % des fonctionnalités peuvent être notées 3 (massif). Définissez ce que signifie chaque niveau pour vos métriques spécifiques. Par exemple, « 3 = amélioration projetée de 10 %+ dans une métrique commerciale que nous suivons activement ».

Confiance : commencez bas et montez progressivement

Par défaut, mettez 50 % de confiance pour toute idée qui n'a pas été validée. Une demande de partie prenante sans recherche utilisateur ? 50 %. Une fonctionnalité inspirée d'un concurrent sans données sur le fait que vos utilisateurs la veulent ? 50 %. Passez à 80 % lorsque vous avez des preuves à l'appui comme des entretiens utilisateurs, des données d'enquête ou des résultats de tests de prototypes. Réservez 100 % pour les fonctionnalités soutenues par des analyses solides ou des expériences réussies.

Effort : comptez tout, pas seulement l'ingénierie

Un piège courant est d'estimer uniquement le temps de développement. L'effort réel inclut également la découverte, la conception, le QA, la documentation et la coordination du lancement. Demandez à chaque discipline son estimation et ajoutez une marge de 30 %. Une personne équilibrant soigneusement des objets de différentes tailles sur une balance, représentant la pondération de la portée, de l'impact, de la confiance et de l'effort

RICE vs MoSCoW vs WSJF

RICE n'est pas le seul cadre de priorisation disponible. Deux autres options populaires sont MoSCoW et WSJF. Chacune fonctionne mieux dans des contextes différents.

	RICE	MoSCoW	WSJF
Type	Score quantitatif	Catégories	Score économique
Meilleur pour	Classement au niveau des fonctionnalités	Définition de la portée MVP	Décisions au niveau des épopées/initiatives
Données nécessaires	Métriques utilisateurs + estimations	Jugement des parties prenantes	Données économiques + apport inter-équipes
Complexité	Moyenne	Faible	Élevée
Résultat	Score de priorité numérique	Doit / Devrait / Pourrait / Ne fera pas	Priorité du coût du délai

MoSCoW trie les éléments en Doit avoir, Devrait avoir, Pourrait avoir et Ne fera pas. C'est rapide et facile à expliquer aux parties prenantes non techniques. L'inconvénient est que c'est subjectif : tout tend à dériver vers « Doit avoir » sans critères clairs. Cela fonctionne mieux au début lorsque vous définissez un MVP. WSJF (Weighted Shortest Job First) provient du cadre SAFe. Sa formule prend en compte la valeur commerciale, la criticité temporelle et la réduction des risques, le tout divisé par la taille du travail. Cela fonctionne bien pour les grandes initiatives couvrant plusieurs équipes, mais cela nécessite une véritable formation pour être utilisé correctement. La plupart des équipes trouvent cela excessif pour les décisions au niveau des fonctionnalités. RICE se situe entre les deux. Il demande plus de rigueur que MoSCoW mais n'a pas besoin de l'infrastructure de données lourde que WSJF exige. Si votre équipe dispose d'analyses utilisateurs de base et souhaite dépasser la priorisation au feeling, RICE est un bon point de départ. Si votre équipe utilise le priority poker pour classer collaborativement les éléments du backlog, les scores RICE vous donnent un solide point de départ pour ces discussions.

Erreurs courantes qui faussent vos scores

Même les équipes qui adoptent RICE tombent systématiquement dans quelques pièges. Noter en isolation. Lorsqu'un seul PM note tout seul, les biais s'infiltrent. Faites estimer l'Effort par les ingénieurs, demandez aux designers de peser sur l'Impact et faites valider la Portée par les analystes de données. La notation collaborative produit de meilleurs résultats. S'ancrer sur le premier score. Si vous discutez des scores à voix haute avant que tout le monde ne vote, les gens s'ancrent sur le premier nombre qu'ils entendent. Notez individuellement d'abord, puis comparez. Même principe que le planning poker : estimation indépendante avant discussion de groupe. Sauter le recalibrage. Les scores RICE deviennent obsolètes. Les conditions du marché changent, de nouvelles données arrivent et la capacité de l'équipe évolue. Revisitez les scores trimestriellement et mettez à jour tout élément resté dans le backlog pendant plus d'un cycle. Traiter le nombre comme absolu. Un score RICE de 850 contre 820 ne signifie pas que la première fonctionnalité est significativement plus importante. Regroupez les scores similaires en niveaux (priorité haute / moyenne / basse) et utilisez votre jugement au sein de chaque niveau. Membres d'équipe écrivant individuellement des scores sur des cartes avant de les révéler ensemble, prévenant le biais d'ancrage

Débuter avec RICE

Si vous n'avez jamais utilisé RICE auparavant, voici comment le déployer sans trop compliquer les choses. L'objectif n'est pas une précision parfaite. Une estimation à peu près juste bat une opinion sûre d'elle mais fausse. La majeure partie de la valeur de RICE provient de la conversation qu'il force : pour qui construisons-nous, à quel point c'est important, et combien cela coûtera-t-il réellement. Pour plus d'informations sur la préparation de votre backlog pour la planification de sprint, consultez nos guides sur l'affinage du backlog et la planification de sprint.