La plupart des projets ne meurent pas d’un problème technique. Ils meurent parce qu’ils résolvent un problème que personne n’avait, ou qu’ils résolvent le bon problème de la mauvaise manière. Les rapports du Standish Group, publiés régulièrement depuis 1994, montrent que les fonctionnalités inutilisées représentent une part considérable des livrables projet.
Le Lean Canvas, développé par Ash Maurya à partir du mouvement Lean Startup d’Eric Ries, propose une réponse structurée à ce problème. Plutôt que de rédiger un cahier des charges exhaustif avant de commencer, il force l’équipe projet à expliciter ses hypothèses sur une seule page, puis à les tester méthodiquement.
Le projet comme ensemble d’hypothèses
Chaque projet repose sur des suppositions. Le sponsor suppose que les utilisateurs ont un problème spécifique. L’équipe suppose que la solution envisagée résoudra ce problème. Le chef de projet suppose que les délais et le budget permettront de livrer cette solution. Ces suppositions sont rarement formulées explicitement, ce qui les rend impossibles à tester.
Le Lean Canvas oblige à les mettre par écrit. Sa grille de neuf cases, dérivée du Business Model Canvas d’Osterwalder et Pigneur (Business Model Generation), couvre les dimensions essentielles: qui sont les utilisateurs cibles, quels problèmes rencontrent-ils, quelle valeur le projet leur apporte, comment la solution fonctionnera et comment mesurer si elle fonctionne réellement.
Chaque case contient une hypothèse. “Nos utilisateurs peinent à trouver l’information pertinente en moins de cinq minutes” est une hypothèse testable. “Il nous faut un portail de connaissances” est une conclusion déguisée en besoin. La distinction est fondamentale, et le Lean Canvas pousse systématiquement vers la première formulation.
Les hypothèses que les chefs de projet oublient de tester
L’hypothèse la plus dangereuse est celle du problème lui-même. Un chef de projet reçoit souvent un mandat qui présuppose l’existence d’un problème et prescrit déjà une direction de solution. Le Lean Canvas demande de revenir en arrière: le problème existe-t-il réellement? Est-il suffisamment douloureux pour que les utilisateurs changent leurs habitudes? Si la réponse est non, aucune qualité d’exécution ne sauvera le projet.
L’hypothèse de la proposition de valeur est la deuxième à examiner. Même si le problème est réel, la valeur promise par le projet doit être suffisamment forte pour justifier l’effort d’adoption. Un outil de reporting peut résoudre un vrai problème de visibilité, mais si les managers obtiennent déjà l’information par d’autres canaux, l’adoption sera faible.
Les métriques clés constituent la troisième zone aveugle. Beaucoup de projets mesurent leur succès par des indicateurs d’activité (nombre d’utilisateurs connectés, nombre de documents créés) plutôt que par des indicateurs de valeur (temps économisé, décisions améliorées, erreurs évitées). Le Lean Canvas incite à définir les métriques de succès avant le lancement, pas après.
De l’hypothèse au test: la boucle de validation
Remplir un Lean Canvas n’est que la moitié du travail. L’autre moitié consiste à prioriser les hypothèses par niveau de risque et à concevoir des tests pour les valider. Ash Maurya, dans Running Lean, propose une hiérarchie simple: tester d’abord l’hypothèse du problème, puis celle de la solution, puis celle du modèle économique.
En gestion de projet classique, cette approche correspond à un prototype ou une phase pilote, mais avec une différence de posture importante. Le prototype classique vise à démontrer la faisabilité technique. La validation Lean vise à démontrer la désirabilité: les utilisateurs veulent-ils réellement ce que le projet propose de construire?
Concrètement, un test d’hypothèse peut être aussi simple qu’une série d’entretiens avec dix utilisateurs potentiels, un questionnaire ciblé ou une maquette interactive présentée aux parties prenantes. L’investissement est minime comparé au coût d’un développement complet, et les enseignements sont souvent décisifs.
Quand la validation n’est pas nécessaire
Le Lean Canvas et la logique de validation qui l’accompagne ne s’appliquent pas à tous les projets. Un projet de mise en conformité réglementaire n’a pas besoin de valider la “désirabilité” de la conformité. Un projet de migration d’infrastructure n’a pas besoin de tester si les utilisateurs veulent un système qui fonctionne. Dans ces cas, le périmètre est dicté par des contraintes externes et la question n’est pas “faut-il le faire?” mais “comment le faire au mieux?”.
La validation des hypothèses est pertinente quand le projet comporte une incertitude significative sur le besoin ou l’usage. Les projets d’innovation, les nouveaux services internes, les transformations organisationnelles ou les produits destinés à un marché mal connu sont les candidats naturels.
Le Lean Canvas dans le cycle de vie du projet
Le Lean Canvas se positionne en amont du cycle de vie projet classique, dans ce que certains référentiels appellent la phase d’avant-projet ou de faisabilité. Il précède la charte de projet (le document formel qui autorise le projet et en définit les grandes lignes) et le business case (la justification économique). Il peut même servir de base pour rédiger ces documents, puisque les hypothèses validées deviennent des arguments solides pour le business case.
Pour un chef de projet qui reçoit un mandat vague du type “il faudrait digitaliser tel processus”, le Lean Canvas offre une méthode structurée pour transformer cette intuition en hypothèses vérifiables. Deux heures d’atelier avec les parties prenantes suffisent pour produire un premier canvas et une liste de points à valider, un investissement dérisoire comparé aux semaines de rédaction d’un cahier des charges qui pourrait s’avérer hors sujet.