Quand la complexité remplace la compréhension
Un chef de projet qui ne sait pas exactement ce que le client veut a deux options: poser la question ou construire suffisamment large pour couvrir toutes les hypothèses. La deuxième option est plus confortable parce qu’elle évite la conversation difficile, mais elle génère du travail inutile, des délais supplémentaires et des livrables que personne n’a demandés.
Ce réflexe porte un nom en ingénierie: la surconception (over-engineering). Dans le contexte de la gestion de projet, il se manifeste à trois niveaux distincts: des processus trop lourds pour la taille du projet, des livrables plus sophistiqués que nécessaire et une communication noyée dans la documentation au détriment des échanges directs. Le principe KISS (Keep It Simple, Stupid), issu de l’ingénierie militaire américaine des années 1960, prescrit de faire de la simplicité un objectif central de conception, et non un compromis à regret.
Des processus calibrés au contexte
La première forme de surconception concerne les processus de gestion eux-mêmes. Un projet de six mois avec une équipe de cinq personnes n’a pas besoin du même dispositif de gouvernance qu’un programme pluriannuel. Pourtant, la tentation de “faire les choses bien” conduit souvent à reproduire des cadres méthodologiques conçus pour des projets d’une tout autre envergure: comités de pilotage mensuels pour un projet sans sponsor actif, registres de risques à quarante colonnes quand dix risques suffiraient, matrices RACI (Responsible, Accountable, Consulted, Informed) exhaustives pour une équipe qui tient dans une seule pièce.
Le PMBOK 7e édition a d’ailleurs amorcé une évolution significative en abandonnant son approche historique par processus au profit de principes et de domaines de performance. Ce virage reflète une prise de conscience: ce n’est pas le nombre de processus appliqués qui détermine la réussite d’un projet, mais leur pertinence par rapport au contexte.
L’approche pragmatique consiste à se poser une question simple à chaque processus envisagé: “si nous ne faisons pas ceci, que risquons-nous concrètement?” Si la réponse est vague ou hypothétique, le processus peut probablement être allégé ou supprimé.
Des livrables qui servent l’utilisateur
La deuxième forme de surconception touche les livrables eux-mêmes. Le phénomène, que le PMI qualifie de “gold plating” (dorure à l’or), désigne l’ajout de fonctionnalités ou de qualité au-delà de ce que les parties prenantes ont demandé. Contrairement à la dérive de périmètre (scope creep) qui provient de demandes externes, le gold plating est initié par l’équipe, convaincue de “faire plaisir”.
Selon les données du Standish Group, environ 80% des fonctionnalités d’un produit sont rarement ou jamais utilisées. Chacune a pourtant été conçue, développée, testée et maintenue. Ricardo Vargas, expert reconnu en management de projet, propose d’appliquer le rasoir d’Occam à chaque décision de conception: face à plusieurs solutions équivalentes, choisir systématiquement la plus simple. Guillaume d’Ockham formulait ce principe au XIVe siècle par une maxime qui n’a rien perdu de sa pertinence: “il est vain de faire avec plus ce qu’on peut faire avec moins.”
Le garde-fou le plus efficace contre le gold plating reste la définition explicite de critères d’acceptation pour chaque livrable. Ces critères, validés avec le sponsor, répondent à la question “comment saurons-nous que c’est suffisant?” et tracent une frontière nette entre le nécessaire et le superflu.
Communiquer plutôt que documenter
La troisième forme de surconception, souvent la moins visible, concerne la communication projet. La tentation est forte de substituer des documents écrits aux conversations directes: rapports d’avancement exhaustifs plutôt que points réguliers de quinze minutes, présentations formelles plutôt qu’échanges en face à face, chaînes d’e-mails plutôt que discussions ciblées.
Amy Leschke-Kahle, dans un article publié par l’ATD (Association for Talent Development), rapporte des résultats sans ambiguïté: de simples check-ins hebdomadaires entre un manager et ses collaborateurs améliorent l’engagement de 54 à 60% selon les secteurs étudiés (retail, tech, santé). Le mécanisme est transposable à la gestion de projet: une conversation régulière avec les parties prenantes clés remplace avantageusement un rapport de vingt pages que personne ne lit en entier.
Le premier principe du Manifeste Agile formalise cette intuition: “les individus et leurs interactions plutôt que les processus et les outils.” Il ne s’agit pas de supprimer toute documentation, qui reste indispensable pour la traçabilité et le transfert de connaissances, mais de reconnaître qu’un document ne remplace jamais la compréhension mutuelle que produit un échange direct.
Pourquoi simplifier est plus difficile qu’il n’y paraît
Si le principe KISS semble relever du bon sens, sa mise en œuvre se heurte à des résistances bien réelles. L’aversion aux pertes pousse les chefs de projet à conserver des processus et des fonctionnalités “au cas où”, même quand aucun risque concret ne les justifie. L’attrait de la nouveauté incite à intégrer des outils ou des méthodes récents non parce qu’ils résolvent un problème identifié, mais parce qu’ils sont disponibles. Et le biais de confirmation conduit, une fois engagé dans une solution complexe, à chercher des preuves qu’elle était nécessaire plutôt qu’à questionner son utilité réelle.
La simplicité en gestion de projet résulte d’une compréhension fine des besoins réels, pas d’un choix par défaut. Elle suppose d’avoir identifié ce qui est essentiel avant de décider ce qui ne l’est pas. Le dixième principe du Manifeste Agile le formule avec précision: “La simplicité, c’est-à-dire l’art de maximiser la quantité de travail qu’on ne fait pas, est essentielle.” Maximiser ce qu’on ne fait pas exige une compréhension claire de ce qui mérite d’être fait, et cette compréhension ne vient que de la connexion avec les personnes que le projet est censé servir.