Dans la plupart des organisations, le business case est un document de lancement. Il justifie le projet, obtient le financement, puis disparaît dans un tiroir numérique. Cette pratique gaspille un outil de gouvernance dont la valeur ne se révèle pleinement qu’en cours de projet.
PRINCE2 place le business case au centre de sa logique de pilotage à travers un cycle en quatre temps: développer, vérifier, maintenir, confirmer. Cette approche repose sur un principe que d’autres référentiels reconnaissent sans toujours l’opérationnaliser: la justification économique d’un projet doit rester valide tout au long de son cycle de vie.
Développer: poser les fondations de la décision
Le business case initial naît d’un besoin d’affaires identifié et d’une analyse structurée des options disponibles. Le guide du Conseil du Trésor du Canada formalise cette phase en exigeant un minimum de trois options viables, incluant systématiquement le statu quo comme référence.
L’analyse coûts-bénéfices, avec des outils comme la valeur actuelle nette (VAN) ou le taux de rendement interne (IRR, pour Internal Rate of Return), permet de comparer ces options sur une base financière commune. Le business case documente aussi les risques majeurs, les hypothèses sous-jacentes et les bénéfices attendus, qu’ils soient financiers ou non.
La distinction que PRINCE2 établit entre outputs, outcomes et bénéfices mérite d’être retenue: un livrable (output) n’est pas un résultat d’usage (outcome), et un résultat d’usage n’est pas automatiquement un bénéfice pour l’organisation. Un nouveau système de gestion des temps est un livrable; la visibilité en temps réel sur la charge des équipes est un résultat; la réduction de 15% du sureffectif temporaire est un bénéfice. Le business case doit tracer cette chaîne complète.
Vérifier: des points de décision, pas des formalités
PRINCE2 impose une vérification du business case à chaque passage d’étape (stage gate). Le comité de pilotage examine si le projet reste désirable (les bénéfices justifient-ils encore l’investissement?), viable (le financement et les ressources sont-ils suffisants?) et atteignable (les risques et la complexité restent-ils gérables?).
Ces trois critères forment un filtre puissant quand ils sont appliqués avec rigueur. Un projet peut devenir non désirable si les priorités stratégiques évoluent, non viable si les coûts dérapent au-delà des marges de tolérance, ou non atteignable si des risques techniques se matérialisent. Dans chacun de ces cas, la décision rationnelle peut être d’arrêter le projet, et c’est précisément la valeur d’une vérification honnête du business case.
En pratique, peu d’organisations arrêtent un projet en cours de route. L’effet d’engagement (sunk cost fallacy) pousse à continuer un investissement défaillant pour “ne pas perdre ce qui a déjà été investi”. Le business case vérifié à intervalles réguliers est l’antidote à ce biais: il recentre la discussion sur la valeur future, pas sur les dépenses passées.
Maintenir: un document qui reflète la réalité
Maintenir le business case signifie le mettre à jour avec les coûts réels, les bénéfices réalisés, les risques émergents et les changements de contexte. Ce travail incombe au chef de projet, mais il ne peut se faire sans la contribution du sponsor (project executive dans PRINCE2) et des responsables métier (senior users) qui détiennent l’information sur les bénéfices.
Les moments clés de mise à jour coïncident avec les révisions de fin d’étape, mais aussi avec tout événement significatif: dérive budgétaire, changement de périmètre, nouvelle contrainte réglementaire, départ d’un acteur clé. Un business case qui reflète les données d’il y a six mois perd sa fonction d’aide à la décision.
L’enjeu pratique est de trouver le bon niveau de détail. Un business case trop granulaire devient un fardeau administratif que personne ne maintient, tandis qu’un document trop sommaire ne permet pas de prendre des décisions éclairées. L’équilibre se situe généralement au niveau des hypothèses critiques: quelles sont les cinq ou six variables dont le changement remettrait en cause la justification du projet?
Confirmer: mesurer ce qui a été promis
La phase de confirmation intervient après la livraison du projet, parfois plusieurs mois après, quand les bénéfices attendus devraient se matérialiser. C’est l’étape que presque personne ne réalise, pour une raison structurelle: l’équipe projet est dissoute, le chef de projet est affecté à un autre mandat, et la responsabilité de mesurer les bénéfices tombe entre les mailles de l’organisation.
Le PMI identifie ce problème comme l’un des facteurs qui minent la crédibilité des business cases: si personne ne vérifie jamais les bénéfices promis, les prochains business cases seront tout aussi optimistes et tout aussi peu fiables. La solution passe par la désignation explicite, dès le business case initial, d’un responsable de la réalisation des bénéfices qui reste en poste après la clôture du projet.
Quand le business case change de statut
Le business case n’est pas un document binaire (approuvé ou rejeté). Au fil du projet, il peut passer par plusieurs états: esquisse lors du cadrage initial, version détaillée après l’initialisation, version mise à jour à chaque fin d’étape, version confirmée après réalisation des bénéfices. Chaque transition correspond à un moment où les décideurs disposent d’informations plus fiables pour arbitrer la poursuite ou l’arrêt du projet.
Cette progression reflète une réalité souvent ignorée: la qualité d’un business case dépend directement de la maturité de l’information disponible. Exiger un business case détaillé et chiffré à un stade où l’incertitude reste élevée produit un document précis mais faux, ce qui est pire qu’un document honnêtement approximatif.