Mathilde est product manager. Elle sort d’une réunion produit : deux heures de débat sur la feuille de route. Et la décision finale tient en une phrase du directeur général : « On fait la fonctionnalité X, j’en ai besoin pour le salon de juin. »

Mathilde a un point de vue différent, basé sur les besoins des utilisateurs. Mais elle ne se risque pas à trop insister sur la priorisation. La fonctionnalité X devient la priorité.

La priorisation se fait avec la méthode HiPPO : Highest Paid Person’s Opinion. Et si cette méthode résiste malgré son inefficacité, c’est qu’elle est un symptôme.

HiPPO, symptôme d’une structure hiérarchique

La sociologie des organisations aide à comprendre pourquoi HiPPO résiste. Dans les structures hiérarchiques classiques, le pouvoir formel, comme le titre ou le salaire, prime sur le pouvoir légitime : la compétence, la proximité avec les utilisateurs, la maîtrise des données. Remettre en question une décision de la direction, même avec des arguments solides, est souvent perçu comme de l’insubordination plutôt que comme de la rigueur. Le product manager qui ose dire « les données suggèrent une autre priorité » prend un risque politique réel.

Mais HiPPO offre aussi une forme de confort organisationnel. Quand la direction décide, la décision est immédiate, le débat est clos, et la responsabilité repose sur une personne qui porte rarement les conséquences directes de l’échec. Le PM peut se déresponsabiliser : il exécutait. C’est émotionnellement plus sûr que de prioriser par la donnée et d’assumer pleinement les hypothèses que cela implique. La résistance à l’objectivation n’est donc pas irrationnelle. Elle est la réponse logique à une culture où la prise de risque décisionnel n’est pas protégée.

La méthode RICE : rendre les hypothèses discutables

C’est précisément là que le cadre RICE, intégré directement dans Jira Product Discovery, prend tout son sens. Le principe repose sur quatre critères appliqués à chaque idée.

• Le Reach mesure le nombre d’utilisateurs potentiellement concernés.
• L’Impact évalue l’effet attendu sur les métriques business : conversion, rétention, revenu.
• La Confidence traduit le degré de certitude des hypothèses retenues : 100 % signifie qu’on dispose de preuves solides, 50 % que l’on table sur une intuition raisonnée.
• L’Effort chiffre enfin le coût de développement.
• Le score s’obtient par la formule : (Reach × Impact × Confidence) / Effort.

Lorsqu’une partie prenante exige une fonctionnalité « tout de suite », montrer le classement RICE change la nature du débat. On ne discute plus d’opinions, on discute d’hypothèses, de preuves, de valeur relative. C’est ce glissement qui est précieux. Et c’est lui qui transforme la conversation d’un rapport de force en un exercice de pensée collective.

Pourtant, une limite mérite d’être nommée clairement : RICE n’est pas un fait objectif au sens strict. C’est un cadre de rationalisation de jugements subjectifs. Qui définit le Reach ? Sur quelle base évalue-t-on l’Impact avant d’avoir développé quoi que ce soit ? Quel est le fondement réel d’un niveau de Confidence à 80 % ? Ces chiffres sont des hypothèses habillées en calcul. Le vrai avantage de RICE n’est pas de supprimer la subjectivité, c’est de la rendre explicite, et donc discutable.

Le coût cognitif souvent ignoré

L’ergonomie cognitive invite à prendre au sérieux un effet secondaire que l’on sous-estime : le coût cognitif de l’évaluation RICE à grande échelle. Scorer cinquante idées exige d’estimer le Reach sur des bases empiriques, de modéliser l’Impact avec une équipe qui manque souvent de temps, de consulter les développeurs pour chiffrer l’Effort, et de s’interroger honnêtement sur ses propres biais de Confidence. Pour une équipe produit déjà sous pression, ce travail peut devenir un fardeau administratif qui ralentit la décision au lieu de la clarifier.

Le risque est réel : RICE se transforme alors en théâtre de rationalité. On remplit les champs pour satisfaire un processus, sans vraiment croire aux chiffres. La forme est respectée, le fond reste inchangé. Et HiPPO revient par la fenêtre, cette fois habillé en score.

Conditions pour que RICE transforme réellement la prise de décision

Pour éviter ce piège, plusieurs principes s’imposent. Il s’agit d’abord de réserver RICE aux décisions stratégiques : scorer chaque petite amélioration d’interface serait contre-productif. Le cadre conserve son efficacité là où l’enjeu justifie l’investissement cognitif. Il faut ensuite accepter l’approximation : les scores RICE ne seront jamais exacts, et c’est acceptable. L’objectif est de construire un ordre de grandeur comparatif, pas une science exacte. Il convient également de revisiter les scores régulièrement, car les hypothèses qui sous-tendent un chiffre changent avec le marché, les retours utilisateurs et l’évolution de la stratégie. Un score vieux de six mois peut raconter une tout autre histoire que la réalité du moment.

Mais la condition la plus décisive est culturelle. Pour que RICE transforme réellement la prise de décision, il faut que la direction accepte d’être interpellée sur ses demandes, que les product managers soient protégés politiquement lorsqu’ils s’appuient sur les données pour dire non, et que la transparence des scores devienne une norme partagée, pas un privilège réservé à quelques-uns.

Mathilde a dorénavant un cadre pour prioriser, un scoring visible de tous dans Jira. A charge à chacun de prendre ses responsabilités.

La question n’est pas technique. Ce n’est pas « comment configurer RICE dans Jira Product Discovery ». C’est : votre organisation est-elle prête à redistribuer le pouvoir décisionnel du titre hiérarchique vers la donnée ? La réponse à cette question détermine si RICE sera un outil de transformation ou une case supplémentaire à cocher.