Votre backlog produit contient probablement des dizaines de demandes, mais votre équipe ne peut en traiter qu’une poignée par sprint. Le scoring RICE aide à classer ces demandes par ordre de priorité. Le problème, c’est que beaucoup d’équipes appliquent RICE à toutes les idées sans tri préalable, ce qui transforme un outil de comparaison en générateur de faux classements. Filtrer les demandes avant de les scorer change la qualité des décisions sans ajouter de réunion.
Qualifier chaque feature avant d’ouvrir le tableur RICE
RICE fonctionne mieux quand il porte sur un nombre réduit de fonctionnalités déjà validées. Avant de remplir la moindre colonne Reach ou Impact, chaque demande mérite un test simple : peut-on nommer l’indicateur qu’elle est censée améliorer ?
Ce test s’applique demande par demande, d’où le terme « feature by feature ». On ne parle pas d’un framework de scoring, mais d’une étape de qualification. Chaque demande doit être reliée à un KPI précis : rétention à 30 jours, revenu récurrent, volume de tickets support, coût du délai.
Si personne dans l’équipe ne peut rattacher une idée à un indicateur opérationnel, elle ne passe pas à l’étape suivante. Elle rejoint un parking lot consultable, pas la corbeille. Les sources qui alimentent ce filtre sont concrètes : remontées du support, données d’usage, retours utilisateurs documentés.
Ce tri élimine souvent une part significative des idées d’un backlog gonflé. Le scoring RICE ne devrait démarrer qu’après cette réduction.
Scoring RICE : comment fonctionne la formule de priorisation
Une fois les demandes qualifiées, RICE leur attribue un score fondé sur quatre critères. Chacun répond à une question précise.
- Reach (portée) : combien d’utilisateurs seront touchés sur une période donnée, par exemple un trimestre ou un mois.
- Impact : quel changement cette fonctionnalité produira sur la métrique cible, évalué sur une échelle qualitative (minimal, faible, moyen, fort, massif).
- Confidence (confiance) : à quel point les estimations précédentes reposent sur des données fiables, exprimé en pourcentage.
- Effort : combien de temps-personne la réalisation va demander.
RICE = (Reach x Impact x Confidence) / Effort. Le résultat produit un classement. Mais ce classement n’est pas un verdict automatique.
Un score élevé construit sur des intuitions vaut moins qu’un score moyen appuyé sur des données d’usage réelles. La variable Confidence existe pour signaler ce risque. Quand quelqu’un coche 100 % de confiance sans pouvoir citer une source, le score perd sa valeur de comparaison.
Workflow produit : enchaîner pré-tri et scoring RICE
Vous avez déjà remarqué qu’une réunion de priorisation sans cadre tourne au débat d’opinions ? L’enchaînement pré-tri puis scoring puis contestation sur preuve structure la décision en trois temps.
Pré-tri feature by feature
Avant la réunion, chaque demande passe un test binaire. Un KPI opérationnel est rattaché. Au moins une source de données la soutient. La demande ne fait pas doublon avec une entrée existante. Les demandes qui échouent sortent du périmètre de scoring.
Scoring des demandes qualifiées
Seules les fonctionnalités ayant franchi le filtre reçoivent un score RICE. Cela concentre l’effort d’estimation sur des sujets déjà ancrés dans un objectif mesurable. Pour chaque critère, la personne qui remplit la grille indique la source de son estimation. Une confiance haute sans donnée d’appui est un signal d’alerte, pas une validation.
Contestation sur preuve avant l’arbitrage final
La grille RICE complète est partagée avant la réunion de décision. Toute personne qui souhaite contester un score apporte une donnée concrète ou un retour utilisateur documenté. Les objections sans preuve ne modifient pas le classement.
Cette règle protège les scores des biais hiérarchiques, où la voix la plus forte l’emporte sur l’estimation la mieux documentée. Partager la grille RICE avant la réunion élimine les débats d’opinion et recentre la discussion sur les faits.
Fausse précision RICE : le piège principal à éviter
Multiplier Reach par Impact par Confidence puis diviser par Effort produit un chiffre rassurant. Ce chiffre peut donner l’illusion d’une décision objective alors que chaque variable repose sur une intuition.
Deux fonctionnalités séparées par quelques points de score ne sont pas réellement départagées si les estimations sous-jacentes ont été posées sans données. Scorer une demande sans KPI rattaché revient à quantifier du vide.
Un réflexe utile : traiter les scores proches comme équivalents. Plutôt que de trancher sur un écart non significatif, arbitrer entre ces fonctionnalités sur un critère contextuel (alignement stratégique, dépendance technique, fenêtre de marché). Le pré-tri feature by feature réduit ce risque en amont en éliminant les sujets pour lesquels aucune donnée exploitable n’existe.
Adapter RICE et pré-tri à la taille de votre équipe produit
Le mécanisme reste le même quelle que soit la taille de l’équipe. Ce qui change, c’est la logistique.
Pour une équipe de moins de cinq personnes, le pré-tri se fait de manière asynchrone dans un document partagé. Chaque demande reçoit trois colonnes : KPI rattaché, source de la demande, doublon oui/non. Le scoring RICE se fait ensuite sur un tableur simple, sans outil dédié.
Dans une équipe de taille moyenne, le product manager réalise le pré-tri seul, puis le scoring est rempli collectivement lors d’un atelier dédié. Pour les organisations avec plusieurs squads, chaque squad pré-filtre ses propres demandes, et les scores RICE sont consolidés lors de l’arbitrage inter-équipes.
Ne scorer que ce qui mérite d’être scoré ne ralentit pas le processus. Cette étape supprime le bruit qui, sans filtre, transforme chaque réunion de priorisation en négociation sans fin.
Le pré-tri feature by feature et le scoring RICE ne sont pas deux méthodes concurrentes. Le premier décide de ce qui entre dans le calcul. Le second classe ce qui y est entré. Scorer moins de fonctionnalités avec de meilleures données produit des arbitrages plus rapides et plus défendables qu’un tableur exhaustif rempli d’estimations approximatives.
