Structure de découpage du projet (WBS) : comment la construire et en faire un planning

Quand un plan oublie les redirections des anciennes pages de documentation, ou la formation à laquelle personne n’a pensé, les dates sont fausses avant même la première tâche. La structure de découpage du projet (WBS, pour work breakdown structure) est l’endroit où ce travail manquant se rattrape. Elle divise le projet selon ce qu’il doit livrer, avant que quiconque ne parle de dates.

Ce guide présente les deux tests qui garantissent une WBS complète, la profondeur à viser et la raison pour laquelle la plupart des petites équipes devraient écarter les phases du niveau 2. Il suit ensuite le lancement d’un centre d’aide, d’une WBS de 14 lots à un planning de 27 jours, liens entre livrables compris.

Ce qu’est une structure de découpage du projet#

Une structure de découpage du projet est une hiérarchie qui divise un projet en livrables à produire, puis chaque livrable en éléments de travail plus petits, que l’on peut estimer et affecter. Le guide WBS de la NASA la décrit comme « une arborescence orientée produit qui identifie le matériel, les logiciels, les services et tous les autres livrables nécessaires pour atteindre l’objectif final du projet »^[1].

Le niveau 1 est le projet et le niveau 2 regroupe les principaux livrables. Chaque niveau suivant découpe un élément en parties, jusqu’aux lots de travaux, chacun étant « l’unité de travail nécessaire pour accomplir une tâche précise »^[1]. Sur les grands programmes, coûts et délais sont pilotés un cran au-dessus, au compte de contrôle, qui peut contenir plusieurs lots de travaux^[1]. Avec trois à dix personnes, les deux se confondent, et c’est au lot de travaux que l’on nomme un responsable.

L’arborescence ne contient ni dates ni séquence. Celles-ci arrivent avec le planning, construit à partir des lots de travaux au bas de chaque branche.

Deux tests pour garder une WBS complète#

Le premier test découle d’une phrase du guide de la NASA : « Le périmètre de travail qui ne figure pas dans la WBS du projet ne doit pas être considéré comme faisant partie du projet »^[1]. Posé à chaque élément, il devient une question pratique. Si tous les enfants sont terminés, le parent l’est-il ? Une réponse qui commence par « oui, sauf » a trouvé un élément manquant. Le travail de soutien fait aussi partie du périmètre, et la liste de contrôle de développement de la NASA cite explicitement la gestion de projet^[1].

Le second test détecte les doublons. Coûts et délais doivent remonter depuis les éléments les plus bas « sans qu’aucun élément de périmètre ne soit affecté à deux éléments de WBS ou plus »^[1]. Dans les plans sur tableur, le signe habituel est une ligne collée sous deux intitulés, par exemple « Guide utilisateur » sous Réalisation et à nouveau sous Formation, avec deux estimations et deux pourcentages d’avancement.

Un dictionnaire de la WBS comble les lacunes que laissent les noms d’éléments trop courts, et la NASA en prépare un en partie pour « éliminer les doublons et les chevauchements dans l’affectation du travail »^[1]. Sur un petit projet, trois ou quatre lignes par lot de travaux suffisent. Une entrée type de l’exemple ci-dessous :

1.1.5 Articles publiés. Périmètre : 23 articles validés, chargés et reliés entre eux. Exclus : traductions et vidéo. Responsable : rédactrice technique. Terminé quand chaque article a une URL publique et apparaît dans la recherche du centre d’aide.

Cette dernière ligne compte plus tard, car elle relie la branche contenu à la branche plateforme.

Livrables, phases ou services au niveau 2#

Le niveau 2 peut s’organiser autour de ce que produit le projet (Contenu, Plateforme, Intégration, Lancement), autour du temps (Conception, Réalisation, Test, Mise en production) ou autour de ceux qui font le travail. Seul le premier montre ce qui existe à la fin du projet. Les phases répètent ce que le diagramme de Gantt montre déjà le long de ses barres, et les services perdent le travail qui tombe entre deux d’entre eux.

La NASA range Conception, Ingénierie et Phase A parmi les éléments qui « ne sont pas des produits et ne devraient en principe pas être utilisés » comme subdivisions de la WBS, la Phase A étant « une période de temps »^[1]. Ses contre-exemples fondés sur les phases et sur les fonctions portent la même légende : « Cette approche n’est pas recommandée »^[1]. La même section nomme l’attrait des arborescences calquées sur les services. Les gens demandent « Où suis-je dans cette WBS ? » et veulent des éléments qui reflètent leur propre domaine de responsabilité, une erreur que le guide invite à éviter^[1]. La responsabilité relève d’une matrice distincte qui croise la WBS avec l’organigramme^[1], et sur un projet de trois personnes cette matrice se réduit à une colonne Responsable.

Pourquoi les petites équipes mettent des phases au niveau 2, et quand elles ont raison#

Les petites équipes finissent souvent avec Conception, Réalisation, Test et Mise en production au niveau 2, surtout quand l’arborescence et le planning sont construits dans la même grille le même après-midi et que les lignes de synthèse deviennent des tiroirs temporels. Le coût apparaît des semaines plus tard. Les redirections des anciennes pages n’appartiennent ni à la Conception ni à la Réalisation : dans une arborescence par phases, personne ne les estime.

Notre recommandation : pour une équipe de trois à dix personnes, placez les livrables au niveau 2 et montrez les phases sous forme de jalons dans le planning. Le diagramme de Gantt montre déjà le temps, donc un niveau de phases le répète. Un niveau de livrables répond d’un coup d’œil à la question « le centre d’aide est-il complet ? » et permet de lire le point d’avancement hebdomadaire livrable par livrable.

L’exception est un contrat validé et payé phase par phase, par exemple une phase de cadrage au forfait suivie d’une réalisation financée séparément. La recette et la facturation exigent un total par phase, et la validation du client conditionne la phase suivante. Avec des phases au niveau 2, ce total est une ligne de synthèse plutôt qu’une somme manuelle.

Combien de niveaux, et comment les numéroter#

La NASA lie le nombre de niveaux à « la taille et la complexité de l’ensemble de l’effort, au degré d’incertitude technique, aux structures organisationnelles concernées et à l’appréciation du besoin par la direction »^[1], et toutes les branches ne s’arrêtent pas forcément à la même profondeur. En règle générale, trois niveaux conviennent à une équipe de trois à dix personnes sur deux ou trois mois, avec les lots de travaux directement sous les livrables. La limite est la réunion hebdomadaire d’avancement : à une ou deux minutes par lot, 15 à 20 lots remplissent une demi-heure. Passez à un quatrième niveau sur une branche quand un lot exigerait deux responsables, ou quand son estimation pessimiste dépasse le double de l’optimiste. La même décision un cran plus bas, dans le planning, est traitée dans quand découper une tâche en sous-tâches.

Les codes décimaux indiquent le niveau d’un élément et l’élément dont il dépend. Le code 1.2.3 se situe au niveau 3 sous 1.2. Une fois le plan partagé, les rapports d’avancement et les tickets citent ces codes : un nouvel élément se place donc à la fin de sa branche, comme 1.3.3 après 1.3.2, même s’il se lirait mieux au milieu.

Un exemple concret : lancer un centre d’aide#

Une entreprise de logiciels remplace un manuel PDF et un ensemble d’anciennes pages de documentation par un centre d’aide public. L’équipe se compose d’une rédactrice technique, d’un développeur front-end et du responsable du support, qui dirige aussi le projet. La première version est en anglais uniquement.

Le premier jet de la WBS comptait 10 lots de travaux. La relecture de chaque branche avec le premier test en a ajouté quatre. Personne n’avait validé les brouillons, les anciennes pages mises en favori cesseraient de fonctionner à la mise en ligne, le produit continuerait de pointer vers le PDF et le support continuerait de traiter les tickets à partir de l’ancien manuel.

La mise en ligne ne figure pas dans l’arborescence parce qu’elle n’a pas de périmètre propre : elle marque seulement le moment où le travail qui la précède est terminé. Elle entre dans le planning comme un jalon, au même titre que « Contenu validé ».

Chaque lot de travaux devient une tâche nommée avec un verbe, ce qui respecte la règle de la NASA selon laquelle le niveau le plus bas de chaque élément « devrait comporter au moins une tâche ou activité »^[1]. Les durées sont en jours ouvrés et chaque lien est de type fin-début (le guide sur les dépendances entre tâches et le décalage présente les trois autres types). Les deux jalons se situent à la fin de leurs branches, de sorte qu’un outil qui numérote chaque ligne conserve les codes de lots de la WBS.

La publication attend la recherche parce que le dictionnaire précise qu’un article n’est terminé que lorsque la recherche le renvoie. Sans ce lien, la recherche et l’analytique afficheraient 13 jours de marge et pourraient dépasser la publication sans que personne ne s’en aperçoive.

La gestion de projet (1.5.1) est une tâche à effort continu : elle court du jour 1 au jour 27 à raison de quelques heures par semaine et ne pilote rien, elle reste donc hors de la lecture du chemin critique. Les redirections utilisent les slugs convenus dans l’inventaire et n’attendent la recherche que parce que le même développeur réalise les deux. Les liens dans l’application attendent les URL publiées parce qu’ils sortent avec une version du produit, et qu’un lien cassé exige une nouvelle version.

Le projet dure 27 jours ouvrés. Le chemin critique passe par l’inventaire, la rédaction, les captures, la relecture, la publication, les liens dans l’application, le test de recette et l’annonce, soit 2 + 11 + 3 + 3 + 2 + 3 + 2 + 1 = 27 jours, et il traverse quatre des cinq branches. Un rapport d’avancement par livrable montrerait la Plateforme presque terminée au jour 9, avec trois lots sur quatre achevés, alors que le lot qui décide de la date, le test de recette, ne peut pas démarrer avant le jour 25. La mise en place, le thème et la recherche disposent de 10 jours de marge, les redirections de 13, la formation de 5.

La rédaction concentre le plus de risque : vingt-trois articles en 11 jours, c’est un peu plus de deux par jour pour une seule rédactrice, et chaque jour de retard décale la mise en ligne. Elle mérite une estimation à trois points (estimer la durée des tâches) ; le guide du chemin critique explique les passes de calcul qui donnent les valeurs de marge.

La vérification de la charge révèle un creux : le développeur n’a rien de planifié du jour 12 au jour 21. Convenez des slugs à la fin de l’inventaire, détachez les liens dans l’application de la publication (prédécesseurs 1.1.1 et 1.3.2) et exécutez-les aux jours 12–14. La publication se relie alors directement au test de recette, qui démarre au jour 22. La mise en ligne passe à la fin du jour 23 et l’annonce au jour 24. C’est du fast-tracking (comment rattraper un projet en retard), et il étend le pari sur les slugs de l’inventaire à des liens livrés dans le produit, où un slug renommé exige une nouvelle version pour être corrigé.

Erreurs fréquentes#

• Réutiliser telle quelle la WBS du projet précédent. La NASA met en garde contre le report de « toute erreur ou caractéristique indésirable de la WBS antérieure »^[1]. Partez-en si cela aide, puis repassez le premier test sur le périmètre de ce projet.
• Des éléments appelés « Réunions » ou « Reprises ». Aucun des deux n’est ce que le projet produit, et les reprises figurent sur la liste des termes non produits de la NASA^[1]. Le temps de réunion va sous la gestion de projet, les reprises à l’intérieur du lot qu’elles corrigent.
• La mise en ligne comme lot de travaux. Elle n’a aucun périmètre à estimer.

Quand une WBS complète n’en vaut pas la peine#

En dessous d’environ 15 tâches avec un seul responsable, en règle générale, une simple liste de tâches avec une ligne « terminé quand » sur chaque ligne remplace l’arborescence et le dictionnaire. Appliquez quand même le premier test à la liste.

Détailler chaque branche jusqu’aux lots de travaux dès le premier jour tourne mal pour un travail situé à plusieurs mois, car cela invente une précision que le trimestre suivant balaiera. L’alternative de la NASA est le lot de planification, qui « définit le travail lointain à un niveau synthétique »^[1] et se découpe en lots de travaux à mesure que le travail approche. Dans un planning, c’est une ligne avec une durée approximative et une note indiquant la date à laquelle elle doit être détaillée.

Comment faire dans Planitude#

Construisez l’arborescence dans le diagramme de Gantt, sans limite de niveaux. Tab fait d’une ligne une sous-tâche de celle du dessus, Maj+Tab la ressort. Planitude appelle les lignes de synthèse des phases ; nommez-les d’après les livrables et les lots de travaux deviennent leurs sous-tâches.

Pour partir d’un tableur, importez le fichier Excel ou CSV. Planitude reconstruit les lignes de synthèse à partir d’une colonne WBS, d’une colonne de niveau ou de l’indentation, lit les prédécesseurs écrits sous forme de codes WBS et affiche d’abord un aperçu. Un modèle ou un plan proposé par l’assistant IA sont les autres points de départ.

La colonne WBS est en lecture seule. Les nouvelles lignes reçoivent un code selon leur position, jalons compris. Les codes issus d’un fichier importé (.mpp compris), d’un modèle ou d’un projet dupliqué sont en revanche enregistrés et ne bougent pas quand les lignes se déplacent : ajoutez donc les nouvelles lignes à la fin de leur branche. Pour obtenir des codes du type 1.2.3, placez tout sous une ligne de synthèse unique portant le nom du projet. Il n’existe pas de dictionnaire de la WBS ; le périmètre et la ligne « terminé quand » vont dans les notes de la tâche.

Questions fréquentes#