Beaucoup de projets démarrent sur la base d’une intuition, d’une directive hiérarchique ou d’un simple consensus en réunion. Le business case, parfois appelé “analyse de rentabilité” en Europe francophone ou “cas d’affaires” au Québec, existe précisément pour éviter ce genre de départ à l’aveugle. C’est le document qui répond à une question simple: ce projet mérite-t-il qu’on y investisse des ressources?
Ce que le business case n’est pas
Il faut d’abord dissiper un malentendu fréquent. Le business case n’est pas une charte de projet (project charter), qui formalise l’autorisation de démarrer et nomme le chef de projet. Il ne remplace pas non plus une étude de faisabilité technique. Son rôle est plus fondamental: il démontre que les bénéfices attendus justifient les coûts et les risques engagés. La charte vient après, une fois la décision prise.
En pratique, beaucoup d’organisations confondent les deux documents ou les fusionnent dans un formulaire unique. Le résultat est un document hybride qui ne remplit correctement aucune des deux fonctions.
Trois questions avant tout investissement
Le Secrétariat du Conseil du Trésor du Canada structure l’évaluation d’un business case autour de trois questions: le projet est-il souhaitable (les bénéfices sont-ils réels et alignés avec la stratégie), est-il viable (peut-on le financer et les bénéfices dépassent-ils les coûts) et est-il réalisable (a-t-on la capacité de le mener à bien)? Ces trois filtres sont séquentiels: inutile d’analyser la faisabilité d’un projet qui n’est pas souhaitable.
Cette structure peut paraître évidente, mais elle révèle un biais courant. La plupart des porteurs de projet commencent par démontrer la faisabilité technique, parce que c’est le terrain qu’ils maîtrisent. La question de la pertinence stratégique arrive en dernier, souvent traitée comme une formalité. Inverser cet ordre change radicalement la qualité du document.
L’analyse coûts-bénéfices sans jargon financier
Le coeur du business case repose sur une analyse coûts-bénéfices qui compare les options envisagées. Trois indicateurs reviennent fréquemment.
La valeur actuelle nette (VAN) actualise les flux financiers futurs pour les comparer en francs d’aujourd’hui. Le retour sur investissement (ROI) exprime le gain net en pourcentage du coût total. Le ratio coûts-bénéfices (RCB) divise les bénéfices totaux par les coûts totaux, un ratio supérieur à 1 signalant un projet potentiellement rentable.
Aucun de ces indicateurs n’est complexe en soi, mais leur fiabilité dépend entièrement de la qualité des estimations qui les alimentent. Un business case construit sur des estimations optimistes produira un ROI flatteur qui ne résistera pas à la réalité. C’est pourquoi les référentiels recommandent systématiquement d’inclure une analyse de sensibilité: que se passe-t-il si les coûts augmentent de 20%? Si les bénéfices tardent de six mois?
Un point souvent négligé: le statu quo doit toujours figurer comme option. Ne rien faire a un coût (coût d’opportunité, dégradation progressive), et le quantifier renforce la légitimité du projet proposé. Si le statu quo est tenable, c’est peut-être que le projet n’est pas prioritaire.
Qui porte le business case?
La gouvernance du business case mérite qu’on s’y arrête, car elle est source de confusion. Dans PRINCE2, le business case appartient au sponsor (ou SRO, Senior Responsible Owner), pas au chef de projet. Cette distinction est fondamentale: le chef de projet gère l’exécution, mais c’est le sponsor qui garantit que le projet reste justifié tout au long de son cycle de vie.
En pratique, dans beaucoup d’organisations, le chef de projet rédige le business case parce que personne d’autre ne le fait. Ce glissement est problématique: il met la même personne en position de justifier le projet et de le livrer, ce qui crée un conflit d’intérêts implicite. Un chef de projet a naturellement intérêt à ce que son projet soit approuvé.
Des livrables aux bénéfices: une chaîne à tracer
Une erreur fréquente consiste à confondre ce que le projet produit avec la valeur qu’il génère. Le business case gagne en rigueur lorsqu’il distingue trois niveaux: les livrables (outputs), c’est-à-dire ce que le projet produit concrètement; les effets (outcomes), soit les changements opérationnels que ces livrables permettent dans l’organisation; et les bénéfices, la valeur mesurable qui en découle à terme. Un nouveau logiciel de planification (livrable) ne crée de la valeur que s’il modifie réellement les pratiques de suivi (effet) et réduit les dépassements de délais (bénéfice).
Cette distinction explique pourquoi le business case ne peut pas être un document ponctuel, rédigé pour obtenir le feu vert puis rangé dans un dossier. Les livrables se vérifient à la livraison, mais les bénéfices ne se matérialisent souvent que des mois après la clôture du projet.
Un document vivant, pas un formulaire d’approbation
PRINCE2 propose un cycle explicite pour maintenir le business case pertinent: le développer en phase initiale, le vérifier à chaque étape clé, le mettre à jour quand les circonstances changent et le confirmer à la clôture du projet pour évaluer si les bénéfices annoncés se concrétisent.
Cette dernière étape est la plus négligée. Très peu d’organisations reviennent sur un business case après la livraison pour vérifier si les bénéfices se sont matérialisés. Sans cette boucle de rétroaction, l’organisation ne peut pas améliorer la qualité de ses futures estimations et répète les mêmes erreurs de jugement d’un projet à l’autre.
Le business case comme outil de lucidité
Il existe un dernier écueil, peut-être le plus insidieux: le business case rédigé pour justifier une décision déjà prise. Quand la direction a décidé de lancer un projet et demande un business case “pour le dossier”, le document perd toute valeur. Les chiffres sont ajustés pour confirmer la conclusion souhaitée, les risques sont minimisés et les alternatives ne sont pas sérieusement examinées.
Un business case honnête doit pouvoir conclure que le projet ne devrait pas être lancé. C’est même sa fonction la plus précieuse: éviter de gaspiller des ressources sur des initiatives qui ne créent pas suffisamment de valeur. Les organisations qui prennent ce document au sérieux économisent bien plus en projets évités qu’en projets optimisés.