Du clavier au tableau blanc: la transition qui change tout
Un développeur senior promu chef de projet continue souvent à coder, tout comme un ingénieur devenu coordinateur vérifie encore les calculs de ses collègues ou un analyste passé à la gestion de projet refait les rapports qu’il juge insuffisants. Ce schéma se reproduit dans tous les secteurs, et il constitue l’un des obstacles les plus persistants à l’efficacité des projets.
Le problème ne réside pas dans la compétence technique, mais dans son utilisation. Le passage d’un rôle d’expert à un rôle de chef de projet suppose un changement d’identité professionnelle que la plupart des organisations accompagnent mal. On promeut les meilleurs techniciens sans leur donner les clés d’un métier fondamentalement différent.
Responsabilité et redevabilité: une distinction structurante
La gestion de projet repose sur une distinction que la langue française rend mal: celle entre responsabilité (exécuter une tâche, produire un résultat) et accountability, traduite par “redevabilité” dans les référentiels HERMES et PRINCE2, ou “imputabilité” en contexte suisse-romand et québécois. Être accountable signifie répondre d’un résultat devant le sponsor, la direction ou le client, y compris lorsque ce résultat a été produit par d’autres.
La matrice RACI (Responsible, Accountable, Consulted, Informed) formalise cette séparation. Le R désigne le réalisateur, le A l’approbateur. En théorie, le chef de projet est A pour les livrables principaux et R pour ses propres tâches de coordination. En pratique, beaucoup de chefs de projet issus de l’expertise technique se retrouvent A et R sur la majorité des lignes, ce qui trahit un problème de délégation.
Le goulet d’étranglement auto-infligé
Quand la pression monte (retard sur un livrable, qualité en deçà des attentes, absence d’un membre clé), le réflexe de l’ancien expert est prévisible: reprendre la tâche à son compte. “Je vais le faire, ce sera plus rapide.” Cette phrase, prononcée une fois, est un geste pragmatique. Répétée systématiquement, elle transforme le chef de projet en point de passage obligé de toutes les décisions et productions critiques.
Ces conséquences sont bien documentées: l’équipe perd progressivement en autonomie puisqu’elle sait que le chef de projet interviendra de toute façon. Le chef de projet, surchargé, ne remplit plus ses fonctions de coordination: les risques ne sont plus suivis, la communication avec les parties prenantes (stakeholders) se dégrade, les arbitrages sont reportés. Le projet ne ralentit pas parce que l’équipe est incompétente, mais parce que son coordinateur a cessé de coordonner.
Quatre territoires qui n’appartiennent pas au chef de projet
La confusion entre redevabilité et responsabilité directe se manifeste dans quatre domaines récurrents.
La production des livrables. Le chef de projet s’assure que les livrables sont produits conformément aux exigences, dans les délais et le budget convenus, mais il ne les produit pas lui-même. Quand il le fait, il occupe deux rôles incompatibles: celui du contrôleur et celui du contrôlé, ce qui crée une situation intenable puisque personne ne vérifie efficacement son propre travail.
L’engagement de l’équipe. Les données Gallup montrent que 77% des salariés dans le monde ne sont pas activement engagés dans leur travail. Le chef de projet peut agir sur les conditions: clarté des objectifs, utilité perçue des réunions, reconnaissance, suppression des obstacles. Il ne peut pas fabriquer une motivation qui relève de facteurs largement personnels. Simon Sinek résume bien la posture: “Leaders are not responsible for the results. Leaders are responsible for the people who are responsible for the results.” Le chef de projet répond des conditions, pas de l’état d’esprit individuel.
Le bien-être des collaborateurs. La frontière est nette: le chef de projet élimine les irritants professionnels dans son périmètre (processus inutiles, conflits non traités, priorités contradictoires). Le bien-être global d’une personne dépend de facteurs que le projet ne contrôle pas. Confondre ces deux périmètres crée une charge émotionnelle insoutenable et détourne le chef de projet de ses responsabilités réelles.
L’expertise technique complète. Un projet mobilise par nature des compétences que le chef de projet ne possède pas toutes. Son rôle consiste à identifier les expertises nécessaires, à recruter ou mobiliser les bonnes personnes et à poser les questions qui permettent de valider les choix techniques. Tenter de tout maîtriser personnellement revient à substituer un contrôle illusoire à une délégation structurée.
Ce que signifie réellement coordonner
Si le chef de projet ne produit pas les livrables, ne garantit pas l’engagement, ne porte pas le bien-être et ne détient pas toute l’expertise, que fait-il exactement? La réponse tient dans le verbe “coordonner”, souvent sous-estimé parce qu’il ne produit rien de tangible.
Coordonner, c’est d’abord définir des objectifs suffisamment clairs pour que l’équipe puisse travailler sans validation permanente. C’est ensuite structurer la délégation: décider qui fait quoi, avec quel niveau d’autonomie et quel mécanisme de contrôle. C’est enfin lever les obstacles avant qu’ils ne bloquent le travail, qu’il s’agisse de décisions en attente, de ressources manquantes ou de conflits entre priorités concurrentes.
Cette fonction de coordination est d’autant plus exigeante qu’elle reste largement invisible. Contrairement à un livrable technique, le cadre mis en place par le chef de projet ne se voit que lorsqu’il manque: réunions qui s’éternisent faute d’ordre du jour, décisions repoussées faute d’arbitrage, équipiers qui travaillent en doublons faute de répartition claire.
La GPM (Deutsche Gesellschaft für Projektmanagement), dans ses travaux sur le leadership orienté valeurs, insiste sur le fait que l’efficacité du chef de projet ne se mesure pas à sa capacité d’intervention directe, mais à la qualité du cadre qu’il met en place pour que les autres produisent.
Accepter le changement d’identité
Le passage de l’expertise à la coordination n’est pas une promotion classique, c’est un changement de métier. L’ancien expert doit accepter que sa valeur ajoutée ne réside plus dans sa capacité à produire un livrable de qualité, mais dans sa capacité à obtenir ce livrable d’une équipe qu’il encadre sans micromanager.
Cette transition suppose de renoncer à une source de satisfaction professionnelle directe, le travail bien fait de ses propres mains, au profit d’une satisfaction indirecte: le travail bien fait par d’autres, dans un cadre qu’on a soi-même construit. Pour beaucoup de professionnels, ce renoncement est le véritable obstacle, bien plus que n’importe quel outil ou méthode de gestion de projet.