AccueilBlogLe WBS : découper le travail pour savoir ce qu'on peut suivre
FondamentauxDébutant
Publié le 1 septembre 2026 · Par Vincent KENNEL

Le WBS : découper le travail pour savoir ce qu'on peut suivre

Deux projets identiques, deux découpages différents, et pas les mêmes choses à suivre. Ce que les normes disent vraiment de l'orientation du découpage, d'où vient l'organigramme des tâches, et sur quel critère il se décide.

Sur un plan de travail couvert de plans et d'instruments de mesure, quatre casiers alignés rassemblent chacun les pièces d'une même partie du projet : dessins, listes de composants, notes de prix, échantillons de matière. Chaque casier porte un numéro, 01 à 04, un jeton de responsable, une pile de jetons de coût et un anneau d'avancement. Un trait bleu relie chaque casier à sa ligne dans un tableau de report qui reprend les mêmes numéros, avec les coûts 380, 540, 270 et 460 et les avancements 62 %, 48 %, 71 % et 55 %.
En bref

Un organigramme des tâches, ou WBS, décompose le travail d'un projet en éléments de plus en plus fins, jusqu'au lot de travaux : le niveau où le travail est affecté à un responsable unique et contre lequel remontent les coûts et l'avancement. Le découpage retenu détermine ce que le projet saura suivre.

Sur beaucoup de projets, l'organigramme des tâches n'est pas mal construit : il n'est pas construit du tout. Les auteurs du principal ouvrage consacré au sujet le constatent sans détour, le passage du découpage au planning est si laborieux que beaucoup de chefs de projet « choisissent simplement de sauter l'étape de construction du WBS et de définir le travail en saisissant des tâches, des activités et des jalons dans l'outil de planification » (Norman, Brotherton et Fried, Work Breakdown Structures, 1re édition, Wiley, 2008, chapitre 7). Quand il existe, il finit souvent dans un tiroir, constat des mêmes auteurs au chapitre 4. Or sur un projet sous contrat, ce qu'on saura rapporter dépend directement de la façon dont on a découpé.

Ce qu'est un organigramme des tâches

Deux normes le définissent, et elles disent la même chose de deux façons.

Pour l'ISO, c'est la décomposition du contenu défini du projet ou du programme en niveaux successivement plus fins, constitués d'éléments de travail (ISO 21511:2018, article 3.13). C'est la seule norme ISO consacrée au seul organigramme des tâches, et son titre français officiel donne l'équivalence qui sert de fil à tout ce qui suit : organigramme des tâches, en anglais work breakdown structure, ou WBS.

La norme française en vigueur ajoute la finalité. C'est un « outil de structuration permettant d'identifier de manière arborescente et exhaustive l'ensemble des tâches d'un projet et/ou d'un programme afin de maîtriser les coûts, délais et performances » (NF X 50-115, 15 décembre 2017, article 3.15).

Deux remarques sur ces deux phrases. La première : la définition contient déjà la fonction. On ne découpe pas pour représenter, on découpe pour maîtriser des coûts, des délais et des performances. La seconde : la norme française en vigueur n'emploie jamais le sigle WBS, pas une fois sur ses quatre-vingt-dix pages.

Le vocabulaire n'est pas stabilisé pour autant. L'Office québécois de la langue française retient aussi « organigramme technique de projet » (fiche Organigramme des tâches, OQLF). L'AFITEP parlait de « structure de base du travail » (Dictionnaire de management de projet, 3e édition, AFNOR, 1996). Le PMI en français écrivait « structure de découpage du projet » (Guide PMBOK, 4e édition française, 2008). Et le mot organigramme désigne aussi, en français, la structure de l'organisation qui réalise le projet, qui est un tout autre objet.

Le dernier niveau du découpage porte un nom : le lot de travaux. C'est « l'élément le plus détaillé apparaissant dans un organigramme des tâches », caractérisé par un travail défini, un responsable unique, un budget et des éléments de délais (AFITEP, 1996). La norme de 2017 le confirme et précise son usage, « essentiellement pour la contractualisation et le reporting » (NF X 50-115, article 3.11).

Ce qu'il permet de piloter sur un projet sous contrat

L'organigramme des tâches sert d'abord à agréger. Les coûts, l'avancement et l'état remontent du lot de travaux vers le projet, niveau par niveau.

Sur un marché, cette remontée prend une forme particulière : il n'y a pas un organigramme des tâches, il y en a trois, emboîtés. Le standard américain de défense les nomme. Le Program WBS couvre le programme entier et appartient au donneur d'ordre. Le Contract WBS est celui du titulaire, et l'intention y est explicite, permettre au contractant de définir et de gérer les éléments du programme comme il l'entend. Le Subcontract WBS est celui du sous-traitant, avec une règle de non-recouvrement : ses éléments ne doivent pas être dupliqués dans celui du contrat (MIL-STD-881F, révision F, 13 mai 2022, articles 1.5.7 à 1.5.9). Le Department of Energy pose la même articulation à trois niveaux hors du monde de la défense (Work Breakdown Structure Handbook, DOE, 16 août 2012).

La conséquence est opérationnelle : l'organigramme reçu d'un client n'est pas celui qu'on construit en interne, et la frontière entre les deux est précisément l'endroit où passe le contrat.

Un objet accompagne le découpage et se néglige souvent : le dictionnaire de l'organigramme des tâches, qui décrit et borne chaque élément. Il se tient à deux mains. Préparé initialement par le responsable de programme côté donneur d'ordre, il est étendu par le contractant à mesure que le WBS de contrat se développe (MIL-STD-881F, article 2.2.4). C'est lui, et non le découpage seul, qui permet de passer aux activités : la norme ISO écrit que l'organigramme des tâches et son dictionnaire servent ensemble de base à l'établissement de la liste des activités de chaque élément (ISO 21511:2018, article 5.2.4).

Le niveau de reporting situé juste au-dessus du lot de travaux porte lui aussi un nom, le compte de contrôle. Il relève du croisement entre le découpage du travail et celui de l'organisation, qui est un autre sujet.

Un organigramme des tâches n'est pas un planning. C'est une hiérarchie du travail à réaliser et de ses sous-ensembles, et « ce n'est pas un échéancier » (Pritchard, How to Build a Work Breakdown Structure, ESI International, 1998). Les tâches, les activités et les jalons appartiennent à l'échéancier, pas au découpage. Construire le planning avant d'avoir découpé est d'ailleurs considéré comme une mauvaise pratique (Taylor, How to Develop Work Breakdown Structures, Systems Management Services, 2009).

D'où il vient, et quel problème il résolvait

La plus ancienne définition formelle que nous ayons pu consulter date de mars 1963. Elle figure au glossaire d'un supplément au guide commun du ministère de la Défense et de la NASA sur le système PERT COST : une subdivision en arbre généalogique d'un programme, commençant par les objectifs finaux puis subdivisant ces objectifs en sous-ensembles de plus en plus petits. Le même texte lui assigne trois usages : définir le travail à accomplir, construire un réseau, et résumer l'état des coûts et des délais pour des niveaux de management successivement plus élevés (DOD and NASA Guide, PERT COST, Output Reports, supplément n° 1, mars 1963).

Le manuel qui décrit le fonctionnement du système, la même année, montre à quoi cela servait concrètement. Chaque sous-ensemble reçoit un numéro de synthèse, chaque lot de travaux un numéro d'imputation, et c'est contre ces numéros que les estimations sont faites et les coûts réels accumulés (USAF PERT Volume III, PERT Cost System Description Manual, décembre 1963). L'objet naît donc comme un dispositif comptable, pas comme un schéma à commenter. Le même manuel exige déjà que l'appel d'offres comporte un organigramme des tâches développé dans la mesure où le programme est défini : c'est une pièce contractuelle dès l'origine.

La première norme qui lui est consacrée est le MIL-STD-881, du 1er novembre 1968, date lue sur la page de garde de sa première révision (MIL-STD-881A, 25 avril 1975). Des travaux d'ingénierie système en donnent la même origine et ajoutent une précision utile : le WBS a été développé « comme un arbre généalogique orienté produit » (Sharon et Dori, A Model-Based Approach for Planning Work Breakdown Structures of Complex Systems Projects, IFAC, 2012).

Ce qui frappe ensuite, c'est l'immobilité du vocabulaire. L'expression family tree, arbre généalogique, de mars 1963 se retrouve dans le Project Management Body of Knowledge du PMI, en 1987, dans le standard de défense de 2022 (MIL-STD-881F, article 1.5.3) et dans le manuel de la NASA de 2025 (NASA Work Breakdown Structure Handbook, juin 2025). La définition du lot de travaux de ce dernier est presque mot pour mot celle du glossaire de 1963.

Une précision s'impose, parce qu'une date circule sans source : l'organigramme des tâches n'est pas né en 1957 avec le PERT. L'article fondateur de la méthode, lu intégralement, ne contient ni le terme ni aucun de ses composants (Malcolm, Roseboom, Clark et Fazar, Application of a Technique for Research and Development Program Evaluation, Operations Research, 1959).

Reste la formulation la plus juste sur l'utilité de l'objet, et elle a soixante-deux ans : il est manifeste que des réseaux peuvent être construits sans recourir à un organigramme des tâches, mais il est fort possible que de tels réseaux soient incomplets ou incohérents avec les objectifs du programme (USAF PERT Volume I, PERT-Time System Description Manual, septembre 1963).

Comment se décide le découpage

Il n'existe pas un découpage correct, et la norme le dit elle-même. Le travail « peut être orienté produit, orienté livrable ou orienté résultat, et peut en outre être organisé par phases du projet ou du programme, par disciplines ou par localisations » (ISO 21511:2018, article 4.1). Le même texte qualifie l'organigramme des tâches de concept flexible, à adapter aux exigences du projet (article 4.3). La norme française admet de son côté un découpage fondé sur l'arborescence d'un produit ou des fonctions (NF X 50-115, article 3.15, note 1).

Deux organigrammes des tâches d'un même projet, côte à côte. À gauche, un découpage par produit : le projet se divise en Subsystem A et Subsystem B. À droite, un découpage par discipline : le même projet se divise en Engineering et Testing. Les quatre mêmes lots de travaux, WP1 à WP4, se retrouvent en feuilles des deux arbres, répartis sous des parents différents.

Ce que la figure montre est établi par deux sources indépendantes. Norman, Brotherton et Fried observent que deux représentations d'un même projet contiennent les mêmes lots de travaux, les éléments de plus bas niveau, et que la différence principale est l'organisation des éléments de niveau supérieur (2008, chapitre 2). Pritchard décrit le même phénomène par son inconvénient : le travail relatif à des livrables voisins peut s'étendre sur différents sous-ensembles de la structure, et « il devient beaucoup plus difficile de suivre l'avancement d'un composant unique » (1998).

Le critère de choix se déduit de là, et c'est une lecture plus qu'une prescription de norme : puisque l'organigramme des tâches sert à agréger, on le découpe selon ce qu'on devra pouvoir agréger et rapporter.

Deux règles rendent ensuite le découpage vérifiable. La première vient de l'audit : chaque activité du planning doit être rattachable à un élément de l'organigramme, chaque élément doit porter au moins une activité, et il ne doit exister qu'un seul organigramme par programme (GAO Schedule Assessment Guide, GAO-16-89G, décembre 2015). La seconde tient en une ligne : un élément décomposé a au moins deux enfants (ISO 21511:2018, article 5.1). La démonstration en est élégante, un parent doté d'un enfant unique serait le duplicata de cet enfant, donc sans usage (Norman, Brotherton et Fried, 2008, chapitre 4).

Un mot sur l'orientation du découpage, parce qu'elle circule à peu près partout comme une règle établie. Elle a changé trois fois. Le Project Management Body of Knowledge du PMI définissait en 1987, dans son glossaire, l'organigramme des tâches comme un arbre généalogique orienté tâche, formulation que rapportent aussi Pritchard (1998) et Norman, Brotherton et Fried (2008). L'édition de 1996 bascule vers l'orientation livrable (Guide PMBOK, 1re édition, PMI, 1996), changement qu'un praticien qualifiait deux ans plus tard de virage assez radical (Pritchard, 1998). Puis l'adjectif disparaît du glossaire à la 5e édition (Guide PMBOK, 5e édition, PMI, 2013), et la formulation reste inchangée jusqu'à la 7e édition (Guide PMBOK, 7e édition, PMI, 2021). L'ISO, elle, n'a jamais tranché. Et le même praticien écrivait déjà en 1998 que le chef de projet doit déterminer quelle approche servira au mieux les intérêts du projet.

Une nuance à connaître si le contexte est contractuel : le découpage par phases est admis par l'ISO et outillé par Pritchard, mais le standard américain de défense l'interdit, les phases n'étant pas des éléments d'organigramme puisque le WBS y est une structure de cycle de vie (MIL-STD-881F, article 2.2.5.1).

Reste le garde-fou. Un découpage trop fin ne sert personne : un organigramme des tâches « est trop détaillé quand il dit aux membres de l'équipe : bouge le pied gauche, bouge le pied droit » (Pritchard, 1998).

En résumé

Ce qui reste de tout cela n'est pas une définition, c'est un ordre d'opérations. Avant de découper, écrire ce sur quoi il faudra rendre compte : à qui, à quelle maille, et sur quels engagements contractuels. Le découpage se déduit de cette liste, il ne la précède pas. Un organigramme construit sans elle produit des niveaux intermédiaires qui n'agrègent rien d'utile, et c'est ainsi qu'il finit dans un tiroir.

Sur un projet sous contrat, la conséquence est plus directe encore. Quand le client impose son propre découpage, la question n'est pas de le reproduire mais de savoir ce qu'il permet de suivre, et donc ce qu'il faudra suivre autrement.

Stop guessing. See the real impact.

Questions fréquentes

Q.Quelle différence entre l'organigramme des tâches et l'organigramme du projet ?

Le premier structure le travail à réaliser, le second l'organisation qui le réalise. Le français emploie le même mot pour les deux, ce qui entretient la confusion. Le croisement des deux structures est un troisième objet, qui sert à attribuer les responsabilités.

Q.Faut-il un organigramme des tâches sur un petit projet ?

Les référentiels que nous avons consultés le supposent tous, sauf un. PRINCE2 7 écrit qu'un projet très simple, livrant un seul lot de travaux avec une petite équipe, n'en réclame pas (AXELOS, PRINCE2 7, Managing Successful Projects, 2023). À l'inverse, il est obligatoire sur les grands programmes d'acquisition publics américains (MIL-STD-881F, révision F, 13 mai 2022).

Q.Qui construit l'organigramme des tâches ?

Il est construit par ceux qui réaliseront le travail, avec l'appui technique d'experts du domaine et des autres parties prenantes. C'est l'un des critères de qualité que retiennent Norman, Brotherton et Fried, qui en font une condition et non une bonne pratique.

Références

  • AFNOR - NF X50-115 - Management de projet et de programme, présentation générale - Décembre 2017
  • AFNOR, AFITEP - Dictionnaire de management de projet français-anglais-espagnol - 3e édition, 1996
  • AXELOS - PRINCE2 7 - Managing Successful Projects - 2023
  • DoD - MIL-STD-881A - Work Breakdown Structures for Defense Materiel Items - Revision A, 1975
  • DoD - USAF PERT Volume III - PERT Cost System Description Manual - Advance Copy for AFSC Implementation, December 1963
  • DoD - USAF PERT Volume I - PERT-Time System Description Manual - Advance Copy for AFSC Implementation, September 1963
  • DoD - MIL-STD-881F - Work Breakdown Structures for Defense Materiel Items - Revision F, 2022
  • DOE - Work Breakdown Structure Handbook - Edition of 16 August 2012
  • ESI International - Carl L. Pritchard - How to Build a Work Breakdown Structure: The Cornerstone of Project Management - 1998
  • GAO - GAO-16-89G - Schedule Assessment Guide - Best Practices for Project Schedules - 2015
  • IFAC - Amira Sharon, Dov Dori - A Model-Based Approach for Planning Work Breakdown Structures of Complex Systems Projects - 2012
  • INFORMS - D. G. Malcolm, J. H. Roseboom, C. E. Clark, W. Fazar - Application of a Technique for Research and Development Program Evaluation - vol. 7, no. 5, 1959
  • ISO - ISO 21511:2018 - Organigrammes des tâches en management de projet et de programme - 1st edition, 2018
  • John Wiley & Sons - Eric S. Norman, Shelly A. Brotherton, Robert T. Fried - Work Breakdown Structures - The Foundation for Project Management Excellence - 1st edition, 2008
  • NASA - NASA/SP-20250006071 - Work Breakdown Structure (WBS) Handbook - revision E, 2025
  • Office québécois de la langue française - OQLF Vitrine linguistique - fiche organigramme des tâches - 2026
  • PERT Coordinating Group - Supplement No. 1 to DoD and NASA Guide, PERT COST - Output Reports - 1963
  • PMI - Project Management Body of Knowledge - 1987
  • PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 1996 Edition - 1996
  • PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 7th Edition - 2021
  • PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 5th Edition - 2013
  • PMI - Guide du corpus des connaissances en management de projet (Guide PMBOK) - 4e édition - 2008
  • Systems Management Services - Michael D. Taylor - How to Develop Work Breakdown Structures - 2009
Dans ce domaine : Périmètre & exigences
Le WBS : découper le travail pour savoir ce qu'on peut suivre