← Tous les articles
    8 juin 2026 · priorisation · ROI · audit IA

    Prioriser ses cas d'usage IA par ROI, sans tableur mystique

    Une grille à quatre colonnes qui tient sur une page et qui survit à la réunion d'arbitrage.

    Par Marie Van Haecke

    J'ai vu passer beaucoup de matrices de priorisation dans ma vie de product manager. Les plus belles sont mortes en réunion. Un directeur regarde le classement, dit « je ne suis pas d'accord avec la ligne 4 », et en trente secondes tout l'édifice de pondérations s'effondre — parce que personne dans la salle ne sait remonter à ce qui produit le score. Une grille de priorisation n'a qu'un seul job : tenir debout quand on la conteste.

    Pourquoi les scores sophistiqués ne survivent pas

    Le tableur à douze critères pondérés donne une illusion d'objectivité. En pratique il déplace le débat au lieu de le trancher : on discute des coefficients au lieu de discuter des projets. Et comme les coefficients ont été choisis par quelqu'un, seul, un jeudi soir, ils n'ont aucune légitimité en comité.

    Trois défauts systématiques :

    • L'opacité. Personne ne sait de tête pourquoi le projet A finit devant le projet B.
    • La fausse précision. Un gain estimé à 47 000 € est un gain estimé entre 20 000 et 80 000 € qu'on a maquillé.
    • La rigidité. Le classement ne bouge pas quand le contexte bouge, donc on cesse de le mettre à jour, donc il devient faux.

    En product management, je m'appuie sur RICE ou MoSCoW selon les cas. Ce sont de bons outils, précisément parce qu'ils sont grossiers : quatre facteurs pour RICE, quatre catégories pour MoSCoW. La grossièreté est une fonctionnalité. Elle force à discuter du fond.

    La grille à quatre colonnes

    Pour les cas d'usage IA, j'utilise quatre colonnes et une notation en trois niveaux — fort, moyen, faible. Pas de décimales.

    1. Gain estimé. En temps ou en euros, avec l'hypothèse écrite à côté. Le format que j'impose : « ce geste est fait N fois par semaine, il prend X minutes, on vise une réduction de Y ». Si tu ne connais pas N, la première action n'est pas le projet, c'est de compter pendant deux semaines.

    2. Faisabilité technique. Est-ce que ça se branche sur l'existant, ou faut-il refaire la plomberie ? Un cas d'usage qui suppose de connecter trois systèmes qui ne se parlent pas n'est pas « moyen », il est faible.

    3. Disponibilité des données. Existantes, exploitables, utilisables juridiquement. Trois oui pour un « fort ». Un seul non suffit à descendre en faible.

    4. Appétence de l'équipe. La colonne qu'on oublie et qui décide de tout. Y a-t-il quelqu'un côté métier qui veut que ça marche ? Un projet à fort gain porté par une équipe qui n'en veut pas produit un outil que personne n'ouvre.

    Une page. Une ligne par cas d'usage. Quatre appréciations. C'est tout.

    Comment on lit la grille

    Pas avec une formule. Avec trois règles de lecture, énoncées à voix haute avant de commencer :

    • Un « faible » en données ou en appétence est éliminatoire pour ce trimestre. Pas définitif : on note la condition à lever.
    • On lance en priorité les lignes « fort » en faisabilité et en appétence, même si le gain est moyen. Le premier chantier sert autant à installer la confiance qu'à produire de l'économie.
    • On garde au maximum un chantier à gain fort et faisabilité faible. Un seul. C'est le pari, il est assumé comme tel, et il a un budget plafonné.

    Ces règles se retiennent. C'est leur qualité principale.

    La partie qui compte : la construire ensemble

    Une grille remplie seule ne vaut rien, même si elle est juste. Je remplis toujours les colonnes en séance, avec les responsables métier, en une heure ou deux.

    Il se passe deux choses intéressantes. D'abord, les désaccords sortent au moment où ils sont utiles — quelqu'un dit « non, la donnée n'est pas dispo, on a arrêté de la saisir en janvier », et cette phrase vaut trois jours d'analyse. Ensuite, chacun repart avec un classement qu'il a co-produit, ce qui rend l'arbitrage ultérieur beaucoup plus facile à défendre.

    Un détail de méthode : je fais noter les colonnes 3 et 4 par les personnes concernées, pas par moi. La disponibilité des données se note par ceux qui les manipulent, l'appétence par l'équipe elle-même. Je ne garde la main que sur la faisabilité technique.

    Ce que la grille ne fait pas

    Elle ne remplace pas la décision. Elle l'éclaire et la rend traçable. Le jour où le comité passe outre le classement — ça arrive, pour des raisons politiques ou commerciales parfaitement légitimes — la grille sert au moins à ce que tout le monde sache que la décision a été prise en connaissance de cause.

    Elle ne dit pas non plus quoi faire des cas d'usage écartés. Prévois une colonne de plus, ou une liste à part : le cas d'usage, la condition manquante, et qui la lève. Sans ça, le travail d'analyse est perdu et on refera la même séance dans un an.

    À tester à ta prochaine réunion

    Prends tes idées en cours, ouvre un document, fais quatre colonnes, note fort/moyen/faible en séance avec ceux qui exécutent. Chronométrez-vous : si vous n'y arrivez pas en quatre-vingt-dix minutes, ce n'est pas la grille qui est en cause, c'est que les cas d'usage sont trop flous pour être arbitrés. Ça aussi, c'est une information exploitable.

    À lire aussi

    Vous travaillez sur un sujet proche ?

    J'accompagne les organisations sur l'audit IA, le cadrage de produits IA, les agents et l'automatisation. Si cet article recoupe une question que vous vous posez, on peut en parler.