Dans presque tous les business cases que j'ai vus passer en vingt-cinq ans, on chiffre soigneusement deux choses : ce que le projet va coûter, et ce qu'il va rapporter. Et entre les deux, on laisse un trou.

Ce trou, c'est la relation entre la dépense et le bénéfice. On l'affirme — « ce projet rapportera X » — mais on l'objective rarement. Les coûts sont détaillés ligne à ligne, les bénéfices sont quantifiés, et le lien de causalité entre les deux reste un acte de foi. C'est là que tant de programmes déraillent : non pas parce qu'ils sont mal exécutés, mais parce que personne n'a vérifié que les livrables produisaient réellement le bénéfice attendu.

L'approche classique saute une étape

Le raisonnement implicite de la plupart des business cases relie directement les livrables aux bénéfices : on construit la solution, donc le gain arrive. Or ce raccourci ignore le seul mécanisme qui produit vraiment la valeur : le changement d'usage.

On ne livre pas pour livrer. On livre pour changer un usage — une façon de travailler, une décision, un processus. Et c'est ce changement d'usage, lui seul, qui produit le bénéfice pour l'entreprise.

La chaîne complète n'est donc pas « livrables → bénéfices ». Elle est :

Livrables  →  Objectifs d'usage  →  Bénéfices

Trois maillons, trois questions, et surtout trois niveaux de mesure : est-ce qu'on a bien livré ? est-ce que les gens s'en servent vraiment ? est-ce que l'entreprise y gagne ? La plupart des projets ne mesurent que le premier. Certains mesurent le troisième — longtemps après la fin, quand plus personne ne peut agir. Presque aucun ne mesure celui du milieu, alors que c'est le seul qui explique les deux autres.

Ce que ça change pour la gouvernance

Rendre le maillon d'usage explicite transforme la gouvernance d'un exercice de reporting en un système de décision. Chaque objectif d'usage porte un ou deux indicateurs, définis et confirmés par les acteurs concernés — pas imposés par le programme. Le comité d'investissement peut alors arbitrer sur des faits : si l'usage ne décolle pas, on le voit pendant le programme, pas dans un bilan post-mortem ; si une priorisation budgétaire doit être rendue, son impact sur la chaîne de valeur est lisible.

Et l'effet le plus important est humain : définir ensemble les objectifs d'usage force le métier, l'IT et la finance à écrire la même définition du succès avant de démarrer. Tant que cette définition commune n'existe pas, il n'y a pas d'accord — il y a des malentendus qui n'ont pas encore éclaté.

Trois étapes pour l'installer

La démarche n'exige aucun outillage sophistiqué. En préparation : définir les chaînes de valeur et identifier qualitativement enjeux, bénéfices et macro-livrables. En définition : identifier les objectifs d'usage et leurs indicateurs — idéalement un à deux par bénéfice — puis faire confirmer les métriques et leur mode de calcul par les acteurs concernés. En exécution : intégrer le pilotage régulier de ces indicateurs dans les comités, et réajuster priorités et indicateurs quand le réel l'exige.

C'est un travail modeste, presque banal. C'est aussi, d'expérience, ce qui décide seul si un programme crée de la valeur ou consomme un budget.

Cette approche est au cœur des missions de gouvernance par la valeur que je dirige. Si votre organisation chiffre bien ses coûts et ses bénéfices mais peine à relier les deux, parlons-en — ou retrouvez-moi sur LinkedIn.