Ce document s'intéresse à la définition et à la gestion des projets, en insistant sur l'importance de la communication et d'une terminologie commune. Il précise qu'un projet doit avoir un objectif unique et mesurable, et expose des exemples concrets pour distinguer les projets des simples activités. Il aborde également les méthodes de conduite et de gestion de projets, ainsi que les enjeux liés à la gestion multi-projets.

1. 1
LACONDUITEDEPROJET
INTRODUCTION
Un projet est avant tout une activité humaine. Quand plusieurs personnes sont impliquées
dans une même activité, la communication est un facteur clé, et une terminologie commune
l'ingrédient de base. Voilà pourquoi cette introduction définit les termes principaux avec
lesquels les différentes techniques seront exposées.
1. DEFINITION D'UN PROJET
Un projet est un ensemble particulier de travaux. Le terme « projet » a plusieurs sens en
français :
 ébauche ou esquisse de ce qui va être élaboré (par exemple, un projet architectural),
 souhait ou intention d'atteindre un état (par exemple, un projet de déménagement),
 ensemble d'étapes et d'actions destinées à réaliser un but (par exemple, un projet
informatique).

2. 2
Dans l'expression « gestion de projets », c'est le troisième sens qui est utilisé. Pour éviter de
possibles confusions, le terme projet ne sera utilisé que dans ce troisième sens.
Un projet est un ensemble d'actions ou de travaux qui concourent tous à la réalisation d'un
objectif unique et mesurable.
Un objectif est dit unique si, lorsqu'il a été atteint une fois, il est atteint définitivement.
Par exemple, assurer un ramassage scolaire quotidien n'est pas en soi un projet, car le fait
qu'il se soit bien déroulé un jour ne signifie pas qu'il ne reste rien à faire pour le lendemain.
Par contre, mettre en place un ramassage scolaire est un projet car une fois qu'il a été mis en
place, l'objectif est atteint et le projet s'arrête.
Un objectif est dit mesurable s'il est possible de déterminer à chaque instant s'il a été atteint
ou s'il n'est pas atteint.
Par exemple, améliorer l'image d'une marque n'est pas un projet. Par contre, amener la
notoriété d'une marque à un point où 10% de la population sait que « L » est une marque de
lessive, est un projet.
Un objectif n'est pas un projet. Un objectif est le résultat d'un projet. Cependant un projet

3. 3
est défini par son objectif.
Un facteur important d'échec de projet est que l'objectif a été mal défini.
Il y a bien évidemment des actions et des travaux qui doivent être menées sans pour autant
qu'un objectif unique et mesurable puisse être exprimé et fixé. Dans ce cas (et il existe bien
souvent), il ne s'agit pas de projets. Par exemple, « satisfaire son public » ne correspond pas
à un objectif unique et mesurable ; il ne s'agit pas d'un projet.
Pourtant, il faut bien satisfaire son public ! En réalité, « satisfaire son public » est un besoin
(et non pas un objectif) qui doit être transformé en un ou plusieurs objectifs).
C'est une fonction marketing qui se doit de transformer « satisfaire son public » en
« proposer un produit de telles dimensions, de telle couleur, de tel poids, avec telles
fonctions et à tel prix » ; autrement dit de transformer un besoin en objectif.
Des méthodes, techniques et outils de conduite de projets ne sont efficaces que pour des
projets. Les mettre en œuvre pour des travaux qui ne sont pas des projets réduit leur
efficacité et les chances d'aboutir. Savoir reconnaître les travaux qui constituent un projet de
ceux qui n'en constituent pas un (qu'ils en constituent soit plusieurs, soit aucun) est une
nécessité pour pouvoir mener des projets à terme.

4. 4
Quelques exemples
Voici quelques phrases qui commencent chacune par un verbe. Chacune représente des
actions et des travaux. Certaines représentent des projets et d'autres pas. Lesquelles ?
 Prendre 1% du marché des tulipes rouges.
 Faire des études de faisabilité.
 Intégrer deux systèmes informatiques.
 Maintenir un aérodrome.
 Faire la révision annuelle d'un parc de voitures.
 Réaliser un logiciel de gestion de personnel.
 Commercialiser un logiciel.
Si un « produit », un résultat unique et mesurable, peut être identifié, alors il s'agit d'un
projet. Dans le cas contraire, il ne s'agit pas d'un projet.

5. 5
Prendre 1% du marché des tulipes rouges. Le « produit » est 1% du marché des tulipes
rouges. A la condition de disposer d'un moyen de mesure de sa pénétration du marché, il est
possible de savoir à chaque instant si l'objectif est atteint ou s'il ne l'est pas. Il s'agit donc
bien d'un projet. A noter cependant que la phrase « détenir 1% du marché des tulipes rouges »
ne représente pas un projet, car le fait de détenir 1% du marché à un moment donné
n'empêche pas que la part de marché puisse diminuer.
Faire des études de faisabilité. Dans un sens de la phrase, il s'agit de plusieurs projets (faire
une étude de faisabilité est en soi un projet, dont le « produit » est la réponse à la question :
peut-on faire, et comment ?). Dans l'autre sens de la phrase, il s'agit non pas de plusieurs
projets mais d'un type d'activité ou d'un métier.
Intégrer deux systèmes informatiques. Le « produit » est ici l'installation finale. La phrase
représente donc bien un projet. Une réserve s'impose cependant : la maintenance de logiciel
n'est en réalité pas une maintenance dans le sens industriel ou matériel du terme. Un logiciel
ne s'use pas. Par contre son utilisation progressive se heurte à des défaillances qui mettent en
lumière des insuffisances du logiciel ou défauts : les « bugs » (ce qui signifie littéralement
«punaises», de l'époque des ordinateurs à lampes qui devaient être ventilés en permanence et
qui attiraient des insectes. En se collant sur les tubes, les insectes provoquaient des pannes si
fréquentes que toute défaillance informatique était attribuée à un « bug ». Il n'y a plus de
tube dans les ordinateurs, mais l'usage des « bugs » est resté). Tous les systèmes

6. 6
informatiques font l'objet d'une maintenance corrective du logiciel qui consiste à corriger
les défauts au fur et à mesure qu'ils sont découverts. Or, corriger un défaut revient à dire
que le développement du logiciel n'était pas terminé à la fin du projet. La définition de la
fin d'un projet logiciel doit donc s'appuyer sur des conventions de recette.
Maintenir un aérodrome. Cette activité consiste à veiller à ce qu'un ensemble
d'équipements et de systèmes soient opérationnels. L'objectif peut donc bien être défini,
mais le fait que l'aérodrome soit opérationnel à un instant donné ne signifie pas qu'il le sera
cinq minutes plus tard. Dans ce cas, l'objectif peut être atteint, puis ne l'est plus, puis l'est à
nouveau, etc. Pour cette raison, il ne s'agit pas d'un projet. La maintenance d'installations ou
d'équipements s'appuie sur des techniques qui ressemblent à celles mises en œuvre en
gestion de projets, mais qui sont cependant différentes. La gestion de maintenance est un
domaine différent de la gestion de projets.
Faire la révision annuelle d'un parc de voitures. Telle que cette phrase est formulée, il s'agit
bien d'un projet. Pour une année donnée, l'ensemble des opérations de révision conduit à un
« produit » (toutes les voitures du parc ont été révisées). Pour faire le lien avec la phrase
précédente, le fait que les voitures aient été révisées ne signifient pas qu'elles n'auront
aucune panne. De fait, une partie de la maintenance est en fait constituée de projets.
Réaliser un logiciel de gestion de personnel. II s'agit bien d'un projet dont le « produit » est

7. 7
le logiciel de gestion de personnel (avec la réserve exprimée ci-dessus concernant la fin des
projets logiciels).
Commercialiser un logiciel. Il s'agit là d'un besoin mais quel est le « produit » ? Est-ce de
préparer une infrastructure de support technique ? Est-ce de vendre un premier exemplaire ?
Ou bien est-ce d'amortir les coûts de développement ? En conclusion, il ne s'agit pas d'un
projet.

8. 8
2. HIERARCHIE DE PROJETS
L'objectif d'un projet est unique. Un objectif peut cependant être décomposé en plusieurs
«sous-objectifs», qui correspondent alors chacun à un «sous-projet».
Ce que l'on nomme «projet», «sous-projet», ou «plan» devient une question de taille et non
pas de nature. La nature «projet» est une constante alors que le volume qui correspond à ce
qu'une entreprise appelle un «projet» (relativement à un sous-projet ou à un programme)
relève de conventions.

9. 9
Voici un exemple de hiérarchie de projets :

10. 10
Des méthodes, techniques et moyens de gestion de projets s'utilisent aux différents niveaux
d'une hiérarchie de projets.
La difficulté complémentaire en gestion de projets consiste:
 d'une part, à agréger la gestion de sous-projets en une gestion de projets, puis à
agréger la gestion de projets en une gestion de programme, etc. ;
 d'autre part, à traduire les contraintes d'un programme sur ses projets, puis à
traduire les contraintes d'un projet sur ses sous-projets, etc.

11. 11
3. CONDUITE DE PROJET
La conduite d'un projet consiste à faire en sorte que le projet concerné aboutisse dans les
délais, dans le budget et avec le niveau de qualité requis.
La fonction essentielle de la conduite d'un projet est d'obtenir le «produit» du projet.
Selon les projets, l'importance du respect des délais et des budgets peut varier. Il est parfois
primordial de tenir les délais (par exemple, dans le lancement d'un produit sur un marché
concurrentiel).
Dans d'autres cas les budgets sont impératifs alors que les délais sont plus souples. Dans tous
les cas, le point clé est l'aboutissement.
La conduite de projet, comparable au pilotage d'un engin, est confiée à une personne ou une
équipe : le Chef de Projet.
D'une entreprise à l'autre la dénomination peut varier (Directeur de Projet, Équipe Projet,
Responsable d'Affaire, etc.), mais le rôle est toujours le même.
Le Chef de Projet, dans sa conduite du projet, s'appuie sur la gestion de projets et sur la

12. 12
gestion de la qualité.

13. 13
4. GESTION DE LA QUALITE
La qualité d'un produit est son aptitude à répondre aux besoins des utilisateurs (Association
Française de NORmalisation ou AFNOR). Selon l'AFNOR également, la qualité d'un logiciel
est son aptitude à répondre aux besoins exprimés des utilisateurs.
L'assurance qualité consiste à formaliser un ensemble de règles qui permettent d'obtenir un
résultat de qualité.
Le contrôle qualité consiste à constater et vérifier au cours de l'élaboration du produit que
les règles de l'assurance qualité sont bien mises en œuvre et non pas à vérifier que le
produit est «bon» (ceci est vérifié par les tests et les revues).
L'assurance qualité se traduit formellement par un Manuel Qualité, propre à l'entreprise ou à
un ensemble de projets. Pour chaque projet, le Manuel Qualité est adapté aux nécessités et
aux particularités du projet. Le résultat est le Plan Qualité du projet. L'assurance qualité
prévoit la gestion de projets en tant que l'une des actions qualité.
La gestion de projets s'appuie sur l'assurance qualité pour l'analyse du projet et sur le
contrôle qualité pour le suivi d'avancement.

14. 14
5. GESTION DE PROJET
La gestion d'un projet consiste à répondre à la question : où en est-on dans le projet ?
Gérer un projet représente des efforts — du temps et des coûts —. D'expérience, la gestion
d'un projet coûte entre 2 et 5% de la valeur ajoutée du projet (coûts d'étude et d'ingénierie).
Si dans un projet, le Chef de projet sait intuitivement répondre à la question : où en est le
projet ? ou encore si la réponse à cette question ne l'intéresse pas ou n'intéresse pas les
décideurs (ce qui n'est pas si rare), alors la gestion du projet en tant que telle n'a pas lieu
d'être.
Répondre à la question «où en est-on dans le projet ?» n'est pas si simple. Il faut pour cela :
 d'une part, avoir formalisé un scénario du projet (le terme souvent retenu est «tableau
de marche prévisionnel»), autrement dit un planning, des plans de charges et un budget ;
 d'autre part, disposer de moyens de déterminer périodiquement ce qui a été fait et ce qui
reste à faire ;
 enfin, pouvoir représenter un avancement, c'est-à-dire pouvoir pointer l'avancement sur

15. 15
le tableau de marche prévisionnel.
Ce dernier point (la métrique d'avancement) n'est pas évident. En voici une illustration :
Dans cet exemple, un «projet» (très simple) dure deux mois. Un mois après son démarrage,
on constate qu'il faut encore trois mois pour terminer (il s'agit bien évidemment d'un
exemple inventé !).

16. 16
Le tableau de marche prévisionnel est ici une barre qui représente les deux mois prévus.
L'extrémité gauche de la barre représente le début du projet, et l'extrémité droite, la fin. Les
trois figures présentent trois possibilités de représenter l'avancement (autrement dit, trois
métriques possibles d'avancement).
La figure 1 montre que le projet a déjà duré un mois, mais ne montre pas qu'il va encore en
durer trois.
La figure 2 montre que le projet va encore durer trois mois, mais ne montre pas qu'il a déjà
duré un mois.
La figure 3 montre que le projet en est à 25% d'avancement (1 mois réalisé sur une durée
totale de 4 mois, 1 mois réalisé + 3 mois pour finir), par contre l'échelle de temps n'est plus
vraie.
Devant une telle situation pourtant très simple du point de vue de la gestion de projets,
plusieurs solutions existent, avec chacune des avantages mais aussi des inconvénients.
Pour chaque projet, ou pour chaque ensemble de projets, le choix de la métrique
d'avancement détermine ce que la gestion de projets permettra de voir au cours du (ou des)
projet(s) :

17. 17
 Avec une métrique similaire à celle de la figure 1, l'accent est mis sur ce qui a été fait. Ce
type de métrique est utilisé dans des projets dits «à dépenses contrôlées» (en «régie»)
ou dans des projets dans lesquelles la part de recherche est importante.
 Avec une métrique similaire à celle de la figure 2, l'accent est mis sur ce qui reste à faire.
Ce type de métrique est utilisé dans des projets où les délais priment sur les budgets.
 Avec une métrique similaire à celle de la figure 3, l'accent est mis sur l'avancement relatif.
En complément d'un suivi des coûts, ce type de métrique permet de comparer ce qui a été
«gagné» (dans l'exemple du dessin, 25% du budget du projet) à ce qui a été dépensé.
La norme américaine du Département de l'Énergie (la norme «C/SCSC» ou «Earned
Value», soit la «Valeur Gagnée») est fondée sur ce principe. Ce type de métrique permet
une comptabilité analytique de projets.
La gestion de projets s'appuie sur :
 une façon de décomposer les projets en tâches.
 des techniques de calcul de délais, de plans de charge et de budgets,
 l'appréciation périodique de l'avancement,
 une (ou des) métrique(s) d'avancement.

18. 18
6. CONDUITE MULTI-PROJETS
Une entreprise ou une partie de l'entreprise peut être responsable de plusieurs projets qui ne
soient pas les parties d'un même ensemble (programme ou plan). C'est par exemple le cas
d'un bureau d'études. Dans ce cas, le terme multi-projets est utilisé.
Les différents projets sont indépendants dans le sens où leurs «produits» respectifs le sont,
mais ils nécessitent par contre fréquemment les mêmes ressources (équipements, matériels ou
équipes) en même temps.
L'arbitrage des conflits d'utilisation de ressources est appelée la conduite multi-projets, qui
consiste à assigner des priorités aux différents projets pour permettre à chacun de disposer des
ressources communes.
Sur une longue période de temps, la conduite multi-projets consiste également à prévoir et
rendre disponible les ressources communes qui seront nécessaires au bon déroulement des
différents projets à mener.
Dans sa nature, la conduite multi-projets (arbitrer des priorités) est différente de la conduite
d'un projet (parvenir à l'objectif). Alors que les moyens utilisés se rejoignent.

19. 19
7.GESTION MULTI-PROJETS
La gestion multi-projets consiste à fournir des tableaux de bord sur les besoins en ressources
des différents projets.
Pratiquement, il s'agit de consolider l'avancement des différents projets (selon, bien
évidemment, une métrique d'avancement commune), puis de répercuter sur la gestion des
différents projets les choix ou les changements de priorités effectués.

20. 20

21. 21
8. PROBLEMES RENCONTRES EN GESTION DE PROJETS
Il est des modes. La gestion de projets en est une. Voici un exemple fréquemment rencontré
de mise en place d'une gestion de projets :
« La Direction des Etudes se trouve confrontée à un problème de délais sur un projet. Elle
décide de la mise en place d'une gestion des projets et nomme un responsable plannings qui
fait un premier tour des différents chefs de projet et des responsables.
Le besoin semble simple : chacun sait bien pourquoi les projets dérivent, mais il manque
la forme pour communiquer l’information. La conclusion s'impose : il faut un logiciel de
gestion de projets.
Le responsable plannings fait ensuite le tour des logiciels disponibles sur le marché et établit
des critères de choix :
 ordinateur et environnement technique de mise en œuvre,
 facilité de mise en d'oeuvre,
 lisibilité des sorties,
 interfaces vers d'autres logiciels,
 possibilités de paramétrage,

22. 22
 possibilités de support du fournisseur.
 réduction de prix accordées.
Le choix est fait et le logiciel installé.
La période d'enthousiasme prend fin progressivement avec les contraintes quotidiennes
du logiciel :
 il faut saisir les données,
 il faut analyser les résultats,
 il faut réitérer des calculs.
 etc.
Il faut finalement un travail important pour parvenir à des résultats décevants : il y a
toujours des retards. Une conclusion s'impose : le logiciel est mauvais.
Un nouveau responsable plannings est nommé. Mais cette fois, les chefs de projet sont
réticents.
Un logiciel de gestion de projets ne fait évidemment pas tout. Pour que sa mise en place soit
un succès, il faut mener une démarche préalable qui apporte rigueur et homogénéité dans :

23. 23
 la terminologie de gestion des projets,
 les échanges d'informations,
 les tableaux de bord attendus,
 la compréhension des mécanismes de calcul.
Rigueur et homogénéité vont avec contrainte. La gestion de projets (surtout si elle est
automatisée) devient un cadre de travail dans lequel chaque projet doit se dérouler.
Mais chaque projet est spécifique (par la nature même des projets). Travailler sur un projet
(spécifique) dans un cadre commun est une contrainte.
Pour être acceptée, celle-ci doit avoir une contrepartie claire : une visibilité sur les projets.
Autrement dit, une condition nécessaire du succès de la mise en place de la gestion des
projets est une volonté de la Direction des projets, claire et exprimée.
Alors l'effort de cohérence dans la terminologie et dans les procédures de gestion des projets
peut être entrepris.
La Direction et les chefs de projet sont directement concernés par la gestion de projets. Mais
ce ne sont pas les seuls. L'avancement des projets doit être périodiquement «signalé» au

24. 24
logiciel de gestion des projets. Autrement dit, les acteurs directs des projets doivent
périodiquement rendre compte de l'avancement de leurs travaux (ce qui a été fait et ce qui
reste à faire).
Pour un grand nombre de personnes, gestion de projets représente comptes rendus
périodiques. Et par conséquent, contrainte. Et avec quelle contrepartie ?
Une première façon de résoudre le problème est de ne pas demander de compte rendu
d'avancement systématique. Autrement dit, le planning est supposé suivi à la lettre, et tout
écart doit être signalé.
L'avantage de cette formule est de minimiser les contraintes pour les acteurs du projet.
L'inconvénient majeur est de ne faire apparaître que les problèmes déjà vus, et pour lesquels
personne n'a oublié de faire «remonter l'information».
Cette façon de résoudre le problème est bien souvent une façon de ne pas le résoudre, un
compromis entre un certain degré de transparence dans le projet et le respect de l'autonomie
de gestion des intervenants.
D'une façon ou d'une autre, le suivi de l'avancement du projet s'appuie sur des comptes
rendus d'avancement (ne serait-ce que, dans des cas extrêmes, le silence).

25. 25
Les personnes qui fournissent un compte rendu d'avancement doivent recevoir un retour de
l'information.
Voici un exemple de retour :
« Un compte rendu papier est rempli chaque semaine par chacun des participants au
projet. Ces comptes rendus sont ensuite visés par les chefs de projet concernés (une
même personne peut travailler sur plusieurs projets), puis centralisés et saisis dans le
logiciel.
Chaque semaine, les données d'avancement permettent de calculer une révision du plan
de travail de chaque projet. Ce plan de travail révisé est examiné par le chef de projet
qui s'assure qu'aucune erreur de saisie n'est passée.
Puis chacun reçoit un état d'avancement qui lui indique l'extrait du nouveau plan de
travail qui le concerne directement. La gestion des plannings est l'affaire de tous. »
La forme de la procédure peut varier. En voici un autre exemple :
« Chaque vendredi, le chef de projet s’entretient individuellement avec les différentes

26. 26
personnes du projet et revoit l’avancement de chaque tâche. Il saisit directement l'avancement
des tâches sur son ordinateur et il constate directement les modifications du plan de travail.
Le suivi de l'avancement est alors l'occasion de faire un point régulier sur chacun des
travaux. »
Le retour d'information a deux aspects : sa forme et son délai. La forme est la nature des
informations qui reviennent à celui qui a fourni un compte rendu. Le délai est le temps qui
s'écoule entre la fourniture du compte rendu et la mise à disposition du retour.
Dans un cas rencontré, il s'écoulait plusieurs mois pour un rythme mensuel de compte rendu.
La tendance bien naturelle était alors de mettre «n'importe quoi», parce que «de toute façon,
le temps que tout cela revienne...».
Le suivi d'avancement représente la plus grande part des informations gérées et du temps
passé en gestion de projets. Pour bien cibler le suivi d'avancement, il faut distinguer trois
aspects :
 le suivi des projets (où en est-on des projets ?),
 le suivi budgétaire (les prévisions de dépenses sont-elles suivies ?),
 le suivi d'activité (combien d'heures sont travaillées par chaque personne dans l'année ?).

27. 27
Privilégier un aspect fait s'estomper les autres.
Un suivi d'activité nécessite d'imputer son temps sur différentes rubriques : les projets, mais
aussi les absences en tous genres, les «divers» et autres «hors projets».
Or, il y a des périodes où les nécessités d'un projet font que le volume de travail y est
supérieur. Ces variations de volumes prévisibles à court terme ne sont plus suivies dans une
gestion d'activité.
Un suivi budgétaire a tendance à faire imputer les charges sur les postes encore ouverts.
Globalement, les charges sont bien suivies, mais la visibilité est faussée.
Lors de la mise en place d'une gestion des projets, l'explication qui en est faite doit
s'appuyer sur ses finalités, et sur les informations d'avancement qui sont attendues.

28. 28
LACONDUITEDEPROJET
ANALYSEDEPROJETS
La mise en oeuvre d'une technique de planification (par les tâches ou par les ressources)
nécessite que :
 les tâches soient identifiées,
 la logique de l'ensemble des tâches ait été analysée,
 les tâches soient quantifiées en termes de délais, de charges ou de ressources,
 les ressources soient identifiées.
Ces éléments sont issus de l'analyse d'un projet, qui se situe en amont de la planification.
Dans les faits, le processus complet de l'analyse d'un projet dépend du type de projet.
Par exemple, l'analyse d'un projet de développement d'un produit nouveau dans un marché
concurrentiel est différente de l'analyse d'un projet de rénovation d'un hôpital.

29. 29
Différentes méthodes d'analyse existent, adaptées chacune à des catégories de projets.
Ce qui est présenté ci-après relève plus du formalisme que de la méthode. Les termes
indiqués (d'origine anglo-saxonne) sont dans la pratique des «standards» retenus dans la
gestion de projets internationaux et de plus en plus dans la gestion de projets locaux.
Ces termes apparaissent souvent dans les logiciels de gestion de projets et sont utilisés
comme des moyens de regroupements transversaux de tâches pour des besoins de tableaux de
bord spécifiques.
1. FORMALISMES
Voici les principaux formalismes autour desquels s'articule l'analyse d'un projet :
Le «quoi» signifie l'objectif du projet, autrement dit le «produit».
Le «comment» représente la façon de parvenir au produit, c'est-à-dire les travaux qui
constituent le projet.
Le «qui» résume les rôles dans le projet.

30. 30
Le «réseau» permet de rassembler toutes les hypothèses de quantification des tâches (délais,
charges et/ou intensités de ressources) ainsi que de dépendances entre tâches.
Le «scénario» est le résultat du traitement du réseau par une technique de planification.
Ces différentes étapes sont décrites ci-après.

31. 31
PBS (Product Breakdown Structure)
Voici un exemple de PBS (Product Breakdown Structure) ou Structure de Décomposition du
Produit :

32. 32
Cette arborescence se lit comme suit :
 en descendant, le trait signifie «est composé de»,
 en montant, le trait signifie «fait partie de».
Dans l'exemple du schéma ci-dessus, le système est composé de trois sous-systèmes, et l'un
des sous-systèmes est composé de trois ensembles.

33. 33
WBS (Work Breakdown Structure)
La Structure de Décomposition des Travaux ou WBS (Work Breakdown Structure) est la
représentation structurée de toutes les tâches, phases, et plus généralement de toutes les
parties et composantes d'un projet.
La Structure de Décomposition des Travaux peut être représentée sous la forme d'une
arborescence. En voici un exemple :

34. 34

35. 35
Comme pour une arborescence PBS, cette arborescence WBS se lit comme suit :
 en descendant, le trait signifie «est composé de»,
 en montant, le trait signifie «lait partie de».
Cet exemple illustre les liens qui existent entre une PBS et une WBS. Les travaux relatifs à
une PBS sont articulés autour des composantes du produit.
Dans une gestion de projet, un code WBS associé à une tâche permet d'établir des tableaux de
bord structurés par niveau de détail. Voici, par exemple, un planning complet du projet
précédent :

36. 36

37. 37
L'utilisation des codes WBS permet de structurer le planning par niveau de WBS. Le résultat
est un ensemble de plannings dont le schéma qui suit reprend le niveau général.
A un niveau intermédiaire de détail, voici le planning de «réalisation du sous-système 2 »

38. 38
Voici enfin, au niveau de détail le plus fin, l'exemple du planning de la réalisation de
l'ensemble 21 :

39. 39
La structure des travaux WBS permet en particulier de structurer les plannings (comme le
montre l'exemple qui précède), mais aussi les plans de charge et les budgets. Cet aspect
structurant est ce que l'on voit de la fonction WBS dans les outils logiciels de gestion de
projets.

40. 40
Mais le formalisme WBS a bien d'autres usages. Associé à des procédures d'analyse, il permet
également de formaliser l'ensemble (tel qu'il est connu à un moment donné) des tâches d'un
projet.
Un problème majeur de la gestion d'un projet est d'identifier tout ce qui est à faire dans le
projet.
Une des causes principales de dérives dans un projet est tout simplement que des travaux à
mener n'avaient pas été vus, et donc n'avaient pas été prévus.
Il n'est pas rare que 30% de la charge de travail d'un projet représentent des tâches qui
n'avaient pas été identifiées assez tôt dans le déroulement du projet.
Le formalisme WBS, qui est simple, permet de voir et confronter l'ensemble des travaux que
l'on prévoit pour un projet. Il permet de mener des revues de projet.
Les tâches directement liées à l'élaboration des composantes du produit final ne posent pas de
problème majeur en pratique.

41. 41
Par contre les tâches annexes sont souvent mal vues, voire omises. Par exemple :
 les tâches de logistique,
 la mise en place des moyens de développement,
 les expérimentations nécessaires,
 la négociation des marchés de sous-traitance,
 la préparation des environnements de test,
 la mise en place ou le déploiement du produit final,
 etc.
Les travaux de ce genre dépendent de toute évidence de l'entreprise ou du contexte du projet.
Pour une même entreprise, ou pour un contexte donné, les différents projets menés ont bien
souvent en commun de telles tâches.
A partir de ce constat, une approche consiste à établir une liste exhaustive de tous les travaux
qui peuvent faire partie d'un projet.
Cette liste structurée (utilisée comme canevas pour établir la WBS d'un projet à venir) est
appelée la WBS-type.

42. 42
Une WBS-type se présente comme le sur-ensemble des travaux qui peuvent se trouver dans
un projet (hors tâches directement liées à l'élaboration de composantes du produit final), et
non comme le dénominateur commun.
Autrement dit, si une tâche peut apparaître dans quelques projets sans pour autant être
systématique, cette tâche est placée dans la WBS-type.
Le principe sous-jacent est le suivant :
« Il est plus facile d’enlever d'une liste exhaustive des éléments qui ne s'appliquent pas au
projet analysé plutôt que d'ajouter des éléments spécifiques à une liste minimale. »
L'ensemble des procédures et des moyens utilisés dans une entreprise pour parvenir à la WBS
d'un projet s'appelle la méthode WBS.

43. 43

44. 44
OBS (Organisation Breakdown Structure)
La Structure de Décomposition de l'Organisation ou OBS (Organisation Breakdown Structure
en anglais) est la représentation des acteurs d'un projet ainsi que de leurs rôles respectifs.
Le premier volet de l'OBS est l'identification de qui fait quoi dans le projet. En somme,
quelles sont les ressources humaines.
Du point de vue de la gestion du projet, quels sont les calendriers. Les calendriers de

45. 45
ressources sont un élément clé de l'établissement des plannings et des plans de charge.
Vient ensuite l'identification des responsabilités pour chacun des éléments de la WBS.
Pour la gestion du projet, le responsable d'un travail est la personne (ou plus généralement
l'entité) qui déclare le travail terminé, le moment venu.
Une façon de représenter les responsabilités dans un projet consiste à indiquer le nom du
responsable sur chaque case de la WBS.
Une structure WBS ainsi complétée par l'indication des responsabilités est parfois appelée
«organigramme technique».
Attention : selon les contextes le terme «organigramme technique» a des acceptions qui
diffèrent :
 parfois, il s'agit seulement de la WBS,
 parfois, il s'agit de la WBS complétée par l'indication des responsabilités,
 parfois enfin, il s'agit d'une liste structurée des travaux, des responsabilités et des
moyens.

46. 46
L'identification de qui est responsable de qui (autrement dit, la hiérarchie de l'entreprise ou du
montage industriel) permet des niveaux de synthèse des tableaux de bord.
Pour la gestion du projet, il s'agit là d'une facilité de regroupement d'informations.
La structure des liens hiérarchiques est appelée RBS (Resource Breakdown Structure) ou
Structure de Décomposition des Ressources.
Dans la pratique des projets, l'identification de «qui fait quoi» et de «qui est responsable de
quoi» s'avère souvent insuffisante.
Il existe de fait d'autres types de rôles dans un projet : par exemple, celui qui consiste à
«approuver» ou à «accepter» le résultat d'un travail.
L'identification de ces autres rôles fait assurément partie de la conduite d'un projet mais sort
du cadre de la gestion de projets tel qu'il est défini dans ce module de formation.

47. 47

48. 48
Le réseau
Le réseau reprend l'ensemble des hypothèses de liens, de durées, de charges, de ressources, de
priorités posées sur les tâches du projet. Une grande partie de ce module est illustrée par le
réseau suivant :
La forme du réseau peut varier. Lorsqu'un logiciel de gestion de projets est utilisé (ce qui est
de plus en plus le cas), la mise en forme des hypothèses se présente sous la forme de
documents de saisie informatique spécifiques au logiciel. La présentation sous forme d'un
réseau dessiné est l'une des sorties du logiciel destinée en particulier à permettre une
validation visuelle rapide des informations saisies.

49. 49

50. 50
Le scénario résultant
Le réseau est traité par une technique de planification.
Le résultat est un ensemble de plannings et de plans de charge.
La transition d'un réseau à un scénario est effectuée selon une technique de planification ou
une autre.
A noter que selon la technique mise en œuvre, le résultat n'est pas constant.
Il est très rare que la présentation d'un scénario de projet soit accompagnée de la description
de la technique utilisée.
C'est pourtant une information importante pour prévoir le comportement du scénario en cas de
modification des hypothèses.

51. 51
L'établissement du tableau de marche
Dans la pratique, le scénario obtenu ne convient jamais (délais trop grands, ressources mal
employées, ou autre).
De nouveaux scénarios sont alors établis, à partir d'autres hypothèses. Par exemple :
 modification de priorités (changement du réseau),
 modification des ressources (changement de l'OBS),
 modification des tâches (par exemple, reprise d'un existant),
 voire modification de la définition du produit.
Les modifications suivent alors le chemin suivant :

52. 52

53. 53
Les différents formalismes représentent les couches de plus en plus profondes sur lesquelles
s'appuie un scénario :
 modifier une priorité est un ajustement technique,
 affecter de nouvelles ressources relève du responsable du projet,
 modifier un scénario requiert en général l'accord du «client» du projet,
 quant au changement de l'objectif (le produit), une telle décision peut remettre en cause
l'existence même du projet.
Les outils utilisés pour établir le scénario et l'habileté du gestionnaire du projet permettent de
parvenir plus ou moins rapidement au tableau de marche.
De toute évidence, plus le projet est complexe et plus l'établissement du tableau de marche
peut prendre de temps. En pratique, entre trois et six tentatives permettent de conclure.

54. 54
Pour résumer
Voici un schéma qui présente l'articulation des différents formalismes et transitions en gestion
de projets :

55. 55
Le point de départ est la PBS (pour qu'il y ait projet, il doit y avoir produit).
L’assurance qualité définit les travaux, étapes (WBS) et rôles (OBS) du projet.
Elle induit également la forme et la nature de la documentation du projet. La liste des
documents prévus pour le projet est le plan de documentation.
La gestion de configurations est la gestion de la cohérence entre différentes versions de
composantes du produit, entre différentes versions de documents techniques et entre versions
de composantes de produit, versions de documents techniques et versions des moyens
techniques.
Les logiciels de gestion de projets disposent de moyens plus ou moins développés selon les
logiciels pour assister les utilisateurs dans rétablissement de la WBS et l'OBS d'un projet.
Le calcul d'un scénario est la fonction centrale d'un tel outil logiciel. Il doit rester bien clair
que les techniques mises en œuvre varient d'un logiciel à l'autre.
Le suivi d'avancement diffère d'un logiciel à l'autre, mais tous offrent des possibilités de suivi.
Les fonctions de gestion d'un historique de projet consistent à archiver des vues successives

56. 56
de l'avancement d'un projet:
L'objectif de l'historique d'un projet est la constitution à la fin du projet d'un bilan du projet.
Les bilans de projets passés peuvent ensuite faire l'objet d'analyses statistiques permettant de
modéliser, et donc d'estimer de nouveaux projets.

57. 57
2. GUIDE D'AUDIT DE GESTION D'UN PROJET
Les paragraphes qui suivent présentent la trame des points à analyser lors de l'audit d'une
gestion de projets ou lors de la mise en place d'une gestion de projets.
Le choix d'un outil logiciel de gestion de projets découle des conclusions d'une telle analyse.

58. 58

59. 59
PBS
Le produit est-il assez clairement défini pour être représenté sous la forme d'une arborescence
PBS ?
Les niveaux de composantes du produit correspondent-ils bien aux niveaux définis par
l'entreprise ou le consortium dans laquelle ou lequel le projet a lieu ?
WBS
La Structure de Décomposition des Travaux a-t-elle fait l'objet d'une revue avec des «yeux
neufs» ? Qu'est ce qui a été oublié ?
WBS-type
Existe-t-il une WBS-type dans l'entreprise ou pour cette catégorie de projets ? Quand et
comment est-elle mise à jour ?
Niveau de détail géré
Quel est le niveau de détail le plus fin pour une tâche ?

60. 60
Le niveau de détail est très souvent trop fin (ce qui augmente la charge de gestion du projet
sans pour autant fournir une vue plus juste de l'avancement). Voici quelques points de repère :
 un rapport de un à dix entre le «pas de planification» (le degré d'imprécision du logiciel
de gestion de projets) et la taille minimale d'une tâche,
 moins de cinq tâches par intervenant entre deux points d'avancement,
 La taille minimale d’une tâche est déterminée par la quantité de travail qui, une fois
déclenchée, se déroule jusqu’à sa fin sans intervention extérieure.
Attention au fait qu’une tâche doit se terminer par un événement ou par un produit
intermédiaire mesurable.
OBS
Connaît-on tous les acteurs du projet ? Qui a été oublié ?
Ressources
La représentation des ressources est-elle homogène dans le projet ?

61. 61
La disponibilité des ressources pour le (ou les) projets(s) ne prend pas en compte une part du
temps et de l'activité des ressources. L'indisponibilité des ressources est traitée soit comme
une réduction de la disponibilité, soit comme des tâches prioritaires dans les projets. Cette
différence est-elle bien la même pour toutes les ressources ?
Fait-on bien la différence entre gestion de projets et gestion de l'activité ?
Calendriers
Quelle partie du temps des ressources est traitée comme réduction de la disponibilité ?
Tâches gérées
Quelle partie du temps des ressources est traitée comme tâches prioritaires ?
Responsabilités
Où sont les responsabilités partagées ?

62. 62
Réseau
Les liens représentent-ils bien des contraintes techniques ? Qui a revu la logique de l'ensemble
?
Affectation des priorités
Les valeurs des priorités correspondent-elles à une échelle préalablement établie pour
l'entreprise ?
Comment sont déterminées les priorités entre projets (en gestion multi-projets) ?
Qui détermine les priorités des travaux ? Qui peut les modifier ?
Estimation des charges
Qui estime les charges de travail ? Qui accepte ces estimations ? Quelles techniques ou quels
modèles sont utilisés ?

63. 63
Estimation des durées
Comment sont évaluées les durées ?
Comment une durée peut être modifiée pendant le déroulement du projet ?
Planification
Qui établit le tableau de marche ?
Quelle dose d'imprévus est prise en compte ?
Outil
Quel outil logiciel de gestion de projets est utilisé ? Quelle technique est utilisée pour
annoncer des délais ?
Procédure d'acceptation
Qui fixe la durée du projet ? Qui la modifie ?
Qui met les moyens nécessaires à la disposition du chef du projet ?

64. 64
Suivi
Quelle(s) métrique(s) de suivi de l'avancement est (sont) adoptée(s) ?
Saisie de l'avancement
Qui rend compte de quoi ? à qui ? à quelle fréquence ?
Validation de l'avancement
Qui vérifie que l'avancement annoncé est correct ?
Attention : cette question ne signifie pas du tout une présomption de mauvaise foi, mais que la
saisie de l'avancement comporte systématiquement des erreurs (comme toute procédure de
circulation d'informations). Une erreur de saisie de l'avancement peut se traduire par une
apparence de dérive du projet et déclencher des actions correctives sur le projet. Dans ce cas,
la seule action corrective à mener est de corriger la saisie. Encore faut-il pouvoir localiser
les erreurs.

65. 65
Calcul des dérives
Comment est déterminé l'impact d'un point d'avancement sur les prévisions du projet ?
Corrections
Lorsqu'un point d'avancement met en lumière une dérive probable, qui fait quoi ?
Circulation de l'information
Qui a accès à quelle information de gestion du projet pendant le déroulement du projet ?
Historique
Existe-t-il une volonté de l'entreprise de constituer une mémoire de ses projets ?
Contenu
Les différentes variables qui caractérisent les projets sont-elles définies de façon claire,
complète et non ambiguë ? Les différents chefs de projet connaissent-ils tous la signification
de ces variables ?

66. 66
Variables produit
Quelles variables produit constituent l'historique des projets ?
Une variable produit caractérise le produit issu du projet. En voici des exemples :
 la taille,
 la masse,
 un taux de défaillance,
 etc.
Variables projet
Quelles variables projet constituent l'historique des projets ?
Une variable projet caractérise le déroulement du projet. En voici des exemples :
 l'environnement de réalisation,
 le coût du projet,
 l'expérience des équipes,
 etc.

67. 67
Variables processus
Quelles variables processus constituent l'historique des projets ?
Une variable processus caractérise l’écart entre le déroulement prévu du projet et la réalité du
projet. En voici des exemples :
 changement du client du projet,
 défaillance d’un sous-traitant,
 modification en cours du projet du cahier des charges,
 etc.
Procédure de collecte
Oui renseigne quoi dans l'historique ? Qui assure la cohérence de l'historique ?
Exploitation
Qui analyse quand l'historique des projets ? avec quelles techniques d'analyse de données ?

68. 68
LACONDUITEDEPROJET
LEFORMALISMERESEAU
La présentation des techniques de planification de tâches et des techniques d'ordonnancement
de ressources s'appuie sur une représentation des tâches dite «potentiel tâches» qui est la plus
couramment utilisée.
Certains logiciels utilisent aussi une autre représentation dite «potentiel événements».
Mais dans la pratique ils utilisent également la représentation «potentiel tâches».
Chaque tâche d'un projet est représentée par une barre.
L'extrémité gauche de la barre représente le début de la tâche, l'extrémité droite la fin :

69. 69
La longueur de la barre est indépendante de la durée de la tâche : cette représentation n'est pas
un planning à barres ; elle est simplement utilisée pour marquer la logique (c'est-à-dire
l'enchaînement) des tâches.
Un projet est composé de plusieurs tâches qui sont reliées les unes aux autres.
Un lien (ou une dépendance, ces deux termes sont synonymes) est une relation entre deux
tâches représentée par une flèche.
Un réseau (on dit aussi «réseau logique») est un ensemble de tâches et de liens représenté par
un ensemble de barres et de flèches. Voici un exemple de lien :

70. 70
Ce lien signifie que la tâche S peut débuter lorsque la tâche A est terminée. Pour ce lien, la
tâche A est dite l'«antécédent», et la tâche S le «successeur».
Le terme «antécédent» signifie «point de départ d'un lien».
Le terme «successeur» signifie «point d'arrivée d'un lien».
Dans certains cas, l'antécédent se trouve chronologiquement avant son successeur, mais dans
d'autres, il se trouve en parallèle ; enfin il arrive que l'antécédent doive avoir lieu après son
successeur. Les exemples suivants vont le montrer.
Les notions d'antécédent et de successeur sont des notions topologiques et non pas
chronologiques.

71. 71
1. LES TYPES DE LIENS
Un lien est une relation entre le début ou la fin d'un antécédent et le début ou la fin d'un
successeur.
Il existe quatre types de liens (classés du plus fréquent au plus rare) :
 fin à début (de la fin de l'antécédent au début du successeur),
 début à début (du début de l'antécédent au début du successeur),
 fin à fin (de la fin de l'antécédent à la fin du successeur),
 début à fin (du début de l'antécédent à la fin du successeur).
Ces différents types de liens sont présentés ci-après.

72. 72
Liens de type «fin à début»
Les liens de type «fin à début» sont les plus fréquents (environ 90% des liens effectivement
rencontrés dans les réseaux). L'exemple précédent de lien est de type «fin à début» :
Il signifie : la tâche S (le successeur) peut débuter lorsque la tâche A (l'antécédent) est
terminée. Il ne signifie pas que la tâche S doit débuter lorsque la tâche A est terminée. La
tache S débute à la fin de la tâche A ou plus tard.
Un exemple de lien de type «fin à début» :
 la tâche A représente la pose de la charpente d'une maison,
 la tâche S représente la pose de la couverture,
 le lien signifie que la couverture ne peut pas être posée tant que la charpente n'est pas
terminée.

73. 73
Liens de type «début à début»
Environ 5% des liens rencontrés dans les réseaux sont des liens de type «début à début». En
voici un exemple :
II signifie : la tâche S (le successeur) peut débuter lorsque la tâche A (l'antécédent) est
commencée. La tâche S débute au début de la tâche A ou plus tard. Dans ce cas, l'antécédent
et le successeur peuvent se trouver en parallèle.
Un exemple de ce type de lien :
 la tâche A représente une série d'entretiens,
 la tâche S représente la rédaction des comptes rendus,
 le lien signifie que la rédaction des comptes rendus peut commencer dès que la série
des entretiens a commencé (il n'est pas nécessaire d'attendre que le dernier entretien ait
eu lieu pour commencer à rédiger le compte rendu du premier).

74. 74
Les liens de ce type se rencontrent lorsque les tâches sont en fait des ensembles d'actions
élémentaires qui ne sont pas représentées chacune par une tâche. Au niveau le plus détaillé,
chaque compte rendu ne peut être rédigé qu'après l'entretien correspondant (liens de type «fin
à début»). Au niveau global de l'ensemble des entretiens et de l'ensemble des comptes rendus,
le lien est de type «début à début».
En toute rigueur dans cet exemple, il faudrait également noter que le dernier compte rendu ne
peut être rédigé qu'après le dernier entretien (lien de type «fin a fin»).

75. 75
Liens de type «fin à fin»
Les liens de type «fin à fin» sont aussi fréquemment rencontrés que les liens de type «début à
début». En voici un exemple :
II signifie : la tâche S (le successeur) peut se terminer lorsque la tâche A (l'antécédent) est
terminée. La tâche S se termine à la fin de la tâche A ou plus tard. Ici encore, l'antécédent et le
successeur peuvent se trouver en parallèle.
Un exemple de ce type de lien :
 la tâche S représente une course autour du monde,
 la tâche A représente la préparation des prix,
 le lien signifie que les prix doivent être prêts pour la fin de la course.

76. 76
Liens de type «début à fin»
Les liens de type «début à fin» sont très rares dans les réseaux de projets, En voici un
exemple:
Il signifie : la tâche S (le successeur) peut se terminer lorsque la tâche A (l'antécédent) est
commencée. La tâche S se termine au début de la tâche A ou plus tard. Dans ce cas, le
successeur peut se trouver chronologiquement avant l'antécédent. Un exemple de ce type de
lien :
 la tâche A représente l'exploitation d'un nouveau réseau de télécommunication,
 la tâche S représente l'exploitation de l'ancien réseau,
 le lien signifie que l'ancien réseau doit être exploité jusqu'à ce que le nouveau soit
opérationnel.
Les liens de ce type sont fréquents en gestion de maintenance. Ils apparaissent en gestion de
projets pour prendre en compte des évolutions de logistique qu'il est plus simple de gérer
comme des tâches plutôt que comme des ressources.

77. 77
Délais
Un lien est une relation entre deux événements : le début ou la fin de l'antécédent, et le début
ou la fin du successeur.
Le lien signifie : l'événement successeur peut avoir lieu en même temps que l'événement
antécédent ou après (autrement dit, pas avant).
Un lien peut également être caractérisé par une valeur (positive ou négative) : le délai du lien.
Le délai indique la durée minimale (en valeur algébrique) qui doit séparer l'événement
successeur de l'événement antécédent.
Dans l'exemple de lien de type «début à début», la tâche S de rédaction des comptes rendus
pouvait débuter dès le début de la tâche A de conduite de la série des entretiens.
En réalité, le premier compte rendu ne peut être rédigé qu'après le premier entretien qui dure
un jour, par exemple. En conséquence, la tâche S ne peut réellement débuter qu'un jour après
le début de la tâche A. Le lien de type «début à début» doit donc être caractérisé par un délai
d'un jour, ce qui se représente comme suit :

78. 78
Ce lien (désormais caractérisé par un délai) se lit ainsi : la tâche S peut débuter un jour après
le début de la tâche A, ou après.
Le délai permet d'indiquer une période d'attente, et évite de créer une tâche fictive
intermédiaire, ce qui se traduirait de la façon suivante :

79. 79
Un délai négatif sur un lien permet d'indiquer que l'événement successeur peut avoir lieu
avant l'événement antécédent. Par exemple, la pose de la couverture d'une maison peut
commencer un jour avant la fin de la pose de la charpente :
Un délai positif est appelé un retard (en anglais un «lag»). Un délai négatif est appelé une
avance (en anglais un «lead»).
Les délais de liens peuvent être exprimés en unités de temps (jours calendaires, jours ouvrés,
semaines, mois, etc.) ou parfois aussi en pourcentage de l'antécédent. Par exemple, dire que la
tâche S peut débuter alors qu'il ne reste que 10% de la tâche A à faire se représente comme
suit :

80. 80
Le délai d'un lien est toujours explicite. Une représentation oblique de la flèche ne signifie pas
un délai. Autrement dit, les représentations suivantes sont équivalentes :

81. 81
Exemples
Voici des exemples de traduction de phrases en termes de liens.
Lien de type «fin à fin» avec pour antécédent, la tâche A, et pour successeur, la tâche B.
Lien de type «fin à début» avec pour antécédent, la tâche A, et pour successeur, la tâche B.

82. 82
Lien de type «début à fin» avec pour antécédent, la tâche A, et pour successeur, la tâche B.
Lien de type «début à début» avec pour antécédent, la tâche B, et pour successeur, la tâche A.

83. 83
Lien de type «fin à début» avec pour antécédent, la tâche A, pour successeur, la tâche B, et un
délai de - 50%.
Ou bien,
Lien de type «début à début» avec pour antécédent, la tâche A, pour successeur, la tâche B, et
un délai de +50%.

84. 84
Lien de type «fin à début» avec pour antécédent, la tâche A, pour successeur, la tâche B, et
avec un délai de +2 jours.
Combinaisons de liens
Les différentes tâches d'un réseau sont reliées les unes aux autres par des liens. Toutes les
combinaisons de liens sont possibles sauf une : la boucle (en anglais «loop»). En voici un
exemple :

85. 85
Un antécédent ne peut pas être le successeur de son successeur (direct ou indirect). Cet
exemple se comprend de lui-même.
Voici un autre exemple qui pourrait avoir un sens rationnel, mais qui n'est pas admissible :
Une caractéristique systématique des logiciels de gestion de projets est de pouvoir détecter les
boucles dans un réseau. Lorsqu'une boucle est détectée, le réseau doit être modifié pour la
faire disparaître.

86. 86
2. ETUDE DE CAS DE LA PREPARATION D'UN LANCEMENT ARIANE 4
L'établissement d'un réseau est illustré par la préparation d'un lancement Ariane 4.
Ce projet, qui est appelé dans ce cas une «campagne», est constitué de plusieurs centaines de
tâches élémentaires (appelées «opérations»).
Les «opérations» ont été ici regroupées en ensembles de tâches, représentés chacun par un
rectangle et non pas par une barre. Les durées apparaissent à l'intérieur des rectangles (en haut
à droite).
Les liens entre rectangles sont tous du type «fin à début».
Le type des liens n'est pas explicité sur le diagramme qui suit. Certains liens sont caractérisés
par un délai qui apparaît de façon explicite dans un cercle proche de la flèche qui représente le
lien.

87. 87

88. 88
La partie gauche du diagramme représente l'ensemble des opérations de préparation du
lanceur lui-même (le terme consacré pour désigner Ariane est «lanceur» et non pas «fusée») :
il s'agit de la «campagne lanceur».
La partie droite du diagramme représente l'ensemble des opérations de préparation d'un
satellite : c'est la «campagne satellite».
Lorsqu'il y a plusieurs satellites pour un vol (le cas nominal est de deux satellites), il y a
autant de «campagnes satellite» que de satellites.
Ces différentes «campagnes satellite» constituent des branches parallèles du réseau qui
convergent toutes sur la tâche : «plan des opérations combinées».

89. 89
LACONDUITEDEPROJET
TECHNIQUESDEPLANIFICATIONDETACHES
Les techniques de planification de projets traitent de tâches et (fréquemment) de ressources.
Elles permettent de déterminer des dates de début et de fin de tâches (autrement dit des
plannings).
Dans la pratique, deux approches existent :
 la première consiste à partir des tâches puis à organiser les ressources par rapport aux
tâches : les techniques qui suivent cette approche sont dites alors techniques de
planification de tâches,
 la seconde consiste à partir des ressources puis à ordonnancer les tâches en fonction des
ressources disponibles : les techniques issues de cette approche sont dites techniques
d'ordonnancement de ressources.

90. 90
Ce chapitre traite des techniques de planification de tâches. Le suivant des techniques
d'ordonnancement de ressources.
1. PERT-TEMPS
1.1. Présentation
La technique PERT-temps consiste en une suite de quatre étapes :
 les dates «au plus tôt»,
 les dates «au plus tard»,
 les «marges»,
 le «chemin critique».
Les «dates au plus tôt» sont obtenues en traitant le réseau logique sur une échelle de temps qui
démarre à une date t0, et se déroule vers l'avenir.
Le calcul des «dates au plus tôt» correspond intuitivement à la question : si le projet démarre à
t0, quand se terminera-t-il? et quelles en seront les dates intermédiaires ?
Le terme de «dates au plus tôt» est consacré par l'usage.

91. 91
Cependant, sa signification en français courant est un peu différente dans la mesure où elle
englobe des significations du genre «si tout se passe bien ...» ou encore «si l'on va vite ...». Or
ces significations annexes n'ont, dans certains cas, rien à voir avec le calcul au plus tôt de
PERT-temps (des exemples de ce chapitres vont le montrer).
C'est pour cette raison que le terme «dates au plus tôt» est parfois remplacé par «dates avant»
(temps déroulé de t0 vers l'avant).
Les «dates au plus tard» sont obtenues en traitant le réseau logique sur une échelle de temps
qui démarre à une date tf et se déroule vers le passé.
Le calcul des «dates au plus tard» correspond intuitivement à la question : si le projet doit se
terminer à tf, quand doit-il démarrer ? et quelles en seront les dates intermédiaires ?
La encore, le terme de «dates au plus tard» est consacré par l'usage. En français courant,
l'expression au plus tard est associée à des sens du genre «au pire ...» ou encore «dernier délai
...». Ces sens communs n'ont, dans certains cas, rien à voir avec le calcul au plus tard de
PERT-temps (voir exemples plus loin).
Voilà pourquoi le terme «dates au plus tard» est parfois remplacé par «dates arrière» (temps

92. 92
déroulé de tf vers l'arrière).
La marge de chaque tâche est définie comme la différence entre la date de début au plus tard
de la tâche et sa date de début au plus tôt.
Le calcul des marges ne peut être effectué qu'après un calcul au plus tôt et un calcul au plus
tard. Il nécessite de rapprocher les deux calculs, autrement dit, de faire correspondre les deux
échelles de temps (celle au plus tard et celle «au plus tôt»).
Là encore, attention à une interprétation intuitive du genre «si une tâche n'a pas de marge, elle
ne peut pas prendre de retard sans décaler tout le projet» (voir exemples plus loin).
Le «chemin critique» est défini comme l'ensemble (et non pas la succession !) des tâches dont
la marge est nulle.
Ce n'est rien de plus. Et en tout cas pas systématiquement une chaîne de tâches qui constitue
le plus long chemin minimum entre le début et la fin du projet.
1.2. Exemple de traitement
Voici un exemple du fonctionnement de la technique PERT-temps. Le réseau exemple à

93. 93
traiter est le suivant :
Ce réseau composé de quatre tâches (A qui dure 10 jours, B qui dure 20 jours, C qui dure 10
jours et D qui dure 10 jours) se lit de la façon suivante :
 la tâche B ne peut commencer que lorsque la tâche A est terminée,
 la tâche C ne peut commencer que lorsque la tâche A est terminée,
 la tâche D ne peut commencer que lorsque la tâche B est terminée et lorsque la tâche C
est terminée.

94. 94
Réseau exemple — dates au plus tôt
Dans le calcul au plus tôt, le temps est déroulé dans le sens naturel ; en conséquence, la
succession des états de chaque tâche est le suivant :
 la tâche n'est pas encore commencée,
 début de la tâche,
 la tâche est en cours,
 fin de la tâche,
 la tâche est terminée.
Les tâches du réseau exemple doivent être placées sur une échelle de temps qui démarre à t0 et
qui se poursuit vers l'avenir.
Le traitement du réseau va être illustré par le déplacement d'un pointeur, qui se trouve au
point t0 en début de calcul et qui avance dans le temps au fur et à mesure que se déroule le
calcul «au plus tôt».

95. 95
L'examen du réseau montre que la tâche A peut commencer à t0. Les tâches B et C ne peuvent
commencer que si la tâche A est terminée (comme la durée de la tâche A n'est pas nulle, ni la
tâche B ni la tâche C ne peuvent démarrer à t0). Quant à la tâche D, elle ne peut commencer
que lorsque les tâches B et C sont terminées : la tâche D ne peut donc pas commencer à la
date t0.
En conclusion, seule la tâche A peut démarrer à la date t0.
De plus, la tâche A dure 10 jours. Il doit donc s'écouler 10 journées avant que la tâche A ne se

96. 96
termine, pendant lesquels rien d'autre ne peut avoir lieu.
Le pointeur se trouve alors au point t0+10 jours.
Au point t0 + 10 jours, la tâche A est terminée.
Selon les indications du réseau, les tâches B et C peuvent alors commencer. Quant à la tâche
D, elle ne peut commencer que lorsque les tâches B et C sont terminées : la tâche D ne peut
donc pas commencer à la date t0 + 10 jours (car les tâches B et C ne sont pas toutes les deux
de durée nulle).

97. 97
Au point t0 + 20 jours, la tâche C est terminée. Cependant, la tâche D ne peut toujours pas
commencer car il faut pour cela que les tâches B et C soient terminées (or la tâche B qui dure
20 jours n'est toujours pas terminée).
A ce point t0 + 20 jours, rien ne se produit et le pointeur continue d'avancer.

98. 98
Le point t0 + 30 jours marque la fin de la tâche B. La tâche D peut alors commencer.

99. 99
Au point t0 + 40 jours, la tâche D se termine, et comme toutes les tâches du réseau exemple
ont été traitées, le calcul au plus tôt s'arrête.
Chacune des tâches du réseau exemple est alors caractérisée par une date de début au plus tôt
et par une date de fin au plus tôt.
Réseau exemple - dates au plus tard
Dans le calcul au plus tard, le temps est déroulé dans le sens inverse du sens naturel ; en
conséquence, la succession des états de chaque tâche est le suivant :
 la tâche est terminée,
 fin de la tâche,
 la tâche est en cours,
 début de la tâche,
 la tâche n'est pas encore commencée.
Les tâches du réseau exemple doivent être placées sur une échelle de temps qui démarre à tf et
qui se déroule vers le passé.
Le traitement du réseau va être illustré par le déplacement d'un pointeur, qui se trouve au

100. 100
point tf en début de calcul et qui remonte dans le temps au fur et à mesure que se déroule le
calcul «au plus tard».
L'examen du réseau montre que la tâche D peut se terminer à tf. Les tâches B et C ne peuvent
se terminer que si la tâche D est commencée (comme la durée de la tâche D n'est pas nulle, ni
la tâche B ni la tâche C ne peuvent se terminer à tf).
Quant à la tâche A, elle ne peut se terminer que lorsque les tâches B et C sont commencées :
la tâche A ne peut donc pas se terminer à la date tf.
En conclusion, seule la tâche D peut se terminer à la date tf.

101. 101
De plus, la tâche D dure 10 jours. Il doit donc s'écouler 10 journées avant que la tâche D ne
commence, pendant lesquels rien d'autre ne peut avoir lieu.
Le pointeur se trouve alors au point tf - 10 jours.
Au point tf - 10 jours, la tâche D commence.
Selon les indications du réseau, les tâches B et C peuvent alors se terminer.
Quant à la tâche A, elle ne peut se terminer que lorsque les tâches B et C sont commencées :
la tâche A ne peut donc pas se terminer à la date tf -10 jours (car les tâches B et C ne sont pas

102. 102
toutes les deux de durée nulle).
Au point tf - 20 jours, la tâche C commence.
Cependant, la tâche A ne peut toujours pas se terminer car il faut pour cela que les tâches B et
C soient commencées (or la tâche B qui dure 20 jours n'est toujours pas démarrée).
A ce point tf - 20 jours, rien ne se produit et le pointeur continue de remonter dans le temps.

103. 103
Le point tf - 30 jours marque le début de la tâche B. La tâche A peut alors se terminer.

104. 104
Au point tf - 40 jours, la tâche A débute, et comme toutes les tâches du réseau exemple ont été
traitées, le calcul au plus tard s'arrête.
Chacune des tâches du réseau exemple est alors caractérisée par une date de début au plus tard
et par une date de fin au plus tard.
Réseau exemple — calcul des marges et chemin critique
La date de fin du calcul au plus tôt pour le réseau exemple est t0 + 40 jours.
La date de fin du calcul au plus tard pour le réseau exemple est tf - 40 jours.
Dans les deux cas, la durée totale est de 40 jours.

105. 105
Le fait que la durée totale au plus tôt soit la même que la durée totale au plus tard est une
règle générale qui s'applique dans tous les cas sauf lorsqu'il y a des dates imposées (les dates
imposées sont couvertes plus loin).
L'étape du calcul des marges s'appuie sur une mise en correspondance des deux échelles de
dates au plus tôt et au plus tard :
Le graphique indique une correspondance :

106. 106
 d'une part, entre le point de départ de dates au plus tôt (t0) et le point d'arrivée des dates
au plus tard (tf - 40 jours),
 d'autre part, entre le point de départ de dates au plus tard (tf) et le point d'arrivée des
dates au plus tôt (t0 + 40 jours).
Dans le cas présent, les deux correspondances sont identiques (ce qui provient du fait que le
réseau exemple ne comporte pas de date imposée).
Dans le cas général, la correspondance est prise entre le point de départ des dates au plus
tard (tf) et le point d'arrivée des dates au plus tôt (t0 + n jours). Ce n’est qu'une convention,
mais elle est très largement suivie.
La correspondance entre le point de départ des dates au plus tard (tf) et le point d'arrivée des
dates au plus tôt (t0 + n jours) est également nommée «rapprochement des échelles» (sous-
entendu, rapprochement de l'échelle au plus tard et de l'échelle au plus tôt).
Ce rapprochement permet de comparer les dates au plus tard et les dates au plus tôt.
Par définition, la marge de chaque tâche est la différence entre sa date de début au plus tard et
sa date de début au plus tôt.

107. 107
Ainsi, pour le réseau exemple, les marges sont les suivantes:
L'établissement du chemin critique devient une extraction selon le critère d'une marge nulle :

108. 108
Dans le cas du réseau exemple, le chemin critique représente effectivement un chemin, et
toute tâche critique (c'est-à-dire toute tâche appartenant au chemin critique) qui s'allongerait
d'un jour causerait également un allongement d'un jour de l'ensemble.
Ces deux caractéristiques ne sont vraies que grâce à la condition suivante : le réseau exemple
ne contient que des liens de type «fin à début».
Ce qui n'est pas toujours le cas comme le montre le réseau suivant.

109. 109
1.3. Pratique de la technique
Voici l'exemple choisi pour illustrer la pratique du traitement d'un réseau :

110. 110
Ce réseau, constitué de dix tâches, se lit ainsi :
 pour que la tâche B puisse commencer, il faut que la tâche A soit commencée,
 pour que la tâche B puisse se terminer, il faut que la tâche A soit terminée,
 pour que la tâche C puisse commencer, il faut que la tâche A soit terminée,
 pour que la tâche D puisse commencer, il faut que la tâche A soit terminée,

111. 111
 pour que la tâche E puisse commencer, il faut que la tâche B soit terminée,
 pour que la tâche F puisse commencer, il faut que la tâche C soit terminée et que la
tâche D soit terminée,
 pour que la tâche G puisse commencer, il faut que la tâche D soit terminée et que la
tâche E soit terminée,

112. 112
 pour que la tâche H puisse commencer, il faut que la tâche G soit commencée,
 pour que la tâche J puisse commencer, il faut que la tâche H soit terminée,

113. 113
 pour que la tâche I puisse commencer, il faut que la tâche F soit terminée et pour que la
tâche I puisse commencer, il faut que la tâche G soit terminée et pour que la tâche I
puisse se terminer, il faut que la tâche J soit terminée.
Voici maintenant le traitement de ce réseau par la technique PERT-temps : les dates au plus
tôt (de t0 vers l'avenir), puis les dates au plus tard (de tf vers le passé), puis le rapprochement
des échelles de temps entre ces deux calculs pour le calcul des marges et l'identification du
chemin critique.

114. 114
Dates au plus tôt
L'examen du réseau montre que la tâche A peut commencer à la date t0. A la date t0, la tâche B
peut également démarrer car, d'une part, le lien «début à début» est bien respecté, et d'autre
part, comme la durée de la tâche B est supérieure à celle de la tâche A, le lien «fin à fin» est
également respecté.

115. 115
Le pointeur peut alors avancer jusqu'à la date t0 + 10 jours, date de la fin au plus tôt de la
tâche A.
A la date t0 + 10 jours, les tâches C et D peuvent démarrer. La date t0 + 10 jours représente
alors le début au plus tôt des tâches C et D.

116. 116
Le pointeur peut alors avancer jusqu'à la date t0 + 15 jours, date de la fin au plus tôt de la
tâche B. A la date t0 + 15 jours, la tâche E peut démarrer car la tâche B est terminée.
Le pointeur peut alors avancer jusqu'à la date t0 + 25 jours, date de la fin au plus tôt de la

117. 117
tâche E.
A la date t0 + 25 jours, la tâche E est terminée. Comme la tâche D est également terminée
(depuis la date t0 + 15 jours), la tâche G peut démarrer. Comme la tâche G démarre à la date t0
+ 25 jours, la tâche H peut également démarrer à cette date.

118. 118
Le pointeur peut alors avancer jusqu'à la date t0 + 30 jours, date de la fin au plus tôt de la
tâche C.
A la date t0 + 30 jours, la tâche C est terminée. Comme la tâche D est également terminée
(depuis la date t0 + 15 jours), la tâche F peut démarrer.

119. 119
Le pointeur peut alors avancer jusqu'à la date t0 + 45 jours, date de la fin au plus tôt de la
tâche H.
A la date t0 + 45 jours, la tâche H est terminée et la tâche J peut démarrer.
Attention au fait que la tâche J, qui est un antécédent de la tâche I, doit être placée avant
celle-ci.

120. 120
Le pointeur peut alors avancer jusqu'à la date t0 + 65 jours, date de la fin au plus tôt de la
tâche J.
A la date t0 + 65 jours, la tâche J est terminée et la tâche I peut se terminer.
Si la tâche I se termine au plus tôt à la date t0 + 65 jours, elle démarre au plus tôt à la date t0 +
55 jours. Cette date de début au plus tôt de la tâche I respecte bien les deux autres liens qui
concernent la tâche I :
 «fin à début» de la tâche F vers la tâche I (la date de fin au plus tôt de la tâche F est t0 +
45 jours),
 «fin à début» de la tâche G vers la tâche I (la date de fin au plus tôt de la tâche G est t0
+ 50 jours).

121. 121
Le calcul au plus tôt s'arrête ici.

122. 122
Dates au plus tard
L'examen du réseau montre que la tâche I peut se terminer à tf. A tf, la tâche J peut également
se terminer en raison du lien «fin à fin».
Le pointeur peut alors remonter dans le temps jusqu'à la date tf -10 jours, date du début au
plus tard de la tâche I.

123. 123
A la date tf - 10 jours, la tâche F peuvent se terminer. La date tf -10 jours représente alors la
fin au plus tard de la tâche F.
Le pointeur peut alors remonter dans le temps jusqu'à la date tf -20 jours, date du début au
plus tard de la tâche J.

124. 124
A la date tf - 20 jours, la tâche II peut se terminer car la tâche J démarre à cette date au plus
tard.
Attention : la tâche G est un antécédent de la tâche H. La tâche G ne peut donc être placée
qu'en fonction de la tâche H.

125. 125
Le pointeur peut alors remonter dans le temps jusqu'à la date tf -25 jours, date du début au
plus tard de la tâche F.
A la date tf - 25 jours, la tâche F commence. La tâche C peut se terminer à cette date. La tâche
D (l'autre antécédent de la tâche F) ne peut pas encore être placée car la tâche G (l'autre
successeur de la tâche D) n'a pas encore été placée.
Le pointeur peut alors remonter dans le temps jusqu'à la date tf - 40 jours, date du début au

126. 126
plus tard de la tâche H.
A la date tf - 40 jours, la tâche H commence. La tâche G peut donc démarrer à cette date.
Comme la tâche G démarre à la date tf - 40 jours, les tâches D et E peuvent également se
terminer à cette date.
Le pointeur peut alors remonter dans le temps jusqu'à la date tf -50 jours, date du début au

127. 127
plus tard de la tâche E.
A la date tf - 50 jours, la tâche E démarre. La tâche B peut se terminer à cette date «au plus
tard».
Attention : la tâche A est un antécédent de la tâche B. La tâche A ne peut donc être placée
qu'en fonction de lu tâche B.
Le pointeur peut alors remonter dans le temps jusqu'à la date tf - 65 jours, date du début au

128. 128
plus tard de la tâche B.
A la date tf - 65 jours, la tâche B démarre et la tâche A peut alors également démarrer (en
raison du lien de type «début à début» de la tâche A vers la tâche B).

129. 129
Le calcul au plus tard s'arrête ici.
Marges et chemin critique
La première étape du calcul des marges est le rapprochement des échelles de temps au plus tôt
et au plus tard. Ce qui revient à trouver une relation entre t0 (le point de départ des dates au
plus tôt) et tf (le point de départ des dates au plus tard).

130. 130

131. 131
Le résultat du rapprochement des échelles est la relation :
tf = t0 + 65 jours
Cette relation permet d'exprimer les dates au plus tard en fonction de t0.
Dans le tableau qui suit chaque ligne représente une tâche.
Pour chacune des tâches, la date de début au plus tôt (issue du calcul au plus tôt) est indiquée
dans la colonne D+TOT (sous la forme t0 + n jours).
La date de début au plus tard (issue du calcul au plus tard) est indiquée dans la colonne
D+TARD (sous la forme tf - m jours).
La partie droite de la colonne D+tard est l'expression de la date de début au plus tard en
fonction de t0, selon la règle suivante :
tf - m jours = (t0 + 65 jours) - m jours
= t0 + (65 - m ) jours

132. 132
La dernière colonne du tableau, la colonne MAR, indique la marge de chaque activité.

133. 133
Représenté sous la forme de diagramme à barres, le chemin critique n'est pas un chemin dans
le sens commun du terme (une succession de tâches qui joigne le début à la fin), mais plutôt
une route à plusieurs voies.
C'est pourtant bien le chemin critique dans sa définition PERT-temps.

134. 134
L'exemple suivant montre comment interpréter le chemin critique d'un réseau et comment
éviter de mal l'interpréter.
1.4. Pratique du chemin critique
Une tâche critique (ce qui signifie une tâche qui fait partie du chemin critique) est souvent
interprétée comme une tâche qui, si elle s'allonge d'une journée, va allonger l'ensemble du
projet d'une journée.
Le chemin critique est alors également interprété comme la succession des tâches critiques du
projet.
Cette vue n'est vraie que dans des cas particuliers.
L'exemple qui précède montre un chemin critique qui n'est pas une simple succession. A
différents instants plusieurs tâches critiques ont lieu en parallèle.
L'exemple présenté maintenant porte sur un réseau identique à celui de l'exemple précédent
sauf en un point : la durée de la tâche I (qui faisait partie du chemin critique) passe de 10 jours
à 15 jours.

135. 135
Dates au plus tôt
L'analyse au plus tôt du réseau est la même que dans l'exemple précédent jusqu'à la date t0 +
45 jours, date à laquelle la tâche J peut être placée.
Il est toujours vrai que la tâche J, qui est un antécédent de la tâche I, doit être placée avant
celle-ci.

136. 136
Le pointeur est ensuite avancé jusqu'à la date t0 + 65 jours, date de la fin au plus tôt de la
tâche J.
A la date t0 + 65 jours, la tâche J est terminée et la tâche I peut se terminer.
Si la tâche I se termine au plus, tôt à la date t0 + 65 jours, elle démarre au plus tôt à la date t0 +
50 jours. Cette date de début au plus tôt de la tâche I respecte bien les deux autres liens qui
concerne la tâche I :

137. 137
 «fin à début» de la tâche F vers la tâche I (la date de fin au plus tôt de la tâche F est t0 +
45 jours),
 «fin à début» de la tâche G vers la tâche I (la date de fin au plus tôt de la tâche G est t0
+ 50 jours).
Le calcul au plus tôt qui s'arrête ici, aboutit à la même date de fin que l'exemple précédent.

138. 138
Dates an plus tard
Comme dans l'exemple précédent la tâche I peut se terminer à tf. A tf, la tâche J peut
également se terminer en raison du lien «fin à fin».
Le pointeur peut alors remonter dans le temps jusqu'à la date tf -15 jours, date du début au

139. 139
plus tard de la tâche I.
A la date tf - 15 jours, la tâche F peuvent se terminer. La date tf -15 jours représente alors la fin
au plus tard de la tâche F.
Le pointeur peut alors remonter dans le temps jusqu'à la date tf -20 jours, date du début au
plus tard de la tâche J.

140. 140
A la date tf - 20 jours, la tâche H peut se terminer car la tâche J démarre à cette date au plus
tard.
La tâche G est un antécédent de la tâche H. La tâche G ne peut donc être placée qu'en fonction
de la tâche H.
Le pointeur peut alors remonter dans le temps jusqu'à la date tf -30 jours, date du début au plus

141. 141
tard de la tâche F.
A la date tf - 30 jours, la tâche F commence. La tâche C peut se terminer à cette date.
La tâche D (l'autre antécédent de la tâche F) ne peut pas encore être placée car la tâche G
(l'autre successeur de la tâche D) n'a pas encore été placée.

142. 142
Le pointeur peut alors remonter dans le temps jusqu'à la date tf - 40 jours, date du début au
plus tard de la tâche H.
A la date tf - 40 jours, la tâche H commence. La tâche G peut donc démarrer à cette date. Avec
un début au plus tard de tf - 40 jours, la tâche G se termine au plus tard à la date tf - 15 jours,
ce qui respecte bien le lien de fin à début de la tâche G vers la tâche I.
Comme la tâche G démarre à la date tf - 40 jours, les tâches D et E peuvent également se
terminer à cette date.

143. 143
Le pointeur peut alors remonter dans le temps jusqu'à la date tf -50 jours, date du début au
plus tard de la tâche E.
A partir de ce point le calcul est le même que dans le cas précédent. La fin du calcul concerne
les tâches B et A.

144. 144
Le calcul au plus tard s'arrête à la date tf - 65 jours.
Marges et chemin critique
Le rapprochement des échelles de temps au plus tôt et au plus tard permet la relation entre t0
(Le point de départ des dates au plus tôt) et tf (le point de départ des dates au plus tard).

145. 145

146. 146
Le résultat du rapprochement des échelles est la relation :
tf = t0 +65 jours
Cette relation est la même que dans l'exemple précédent.
Autrement dit, le fait d'avoir allongé la tâche critique I de 5 jours ne modifie pas la durée du
projet.
Avec les mêmes conventions que dans l'exemple précédent, le tableau qui suit indique les
dates de début au plus tôt, les dates de début au plus tard (exprimées en fonction de t0 et en
fonction de tf , ainsi que les marges.

147. 147
La modification de la durée de la tâche I n'a pas changé le chemin critique. Seules les marges

148. 148
des tâches C et F ont été modifiées.
Le chemin critique est présenté maintenant sous la forme de diagramme à barres.
La marge en PERT-temps représente le décalage possible de l'ensemble de la tâche (début,
durée et fin) qui n'affecte pas la fin de l'ensemble du projet.

149. 149
Lorsque un réseau ne comporte que des liens de type «fin à début», alors tout allongement
d'une tâche critique se traduit par un allongement égal de la durée de l'ensemble du projet
(c'est la vision courante mais restrictive du chemin critique).
Lorsqu'un réseau comporte au moins un lien d'un autre type (ce qui est le cas dans l'exemple),
seul le calcul PERT-temps (calcul au plus tôt, calcul au plus tard, marge et chemin critique)
permet de déterminer l'impact d'une modification de durée d'une tâche critique.
Dans l'exemple, la fin de la tâche I ne pouvait être modifiée, alors que son début et donc sa
durée pouvait l'être dans la limite de cinq jours.
De même, le début de la tâche A de l'exemple (qui est une tâche critique) ne peut être modifié,
alors que sa durée (et sa date de fin), pourrait également allongée de 5 jours sans que la durée
du projet ne soit affectée.
Il pourrait être intéressant de disposer de notions de début critique, durée critique et fin
critique pour une tâche. La distinction entre ces notions n'aurait d'intérêt que pour les réseaux
qui comporte des liens d'un autre type que «fin à début».
Ces notions ne font pas partie de la technique PERT-temps de base telle qu'elle est mise en

150. 150
œuvre dans les logiciels de gestion de projets les plus courants actuellement disponibles.
1.5. Traitement des dates imposées
Le traitement des dates imposées est un point délicat de la technique PERT-temps.
Les algorithmes disponibles dans différents logiciels traitent les dates selon des approches qui
peuvent varier beaucoup. Un même logiciel peut traiter plusieurs types de dates imposées.
Le traitement présenté ici est la technique de base (la plus simple et la plus courante), autour
de laquelle de nombreuses variantes existent.
Dans la technique de base, il existe en théorie quatre types de dates imposées
 ne pas commencer avant : la tâche T ne peut pas commencer avant le 1er octobre (parce
que, par exemple, l'équipement nécessaire ne sera disponible qu'à cette date). Ce type de
date imposée
permet de prendre en compte un point d'entrée extérieur au projet ;
 ne pas se terminer avant : la tâche T ne peut pas se terminer avant le 1er
octobre (parce
que, par exemple, la tâche T consiste à maintenir en état un équipement ancien qui sera
remplacé à cette date) ;

151. 151
 ne pas commencer après : la tâche T ne peut pas commencer après le 1er
octobre (parce
que, par exemple, la tâche T consiste à maintenir en état un nouvel équipement qui sera
disponible à cette date) ;
 ne pas se terminer après : la tâche T ne peut pas se terminer après le 1er
octobre (cas
d'une date butoir pour le projet).
Ces quatre types de dates imposées se classent en deux catégories : les dates imposées pas
avant (ne pas commencer avant, et ne pas se terminer avant) et les dates imposées pas après
(ne pas commencer après, et ne pas se terminer après).
La règle de base est la suivante : les dates imposées de la catégorie pas avant sont prises en
compte dans le calcul au plus tôt et ignorées dans le calcul au plus tard ; les dates imposées de
la catégorie pas après sont prises en compte dans le calcul au plus tard et ignorées dans le
calcul au plus tôt.

152. 152
Les quatre types de dates qui existent en théorie ne sont pas tous aussi fréquents dans la
réalité.

153. 153
Les dates imposées du type ne pas se terminer après (les dates cibles) et celles du type ne pas
commencer avant (les points d'entrée) sont les plus fréquemment rencontrées.
Par suite, une simplification courante consiste à adopter comme règle de base : les dates de
début imposé sont prises en compte dans le calcul au plus tôt et ignorées dans le calcul au plus
tard ; les dates de fin imposée sont prises en compte dans le calcul au plus tard et ignorées
dans le calcul «au plus tôt».
1.6. Exemple de traitement de dates imposées
L'exemple de traitement de dates imposées en PERT-temps est issu de l'exemple pris
précédemment :

154. 154
Une contrainte de date-cible pour la tâche D a été rajoutée.

155. 155
Réseau exemple - dates au plus tôt
La contrainte de date concerne une date fin (et plus précisément une contrainte de la catégorie
pas après). En conséquence, cette contrainte de date n'affecte pas le calcul au plus tôt, qui est
identique à l'exemple traité dans la partie 1.2 :

156. 156
Réseau exemple - dates au plus tard
C'est dans le calcul au plus tard que la contrainte de date sur la tâche D doit être prise en
compte.
Cependant, cette contrainte de date est exprimée sous la forme suivante : la tâche D ne peut
pas se terminer après t0 + 35 jours.
Or les dates au plus tard sont toutes calculées en fonction de tf. Ce n'est qu'après le
rapprochement des échelles de temps qu'une relation entre t0 et tf est établie.
Voici comment la question est traitée.
Considérer que la tâche D ne peut pas se terminer après t0 + 35 jours, revient à dire que la date
de fin au plus tard de la tâche D doit être inférieure ou égale à la date t0 + 35 jours.
Les dates au plus tard sont d'abord calculées en fonction de tf ; puis lors du rapprochement des
échelles de temps la contrainte de date sera prise en compte.
Ce qui revient à dire que le rapprochement des échelles fait en réalité partie du calcul «au plus
tard».

157. 157
La première partie du calcul au plus tard (calcul à partir de la date tf. et qui se déroule vers le
passé) est identique à l'exemple traité dans la partie 1.2, sans dates imposées :
Pour le rapprochement des échelles, le traitement est le suivant.

158. 158
Si le réseau n'avait pas eu de contrainte de date, les deux échelles de temps auraient été
rapprochées comme suit :

159. 159
Le schéma ci-dessus montre que la date de fin au plus tard de la tâche D se trouve à t0 + 40
jours, ce qui est supérieur à t0 + 35 jours (la contrainte).
Pour respecter la contrainte, le rapprochement des échelles doit être effectué comme suit :

160. 160
L'échelle de temps des dates au plus tard glisse vers le passé jusqu'au respect de la contrainte
de date.

161. 161
Réseau exemple - calcul des marges et chemin critique
Le glissement de l'échelle des dates au plus tard vers le passé est formalisé pour le calcul des
marges de la façon suivante.
Par convention, la date tf correspond au point d'arrivée des dates au plus tôt (c'est-à-dire t0 +
40 jours), sauf si une contrainte de date est plus forte. Autrement dit : t f  t0 + 40 jours.
La contrainte de date (la tâche D ne peut pas se terminer après t0 + 35 jours) se traduit par la
relation tf. (en tant que date de fin au plus tard de la tâche D)  t0 + 35 jours.
Le système des deux inéquations :
t f  t0 + 40 jours.
t f  t0 + 35 jours.
conduit à la valeur tf = t0 + 35 jours.
Les marges qui en résultent sont les suivantes :

162. 162
Les tâches A, B et D ont une marge négative.
Le fait qu'une tâche ait une marge négative signifie que ses dates au plus tôt se situent plus
tard que ses dates au plus tard.
La présence de marges négatives signifie toujours une incompatibilité de dates imposées.

163. 163
Cela est vrai en PERT-temps, et en PERT-temps seulement (des marges négatives peuvent
apparaître en ordonnancement par les charges, mais elles n'ont pas alors la même
signification).
Lorsqu'une marge négative apparaît lors d'un calcul PERT-temps, elle signifie que la (ou une)
date-cible ne peut pas être tenue. Les actions à entreprendre alors sont les suivantes :
 soit retarder la date-cible (négociation avec le donneur d'ordre),
 soit avancer la date de début (si elle est future),
 soit réorganiser les liens (mettre des tâches en parallèle),
 soit réduire des durées (mais attention à l'optimisme de forme),
 soit prendre une bonne assurance sur le projet.
En présence de marges négatives, la définition du chemin critique repose sur une convention
 le chemin critique est l'ensemble des tâches dont la marge est nulle ou négative
ou
 le chemin critique est l'ensemble des tâches dont la marge est la plus basse.
Dans l'exemple, le chemin critique est constitué des tâches A, B et D (et ce quelle que soit la
convention adoptée).

164. 164
1.7. Pratique des dates imposées
L'illustration du traitement des dates imposées en PERT-temps s'appuie sur le réseau déjà vu,
auquel deux contraintes de dates ont été rajoutées :
La date imposée sur la tâche F est du type ne pas commencer avant, elle doit être prise en
compte dans le calcul au plus tôt et ignorée dans le calcul au plus tard.

165. 165
La date imposée sur la tâche I est du type ne pas se terminer après, elle doit être prise en
compte dans le calcul au plus tard et ignorée dans le calcul au plus tôt.
Dates au plus tôt
Le calcul est identique à l'exemple du chapitre 1.3 qui concerne le même réseau sans date
imposée, jusqu'à la date t0 + 25, date à laquelle la tâche F pouvait débuter.
Maintenant, la tâche F ne peut plus débuter à la date t0+ 25 en raison de la contrainte de date,
à prendre en compte dans le calcul au plus tôt.

166. 166
Le pointeur peut ensuite avancer jusqu'à la date t0 + 45 jours, date de la fin au plus tôt de la
tâche H.
A la date t0 + 45 jours, la tâche H est terminée et la tâche J peut démarrer.

167. 167
Le pointeur peut alors avancer jusqu'à la date t0 + 50 jours, date de début imposé de la tâche F.

168. 168
A la date t0 + 50 jours, les tâches C et D (les deux antécédents de la tâche F) sont terminées et
la contrainte de date sur la tâche F est respectée.
La tâche F peut démarrer.

169. 169

170. 170
Le pointeur peut alors avancer jusqu'à la date t0 + 65 jours, date de la fin au plus tôt de la
tâche F.
A la date t0 + 65 jours, la tâche F est terminée et la tâche I peut démarrer (la tâche G est bien
terminée à cette date).
Si la tâche I débute au plus tôt à la date t0 + 65 jours, elle se termine au plus tôt à la date t0 +
75 jours.
Cette date de fin au plus tôt de la tâche I respecte bien le lien de type «fin à fin» de la tâche J
vers la tâche I :

171. 171
Le calcul au plus tôt s'arrête à la date t0 + 75, date de In fin au plus tôt de la tâche I.
Dates au plus tard
La contrainte de date à prendre en compte dans le calcul au plus tard est la date imposée de la

172. 172
tâche I, qui est exprimée en fonction de t0.
En conséquence, la première partie du calcul au plus tard (calcul en fonction de la date tf) est
identique au calcul effectué sans contrainte de date.

173. 173
Dans cet exemple, la durée totale du projet dans le calcul au plus tôt est de 75 jours, et dans le
calcul au plus tard de 65 jours.
Une différence entre ces deux durées totales ne peut apparaître qu 'en présence de dates
imposées.
Sans la contrainte de date sur la tâche I, le rapprochement des échelles aurait été le suivant :

174. 174

175. 175
La contrainte de date sur la tâche I oblige à faire glisser l'échelle de temps du calcul au plus
tard vers le passé pour satisfaire la condition suivante : la date de lin au plus tard de la tâche I
doit être inférieure ou égale à la date t0 + 70.

176. 176

177. 177
Marges et chemin critique
Formellement, la relation qui lie les dates t0 et tf est établie comme suit :
Par convention, la date tf correspond au point d'arrivée des dates au plus tôt (c'est-à-dire t0 +
75), sauf si une contrainte de date est plus forte.
Autrement dit : tf  t0 + 75.
La contrainte de date sur la tâche I se traduit par la relation tf (en tant que date de fin au plus
tard de la tâche I)  t0 + 70.
Le système des deux inéquations :
tf  t0 + 75
tf  t0 + 70
conduit à la relation : tf = t0 + 70 jours.
Cette relation permet d'exprimer les dates au plus tard en fonction de t0.

178. 178
Le tableau qui suit indique les marges de chaque tâche.
Les tâches F et I ont chacune une marge négative de -5 jours, toutes les autres tâches ont une

179. 179
marge positive.
Dans ce cas, le chemin critique ne couvre pas toute la durée du projet (il est situé entre les
dates t0 + 50 et t0 + 70).
Ce phénomène est fréquent en présence de dates imposées dans un réseau.
A l'inverse, le fait qu'un chemin critique ne relie pas de façon continue le début à la fin d'un
projet ne se produit qu'en présence de dates imposées (cela est vrai en PERT-temps et en
PERT-temps seulement).
La présence de marges négatives indique une incompatibilité entre les dates imposées pour le
réseau tel qu'il est (avec ses liens et ses durées).
C'est là une application très importante de la technique PERT-temps (qui ne prend pas en
compte les contraintes de ressources).
Lors de l'établissement d'un planning de projet, un calcul PERT-temps est souvent effectué en
tant que première étape.
Il permet de mettre en évidence d'éventuelles marges négatives.

180. 180
Avant de traiter la répartition des ressources et des moyens (ce qui est un problème délicat,
comme la suite va le montrer), les incompatibilités de dates sont d'abord mises en évidence,
pour être résolues.

181. 181
2. PERT-CHARGE
2.1. Présentation
La technique PERT-charge est une extension de la technique PERT-temps qui permet de
prendre en compte les ressources affectées au projet.
En gestion de projets, le terme «ressource» désigne un moyen nécessaire au déroulement et à
l'aboutissement d'une tâche.
Voici des exemples courants de ressources :
 une personne,
 une équipe,
 un service de l'entreprise,
 un sous-traitant,
 une machine,
 un stock de matière,
 un budget.
Chaque ressource est représentée sous la forme d'un calendrier.

182. 182
Le terme calendrier a ici un sens particulier : il s'agit de la description jour par jour (ou
semaine par semaine, ou encore mois par mois, ou parfois même heure par heure, voire
minute par minute) du nombre d'unités d'œuvre que la ressource peut consacrer aux tâches du
projet.
Voici un exemple de calendrier de ressource :
Ce calendrier représente une ressource (disponible 8 heures par jour les lundis, mardis, jeudis
et vendredis, et 4 heures les mercredis. Le lundi de la deuxième semaine est férié, le mercredi
de la troisième semaine est consacré à des activités hors projet.
L'affectation d'une ressource à une tâche d'un projet consiste à consacrer une partie du
calendrier de la ressource à la tâche.
La part de calendrier de la ressource consacrée à la tâche est appelée la charge de la tâche

183. 183
pour la ressource (une charge est mesurée en unités d'œuvre).
Pour une ressource humaine, une charge se mesure en heures, en hommes.jours, en
hommes.semaines, en hommes.mois (parfois aussi en hommes.années ou même en
hommes.siècles).
Une même ressource peut être affectée à plusieurs tâches d'un même projet (ou de projets
différents). Plusieurs ressources peuvent être affectées à une même tâche.
L'affectation d'une ressource à une tâche peut prendre plusieurs formes :
— Une proportion du calendrier de la ressource (que l'on nomme l’ «intensité») est
consacrée à la tâche définie par ailleurs par une durée : la tâche est alors définie par
une durée et une intensité et la charge est déduite du calendrier. Pour quelqu'un
disponible 8 heures par jour du lundi au vendredi, une tâche d'une semaine à mi-temps
représente 20 heures de travail.
— La tâche est définie par une durée et une charge pour la ressource : l'intensité est
déduite du calendrier. Pour quelqu'un disponible 8 heures par jour du lundi au
vendredi, une tâche de 20 heures à mener pendant une semaine représente un mi-
temps.
— La tâche est définie par une charge et une intensité pour la ressource. La durée est

184. 184
déduite de ces deux éléments et du calendrier. Pour quelqu'un disponible 8 heures par
jour du lundi au vendredi, une tâche de 20 heures à mi-temps représente une semaine.
Un point clé de la gestion des ressources en gestion de projets (et PERT-charge en est une
technique particulière) est la distinction entre une charge (exprimée en hommes.jours, par
exemple) et une durée (exprimée en jours, par exemple).
En PERT-temps, les tâches sont caractérisées par des durées. En PERT-charge, les tâches sont
caractérisées par des durées et par des intensités de ressources.
Même si les tâches sont exprimées par des charges, elles sont d'abord converties en durées et
intensités avant de suivre le traitement PERT-charge.

185. 185
2.2. Exemple de traitement
L'exemple de fonctionnement de la technique PERT-charge s'appuie sur le réseau suivant :
Dans ce réseau, les durées sont exprimées en jours ouvrés (cinq journées par semaine).
Deux ressources interviennent sur ce projet : R1 et R2.
Elles sont représentées chacune par le calendrier suivant (un homme.jour par jour du lundi au
vendredi) :

186. 186
Chaque rectangle correspond à une semaine de travail.
Les vides entre les rectangles correspondent aux week-ends.
Réseau exemple — dates au plus tôt PERT-temps
La première étape de la technique PERT-charge consiste en un calcul au plus tôt PERT-
temps.
Dans certains cas, la première étape de la technique PERT-charge consiste en un calcul au
plus tard PERT-temps, mais ces cas sont très rares. Ces cas se traitent de façon similaire, la
seule différence tient à la nature du planning de départ (au plus tard au lieu de au plus tôt).

187. 187
Réseau exemple — établissement des plans de charge
La seconde étape de la technique PERT-charge consiste en une projection des durées des
tâches sur les calendriers des ressources correspondantes, en tenant compte de l'intensité qui
caractérise chaque tâche.

188. 188
La tâche A concerne la ressource R1, avec une intensité de 100% :
Le calendrier de la ressource R1 est «chargé» à 100% pendant les deux premières semaines
par la tâche A.

189. 189
Ensuite, c'est la ressource R2 qui est affectée à la tâche B avec une intensité de 100% :

190. 190
C'est la ressources R1 qui est affectée à la tâche C à hauteur de 100%:

191. 191
Enfin, la ressource R2 est affectée à la tâche D :
Lorsque toutes les tâches du réseau ont été chargées sur les calendriers des ressources
correspondantes, cette étape de PERT-charge s'arrête.
L'ordre dans lequel les tâches sont chargées n'a pas d'impact sur le résultat de cette étape. Le
seul point important est que toutes les tâches soient chargées.

192. 192
Le résultat de cette étape est un ensemble de plans de charge. Un plan de charge est un
calendrier de ressource sur lequel les tâches ont été chargées.
Dans sa forme élémentaire, la technique PERT-charge se termine ici.
Réseau exemple - plans de charge cumulée
Un complément fréquemment apporté à rétablissement des plans de charge consiste à déduire
de ces plans de charge des plans de charge cumulée.
Un plan de charge cumulée est la représentation du cumul de toute la charge prévue pour la
ressource à partir du début du projet.
Pour la ressource R1, voici le plan de charge et le plan de charge cumulée correspondant au
réseau exemple :

193. 193
De même, pour la ressource R2 :
La courbe de charge cumulée est l'intégrale de la courbe de charge.

194. 194
C'est pour cette raison qu'elle est parfois aussi appelée «graphe de régression de la ressource».
A partir de courbes de charge cumulée par ressource, il est fréquent de vouloir représenter sur
un même graphe la prévision de consommation de l'ensemble des moyens et des ressources
pour un ou plusieurs projets.
Pour pouvoir consolider les courbes de charge cumulée de toutes les ressources d'un projet, il
est nécessaire que les unités employées soient homogènes et comparables (dire qu'une heure
d'utilisation d'ordinateur plus une heure d'ingénieur d'étude font deux heures de «moyens» n'a
pas grand sens).
Dans ce cas, l'unité commune est l’euro (ou un équivalent comptable).

195. 195
La courbe obtenue représente la prévision du cumul des dépenses effectuées sur le projet.
2.3. Pratique de la technique
Pour illustrer la pratique du traitement d'un réseau par la technique PERT-charge, le réseau de
départ est le suivant :

196. 196
Les durées sont exprimées en jours ouvrés (cinq jours par semaine).
Deux ressources sont affectées aux différentes tâches du projet : R1 et R2. Toutes deux ont le
calendrier suivant (cinq hommes.jours par semaine) :

197. 197
Dates au plus tôt PERT-temps
La première étape est le calcul au plus tôt de PERT-temps, dont voici le résultat :
C'est à partir de ce planning que les plans de charge des ressources sont établis.
La ressource R1 est affectée à la tâche A avec une intensité de 100%:

198. 198

199. 199
La ressource R2 est affectée à la tâche B avec une intensité de 100%:

200. 200
La ressource R1 est affectée à la tâche C avec une intensité de 100% :

201. 201
La ressource R2 est affectée à la tâche D avec une intensité de 100%:
Une surcharge apparaît sur la ressource R2 entre t0 + 10 et t0 + 15.

202. 202
La ressource R2 est affectée à la tâche E avec une intensité de 50% :

203. 203
La ressource R1 est affectée à la tâche F avec une intensité de 50% :

204. 204
La ressource R2 est affectée à la tâche G avec une intensité de 50% :

205. 205
La ressource R1 est affectée à la tâche H avec une intensité de 50% :
La ressource R1 est affectée à la tâche I avec une intensité de 100% :

206. 206
La tâche J fait apparaître une nouvelle surcharge.
Le traitement de base de la technique PERT-charge s'arrête ici.

207. 207
Après ce traitement, les plans de charge mettent en évidence des surcharges de même que des
sous-charges.
Les surcharges ne sont pas systématiquement sources de problèmes à résoudre.
Par exemple, en début de projet, l'utilisation de la technique PERT-charge permet d'évaluer
les besoins en effectifs sur le projet.
Mais il arrive aussi que les effectifs et, plus généralement, le potentiel disponible des
ressources ne soient pas extensibles (par exemple en cours de projet). Dans ce cas, les
surcharges doivent être éliminées : cette opération porte le nom de lissage (en anglais
«resource levelling»).
2.4. Présentation du lissage
Le lissage de plans de charge de ressources a pour but d'éliminer les surcharges.
Pour cela, le lissage consiste à décaler des tâches vers l'avenir, suffisamment pour faire
disparaître les surcharges, mais pas trop (de façon à ne pas trop décaler la fin du projet).
Dans le cas général, l'opération de lissage décale la fin du projet vers l'avenir : le traitement

208. 208
PERT-temps (et le traitement PERT-charge de base dont il est issu) fournissent le délai le plus
court pour le projet, mais supposent que les ressources sont illimitées ; le lissage permet de
limiter la disponibilité des ressources mais allonge le délai.
Dans les cas (encore une fois assez rares) où la technique PERT-charge est mise en œuvre en
partant du calcul au plus tard de PERT-temps, le lissage est effectué en décalant les tâches
vers le passé.
Lorsqu'une surcharge apparaît dans une période de temps sur le plan de charge d'une
ressource, plusieurs tâches se trouvent en parallèle. La question est de savoir laquelle de ces
tâches est en surcharge, autrement dit, laquelle de ces tâches doit être décalée.
Il s'agit là du point délicat du lissage. En effet, le fait de décaler une tâche va décaler les
successeurs de la tâche, et peut-être du même coup faire apparaître de nouvelles surcharges.
Trouver un bon agencement local, ne signifie pas que l'ensemble du projet sera optimisé.
Sans que ce soit une assurance du meilleur agencement pour l'ensemble du projet, une règle
consiste à décaler la tâche qui a le plus de marge.
L'utilisation de cette règle nécessite de connaître les marges des tâches, et donc d'effectuer au

209. 209
préalable un calcul PERT-temps.
Alors que la technique PERT-charge ne nécessite qu'un seul calcul PERT-temps (en règle
générale, le calcul au plus tôt), la technique PERT-charge est utilisée dans la pratique après
tous les calculs PERT-temps.
2.5. Exemple de lissage
Le lissage est illustré par l'exemple qui suit :

210. 210
Dans ce réseau, les durées sont encore exprimées en jours ouvrés (cinq journées par semaine).
Deux ressources interviennent sur ce projet : R1 et R2. Elles sont représentées chacune par le
calendrier suivant (un homme.jour par jour du lundi au vendredi) :
Réseau exemple traitement PERT-temps
Le calcul au plus tôt PERT-temps est le suivant :

211. 211
Le calcul au plus tard PERT-temps est le suivant :
Les marges et le chemin critique peuvent être représentés comme suit :

212. 212
Ce mode de représentation des marges est fréquent dans les états de sortie édités par des
logiciels de gestion de projets.
Remarque : par convention, les marges sont calculées sur les dates de début (début au plus
tard — début au plus tôt) alors qu'elles sont représentées ici à partir de la date de fin au plus
tôt.
Attention au fait que cette convention de représentation n'est vrai qu'en PERT. En
ordonnancement par les charges, cette convention de représentation signifie souvent «tâche en
cours mais ressource indisponible».
Réseau exemple - traitement PERT-charge de base
L'établissement des plans de charge des ressources Rl et R2 à partir du calcul au plus tôt de
PERT-temps aboutit au résultat suivant :

213. 213
Les plans de charge vont faire l'objet d'un lissage.
Réseau exemple - lissage

214. 214
Dans cet exemple, les tâches C et D sont équivalentes (même durée, même ressource avec la
même intensité, même marge). Il y a deux façons équivalentes de lisser :
— soit décaler la tâche C de cinq jours (scénario n°l),
— soit décaler la tâche D de cinq jours (scénario n°2).
L'opération de lissage se traduit par un décalage de tâches : elle se termine donc par une
reprise du planning.
Voici le scénario n°l :

215. 215

216. 216
Le scénario n°2 est le suivant :

217. 217

218. 218
Dans chacun des deux scénarios, la tâche décalée (la tâche C dans le scénario n°l, et la tâche
D dans le scénario n°2) perd sa marge.
Le décalage (qui est parfois nommé le «report» de la tâche) agit comme une date de début
imposé.
Dans le scénario n°2, la tâche D a une marge nulle. Par contre, la tâche C a une marge de 5
jours. Si la tâche C s'allonge d'une journée, la ressource R2 devra alors décaler la tâche D
d'une journée pour pouvoir terminer la tâche C. Mais si la tâche C est décalée d'une journée, la
tâche E sera également décalée d'une journée, et par conséquent la fin du projet aussi.
Voilà donc un exemple où une journée de retard sur une tâche dont la marge est de 5 jours, se
traduit par une journée de retard sur l'ensemble du projet.
En PERT-charge après un lissage, les marges n'ont aucune signification.
2.6. Pratique du lissage
L'exemple traité au chapitre 2.3. «Pratique de la technique PERT-charge» a fait apparaître des
surcharges. Le lissage des plans de charge est traité ici. Le réseau de départ était le suivant :

219. 219
Le planning au plus tôt et les plans de charge résultants sont présentés avec la convention de
pointillés pour représenter les marges :

220. 220
Lorsqu'une tâche est décalée, ses successeurs doivent également être placés de façon à
respecter les liens. Le décalage des successeurs d'une tâche peut faire apparaître de nouvelles
surcharges (ou éventuellement en faire disparaître) sur le plan de charge de la ressource, mais
aussi sur celui d'autres ressources.
Voilà pourquoi le lissage doit être effectué du début du projet (à partir de la date t0) vers
l'avenir, et ce pour toutes les ressources, et non pas plan de charge par plan de charge.

221. 221
Dans les cas où la technique PERT-charge est mise en œuvre à partir des dates au plus tard de
PERT-temps, le lissage est effectué de la fin du projet (à partir de la date tf) vers le passé, et ce
pour toutes les ressources.
Lissage
La première surcharge apparaît à la date t0 + 10, sur le plan de charge de la ressource R2 : les
tâches B (de marge nulle) et D (d'une marge de 10 jours) occupent toutes les deux la ressource
R2 à 100%.
Décaler la tâche B conduirait au résultat intermédiaire suivant :

222. 222
Décaler la tâche D fournit un résultat intermédiaire meilleur comme la suite le montre.
La tâche D est décalée, mais les deux semaines suivantes sont occupées par la tâche E (de

223. 223
marge nulle) à 50%.
Ensuite vient la tâche G qui est un successeur (de type «fin à début») de la tâche D. La tâche
D doit donc être placée avant la tâche G.
La tâche D peut être placée soit entre les tâches E et G (le scénario n°l), soit entre les tâches B
et E (le scénario n°2).
Le scénario n°l aboutit au résultat intermédiaire suivant :

224. 224
Le décalage de la tâche D fait ici disparaître la surcharge du plan de charge de la ressource R1

225. 225
à la date t0 + 25 (tâches C et H).
Le scénario n°2 aboutit au résultat intermédiaire suivant :
Là encore, le décalage de la tâche D fait disparaître la surcharge du plan de charge de la

226. 226
ressource R1 à la date t0 + 25 (tâches C et H).
Hormis les positions des tâches D et H, ces scénarios sont identiques. La suite du lissage sera
par conséquent identique pour les deux scénarios et seul le scénario n°l sera examiné.
La suite du lissage concerne le plan de charge de la ressource R2 qui présente encore une
surcharge à la date t0 + 50 (parallélisme de la tâche G avec une intensité de 50% et de la tâche
J avec une intensité de 100%).
Décaler la tâche G amènerait à retarder également la tâche I (son successeur (lien de type «fin
à début») et donc la fin du projet :

227. 227
Le fait de décaler la tâche J fournit le résultat suivant :

228. 228
Toutes les surcharges ont été éliminées.
La dernière action du lissage consiste à remettre le planning à jour à partir des plans de
charges.
Planning résultant

229. 229
Voici le planning qui correspond au scénario n°l (tâche E avant la tâche D) :

230. 230

231. 231
Voici le planning qui correspond au scénario n°2 (tâche D avant la tâche E) :

232. 232

233. 233
2.7. Présentation du nivellement
Le nivellement de plans de charge de ressources est une forme particulière de lissage. Lors
d'une opération de nivellement, la durée des tâches peut augmenter et l'intensité diminuer. La
charge, elle, demeure constante.
Une tâche de deux semaines à 100% peut être transformée en une tâche de quatre semaines à
50%. La charge de cette tâche (10 hommes.jours) est la même dans les deux cas.
La seule contrainte lors d'un nivellement est que l'intensité ne peut pas augmenter : une tâche
de deux semaines à 50% ne peut pas être transformée en une tâche d'une semaine à 100%.
Le point délicat du nivellement est que la réduction de l'intensité sur une tâche peut ne pas
être constante.
Ainsi la tâche de deux semaines à 100% peut également être transformée en une tâche de trois
semaines, une semaine à 100% et deux semaines à 50%.

234. 234
Le fait que l'intensité d'une tâche puisse être diminuée dépend en réalité de la tâche elle-même
: une tâche d'étude prévue à plein temps peut très bien être menée à mi-temps selon les
nécessités de planning (cette tâche peut être nivelée) : par contre, un déplacement d'une
semaine à plusieurs centaines de kilomètres ne peut pas être fait tous les matins seulement et
ce pendant deux semaines.
Dans la pratique, le nivellement que l'on peut réaliser dépend surtout de l'outil logiciel dont on
dispose.

235. 235
2.8. Pratique du nivellement
Le nivellement est illustré par le même exemple que le lissage, à partir du réseau suivant :
Le point de départ du nivellement est le même que pour le lissage (planning au plus tôt et
plans de charge résultants) :

236. 236
Comme pour le lissage (et pour les mêmes raisons), le nivellement doit être effectué du début
du projet (à partir de la date t0) vers l'avenir, et ce pour toutes les ressources.

237. 237
Dans les cas où la technique PERT-charge est mise en œuvre à partir des dates au plus tard de
PERT-temps, le nivellement est effectué de la fin du projet (à partir de la date tf) vers le passé,
et ce pour toutes les ressources.

238. 238
Nivellement
Le nivellement de la première surcharge qui apparaît à la date t0 + 10, sur le plan de charge de
la ressource R2 (les tâches B et D) peut être traité en conservant les dates de début de ces
deux tâches et en diminuant leur intensité à partir de la date t0+ 10 :

239. 239
Là encore, la surcharge du plan de charge de la ressource R1 à la date t0 + 25 (tâches C et H)
disparaît.

240. 240
Reste à traiter la surcharge du plan de charge de la ressource R2 à la date t0 + 50 (tâches G et
J) :
Ce résultat de nivellement permet d'obtenir une date de fin pour le projet inférieure d'une
demi-semaine au résultat du lissage.

241. 241
Mais il se trouve que dans le cas présent, un autre nivellement fournit un résultat meilleur en
termes de dates de fin.
Le raisonnement est le suivant : les plans de charge contiennent des sous-charges qui
pourraient être utilisées.
Le délai du projet est déterminé par la tâche J (qui entraîne son successeur, la tâche I). La
tâche J est elle-même déterminée par son antécédent (de type «fin à début»), la tâche H. La
tâche H pourrait être placée plus tôt en réduisant l'intensité sur la tâche C, mais son antécédent
de type «début à début» (la tâche G) l'empêche de débuter plus tôt. Le début de la tâche G est
déterminé par les fins des tâches D et E.
C'est donc en ré-organisant les trois premières semaines du plans de charge de la ressource R2
que le délai peut être raccourci.
En repartant de la date t0, voici comment traiter la première surcharge (tâches B et D sur le
plan de charge de la ressource R2) :

242. 242
La surcharge du plan de charge de la ressource R1 à la date t0 + 25 (tâches C et H) est alors
résolue en réduisant l'intensité de la tâche C:

243. 243
Enfin, la dernière surcharge sur le plan de charge de la ressource R2 est traitée comme suit :

244. 244
Ce nivellement permet d'aboutir à une date de fin inférieure d'une semaine au scénario de
nivellement précédent.

245. 245
Planning résultant
Voici le planning qui correspond au dernier nivellement :

246. 246

247. 247

248. 248
3. Quand utiliser les techniques PERT
Les techniques PERT (PERT-temps et PERT-charge) sont les plus courantes dans les logiciels
de gestion de projets (plus de 90% des logiciels disponibles sur le marché).
De ce fait, elles sont les plus couramment utilisées.
Elles se caractérisent par le traitement d'un réseau sur une échelle de temps, qui est parcourue
dans les deux sens dans le cas de PERT-temps (dates au plus tôt et dates au plus tard) à
l'intérieur d'un domaine de contraintes de dates imposées :
Résolution d’un graphe sur une dimension

249. 249
Cette échelle de temps est complétée par une dimension par ressource dans le cas de PERT-
charge. En PERT-charge, le traitement des ressources est vu comme une projection sur des
plans de charge.
Le traitement de base (établissement des besoins en ressources) est simple. Mais dès qu'il
s'agit d'optimiser un lissage ou un nivellement, les choses se compliquent comme les
exemples précédents l'ont montré (la composante principale reste le temps par rapport aux
ressources).
La technique PERT-temps (la plus simple) est la technique à utiliser pour établir et gérer un
planning lorsque les ressources ne sont pas gérées : c'est le cas d'un maître d'œuvre qui sous-

250. 250
traite des résultats intermédiaires (les fins de tâches) sans voir les ressources mises en œuvre.
Dans ce cas, les tâches constituent des durées entre le lancement d'un marché ou d'un lot et la
recette correspondante. Les durées sont annoncées par le fournisseur ou le sous-traitant et le
maître d'œuvre déclenche les tâches.
Pour un responsable de projet qui doit prendre en compte les ressources affectées au projet, la
technique PERT-temps est également utilisée comme première étape de l'élaboration des
plannings et des plans de charge.
Sa mise en œuvre permet de mettre en évidence d'éventuelles marges négatives et donc de se
concentrer d'abord sur les problèmes de dates imposées avant de prendre en compte les
disponibilités de ressources.
Dans un deuxième temps, la technique PERT-charge permet d'établir les besoins en
ressources pour le projet. Jusqu'à ce point les techniques PERT sont bien adaptées.
La suite normale du processus d'établissement d'un tableau de marche prévisionnel est de
prendre en compte un potentiel défini de ressources pour le projet : c'est le domaine du lissage
et du nivellement.

251. 251
Il est facile de lisser des plans de charge, mais il est délicat de trouver le meilleur lissage ou le
meilleur nivellement.
Ces opérations d'optimisation restent manuelles et intuitives dans une logique PERT.
Dans la réalité, un responsable de projet dispose de moyens limités (même s'ils sont
importants) pour le projet. En cours de projet, les plannings évoluent, des tâches prennent
souvent du retard ; il faut alors périodiquement déterminer «où va le projet».
Autrement dit, le responsable du projet doit réactualiser ses plannings et ses plans de charge
avec des conditions initiales qui changent (la date t0 avance dans le temps, des tâches se
terminent et donc ne sont plus à planifier, le reste à faire sur les tâches en cours change, des
estimations sont revues, de nouvelles tâches doivent être prises en compte, etc.).
Refaire périodiquement des calculs PERT-temps ou un calcul PERT-charge de base n'est pas
une chose compliquée, surtout avec un logiciel.
Par contre, examiner de près les plans de charge des ressources impliquées, et déterminer le
meilleur lissage ou le meilleur nivellement requièrent trop de temps pour que le responsable
du projet puisse s'y consacrer en cours du projet (une exception cependant : dans certains
organismes, une équipe séparée est consacrée à la gestion des plannings et des plans de

252. 252
charge).
Les techniques PERT sont donc bien adaptées à l'établissement d'un tableau de marche
prévisionnel, mais pas très bien à sa gestion. Elles permettent bien au cours du projet de
justifier les demandes de moyens supplémentaires, mais ce n'est là qu'un aspect de la gestion
d'un projet.