
Un business case convaincant, puis plus rien
La majorité des organisations savent produire un business case qui obtient le feu vert. Les coûts sont détaillés, les bénéfices sont annoncés avec des pourcentages rassurants, et le projet démarre. Quelques mois ou années plus tard, la question se pose: les bénéfices promis se sont-ils matérialisés? Dans la plupart des cas, personne ne peut répondre avec certitude, parce que le business case n’a jamais précisé les conditions concrètes de leur réalisation.
Le Benefits Dependency Network, ou réseau de dépendances des bénéfices, est un outil conçu précisément pour combler cette lacune. Développé par John Ward et Elizabeth Daniel et formalisé avec Joe Peppard dans un article de MIS Quarterly Executive en 2007, il cartographie les liens de cause à effet entre la stratégie d’un projet et les actions concrètes qui permettront d’en tirer les bénéfices attendus.
Cinq composantes reliées en réseau
Le BDN organise cinq types d’éléments dans un réseau visuel où chaque composante est reliée aux autres par des flèches de dépendance.
À l’extrémité droite se trouvent les drivers (facteurs déclencheurs): les pressions ou opportunités qui rendent le projet nécessaire, qu’il s’agisse d’une nouvelle réglementation, d’un concurrent qui accélère ses délais ou d’un taux d’erreur devenu inacceptable. Les drivers répondent à la question “pourquoi agir maintenant?”.
Les objectifs d’investissement traduisent ces drivers en résultats stratégiques visés: réduire le temps de traitement de 40%, centraliser les données clients ou améliorer le taux de conformité réglementaire.
Les bénéfices attendus décomposent les objectifs en gains mesurables et attribuables. Là où l’objectif est stratégique, le bénéfice est opérationnel: moins d’heures de ressaisie, moins de réclamations clients, des décisions d’achat plus rapides.
Les changements organisationnels (business changes) sont les modifications de processus, de pratiques ou de rôles sans lesquelles les bénéfices ne se concrétiseront pas. C’est la partie du BDN que les équipes projet tendent à sous-estimer, voire à ignorer.
Enfin, les enablers (facilitateurs) sont les prérequis techniques ou structurels qui rendent les changements possibles: un logiciel, une base de données, une formation, une réorganisation d’équipe.
La chaîne causale qui manque aux projets
Ce qui distingue le BDN d’une simple liste de bénéfices, c’est la relation de dépendance explicite entre chaque élément. Un bénéfice comme “réduction des erreurs de saisie de 60%” ne flotte pas dans le vide: il dépend d’un changement organisationnel (les opérateurs utilisent le nouveau formulaire au lieu de l’ancien), qui lui-même dépend d’un enabler (le formulaire numérique est déployé et les opérateurs sont formés).
Cette chaîne causale met en lumière une réalité que beaucoup de projets découvrent trop tard: la technologie ou l’outil ne produit aucun bénéfice par lui-même. Un ERP (Enterprise Resource Planning, progiciel de gestion intégré) flambant neuf n’améliore rien si les équipes continuent à travailler comme avant son installation. Le BDN rend cette dépendance visible dès la phase de cadrage, avant que les budgets ne soient engagés.
En gestion de projet généraliste, ce principe dépasse largement le domaine informatique. Une refonte de processus d’approvisionnement, un programme de transformation Agile ou un projet de centralisation administrative suivent la même logique: les gains ne se matérialisent que si l’organisation change ses pratiques, et ces changements ne se produisent que si les conditions sont réunies.
Un outil à double sens
Le BDN se lit dans les deux directions, et chacune répond à un besoin différent.
De droite à gauche, des drivers vers les enablers, il sert à construire le business case. Cette lecture montre pourquoi chaque composante est nécessaire: tel enabler est requis parce que tel changement en dépend, qui lui-même conditionne tel bénéfice, qui répond à tel driver stratégique. Si un élément ne se rattache à aucun driver, sa présence dans le projet est discutable.
De gauche à droite, des enablers vers les objectifs, il sert à piloter la réalisation des bénéfices pendant et après le projet. À mesure que les enablers sont livrés, le chef de projet peut vérifier si les changements organisationnels associés sont effectivement en cours d’adoption, et donc si les bénéfices sont en voie de réalisation.
Cette double fonction correspond à ce que le PMI appelle le Benefits Realization Management (gestion de la réalisation des bénéfices), formalisé dans un cadre de référence publié en 2019. Le BDN de Ward et Daniel s’inscrit dans la première phase de ce cadre: l’identification et la cartographie des bénéfices.
Construire le réseau: par où commencer
La construction d’un BDN commence idéalement par les drivers, identifiés avec les parties prenantes lors du cadrage en se demandant pourquoi ce projet est nécessaire et quelles pressions ou opportunités le justifient. On formule ensuite les objectifs d’investissement qui répondent à ces drivers, puis les bénéfices attendus.
La partie la plus révélatrice arrive quand on descend vers les changements organisationnels et les enablers. C’est là que l’on découvre des dépendances invisibles: un bénéfice qui suppose un changement de processus que personne n’a prévu, un enabler qui nécessite un budget non planifié ou un changement organisationnel qui se heurte à une résistance prévisible.
Le format visuel est volontairement simple. Un tableau blanc, un outil de cartographie mentale ou même des post-its suffisent. Expert Program Management propose des illustrations de la structure du réseau qui montrent bien comment les cinq composantes s’articulent. Le concept de gestion de la réalisation des bénéfices est également documenté sur Wikipedia pour une vue d’ensemble du domaine.
BDN et ROI: complémentaires, pas interchangeables
Le ROI (Return on Investment, rapport entre le bénéfice net et le coût total d’un investissement) reste l’indicateur de référence pour évaluer la rentabilité d’un projet. Les deux outils sont complémentaires et répondent à des questions différentes: le ROI mesure le rendement attendu, le BDN montre les conditions nécessaires pour l’atteindre.
Un projet qui affiche un ROI attractif mais dont le BDN révèle des changements organisationnels irréalistes est un projet à risque, quel que soit son rendement théorique. À l’inverse, un projet au ROI modeste mais dont la chaîne causale est solide et les changements réalistes a de meilleures chances de tenir ses promesses.
Le BDN transforme ainsi la discussion autour du business case: au lieu de débattre uniquement des chiffres, les décideurs examinent le réalisme du chemin qui mène aux résultats. Cette transparence ne garantit pas le succès du projet, mais elle permet d’identifier les points de fragilité avant qu’ils ne se transforment en échecs constatés au bilan final.