Je me souviens d'une réunion où cinq parties prenantes — produit, ventes, support, marketing et direction — réclamaient chacune la mise en production "pour hier" d'éléments contradictoires. La salle était électrique. Chacun avait des raisons légitimes : quota commercial, taux de churn, visibilité marché, sécurité ou contraintes réglementaires. Résultat : aucune décision claire, frustration, et un backlog qui grossissait sans cesse.

Prioriser un backlog quand tout le monde veut tout maintenant n'est pas un problème de méthode seulement, c'est d'abord un problème de gouvernance, d'alignement d'objectifs et de communication. Voici l'approche que j'utilise et qui m'a permis de débloquer de nombreuses impasses : un mélange de cadrage stratégique, d'outils simples et d'un peu de diplomatie.

Commencer par le principe : pourquoi prioriser ?

Avant d'entrer dans les techniques, j'aime rappeler l'essentiel. Prioriser, ce n'est pas dire non par principe ; c'est choisir où mettre l'énergie limitée de l'équipe pour obtenir le plus grand impact possible, rapidement et de façon répétable. Sans priorisation, on dilue l'effort, on multiplie les allers-retours et on tue la vélocité.

Aligner sur un critère unique (ou très peu)

Quand tout le monde veut tout, la première chose que je fais est d'imposer un cadre d'évaluation commun. Trop de critères rendent la décision opaque. J'encourage à retenir un ou deux critères prioritaires qui reflètent la stratégie actuelle : revenus à court terme, réduction du churn, conformité, ou vitesse d'apprentissage produit. Les équipes aiment la clarté. Quand je dis « clarté », j'entends que chaque demande doit pouvoir se justifier en fonction du critère retenu.

Par exemple, lors d'une mission pour une PME SaaS, nous avons choisi deux indicateurs : impact sur le MRR (revenu récurrent) et effort de développement. Tout élément devait être évalué par rapport à ces deux dimensions. Résultat : beaucoup de "bonnes idées" sont devenues des expérimentations marketing, et seules les modifications impliquant une vraie hausse de MRR ont saturé le sprint.

Méthodes de priorisation pratiques

Voici des méthodes éprouvées. Je n'en recommande pas une seule : le choix dépend du contexte (startup vs grande entreprise, produit mature vs early-stage).

  • MoSCoW (Must / Should / Could / Won't) — simple, bon pour les priorisations tactiques côté features.
  • RICE (Reach, Impact, Confidence, Effort) — utile pour objectiver des choix produits quand on a des données.
  • WSJF (Weighted Shortest Job First) — populaire dans le SAFe : prioritise selon le coût du délai / durée du travail.
  • Cost of Delay — excellent pour parler finance et faire comprendre l'urgence réelle.

    • Mon favori, en pratique, est souvent une version adaptée du RICE ou du WSJF : facile à expliquer, calculable, et surtout défendable auprès des directions.

    Un template simple que j'utilise

    Quand je facilitez un atelier de priorisation, j'affiche un tableau comme celui-ci. Il permet d'objectiver et de visualiser rapidement.

    Feature Reach (nb utilisateurs) Impact (0-5) Confidence (0-100%) Effort (jours) Score RICE
    Amélioration onboarding 1'000 4 80% 10 320
    Rapport export CSV 300 2 90% 2 270
    Refactor sécurité API All 5 70% 15 233

    La formule RICE est : (Reach * Impact * Confidence) / Effort. Les valeurs sont toujours discutables, mais l'intérêt est de comparer des ordres de grandeur.

    Gérer les parties prenantes : trois règles concrètes

    Les outils seuls ne suffisent pas. Voici ce que je fais systématiquement :

  • Impliquer tôt, mais pas trop tôt. Je convie les parties prenantes à un atelier de cadrage où l'on recueille les demandes et leurs hypothèses. Elles contribuent à la définition des critères, mais n'interviennent pas dans le micro-scheduling.
  • Expliquer le coût du changement. Parler en jours/homme et en opportunité : chaque urgence déplacée coûte une autre fonctionnalité. Les parties prenantes comprennent mieux quand on chiffre l'impact.
  • Créer des fenêtres d'injection. Plutôt que de laisser entrer les demandes au fil de l'eau, je définis des moments d'intégration (ex : revue backlog hebdo). Les demandes hors fenêtre sont qualifiées et planifiées.

    • Transformer les demandes "tout de suite" en expériences

    Souvent, une demande urgente est en réalité une hypothèse : "si on fait ça, le taux de conversion augmentera". Plutôt que de lancer une grosse feature, je propose des expérimentations rapides :

  • Prototype low-code ou landing page pour tester l'intérêt.
  • Feature flag pour déployer en A/B auprès d'un petit segment.
  • Campagne marketing ciblée avant le développement pour vérifier la traction.

    • Ces petites expérimentations coûtent peu et réduisent la confiance requise (le paramètre "Confidence" dans RICE). Elles permettent aussi de dégager des quick wins visibles pour les parties prenantes les plus exigeantes.

    Cas pratique : arbitrage entre support et ventes

    Dans une société SaaS que j'ai accompagnée, le support demandait une refonte du moteur de recherche interne pour réduire le backlog tickets. Les ventes exigeaient un tableau de bord commercial. Le CTO menaçait d'arrêter tout nouveau développement tant que la dette technique n'était pas traitée.

    Nous avons mis en place un mini comité de priorisation composé d'un directeur produit, d'un responsable commercial et du head of support. En appliquant RICE et en forçant la discussion sur des chiffres (tickets par jour, CA potentiel par client), nous avons décidé :

  • Priorité 1 : fixs critiques impactant le churn (support).
  • Priorité 2 : tableau de bord minimal viable pour les ventes (2 semaines).
  • Plan D : roadmap technique trimestrielle pour traiter la dette, avec créneaux réservés.

    • Ce compromis a calmé les tensions et rétabli une cadence. Le head of support a ensuite présenté une mesure claire : baisse de 25% du backlog en 6 semaines. Cela a convaincu la direction du bienfondé du plan.

    Rituels pour maintenir une priorisation saine

    Je recommande quelques rituels courts et réguliers :

  • Revue backlog hebdo (30-60 min) : mise à jour des scores et arbitrage rapide.
  • Revue roadmap mensuelle : communiquer l'état et les raisons des choix.
  • Rétrospective priorisation trimestrielle : vérifier si les critères choisis restent pertinents.

    • La transparence est clé : publier un backlog visible et un historique des décisions évite les incompréhensions et les demandes répétées.

    Quand s'affirmer et dire non

    Dire non n'est pas impopulaire si c'est argumenté. J'apprends aux dirigeants à refuser une demande quand :

  • Elle ne répond pas au critère stratégique retenu.
  • Elle coûte plus cher qu'une autre solution moins invasive (expérience, contournement).
  • Elle met en péril le delivery d'un item prioritaire validé par un comité.

    • Un "non" accompagné d'une alternative (expérimentation, MVP, planning) est presque toujours accepté.

    Si vous êtes face à un backlog saturé et à des parties prenantes pressantes, commencez par aligner les objectifs, imposez un critère commun, mettez en place un outil simple de scoring, et révisez régulièrement. Les méthodes existent, mais la discipline et la communication tiennent le reste.