Accueil›Blog›L'organigramme du projet : qui répond de quoi, et avec quelle autorité
FondamentauxDébutant
Publié le 1 septembre 2026 · Par Vincent KENNEL
L'organigramme du projet : qui répond de quoi, et avec quelle autorité
Le découpage du travail dit ce qu'il faut faire, jamais qui en répond. L'organigramme du projet comble ce vide, et les référentiels ne s'accordent pas sur ce qu'il décompose. D'où il vient, ce qu'on y met, et le critère qui dit jusqu'où descendre.
En bref
L'organigramme du projet est la décomposition de l'organisation qui exécute le projet (ISO 21511:2018). Temporaire et propre à un projet, il dit qui répond de quoi et avec quelle autorité, ce que l'organigramme permanent de l'entreprise ne montre pas, et se descend jusqu'au niveau où chaque élément a un responsable de livraison unique et non ambigu.
Un organigramme des tâches complet ne dit pas qui répond de quoi. Sur un grand programme sous contrat, la question ne se pose pas au moment de planifier : elle se pose au premier écart, quand il faut désigner qui traite. C'est là qu'on découvre qu'un lot de travaux n'a pas de propriétaire, ou qu'il en a trois. L'organigramme du projet, souvent désigné par le sigle anglais OBS, est la structure qui répond à cette question. L'organigramme des tâches, lui, c'est le WBS, et il fait l'objet d'un article à part.
Ce qu'est l'organigramme du projet
L'organigramme du projet est la décomposition de l'organisation qui exécute le projet. L'ISO 21511:2018, à son article 3.5, le définit comme la décomposition de l'équipe de management qui réalise le travail d'un projet ou d'un programme, partenaires et sous-traitants compris.
La même norme, à l'article 5.3.2, ajoute la règle qui compte vraiment : quand l'organigramme des tâches et celui du projet sont intégrés, le plus bas niveau du découpage doit porter des éléments dont la responsabilité de livraison est unique et non ambiguë. Le PMI Practice Standard for Work Breakdown Structures, 2e édition (2006), le dit autrement : chaque lot de travaux a un point de responsabilité unique.
Le glossaire du PMBOK Guide ne bouge pas sur ce point de sa 1re édition (1996) à sa 7e (2021) : une représentation hiérarchique de l'organisation du projet, qui relie les activités aux unités organisationnelles qui les exécuteront.
Trois référentiels d'origines différentes se retrouvent donc sur deux points, et deux seulement : l'objet décomposé est une organisation, et l'unicité de la responsabilité de livraison est la condition qui fait tenir l'ensemble. Sur le reste, ils divergent.
Trois mots pour un seul objet
En français, l'objet porte trois noms et aucun n'est normalisé. Le Dictionnaire de management de projet de l'AFITEP, 3e édition (1996), l'appelle organigramme fonctionnel, et porte sur deux pages consécutives trois entrées distinctes : organigramme, organigramme des tâches, organigramme fonctionnel. Le Guide PMBOK, 4e édition en version française (2008), retient structure de découpage organisationnelle. La NF ISO 21500:2012 écrit organigramme du projet, la formulation la plus claire des trois ; cette édition a depuis été retirée, et le texte qui l'a remplacée ne nomme plus l'objet.
La terminologie officielle ne tranche pas davantage. Le Grand dictionnaire terminologique, consulté en août 2026, porte une fiche organigramme des tâches pour work breakdown structure, mais ses fiches organigramme et structure organisationnelle ne donnent que organization chart et organizational structure. L'objet projet n'y a pas d'entrée.
C'est pourquoi nous écrivons organigramme du projet, en gardant OBS comme sigle international.
Figure 1 : trois objets, un seul sujet
L'organigramme du projet n'est ni l'organigramme de l'entreprise, ni la structure de découpage des ressources. La norme ECSS-M-ST-10C Rev.1 (2009) est, de tous les référentiels que nous avons lus, le seul à nommer les deux premiers et à les opposer : le project OBS décrit l'organisation proposée du projet, le company organization breakdown structure décrit les aspects fonctionnels de l'entreprise. Quant à la confusion avec la RBS, Harvey A. Levine la documentait dans PM Network, volume 7 numéro 4 (1993) : d'un logiciel à l'autre, et parfois chez un même éditeur, l'OBS y était configurée tantôt comme une structure de ressources, tantôt comme une variante du WBS.
Figure 2 : les deux axes du projet
À quoi il sert sur un projet sous contrat
Pourquoi une seconde structure, alors que l'entreprise a déjà son organigramme ? Parce qu'un organigramme d'entreprise ne montre pas ce dont un projet a besoin.
Harold Stieglitz l'écrivait en 1964, dans un texte repris au recueil Systems, Organizations, Analysis, Management de Cleland et King (1969) : un organigramme n'est pas une organisation. Ce qu'il montre, c'est la division du travail et qui est le supérieur de qui. Ce qu'il ne montre pas, et c'est exactement le point : le degré de responsabilité et d'autorité exercé par des positions de même niveau. Deux personnes au même échelon peuvent avoir des degrés d'autorité très différents.
La seconde raison est le contrat. John F. Mee, dans le même recueil, rattachait dès 1964 la forme matricielle aux contrats de projet : l'autorité du chef de projet lui est donnée conformément aux stipulations de délai, de coût, de qualité et de quantité du contrat, et l'organisation est fluide, les projets achevés en étant retirés. Linn C. Stuckenbruck, dans Project Management Quarterly en 1979, en tire la conséquence : le projet est temporaire là où les départements fonctionnels sont permanents.
Reste la forme que prend cette organisation. La NF X 50-115:2017, norme française en vigueur, en distingue trois à son paragraphe 7.4 : structure fonctionnelle, structure en équipes autonomes, structure hybride ou matricielle. Le choix entre elles est un autre sujet ; ce qui compte ici est qu'il en existe plusieurs, et que celle du projet doit être écrite quelque part.
Ce qu'on y met, et jusqu'où on descend
Le critère d'arrêt se déduit de ce qui précède : on descend jusqu'à ce que chaque élément ait un responsable de livraison unique et non ambigu. Les référentiels posent cette exigence au point où les deux structures s'intègrent ; l'appliquer à la profondeur de l'organigramme du projet est un choix de méthode, pas une prescription. Ce n'est pas un nombre de niveaux, et aucune des sources consultées n'en fixe un. Moder, Phillips et Davis, dans la 3e édition de Project Management with CPM, PERT and Precedence Diagramming (1983), montrent une codification de niveau 0 à 3 : un exemple attesté, pas une règle.
Sur le contenu, l'ECSS-M-ST-10C Rev.1 (2009) donne une liste de contrôle utilisable telle quelle. L'organisation du projet doit inclure toutes les disciplines essentielles, avec des fonctions définies, des lignes de report claires, les interrelations et les interfaces, et une allocation non ambiguë des rôles, des responsabilités et des autorités.
La NF X 50-115:2017 propose une entrée plus concrète, en trois équipes. L'équipe restreinte de projet, qui regroupe usuellement les responsables de lots de travaux, dirige le projet global ; l'équipe de gestion de projet tient les domaines du management de projet ; l'équipe technique, avec l'architecte, pilote les activités liées au produit. La même norme rappelle qu'il n'existe pas de solution unique.
Elle dit aussi, à son paragraphe 5.4.1, quelque chose que personne d'autre ne formule aussi nettement : le responsable de projet définit l'organisation du projet en prenant en compte, parmi ses entrées, l'organigramme des tâches. Le découpage du travail est donc, normativement et en français, une entrée de la définition de l'organisation. C'est l'énoncé du second axe.
Un exemple, sans inventer d'organigramme. Le rapport NASA TM-81509 de McCarthy (1980) nomme les douze entités qui suffisaient alors à mener un programme aérospatial complexe : plans et programmes, gestion de configuration, ingénierie système, opérations d'essai, ingénierie de conception, logistique, achats, installations, fabrication, gestion des données, assurance qualité, administration des contrats. Une liste réelle et datée, pas un modèle à recopier.
D'où ça vient, et pourquoi les référentiels ne disent pas la même chose
La fonction précède le nom. Le manuel USAF PERT Volume III, PERT Cost System Description Manual (décembre 1963), porte déjà des codes d'organisation responsable et d'organisation exécutante, et un rapport qui les croise. Le sigle, lui, n'y figure nulle part.
Quatorze ans plus tard, la DoDI 7000.2 du 10 juin 1977 rend contractuellement applicables les critères américains de maîtrise des coûts et des délais. Son cinquième critère d'organisation exige d'intégrer le découpage du travail contractuel avec la structure organisationnelle fonctionnelle du contractant, de façon à mesurer la performance par élément de l'un et de l'autre. Le croisement des deux axes est donc exigible en 1977, sans que l'OBS soit nommé.
Le sigle entre dans la doctrine américaine entre 1980 et 1995. Absent de la MIL-STD-881A (1975) comme de la DoDI 7000.2, il est présent chez Moder, Phillips et Davis en 1983, défini dans l'ouvrage dirigé par Kerridge et Vervalin en 1986, et courant dans le guide interarmées Draft Cost/Schedule Management Guide, Version G du 15 mai 1995. Ces dates sont celles des textes lus pour cet article, pas celles d'une première occurrence imprimée, qui n'est pas établie. Le PMI le normalise avec la 1re édition du PMBOK Guide (1996), l'ISO avec l'ISO 21511:2018.
Figure 3 : une source, deux lignées
C'est là que la divergence se joue. Deux traditions partent du même point de 1977. L'une, normative et spatiale, tient que l'OBS décompose l'organisation du projet, temporaire. L'autre, née de la maîtrise des coûts, tient qu'il décompose la portion projet de l'organisation permanente, lue par fonction : structure organisationnelle fonctionnelle en 1977, division fonctionnellement orientée de l'organisation du contractant dans le Planning & Scheduling Excellence Guide, version 4.0 (2019). La lecture fonctionnelle n'est donc pas une négligence tardive : elle est dans le critère fondateur, avec quarante-deux ans de continuité.
Le PMBOK Guide, de sa 3e édition (2004) à sa 6e (2017), en porte la trace : son corps de texte décrit l'OBS comme structuré selon les services existants de l'organisation, quand son glossaire dit l'organisation du projet. La 7e édition (2021) a supprimé la formule.
Un seul texte réconcilie les deux lectures dans le corpus dépouillé ici : le NASA/SP-20220009501 (2022) définit l'OBS comme la hiérarchie projet des organisations hiérarchiques et fonctionnelles appliquée au projet considéré. Côté français, aucun des deux régimes ne s'applique vraiment, la NF X 50-115:2017 ne nommant pas l'objet et structurant l'organisation par des rôles et des équipes.
En résumé
Le critère est plus utile que la définition. Un élément dont personne ne répond seul n'est pas un niveau de trop dans une arborescence : c'est un arbitrage qui arrivera trop tard. La relecture la moins coûteuse consiste à reprendre les lots de travaux un par un et à vérifier qu'un nom, un seul, en réponde.
Et quand un référentiel interne et un outil ne disent pas la même chose de l'OBS, aucun des deux n'a forcément tort : ce sont deux traditions. Le texte qui tranche est celui que le contrat nomme.
Stop guessing. See the real impact.
Questions fréquentes
Q.Lequel vient en premier, le WBS ou l'organigramme du projet ?
Le découpage du travail. La NF X 50-115:2017, à son paragraphe 5.4.1, en fait l'une des six entrées de la définition de l'organisation, avec la logique de déroulement, les exigences, les attentes des parties prenantes, les risques et l'analyse des interfaces organisationnelles.
Q.Faut-il un organigramme du projet si l'entreprise est déjà organisée en équipes projet ?
Oui. L'ouvrage dirigé par Kerridge et Vervalin le posait dès 1986 : que le projet soit mené par une équipe dédiée ou par des départements fonctionnels, il lui faut un organigramme propre, qui désigne les entités responsables de l'exécution.
Q.Qui valide l'organigramme du projet ?
Le responsable de projet le définit. La NF X 50-115:2017 recommande qu'il soit ensuite validé par l'instance de gouvernance du projet avant sa mise en œuvre.
Références
AFNOR - NF X50-115 - Management de projet et de programme, présentation générale - Décembre 2017
AFNOR - NF ISO 21500:2012 - Lignes directrices sur le management de projet - Octobre 2012
AFNOR, AFITEP - Dictionnaire de management de projet français-anglais-espagnol - 3e édition, 1996
Arthur E. Kerridge, Charles H. Vervalin - Engineering and Construction Project Management - 1986
David I. Cleland, William R. King - Systems, Organizations, Analysis, Management: A Book of Readings - 1st edition, 1969
DoD - Cost/Schedule Management Guide - Draft, Version G, 15 May 1995
DoD - DoDI 7000.2 - Performance Measurement for Selected Acquisitions - Edition of 10 June 1977
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
ECSS - ECSS-M-ST-10C Rev.1 - Space project management, Project planning and implementation - 2009
Harold Stieglitz - What's Not on the Organization Chart - 1964
ISO - ISO 21511:2018 - Organigrammes des tâches en management de projet et de programme - 1st edition, 2018
John F. Mee - Matrix Organization - 1964
Joseph J. Moder, Cecil R. Phillips, Edward W. Davis - Project Management with CPM, PERT and Precedence Diagramming - 3rd edition, 1983
NASA - NASA/SP-20220009501 - Space Flight Program and Project Management Handbook - 2022
NASA - John F. McCarthy Jr. - NASA TM-81509 - Matrix Management for Aerospace 2000 - 1980
