Prioriser à vitesse IA : RICE, ICE et MoSCoW tiennent-ils encore ?

Il y a une idée dont on parle encore trop peu en PM : nos frameworks de priorisation ont été conçus pour un problème qui a largement changé de nature.

RICE, ICE, MoSCoW, Kano, tous sont nés dans un contexte de pénurie de données. La question sous-jacente était : "On ne sait pas grand chose, comment structurer notre intuition pour décider quand même ?" En 2026, le problème s'est inversé. Les équipes produit disposent de plus de signaux qu'elles ne peuvent en traiter. L'IA génère du feedback, des hypothèses, des synthèses de tickets support, des analyses d'usage en temps réel. Ce n'est plus l'absence de données qui paralyse, c'est leur abondance.

Continuer à appliquer RICE et MoSCoW dans ce nouveau contexte sans les repenser, c'est un peu apporter un marteau à une table de chirurgie. Les outils ont l'air solides. Mais ils n'ont pas été pensés pour ce contexte.

Ce que ces frameworks sont vraiment

Commençons par un peu d'honnêteté historique.

RICE (Reach, Impact, Confidence, Effort) a été formalisé par Sean McBride chez Intercom et publié en 2016 [1]. La formule : (Reach × Impact × Confidence) / Effort. McBride lui-même écrit dans l'article original : "Choisir un chiffre pour l'Impact peut sembler peu scientifique. Mais souvenez-vous de l'alternative : un fouillis de ressentis." [1] C'est la marque d'un framework défensif, il ne produit pas de certitude, il donne l'apparence d'en produire là où il n'y avait auparavant que de l'intuition brute.

ICE (Impact, Confidence, Ease) a été popularisé par Sean Ellis, l'inventeur du terme "growth hacking", d'abord pour prioriser des expériences de croissance chez Dropbox et Eventbrite [2]. La formule : multiplication des trois facteurs sur 1 à 10. C'est encore plus minimal : pas de dimension Reach, ce qui signifie qu'une amélioration sur une page à fort trafic score autant qu'une sur une page fantôme [2].

MoSCoW (Must / Should / Could / Won't) a été créé par Dai Clegg chez Oracle en 1994 pour le Rapid Application Development, et adopté par la méthode DSDM à partir de 2002 [3]. Sa limite de conception : il classe les items en buckets mais n'aide pas à décider entre deux items dans le même bucket. Résultat documenté : les équipes finissent avec 20 "Must Have" et rien n'a changé [4].

Kano vient du professeur Noriaki Kano, qui a publié son modèle en avril 1984 dans le Journal of the Japanese Society for Quality Control [5]. Il distingue Must-Be (basique), One-Dimensional (performance linéaire), Attractive (délice), Indifférent et Reverse. Son point fort est réel : il capture la dynamique temporelle, ce qui délecte aujourd'hui devient une attente basique demain. Son point faible est structurel : il nécessite des enquêtes clients à grande échelle (instable sous N < 200 [6]) et suppose une base d'utilisateurs existante, ce qui le rend inutilisable en phase pré-produit.

Ce qui montre ses limites : la fausse précision chiffrée

Le problème central de RICE et ICE est mathématique, pas culturel.

Quand vous multipliez des estimations subjectives, les erreurs s'amplifient. Un billet de The Honest Product Manager le formalise ainsi : "Si vous incluez une marge d'erreur sur chaque valeur, vous obtenez une marge d'erreur totale massive. Quand vous multipliez des facteurs avec une marge d'erreur de ±10% chacun, la marge totale sur le score résultant est de 40%." [7] Un score de 72 et un score de 68 ne sont pas statistiquement différents. Mais les traiter comme tels est exactement ce que font les équipes en pratique.

Jenny Wanger, qui a co-écrit un article pro-scoring en 2018 et a depuis fait évoluer sa position publiquement, décrit le mécanisme : "On passe trois heures à débattre si quelque chose vaut 3 ou 4 en 'impact'. Les gens commencent à jouer avec le système, gonflant les scores pour leurs projets favoris. On obtient une fausse précision, un score de 8,2 donne l'impression d'être plus scientifique que 'ça semble assez important'." [8]

Janna Bastow (ProdPad), qui a inventé le roadmap Now/Next/Later, est encore plus directe : "On ne finit pas avec de la clarté. On finit avec un tableur qui ressemble à de la clarté." [9]

Le terme académique est "fausse précision". Jeffrey Saltzman (Fellow de la Society for Industrial and Organizational Psychology) l'articule ainsi : "La fausse précision surgit quand l'apparente certitude des chiffres donne un vernis d'autorité, masquant l'incertitude qui imprègne toute investigation empirique." [10] Et d'ajouter que ce biais est amplifié par notre tendance naturelle à croire en l'autorité des nombres précis, même quand cette précision n'est pas méritée.

Mon point de vue : L'une des fonctions les plus utiles de RICE n'est pas de trouver les meilleures idées. C'est de rendre plus facile, collectivement, le refus des moins bonnes. Le score 14 passe devant le score 12, et le PM dispose d'un appui partagé pour dire non. C'est autant un outil de conversation qu'une méthode de calcul. Ça reste précieux, à condition de le reconnaître pour ce qu'il est.

Ce qui résiste : la discipline de la question

MoSCoW et Kano partagent une même limite de conception : ils demandent quoi prioriser sans jamais forcer la question pourquoi cet objectif.

Mais cette faiblesse révèle ce qui, dans ces frameworks, résiste à l'IA : la contrainte de s'obliger à formuler une question avant de répondre.

Kano, appliqué correctement, force à distinguer ce que les utilisateurs attendent sans le dire de ce qui les surprend positivement. Cette distinction conceptuelle reste valable indépendamment du volume de données. L'IA peut automatiser la collecte des signaux Kano, miner les avis, les tickets, les conversations, mais la taxonomie she-même est un outil de pensée, pas un artefact de l'ère pré-données.

MoSCoW force à trancher sur le périmètre d'une itération. Cette contrainte reste saine. Le problème n'est pas le cadre mais sa dégradation : quand "Must Have" devient "tout ce que quelqu'un avec du pouvoir a réclamé", le framework a cessé de jouer son rôle et risque surtout de légitimer des décisions déjà prises.

Rich Mironov le formule sans détour : "Quand on additionne tout ce qui figure sur les listes de priorisation de chaque département, on obtient généralement entre 20 et 50 fois plus de demandes que ce que les équipes pourront jamais réaliser. Pas 20 à 50%, mais 20 à 50 fois." [11] Le vrai travail de priorisation est de dire non à 95% du backlog. RICE et MoSCoW ne résolvent pas ce problème, ils l'habillent.

Le nouveau problème : la surabondance de signal

En 2026, la contrainte n'est plus le manque de données. C'est leur excès.

Pendo a documenté en 2024 que seulement 6,4% des fonctionnalités génèrent 80% des interactions utilisateurs dans les produits SaaS, soit 94% des features qui existent sans que personne ne s'en serve [12]. C'est l'échec de priorisation à son état le plus concret. Et il précède l'ère de l'IA. L'abondance de signaux générés par l'IA ne fait qu'aggraver l'écart entre bruit et décision.

Les outils évoluent en réponse. Productboard a lancé en 2026 "Spark", une plateforme agentique qui mine les tickets support, les conversations sales et les données d'usage pour alimenter des recommandations de roadmap [13]. Jira Product Discovery intègre désormais Rovo, son agent IA de workflow [13]. L'idée : automatiser le remplissage des scores RICE avec des données réelles plutôt que des estimations à la main.

Shaun Clowes, CPO de Confluent (ex-Atlassian), écrit dans le blog Reforge en mars 2025 : "Les aspects mécaniques de la priorisation ont été largement automatisés. Les PMs doivent maintenant se concentrer davantage sur le 'pourquoi' stratégique derrière les décisions de priorisation." [14]

C'est un renversement de perspective. Les frameworks n'ont jamais vraiment excellé sur le "quoi", ils donnaient surtout l'impression de le résoudre. Maintenant que l'IA fait le "quoi" mécaniquement, le "pourquoi" stratégique devient la seule compétence non substituable.

Mon point de vue : Le principal point de vigilance avec l'IA dans la priorisation n'est pas qu'elle se trompe. C'est qu'elle peut donner une confiance excessive, amplifiée. Un score RICE que vous avez calculé à la main en 30 minutes, vous savez que c'est approximatif. Un score généré par une IA à partir de 10 000 tickets, vous avez envie d'y croire. "Garbage in, garbage out" ne disparaît pas avec l'IA, il devient invisible. La question n'est pas "est-ce que l'IA a analysé assez de données ?" mais "est-ce que ces données capturent ce qui compte vraiment ?"

Le risque de la décision sous incertitude radicale

McKinsey a conduit en 2024 une expérience contrôlée avec 40 product managers sur un cycle produit de 6 mois. Résultat : l'IA générative améliore la productivité PM de 40%, mais n'accélère le time-to-market que d'environ 5% sur le cycle complet [15]. Le goulot d'étranglement n'est pas la production de contenu. C'est la décision elle-même.

Ravi Mehta (ancien CPO de Tinder, Reforge) le formule avec une métaphore juste : "Pensez à conduire une voiture. Quand vous allez lentement, les ajustements du volant ne font pas grand chose. Mais si vous allez vite, de légères impulsions peuvent vous envoyer dans le mauvais sens. Quand les équipes accélèrent, la capacité des PMs à définir la direction devient encore plus importante." [14]

La vitesse augmente l'importance du jugement, elle ne la remplace pas.

Noah Weiss, CPO de Slack, le dit explicitement dans une interview First Round en décembre 2023 : "Il est devenu à la mode de dire que tout peut être répondu empiriquement par les données. L'ethos, surtout en produit, est que sauf si vous faites tout sous forme d'expérimentation, vous le faites mal. Et je ne suis pas d'accord." [16]

Andrew Chen (a16z), dans un essai de mai 2024, décrit l'écueil symétrique de l'excès de confiance data : "Dans ma vingtaine, j'errais vers une dépendance aux données à tout prix. Mais j'ai découvert que ça m'amenait souvent à des maxima locaux. Plus tard, j'ai appris à être data-informé, en gardant mon intuition mais en la superposant avec les données." [17]

Ce qu'il reste à construire

La reconstruction n'est pas un nouveau framework avec un meilleur acronyme. C'est une architecture de décision à trois niveaux :

1. Stratégie d'abord, scoring ensuite. Les frameworks de priorisation classent des options au sein d'une solution space. Ils ne définissent pas la solution space. Quand une équipe passe plus de temps à débattre si une feature vaut 3 ou 4 en impact qu'à clarifier quel problème utilisateur elle résout, le scoring est devenu un substitut à la stratégie. Reforge l'écrit directement : "La difficulté à prioriser est souvent un problème de stratégie, pas d'exécution." [18]

2. Signaux continus plutôt que scoring ponctuel. Un score RICE calculé en Q1 est périmé en Q2 dans un marché qui bouge. Les équipes qui gagnent en 2026 remplacent les cycles trimestriels de priorisation par des "boucles d'opportunité adaptatives", des processus continus alimentés par la télémétrie live, les signaux clients en temps réel, et des révisions hebdomadaires légères. Le score n'est plus une décision mais un indicateur parmi d'autres.

3. Jugement tracé, pas scoring opaque. La vraie valeur de RICE n'est pas le nombre final. C'est la conversation que la notation force. Si un score bas devient inattaquable parce que l'IA l'a calculé, on a perdu l'intérêt du cadre. Le remède : exiger que chaque décision de priorisation documente le raisonnement stratégique, pas seulement le score. Pourquoi cet item est prioritaire face aux alternatives, et quelle hypothèse serait invalidée si on se trompait.

Ce qui reste valable, sans romantisme

RICE tient encore comme langage commun pour forcer une équipe à nommer ses hypothèses sur l'audience, l'impact, la confiance et l'effort. Pas comme oracle. Comme structure de conversation.

ICE tient encore pour les équipes growth en phase d'expérimentation rapide, où la vitesse d'exécution prime et où les features ont une audience homogène, le contexte pour lequel Sean Ellis l'a conçu.

MoSCoW tient encore pour le cadrage de scope sur une itération donnée, à condition d'être couplé à des critères de succès (outcomes) et non à des listes de features.

Kano tient encore pour les décisions de positionnement long terme, distinguer ce qui est désormais une table stakes de ce qui peut encore différencier. C'est une boussole, pas un GPS.

Ce qui ne tient plus : traiter n'importe lequel de ces frameworks comme une réponse suffisante à la question de priorisation en 2026.

Mon point de vue : La dette méthodologique, c'est exactement ça : adopter des outils sans reprendre le temps de reconstruire la méthode sous-jacente. L'IA ne résout pas la priorisation, elle déplace le centre de gravité de la décision. Si l'on automatise RICE avec des données IA sans avoir clarifié sa stratégie produit, on risque surtout de produire des certitudes fragiles beaucoup plus vite. La vitesse n'est pas le point de vigilance. C'est plutôt un jugement solidement ancré dans une stratégie claire qui fait la différence.

Sources

RICE: Simple prioritization for product managers, Sean McBride, Intercom Blog, Définition originale du framework RICE (2016), caveats de l'auteur lui-même.
ICE Framework, Stuart Brameld, Growth Method, Définition ICE, attribution à Sean Ellis, analyse des faiblesses structurelles (absence de Reach, biais d'ancrage).
MoSCoW method, Wikipedia, Origine Dai Clegg 1994, définition des quatre catégories, critiques documentées (Wiegers & Beatty 2013).
The Problem with MoSCoW Prioritization, Umar Nasir, Agile Insider (Medium), Must-Have inflation, perte de contexte, fausse sécurité (novembre 2024).
Kano model, Wikipedia, Origine Kano 1984, définition des 5 catégories, dynamique temporelle.
Criticisms and counter-criticisms of Kano model, Conjointly, Instabilité pour N < 200, problèmes de la grille de réponse, critique théorique de la catégorie Performance.
RICE Ain't So Nice, The Honest Product Manager (Substack), Démonstration mathématique de l'amplification des marges d'erreur par multiplication.
Stop scoring everything: how to prioritize with strategy, Jenny Wanger, Retournement de position d'une ancienne défenseure du scoring, fausse précision, gaming (septembre 2025).
Why Product Teams Don't Have a Prioritization Problem, They Have a Decision Confidence Problem, Janna Bastow, ProdPad, "Un tableur qui ressemble à de la clarté" (janvier 2026).
False Precision, Jeffrey Saltzman, OrgVitality, Définition conceptuelle de la fausse précision, biais cognitif de confiance dans les chiffres.
My Next Word to Retire is 'Prioritization', Rich Mironov, La demande dépasse 20 à 50 fois la capacité de production ; l'enjeu réel est d'éliminer, pas de classer (août 2024).
Feature Prioritization Matrix for Product Teams, Userpilot, Données Pendo 2024 : 6,4% des features génèrent 80% des interactions.
AI Product Roadmap Prioritization: A Guide for Modern Product Teams, Productboard, Outils IA de priorisation, annonce de Spark, intégration Jira/Rovo.
Moving To Higher Ground: Product Management In The Age of AI, Reforge, Citation Shaun Clowes sur l'automatisation du scoring mécanique ; citation Ravi Mehta sur la direction à haute vitesse (mars 2025).
How generative AI could accelerate software product time to market, McKinsey, Étude contrôlée, 40 PMs : +40% productivité, ~5% accélération time-to-market (mai 2024).
How to Take Bigger, Bolder Product Bets, First Round Review / Noah Weiss (Slack), Citation sur les limites du tout-data (décembre 2023).
Why data-driven product decisions are hard, Andrew Chen (a16z), Données = maxima locaux ; "data-informed" vs "data-driven" (mai 2024).
The Product Strategy Stack, Reforge / Ravi Mehta, La difficulté à prioriser est souvent un problème de stratégie, pas d'exécution.