Faire un WBS (Work Breakdown Structure, ou organigramme des tâches) est l’une des premières compétences que tout chef de projet doit acquérir. La démarche paraît intuitive: décomposer le travail du projet en morceaux de plus en plus petits jusqu’à obtenir des lots gérables. En pratique, cette simplicité apparente masque des pièges récurrents qui compromettent la qualité de la planification en aval. Cinq erreurs reviennent avec une régularité préoccupante chez les praticiens qui construisent leur première WBS.
Confondre activités et livrables
L’erreur la plus fondamentale consiste à remplir la WBS avec des verbes plutôt que des noms. “Rédiger le cahier des charges”, “tester l’application”, “former les utilisateurs” sont des activités, pas des livrables. Une WBS correcte contient des éléments comme “cahier des charges validé”, “rapport de tests” ou “support de formation”.
Cette distinction n’est pas un point de vocabulaire. La WBS orientée livrables répond à la question “que doit produire le projet?”, tandis qu’une liste d’activités répond à “que va faire l’équipe?”. La différence a des conséquences concrètes sur la mesure de l’avancement: un livrable est soit terminé soit non terminé, alors qu’une activité peut être “en cours” pendant des semaines sans qu’on sache si elle produit le résultat attendu. Le PMI insiste sur cette orientation dans ses principes fondamentaux de la WBS.
Décomposer trop fin ou pas assez
Le niveau de détail est une question de jugement, et le jugement s’acquiert avec l’expérience. Deux extrêmes sont courants: la WBS qui reste trop grossière, avec des lots de plusieurs centaines d’heures impossibles à suivre, et la WBS qui descend jusqu’au moindre geste, transformant un outil de pilotage en inventaire exhaustif de micro-tâches.
La règle des 8-80 heures offre un repère utile: un work package (lot de travail, niveau le plus bas de la WBS) devrait représenter entre une journée et deux semaines d’effort. En dessous de 8 heures, le coût administratif du suivi dépasse la valeur de l’information obtenue. Au-delà de 80 heures, l’estimation devient trop incertaine et le suivi de l’avancement perd en précision. Ce repère n’est pas une règle absolue, mais un indicateur fiable qui mérite d’être vérifié systématiquement quand on fait un WBS pour la première fois. Le Project Engineer propose une variante de cette règle avec un seuil de 40 à 100 heures-homme, qui reste dans le même ordre de grandeur.
Oublier la gestion de projet dans le périmètre
La WBS doit représenter 100% du travail nécessaire pour mener le projet à terme. Cette règle des 100%, que le PMI considère comme le principe le plus important de la construction d’une WBS, implique que le travail de gestion de projet lui-même figure dans la structure. Coordination, reporting, gestion des risques, réunions de pilotage: ces activités consomment du temps et des ressources, et les exclure de la WBS conduit à sous-estimer systématiquement l’effort total.
En pratique, un lot “gestion de projet” ou “management du projet” apparaît comme un livrable de premier niveau, au même titre que les livrables techniques. Ce lot contient les sous-livrables liés au pilotage: plan de projet, rapports d’avancement, registre des risques, procès-verbaux de comité. Les négliger revient à postuler que le projet se gère de lui-même, ce qui ne correspond jamais à la réalité d’un projet.
Négliger le dictionnaire de WBS
La WBS graphique ou indentée ne suffit pas à garantir une compréhension partagée. Deux personnes qui lisent “module de paiement” sur un diagramme peuvent avoir des interprétations très différentes du contenu, du niveau de finition attendu et des critères d’acceptation. Le dictionnaire de WBS résout ce problème en documentant chaque élément avec une description du contenu, les critères d’acceptation, le responsable et les hypothèses associées.
Ce document est souvent perçu comme une formalité bureaucratique, surtout sur les petits projets. C’est une erreur de perspective. Le dictionnaire n’a pas besoin d’être volumineux: quelques lignes par work package suffisent. Son véritable intérêt apparaît au moment où un désaccord surgit sur le contenu d’un lot de travail, quand un nouveau membre rejoint l’équipe en cours de route, ou quand il faut évaluer si un livrable est réellement terminé. Sans dictionnaire, ces situations se règlent par la négociation improvisée plutôt que par la référence à un document validé.
Construire la WBS seul
La dernière erreur est peut-être la plus répandue: le chef de projet qui construit la WBS seul à son bureau, puis la soumet à l’équipe sans marge de discussion. Cette approche produit une structure qui reflète la vision d’une seule personne et qui comporte inévitablement des angles morts dans les domaines que cette personne maîtrise le moins.
Faire un WBS en atelier collaboratif, avec les experts métier et les responsables de lots, permet de croiser les perspectives et d’identifier des livrables que le chef de projet n’aurait pas anticipés. L’APM (Association for Project Management) recommande de partir de la PBS (Product Breakdown Structure) pour garantir que chaque composant du produit est couvert par au moins un lot de travail. L’atelier a un second bénéfice, moins évident mais tout aussi important: les contributeurs qui participent à la construction de la structure s’approprient le périmètre qu’ils ont contribué à définir, ce qui réduit les contestations ultérieures et renforce l’engagement de l’équipe.
Au-delà de la construction initiale
Un dernier point mérite attention: la WBS n’est pas un document figé. La planification par vagues successives (rolling wave planning) permet de décomposer en détail les livrables proches dans le temps tout en conservant un grain plus grossier pour les phases lointaines. Cette approche reconnaît que l’information n’est pas toujours disponible au moment de la planification initiale et qu’il est préférable d’affiner progressivement plutôt que de forcer des estimations détaillées là où l’incertitude est trop forte. Faire un WBS est donc un processus itératif, pas un exercice ponctuel.