Le piège de la liste plate
Formuler des hypothèses est devenu une pratique courante en gestion de projet. On identifie les suppositions clés, on les rend explicites, et on prévoit de les tester. Jusqu’à ce point la méthode est claire, mais ce qui pose problème survient dès que la liste d’hypothèses dépasse cinq ou six lignes.
En pratique, les équipes se retrouvent souvent avec un inventaire d’hypothèses traitées comme une liste plate, sans hiérarchie. Certaines touchent à l’existence même du besoin, d’autres portent sur des détails d’implémentation. Pourtant, elles cohabitent au même niveau dans un tableur ou sur un mur de post-its, comme si elles avaient toutes la même importance. La conséquence est prévisible: on teste ce qui est le plus facile à tester, ou ce qui intéresse le plus la personne la plus influente dans la salle.
Valeur et risque: deux dimensions au lieu d’une
Jeff Gothelf, co-auteur de Lean UX (O’Reilly), a formalisé un outil pour sortir de cette impasse: le Hypothesis Prioritization Canvas (HPC). Le principe est une matrice à deux dimensions. L’axe vertical représente la valeur perçue de l’hypothèse, c’est-à-dire ce que l’équipe estime être l’importance de la question posée. L’axe horizontal représente le risque, défini de façon contextuelle selon le projet: risque technique, risque de marché, risque organisationnel ou risque lié à l’usage.
La nuance centrale tient dans le mot “perçue”. La valeur n’est pas mesurée, elle est estimée collectivement. L’outil rend cette estimation visible et discutable au lieu de la laisser implicite dans la tête de chaque partie prenante.
Quatre quadrants, quatre postures
Le croisement des deux axes dessine quatre zones qui appellent chacune une réponse différente.
Les hypothèses à haute valeur et haut risque occupent le premier quadrant. Ce sont celles qui pourraient invalider le projet si elles se révèlent fausses, et dont personne dans l’équipe n’est certain qu’elles soient vraies. Elles méritent le temps de discovery (cette phase d’exploration dédiée à tester les hypothèses avant d’engager des ressources de réalisation). Prototypes, entretiens et expériences légères: c’est là que le temps d’exploration a le plus d’impact.
Les hypothèses à haute valeur et faible risque constituent le deuxième quadrant. L’équipe a suffisamment confiance pour construire directement. La vérification se fera en conditions réelles par les métriques d’usage ou de performance, sans nécessiter d’expérimentation préalable.
Le troisième quadrant rassemble les hypothèses à faible valeur et faible risque: les table stakes, ces éléments nécessaires au fonctionnement du projet mais non différenciants. On les intègre dans le plan sans y consacrer de temps d’analyse.
Le quatrième quadrant contient les hypothèses à faible valeur et haut risque. Elles combinent une promesse limitée et une incertitude forte. La décision rationnelle est de les écarter, libérant ainsi des ressources pour les questions qui comptent réellement.
Ce que révèle le placement collectif
L’un des bénéfices les plus concrets du HPC n’est pas la matrice elle-même mais la conversation qu’elle provoque. Quand une équipe place ses hypothèses sur les deux axes, les divergences de perception deviennent visibles.
Un responsable métier peut considérer qu’une hypothèse de marché est à faible risque parce qu’il “connaît ses clients”. Un membre de l’équipe technique peut voir le même sujet comme hautement risqué parce que les données disponibles sont faibles. Le désaccord, rendu explicite par le positionnement sur la matrice, ouvre une discussion productive qui aurait difficilement eu lieu autrement. Sans cet outil, ce type de divergence reste souvent enfoui et n’émerge qu’au moment où le projet rencontre un obstacle.
L’exercice fonctionne mieux en petit groupe (quatre à huit personnes couvrant des perspectives différentes sur le projet). Le format est délibérément visuel: on déplace physiquement les hypothèses sur une surface quadrillée, ce qui rend les arbitrages tangibles et facilite l’émergence de compromis.
La hiérarchie naturelle des hypothèses
Ash Maurya, dans Running Lean (O’Reilly, 2012), propose une hiérarchie qui complète bien la matrice de Gothelf. Selon Maurya, les hypothèses s’organisent en trois niveaux: l’hypothèse de problème (le besoin existe-t-il réellement?), l’hypothèse de solution (notre réponse est-elle adéquate?) et l’hypothèse de modèle économique (le projet est-il viable?). L’ordre de test suit cette hiérarchie, car une hypothèse de solution n’a pas de sens si l’hypothèse de problème est fausse.
Cette hiérarchie apporte un filtre supplémentaire à la matrice valeur-risque. Parmi les hypothèses classées “haute valeur, haut risque”, celles qui portent sur le problème devraient être testées avant celles qui portent sur la solution. Le HPC indique quelles hypothèses méritent l’attention; la hiérarchie de Maurya précise dans quel ordre les aborder.
Application hors du monde produit
Le HPC a été conçu pour s’insérer dans le Lean UX Canvas, un outil en neuf cases utilisé en développement produit. Mais le raisonnement qu’il porte dépasse largement ce cadre.
Un projet d’infrastructure suppose que la capacité actuelle ne suffira pas à la demande future. Un projet de transformation organisationnelle suppose que les collaborateurs adopteront les nouveaux processus. Un projet de déploiement d’outil suppose que l’outil résoudra le problème identifié. Chacune de ces suppositions est une hypothèse, et chacune peut être placée sur une matrice valeur-risque pour déterminer si elle justifie un effort de validation préalable.
Le PMBOK 7e édition du PMI reconnaît cette logique en intégrant la navigation dans l’incertitude parmi ses principes de pilotage. Le référentiel ICB4 de l’IPMA traite la gestion de l’incertitude comme une compétence transversale du chef de projet. La matrice valeur-risque traduit ces principes en une pratique concrète applicable dès la phase de cadrage.
Un outil de cadrage, pas de suivi
Le HPC n’est pas un outil de suivi permanent. Il intervient à un moment précis du projet: après l’identification des hypothèses et avant l’allocation des ressources d’exploration. Son objectif est de produire une décision claire sur les deux ou trois hypothèses qui méritent d’être testées en priorité, compte tenu du temps et du budget disponibles.
Une fois cette décision prise, l’outil a rempli son rôle. Les hypothèses prioritaires entrent dans un cycle de test, les autres sont soit construites directement, soit écartées. La matrice peut être revisitée si le contexte du projet évolue significativement, mais elle n’a pas vocation à être mise à jour en continu. Sa valeur réside dans la clarté qu’elle apporte au moment de la décision, pas dans un suivi au fil de l’eau.