Tout projet repose sur des hypothèses. Le segment visé existe et a un besoin réel. La solution envisagée répond à ce besoin. Les ressources prévues suffisent. Le calendrier est réaliste. Ces suppositions, rarement formulées explicitement, constituent le socle sur lequel repose l’ensemble de la planification. Quand l’une d’elles s’avère fausse, c’est souvent tardivement et à un coût élevé.
Le problème des hypothèses implicites
La gestion de projet traditionnelle traite souvent les hypothèses de cadrage comme des certitudes. Le business case affirme que le marché existe. Le plan projet suppose que l’équipe est disponible. L’analyse de faisabilité présume que la technologie retenue fonctionnera comme prévu. Ces affirmations sont rarement accompagnées d’un niveau de confiance ni d’un plan de validation.
Le Lean Canvas, outil de cadrage en neuf cases développé par Ash Maurya dans Running Lean (2012) à partir du Business Model Canvas d’Alexander Osterwalder, a le mérite de rendre certaines hypothèses explicites: qui sont les clients? quel problème résout-on? quelle est la proposition de valeur? Mais rendre les hypothèses visibles ne suffit pas: il faut les tester.
Le coût d’une hypothèse fausse
Le coût de validation d’une hypothèse en phase de cadrage est négligeable par rapport au coût de sa découverte en phase d’exécution. Quelques entretiens avec des utilisateurs potentiels, un prototype rapide testé auprès d’un groupe pilote, une enquête ciblée: ces investissements modestes permettent de détecter les hypothèses fausses avant d’engager des budgets significatifs.
L’exemple est classique mais instructif: une organisation déploie un outil de gestion des processus sur l’hypothèse que les équipes l’adopteront parce que la direction l’a décidé. Après six mois de développement et de paramétrage, le taux d’adoption est inférieur à 20% parce que les utilisateurs ne voient pas de bénéfice concret dans leur travail quotidien. Deux semaines d’entretiens exploratoires en amont auraient suffi à identifier ce risque et à ajuster l’approche.
Distinguer ce qui est connu de ce qui est supposé
La première étape d’une validation efficace consiste à cartographier les hypothèses du projet et à les classer en trois catégories: validé (confirmé par des données ou des observations), supposé (plausible mais non vérifié) et inconnu (pas d’information disponible).
Cette classification, applicable à n’importe quel document de cadrage (business case, charte de projet, Lean Canvas), révèle généralement que la majorité des affirmations sur lesquelles repose le projet sont des suppositions. Ce constat n’est pas un problème en soi: tout projet comporte de l’incertitude. Le problème survient quand ces suppositions sont traitées comme des certitudes dans la planification.
Quelles hypothèses tester en priorité?
Toutes les hypothèses ne méritent pas le même investissement de validation. La priorité va aux hypothèses qui combinent une incertitude élevée (on ne sait pas si c’est vrai) et un impact fort (si c’est faux, le projet est remis en cause).
L’hypothèse “nos utilisateurs ont ce problème” est typiquement à haute incertitude et à fort impact: si le problème n’existe pas ou n’est pas prioritaire, l’ensemble du projet perd sa justification. L’hypothèse “nous pouvons livrer en six mois” est à impact élevé mais à incertitude variable selon l’expérience de l’équipe sur des projets similaires.
Le Lean Canvas, utilisé correctement, aide à identifier ces hypothèses critiques: la case “problèmes” et la case “segments clients” contiennent les hypothèses les plus fondamentales. Si ces deux cases ne sont pas validées par des observations terrain, le reste du canvas reste spéculatif.
Trois méthodes de validation rapide
Plusieurs approches permettent de tester les hypothèses projet sans engager de ressources disproportionnées.
Les entretiens exploratoires (5 à 10 conversations structurées avec des utilisateurs ou parties prenantes potentiels) suffisent souvent à valider ou invalider une hypothèse sur le besoin. La clé est de poser des questions ouvertes sur les pratiques et les difficultés actuelles plutôt que de présenter la solution envisagée et de demander un avis.
Le prototype rapide (maquette, simulation, version simplifiée) permet de tester une hypothèse de solution sans investir dans un développement complet. L’objectif n’est pas de produire un livrable final mais de collecter du feedback sur un aspect précis.
Le test pilote à périmètre réduit (une équipe, un site, un processus) permet de valider les hypothèses d’adoption et de fonctionnement en conditions réelles, avec un investissement limité et une capacité de correction rapide.
Intégrer la validation dans le cycle projet
La validation des hypothèses n’est pas une phase distincte qui précède le projet, c’est une discipline intégrée à chaque étape. En phase de cadrage, les hypothèses fondamentales (besoin, segment, faisabilité) sont identifiées et testées. En phase de planification, les hypothèses de ressources, de délais et de dépendances sont vérifiées. En phase d’exécution, les hypothèses d’adoption sont confrontées au terrain à chaque livraison intermédiaire.
Le Business Model Canvas d’Alexander Osterwalder et le Lean Canvas d’Ash Maurya sont des outils utiles pour structurer cette démarche, à condition de ne pas les traiter comme des formulaires à remplir une fois pour toutes mais comme des supports vivants qui évoluent au fur et à mesure que les hypothèses sont testées.