Une chaîne, plusieurs responsables
La gestion de projet est souvent résumée par une formule trompeuse: livrer le bon produit, au bon moment, au bon prix. Cette formule laisse entendre que le chef de projet est responsable du produit. Or les référentiels racontent une autre histoire.
La septième édition du PMBOK formalise un système de livraison de valeur structuré en maillons: des personnes réalisent un travail, ce travail produit un livrable, le livrable génère des résultats, les résultats créent des bénéfices, et les bénéfices se traduisent en valeur. Chaque maillon a ses propres responsables. Le chef de projet opère sur un segment précis de cette chaîne, celui qui va du travail au livrable.
Comprendre où commence et où s’arrête cette responsabilité change la façon dont on pilote un projet, dont on rend des comptes et dont on évalue la performance.
Du travail au livrable, pas au-delà
Le PMBOK distingue deux périmètres qui portent le même mot mais désignent des réalités différentes. Le périmètre produit (product scope) décrit ce que le livrable final doit être: ses caractéristiques, ses fonctions, ses critères d’acceptation. Le périmètre projet (project scope) décrit le travail nécessaire pour créer ce livrable: les lots, les activités, les ressources mobilisées.
Le chef de projet gère le second. Il planifie le travail, affecte les ressources, suit l’avancement et gère les risques liés à l’exécution. La définition du produit relève d’autres rôles: le product owner en contexte agile, le maître d’ouvrage en contexte traditionnel, l’équipe technique pour les choix de conception.
Prenons un exemple concret. Pour l’organisation d’un événement d’entreprise, le périmètre produit décrit ce que l’événement doit être: nombre de participants, thématique, format, expérience attendue pour les visiteurs. Le périmètre projet décrit le travail pour y parvenir: réserver la salle, coordonner les intervenants, gérer la logistique et suivre le budget. Le chef de projet qui passe son temps à retravailler le programme des conférences au lieu de s’assurer que la salle est réservée et les prestataires confirmés confond les deux périmètres.
Les domaines de connaissance comme preuve structurelle
La norme ISO 21500 et le PMBOK organisent la discipline autour des mêmes axes: périmètre, temps, coûts, risques, qualité, ressources, approvisionnements, communications et parties prenantes. Aucun de ces domaines ne porte sur la conception du produit, car ils portent tous sur l’organisation du travail.
Cette architecture n’est pas un hasard. Elle reflète le constat fondamental que la gestion de projet est transférable d’un secteur à un autre précisément parce qu’elle porte sur le travail et non sur le produit. Un chef de projet pharmaceutique et un chef de projet de construction gèrent les mêmes dimensions (planification, risques, parties prenantes, budget) appliquées à des livrables radicalement différents. Ce qui les rend interchangeables, c’est que leur compétence n’est pas liée au produit mais à la capacité d’organiser le travail autour de ce produit.
L’effort de gestion de projet représente typiquement 10 à 15% de l’effort total du projet. Ce ratio illustre la séparation des rôles: le chef de projet organise le travail des autres, il ne l’exécute pas. Sur un projet mobilisant dix personnes, une seule se consacre à plein temps à la coordination, tandis que les neuf autres portent la connaissance du produit et en assurent la réalisation technique.
La question des bénéfices
C’est ici que la chaîne de valeur du PMBOK révèle sa tension la plus intéressante. Dans la pratique, les organisations attendent souvent du chef de projet qu’il soit responsable des bénéfices du projet: le retour sur investissement, la satisfaction des utilisateurs, l’amélioration des processus. Or les référentiels placent cette responsabilité ailleurs, chez le commanditaire, le program manager ou le business owner.
L’exemple du pont éclaire cette distinction. Le chef de projet livre un pont conforme aux spécifications, dans les délais et le budget. Mais la valeur attendue (réduire le temps de trajet entre deux villes) dépend aussi des routes d’accès, qui relèvent d’un autre projet ou d’un programme distinct. Si les routes ne sont pas construites, le pont ne génère aucun bénéfice mesurable, sans que le chef de projet ait failli à sa mission.
Cette délimitation crée un inconfort légitime. Un chef de projet qui se désintéresse totalement des bénéfices risque de livrer un produit techniquement conforme mais inutile. La réponse des référentiels modernes est nuancée: le chef de projet doit comprendre la chaîne de valeur dans son ensemble et s’assurer que les hypothèses de bénéfices restent valides tout au long du projet, mais la responsabilité de réaliser ces bénéfices appartient à d’autres rôles. Son travail consiste à signaler quand les conditions de succès ne sont plus réunies, pas à les créer lui-même.
Ce que cela change au quotidien
Tracer cette frontière a des implications concrètes sur la posture du chef de projet. En réunion de pilotage, il rend compte de l’avancement du travail (respect du plan, consommation des ressources, état des risques) et non de la pertinence des choix de conception. Quand un problème technique survient, il s’assure que l’équipe dispose des moyens et du temps nécessaires pour le résoudre plutôt que de le résoudre lui-même. Cette distinction entre faciliter et exécuter constitue le fondement de la légitimité du chef de projet dans une organisation mature.
Cette posture est contre-intuitive pour les experts techniques devenus chefs de projet, qui tirent leur légitimité de leur connaissance du produit. La transition exige d’accepter que la valeur ajoutée du chef de projet réside dans sa capacité à organiser le travail des autres, pas à faire le travail à leur place. Le WBS (Work Breakdown Structure, la décomposition structurée du travail) devient son outil central: il décompose le travail en lots gérables, affecte les responsabilités et suit l’avancement lot par lot.
En contexte agile, la frontière est encore plus explicite. Le product owner définit le quoi (le backlog, les priorités, les critères d’acceptation), le scrum master facilite le comment du travail d’équipe, et le chef de projet, quand le rôle existe séparément, gère les contraintes organisationnelles: budget, dépendances inter-équipes et reporting vers la gouvernance. Chacun opère sur son segment de la chaîne de valeur, sans empiéter sur les responsabilités des autres, ce qui garantit à la fois la clarté des rôles et l’efficacité de l’ensemble.