Prioriser les fonctionnalités d'un outil métier : la grille en 3 critères

Votre outil métier a un objectif de fonctionnalités, pas un objectif de parcours

Un outil interne qui grossit depuis deux ans ressemble souvent à une accumulation de fonctionnalités placées les unes après les autres, chacune répondant à une demande précise du moment, sans qu'aucun critère commun n'ait jamais arbitré entre elles. Le résultat n'est pas un mauvais outil au sens où rien ne fonctionnerait, c'est un outil où personne ne peut expliquer pourquoi telle fonctionnalité est là et pas une autre, sinon par l'historique de qui l'a demandée le plus fort.

Ce mode de construction porte un nom reconnaissable une fois qu'on le voit, l'usine à fonctionnalités. Chaque brique est livrée proprement, chaque ticket est fermé, mais l'ensemble ne raconte plus le parcours réel de l'utilisateur qui doit accomplir une tâche du début à la fin. Sur un projet de refonte d'un outil interne, ce constat a été posé sans détour, une fois toutes les fonctionnalités passées en revue.

« Il n'y a pas un objectif de parcours utilisateur, il y a un objectif de fonctionnalité. Toutes les fonctionnalités ont été placées, mais il n'y a pas un objectif de parcours. »

Pourquoi la complexité technique perçue est le pire critère de priorisation

Face à une pile de demandes, le réflexe le plus courant consiste à trier par faisabilité, on avance sur ce qui semble rapide à coder et on repousse ce qui semble complexe. Ce critère mesure l'effort de développement, jamais la valeur produite pour l'utilisateur. Une fonctionnalité facile à coder mais utilisée une fois par trimestre consomme un temps de développement qu'une fonctionnalité plus lourde mais mobilisée chaque jour aurait mieux justifié.

Ce critère de faisabilité séduit surtout parce qu'il donne une impression d'avancement rapide, chaque ticket facile fermé produit une sensation de progrès immédiat. Le problème apparaît plus tard, quand on additionne le temps passé sur une série de petites fonctionnalités faciles mais marginales, et qu'on le compare au temps qui n'a jamais été consacré à la fonctionnalité plus lourde mais réellement structurante. La facilité perçue d'une tâche ne dit rien de sa valeur, elle dit seulement combien de temps elle prendra à quelqu'un qui la connaît déjà.

Le second critère implicite, tout aussi trompeur, priorise selon la personne qui demande le plus fort ou le plus souvent. Sur le terrain, cela revient à laisser l'organigramme informel décider de la roadmap, pas les usages réels. Un dirigeant qui réclame une fonctionnalité qu'il utilisera lui-même une fois par mois passe alors devant un usage quotidien de dix opérationnels, simplement parce que sa voix porte plus loin en interne.

Ce second biais explique en grande partie pourquoi un outil interne finit par avoir un objectif de fonctionnalité plutôt qu'un objectif de parcours. Chaque fonctionnalité arrive avec sa propre justification locale, valable au moment où elle est demandée, mais personne ne se demande ensuite quel effet elle produit sur la lisibilité de l'ensemble. Ajouter un champ ici, un filtre là, un export ailleurs, chaque décision prise isolément semble raisonnable, jusqu'à ce que l'écran principal accumule quinze options dont trois seulement sont utilisées chaque semaine. Le problème n'est jamais une fonctionnalité prise seule, c'est l'absence de critère qui aurait permis de dire non aux douze autres au moment où elles sont arrivées.

Le tri à trois filtres : fréquence, impact sur la décision, visibilité

Une grille de priorisation plus fiable s'appuie sur trois critères observables, indépendants de qui demande ou de la difficulté technique perçue. La fréquence d'usage mesure si la fonctionnalité sert quotidiennement ou rarement. L'impact sur la décision mesure si elle change réellement un choix opérationnel, ou si elle documente une information déjà connue sans rien changer à l'action qui suit. La visibilité du problème mesure si l'absence de cette fonctionnalité saute aux yeux de plusieurs personnes, ou si elle ne gêne qu'un usage marginal.

Concrètement, notez chaque demande sur les trois critères avec un score simple, faible, moyen, fort, sans chercher une précision illusoire. Une demande d'export mensuel utilisé par une seule personne, sans effet sur une décision immédiate, et invisible pour le reste de l'équipe, obtient trois scores faibles, elle attend. Une demande de correction d'un écran consulté chaque jour par dix opérationnels, qui les fait actuellement se tromper de référence produit, obtient trois scores forts, elle passe devant tout le reste. L'intérêt de la grille n'est pas dans la précision du score, il est dans le fait de forcer une comparaison sur les mêmes trois axes pour toutes les demandes, plutôt que de juger chacune isolément selon son propre mérite apparent.

Ce que ce filtre a exclu concrètement

Sur un outil de gestion de personnel et d'options logistiques, l'application de cette grille a explicitement écarté deux demandes qui semblaient légitimes, l'export par jour et l'affichage des horaires individuels. Aucune des deux ne touchait un usage quotidien à fort volume, aucune ne changeait une décision opérationnelle immédiate. À la place, l'équipe a priorisé la lisibilité des catégories de personnel, la suppression des redondances dans l'affichage, et la correction de bugs qui bloquaient le parcours principal, trois points visibles et fréquents, contrairement aux deux écartés.

Un réflexe simple avant chaque ajout

Sur ce même outil, l'équipe a formalisé une question systématique avant d'intégrer quoi que ce soit de nouveau à l'écran, quel est l'impact de cet ajout sur la lisibilité des fonctionnalités déjà en place. Cette question ne figure dans aucun des trois filtres au sens strict, elle en est le prolongement naturel, parce qu'une fonctionnalité qui score haut sur la fréquence et l'impact décisionnel peut malgré tout dégrader l'ensemble si elle est mal intégrée. La bonne pratique consiste à se demander, à chaque ajout, s'il mérite un nouvel écran dédié ou une place dans l'écran existant, plutôt que d'empiler par défaut au même endroit parce que c'est le chemin le plus rapide à coder.

Pour une méthode complémentaire sur la façon de cadrer ce qui rentre dans une première version d'un outil sur mesure, l'article sur la normalisation avant d'automatiser en V0 détaille comment poser un périmètre initial tenable avant même d'arbitrer entre fonctionnalités.

Ce que cette grille n'arbitre pas, et où elle s'arrête

Le tri à trois filtres ne remplace pas une vision produit. Il évite les décisions arbitraires sur des demandes isolées, il ne dit pas où l'outil doit aller dans deux ans. Une fonctionnalité rarement utilisée aujourd'hui mais nécessaire pour ouvrir un nouveau cas d'usage stratégique peut légitimement passer devant une fonctionnalité plus fréquente mais mineure, à condition que cette exception soit assumée explicitement, pas déguisée en application normale de la grille.

La grille suppose enfin qu'on dispose d'une estimation honnête de la fréquence d'usage réelle, pas de la fréquence supposée au moment de la demande. Une fonctionnalité présentée comme indispensable au quotidien se révèle parfois utilisée deux fois par mois une fois mise en production, tandis qu'un détail jugé mineur devient un point de passage obligé pour la moitié de l'équipe. Revenir mesurer l'usage réel après quelques semaines, plutôt que de se fier uniquement à l'estimation initiale, permet de corriger la priorisation suivante sur la base de faits plutôt que d'anticipations.

La grille ne dit rien non plus sur le rythme d'annonce des livraisons au client. Une équipe peut prioriser correctement selon les trois filtres et continuer à annoncer des dates intenables si elle sous-estime systématiquement le temps nécessaire à chaque brique retenue. Prioriser juste et estimer juste sont deux disciplines distinctes, la première dit quoi faire en premier, la seconde dit combien de temps ça prendra réellement, et confondre les deux est une source fréquente de tension avec un client qui a fini par entendre une date sans que personne n'ait vérifié qu'elle tenait.

Le principe suppose aussi que quelqu'un tranche réellement une fois les scores posés. Une grille de critères qui sert uniquement à documenter un débat sans jamais trancher reproduit le problème initial sous une forme plus sophistiquée. Sur la façon de sécuriser ce type d'arbitrage dans la durée, l'approche documentation first sur un projet IT montre pourquoi consigner ces arbitrages évite de rejouer le même débat six mois plus tard.

Avant la prochaine demande de fonctionnalité qui arrive sur votre outil métier, passez-la dans les trois filtres avant de répondre. Si elle échoue sur les trois, dites-le clairement à la personne qui l'a demandée, avec la raison, plutôt que de la laisser s'empiler dans un backlog que personne ne réexamine jamais.