Les projets échouent rarement par manque de compétences techniques. Ils échouent parce que l’équipe construit un livrable que personne n’avait vraiment demandé, ou que tout le monde avait compris différemment. Le Standish Group documente ce phénomène depuis trente ans dans ses rapports CHAOS: la première cause d’échec reste le manque de clarté sur les objectifs et les exigences.
La méthode Working Backwards, formalisée par Amazon au milieu des années 2000, attaque directement ce problème. Son principe: rédiger le communiqué de presse du projet terminé avant d’écrire la première ligne de spécification. Si vous ne pouvez pas décrire le résultat en termes simples pour un non-spécialiste, vous n’êtes pas prêt à lancer le projet.
Le problème que Working Backwards résout
Dans un cadrage classique, le projet démarre par un besoin exprimé (souvent vague), passe par une analyse de faisabilité (souvent technique) et aboutit à un cahier des charges (souvent long). Chaque étape ajoute de la précision technique mais s’éloigne un peu plus de la question fondamentale: à quoi ce projet sert-il pour celui qui en bénéficiera?
Werner Vogels, CTO d’Amazon, décrit le risque: une équipe techniquement brillante peut construire un système parfait qui ne résout pas le bon problème. Working Backwards empêche cette dérive en plaçant le point de vue du bénéficiaire final au centre du cadrage, avant toute considération technique.
Trois documents, une logique
La méthode produit trois livrables de cadrage, dans un ordre précis.
Le communiqué de presse (press release) est le premier. Rédigé en une page, il décrit le résultat du projet comme un fait accompli. Il nomme le problème résolu, le public concerné et le bénéfice concret obtenu. L’exercice élimine naturellement le jargon technique et les formulations ambiguës: un communiqué de presse qui nécessite un glossaire a échoué dans son objectif.
La FAQ (Foire Aux Questions) est le deuxième. Elle se divise en questions externes (celles que poserait un utilisateur du livrable) et questions internes (celles que poserait un membre du comité de pilotage). La FAQ externe teste la proposition de valeur: si les réponses sont vagues ou circulaires, le bénéfice annoncé dans le communiqué de presse n’est pas réel. La FAQ interne teste la faisabilité: si les réponses techniques sont évasives, le projet n’est pas prêt.
La description de l’expérience utilisateur est le troisième. Selon le type de projet, ce document prend la forme de maquettes, de scénarios d’utilisation ou de descriptions de processus cible. Son rôle est de rendre concret ce que le communiqué de presse annonçait en termes généraux.
Pourquoi l’ordre des documents compte
La séquence communiqué de presse, puis FAQ, puis expérience utilisateur n’est pas arbitraire. Chaque document contraint le suivant. Le communiqué de presse fixe le cap (quel résultat pour quel public). La FAQ vérifie que le cap est tenable (questions de faisabilité et de valeur). L’expérience utilisateur traduit le cap en parcours concret.
Inverser l’ordre, comme le font la plupart des projets, produit l’effet opposé. Quand on commence par les spécifications techniques, le cadrage devient un exercice de justification a posteriori: on écrit un business case pour légitimer des choix déjà faits plutôt que pour guider des choix à faire.
Ce que Working Backwards ne fait pas
La méthode ne remplace pas la planification. Elle ne produit ni planning, ni budget, ni analyse de risques formelle. Elle se situe en amont de ces activités, dans la zone souvent négligée entre “nous avons une idée” et “nous lançons le projet”. Les documents Working Backwards alimentent ensuite les outils classiques: la charte de projet reprend le communiqué de presse, le registre des risques s’alimente de la FAQ interne, les user stories découlent de la description d’expérience utilisateur.
C’est précisément cette modestie qui rend la méthode applicable en dehors d’Amazon. Elle n’impose ni outil ni processus. Elle impose une discipline: décrire le résultat avant de planifier les moyens, et le décrire du point de vue de celui qui en bénéficiera. Un chef de projet peut appliquer cette discipline en une journée de travail avec ses parties prenantes, sans formation préalable ni changement organisationnel. La méthode se combine d’ailleurs naturellement avec d’autres outils de cadrage comme l’Inception Deck, qui pose dix questions fondamentales sur le projet: les deux approches partagent la conviction qu’un projet bien cadré est un projet dont l’équipe peut décrire le résultat en langage clair.
Le seul prérequis est d’accepter que le cadrage puisse conclure “nous ne sommes pas prêts”. Un communiqué de presse impossible à écrire clairement est un signal d’alarme, pas un échec: il vaut mieux le découvrir au jour un qu’au jour cent.