MOAE - BeBlood

Le projet en quelques mots

Le client fictif, BeBlood, exploite un système de gestion des ressources humaines devenu ingérable : des outils différents selon les pays, des données éparpillées, aucune vision consolidée. Notre mission consistait à définir la cible, à en construire la trajectoire et à en chiffrer le programme sur trois ans - le tout à défendre devant un jury.

Mon rôle : chef de projet

J'ai piloté l'équipe de six sur toute la durée du projet : répartition des lots entre les membres, animation des points d'avancement, arbitrages de méthode, et cohérence d'ensemble entre les livrables. Sur le fond, j'ai porté deux volets en propre.

Pour le premier, je ne me suis pas limité au sujet : j'ai sollicité un entretien avec une personne exerçant réellement en ressources humaines, afin de comprendre de quoi son métier est fait. Concevoir un outil pour une profession qu'on ne connaît que par un énoncé mène à des contresens ; une heure de discussion apprend des contraintes qu'aucun document de cadrage ne mentionne.

Découper par valeur, jamais par produit

La première décision structurante a porté sur le découpage du programme. La tentation naturelle est d'organiser les chantiers autour des logiciels retenus - un chantier par outil. Nous avons tranché dans l'autre sens : découper selon les besoins métier auxquels le programme répond.

La raison est concrète. Un découpage par produit rend le programme dépendant des choix d'éditeurs, qui ne seront arrêtés qu'à l'appel d'offres ; un découpage par besoin reste valable quel que soit l'outil finalement retenu, et reste compréhensible par les directions métier qui doivent le valider.

Nous avons également fixé un vocabulaire strict, pour éviter que chacun n'emploie les mêmes mots avec des sens différents :

Chiffrer ce qui n'existe pas encore

Le cœur de l'exercice était là : produire un budget crédible pour un programme dont aucune ligne n'est écrite, dont les éditeurs ne sont pas choisis, et dont les devis n'existent pas. La difficulté n'est pas de calculer - c'est de savoir ce que vaut chaque chiffre qu'on avance.

J'ai donc construit le modèle en distinguant explicitement trois natures de données, et je l'ai écrit noir sur blanc dans une note de méthode :

Chaque résultat a ensuite été vérifié par deux chemins indépendants : une approche descendante, qui part de l'enveloppe globale et l'encadre par des ratios de marché, et une approche ascendante, qui décompose le chantier en tâches dimensionnées une à une. Quand les deux convergent, l'ordre de grandeur tient. Quand elles divergent, c'est qu'une hypothèse est fausse quelque part - et il faut aller la chercher.

Enfin, le budget n'est pas présenté comme un nombre unique. Il est exprimé en fourchettes assorties d'un niveau d'engagement, avec une réserve de risque au-delà : une manière de dire au commanditaire ce qu'il peut raisonnablement provisionner, plutôt que de lui promettre une précision que le stade du projet ne permet pas.

Assumer ce qu'on ne sait pas

La note de méthode que j'ai rédigée pour accompagner le chiffrage comporte une section « limites assumées ». Elle reconnaît qu'aucune base publique ne donne des charges à ce niveau de détail, que les chiffrages d'intégrateurs sont confidentiels, et que deux des trois solutions envisagées ne sont vendues que sur devis.

Ce n'était pas une précaution rhétorique. Écrire cette limite change la manière dont le budget est reçu : il devient une base de discussion et de négociation pour l'appel d'offres, pas un engagement que personne ne pourrait tenir. C'est aussi ce qui permet de défendre le chiffrage devant un jury - on ne peut pas être pris en défaut sur une prétention qu'on n'a pas formulée.

Synthèse du projet