Gestion de Projet

Gestion de Projet
Thomas Berthelot
Notes

ii
Ce livre est distribué sous licence Creative Commons CC BY-SA. Il peut
être modiﬁé, distribué librement, à condition que le nom de l’auteur soit cité et
qu’il reste couvert par la même licence.
ISBN 978-2-9565739-0-6
c Thomas BERTHELOT, 2018

Table des matières
I Introduction 1
II Qu’est-ce qu’un Projet ? 5
1 Un peu de théorie... 7
2 Un Projet en pratique 11
2.1 Comment est-ce que ça se passe ? . . . . . . . . . . . . . . . . . . . 11
2.2 Quelques détails pas anodins . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Une histoire de courbes . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Un rôle plus large que ce qu’on pensait ? . . . . . . . . . . . 15
3 Différents types de Projets 17
3.1 Une première classification qualitative... . . . . . . . . . . . . . . . 17
3.2 Une classification un peu plus formelle . . . . . . . . . . . . . . . . 18
3.2.1 Qu’est-ce que la taille d’un Projet ? . . . . . . . . . . . . . . 18
3.2.2 Et la complexité ? . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3 Pour aller plus loin : le profil de Projet . . . . . . . . . . . . 19
4 Comment est structuré un Projet ? 23
4.1 Structure séquentielle . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 L’ingénierie simultanée/collaborative . . . . . . . . . . . . . . . . . 24
4.3 Comment intégrer tout ça dans l’entreprise ? . . . . . . . . . . . . . 25
4.3.1 Structure fonctionnelle . . . . . . . . . . . . . . . . . . . . . 25
4.3.2 Structure coordonnée . . . . . . . . . . . . . . . . . . . . . . 26
4.3.3 Structure avec une Direction de Projet . . . . . . . . . . . . 27
4.3.4 L’équipe Projet dédiée . . . . . . . . . . . . . . . . . . . . . 28
4.4 Il reste l’humain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
iii

iv TABLE DES MATIÈRES
III Le déroulement d’un Projet 31
5 Pourquoi différentes phases ? 33
5.1 Une question d’organisation . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Et donc, comment est-ce mis en place ? . . . . . . . . . . . . . . . . 33
6 La phase de spécification 37
6.1 Le Cahier des Charges . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1.1 Présentation rapide . . . . . . . . . . . . . . . . . . . . . . . 37
6.1.2 Comment l’écrit-on ? . . . . . . . . . . . . . . . . . . . . . . 38
6.1.3 Qu’est-ce qu’une exigence ? . . . . . . . . . . . . . . . . . . 41
6.1.4 Pour revenir sur l’aspect contractuel . . . . . . . . . . . . . 44
6.2 Utilisation pour la préparation du Projet . . . . . . . . . . . . . . . 44
6.2.1 Comprendre ce qui est demandé . . . . . . . . . . . . . . . . 45
6.2.2 Écriture d’une spécification interne . . . . . . . . . . . . . . 46
6.3 Gérer les exigences pour gérer le Projet . . . . . . . . . . . . . . . . 53
7 Le lancement 55
7.1 Quelques mots sur le Chef de Projet . . . . . . . . . . . . . . . . . 55
7.1.1 Quel est donc le rôle du Chef de Projet ? . . . . . . . . . . . 56
7.1.2 La mise en œuvre – Les compétences générales . . . . . . . . 57
7.1.3 Le spécifique – les aspects processus . . . . . . . . . . . . . . 63
7.2 Donner un cadre clair au Projet . . . . . . . . . . . . . . . . . . . . 64
7.2.1 Le document de définition du Projet . . . . . . . . . . . . . 64
7.2.2 Des objectifs corrects . . . . . . . . . . . . . . . . . . . . . . 65
7.2.3 La structuration du travail - Que doit-on faire ? . . . . . . . 66
7.2.4 Qui fait quoi ? . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.3 Constituons l’équipe ! . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.1 Définir les rôles . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.3.2 Définir les règles de fonctionnement . . . . . . . . . . . . . . 73
7.4 D’autres types de ressources . . . . . . . . . . . . . . . . . . . . . . 75
7.5 Planifier le Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.5.1 Juste avant de planifier : estimer la durée des lots . . . . . . 76
7.5.2 Le PERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.5.3 Le diagramme de GANTT . . . . . . . . . . . . . . . . . . . 81
7.6 La réunion de lancement . . . . . . . . . . . . . . . . . . . . . . . . 85
8 L’exécution du Projet 87
8.1 Le développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.1.1 Connaître l’existant - connaître le possible . . . . . . . . . . 88
8.1.2 Orienter la conception . . . . . . . . . . . . . . . . . . . . . 92

TABLE DES MATIÈRES v
8.1.3 Finaliser la conception . . . . . . . . . . . . . . . . . . . . . 97
8.2 La production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
8.2.1 Décider si on fabrique en interne . . . . . . . . . . . . . . . 101
8.2.2 Choisir des partenaires / sous-traitants . . . . . . . . . . . . 102
8.2.3 Le suivi de fabrication . . . . . . . . . . . . . . . . . . . . . 105
8.3 Les Tests – voir si tout fonctionne comme prévu . . . . . . . . . . . 108
8.3.1 Savoir ce qu’on doit tester . . . . . . . . . . . . . . . . . . . 108
8.4 Livrer son Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.5 La documentation du Projet . . . . . . . . . . . . . . . . . . . . . . 111
8.6 La clôture du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . 111
IV Limiter les problèmes 113
9 Le contrôle 115
9.1 Maîtriser les coûts . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
9.1.1 Les bases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
9.1.2 Instruments de pilotage . . . . . . . . . . . . . . . . . . . . . 116
9.2 Gérer les délais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
9.2.1 Utiliser le planning pour assurer le suivi . . . . . . . . . . . 121
9.3 Contrôler la qualité . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
9.3.1 Les processus . . . . . . . . . . . . . . . . . . . . . . . . . . 124
9.3.2 La traçabilité de l’information . . . . . . . . . . . . . . . . . 124
9.3.3 La validation . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.3.4 Bâtir pour le futur . . . . . . . . . . . . . . . . . . . . . . . 127
9.3.5 Gérer les relations . . . . . . . . . . . . . . . . . . . . . . . . 128
10 La gestion des risques 131
10.1 Qu’est-ce qu’un risque ? . . . . . . . . . . . . . . . . . . . . . . . . 132
10.2 Quels sont les risques à gérer ? . . . . . . . . . . . . . . . . . . . . . 134
10.2.1 Identiﬁer les risques . . . . . . . . . . . . . . . . . . . . . . . 135
10.2.2 Prioriser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
10.2.3 Prévenir les risques . . . . . . . . . . . . . . . . . . . . . . . 138
10.3 Suivre les risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
10.4 Les diﬃcultés arrivent . . . . . . . . . . . . . . . . . . . . . . . . . 144
V Des outils pour la gestion de Projet 147
11 L’organisation 151
11.1 Réunions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

vi TABLE DES MATIÈRES
11.1.1 Préparer eﬃcacement . . . . . . . . . . . . . . . . . . . . . . 153
11.1.2 Piloter la réunion . . . . . . . . . . . . . . . . . . . . . . . . 156
11.1.3 La conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 157
11.2 Le suivi des actions – la TODO list . . . . . . . . . . . . . . . . . . 159
11.3 La gestion documentaire . . . . . . . . . . . . . . . . . . . . . . . . 160
11.4 La communication au sein de l’équipe Projet . . . . . . . . . . . . . 161
12 Les techniques et méthodes 163
12.1 Le Cycle de Deming (PDCA) . . . . . . . . . . . . . . . . . . . . . 163
12.2 Le SIPOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
12.3 La matrice SWOT . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
12.4 Les Méthodes Agiles (SCRUM, SAFe, . . .) . . . . . . . . . . . . . . 169
12.4.1 La méthode SCRUM . . . . . . . . . . . . . . . . . . . . . . 172
12.4.2 La méthode SAFe R . . . . . . . . . . . . . . . . . . . . . . 179
12.5 L’Ingénierie Système . . . . . . . . . . . . . . . . . . . . . . . . . . 188
12.5.1 Qu’est-ce qu’un système ? . . . . . . . . . . . . . . . . . . . 189
12.5.2 La démarche d’Ingénierie Système . . . . . . . . . . . . . . . 190
Appendices 197
A La gestion de Projet en un coup d’œil 199
B À propos de l’auteur 201

Première partie
Introduction
1

3
L’importance de la gestion de Projet aujourd’hui
Le Projet est actuellement un mode de fonctionnement universel dans le do-
maine professionnel, mais aussi dans les domaines associatifs ou privés. On parle
couramment de Projet dès qu’on a un ensemble de tâches à effectuer, voire sim-
plement l’envie de réaliser quelque chose. L’objet du Projet pourra pourtant être
extrêmement varié – le développement d’un nouvel avion ou l’écriture d’un livre.
Dans tous les cas, une organisation est mise en place pour obtenir les ré-
sultats espérés, qui pourra être plus ou moins complexe en fonction du travail à
réaliser. Cela pourra aller d’une simple liste de tâches (la classique To Do list)
à une organisation complexe faisant intervenir des milliers de personnes avec des
compétences, des cultures et des langues différentes.
Le point commun sera cette recherche de structuration du travail avec l’ob-
jectif d’obtenir de façon efficace le résultat escompté. On cherchera à agencer au
mieux un ensemble de tâches en fonction des ressources disponibles, pour se confor-
mer à un calendrier défini.
Énormément de gens travaillent en organisation Projet. a maîtrise des outils
et méthodes constitue un atout important pour participer efficacement à la vie et
au développement de l’entreprise, et évoluer en son sein. Il est donc intéressant de
se former.
Une information théorique abondante
La gestion de Projet fait l’objet d’un nombre important de cours classiques,
de MOOC 1
. La littérature qui y est consacrée est extrêmement riche. Des cer-
tifications professionnelles existent pour attester de la maîtrise des concepts et
méthodes 2
Pour celui qui sera limité à l’autoformation, le Web regorge de sites qui
présentent de façon sérieuse et exhaustive les concepts et outils de la gestion de
Projet.
Il existe donc un grand nombre de sources d’information fiables qui per-
mettent d’acquérir les notions utilisées en gestion de Projet.
La difficulté du passage à la pratique
La qualité de l’information ne garantira toutefois pas le succès des projets
entrepris. On aura acquis des méthodes et un cadre de travail qui mettent dans
1. Par exemple le MOOC GdP de l’Ecole Centrale de Lille que j’ai suivi
2. Par exemple PMP c ou PRINCE2 c .

4
de bonnes conditions, mais seule une exécution eﬃcace permettra d’atteindre les
objectifs.
Mon expérience personnelle – à la fois en tant que Chef de Projet et/ou ob-
servateur extérieur d’une équipe projet – m’a montré que les processus et méthodes
de Gestion de Projet deviennent parfois quasiment une ﬁnalité, au détriment du
livrable Client qu’on devrait avoir à l’esprit en permanence.
J’ai essayé de regrouper dans ce livre les notes que j’ai pu prendre dans le
cadre de ma vie professionnelle en mettant en avant la mise en pratique pour
rendre le sujet un peu plus concret.
Thomas Berthelot
Note : le contenu de ce livre n’engage que moi. J’ai essayé d’intégrer et de
formaliser les multiples informations que j’ai pu regrouper durant plusieurs années.
Sa valeur ne dépend que de ce qu’on en fera...

Deuxième partie
Qu’est-ce qu’un Projet ?
5

Chapitre 1
Un peu de théorie...
Au-delà de l’idée qu’on se fait habituellement de ce qu’est un Projet, il existe
des définitions officielles.
La norme ISO 10006:2003 1
stipule ainsi :
Un projet est un processus unique qui consiste en un ensemble d’activités
coordonnées et maîtrisées, comportant des dates de début et de fin, entrepris dans
le but d’atteindre un objectif conforme à des exigences spécifiques, telles que les
contraintes de délais, de coûts et de ressources.
Cette définition fait apparaître plusieurs concepts importants qu’on attribue
naturellement aux projets :
— Un Projet est un ensemble d’activités – qu’on appellera communément des
tâches – qui se déroulent par étapes.
— Les tâches sont coordonnées et maîtrisées, c’est à dire qu’elles suivront un
enchaînement réfléchi et logique, et qu’on s’assurera dans le cadre du Projet
de garder le contrôle sur leur déroulement. La nécessité de contrôle durant
le déroulement du Projet implique naturellement d’avoir réfléchi à priori au
déroulement optimal et aux moyens de vérification.
— Un Projet est défini temporellement; il comporte une date de début et une
date de fin.
— Un Projet vise à atteindre un objectif qui est défini par des exigences.
Ce point est primordial, car il exprime la nécessité de savoir ce qu’on doit
obtenir à la fin du Projet. Il est évident qu’on ne pourra pas organiser son
travail et celui d’une équipe sans savoir ce qu’on doit avoir comme résultat
à la fin.
— Un Projet est dépendant du temps, des moyens et des ressources qu’on peut
y consacrer.
1. ISO 10006:2003 Systèmes de management de la qualité – Lignes directrices pour le mana-
gement de la qualité dans les projets
7

8 CHAPITRE 1. UN PEU DE THÉORIE...
En pratique, on ne dispose pas de ressources infinies pour viser la perfec-
tion dans ce qu’on fait. Un projet sera systématiquement une recherche de
compromis qui satisfera au mieux les parties impliquées.
Le but d’un Projet sera donc de parvenir à un résultat. Ce dernier sera
souvent évalué suivant un triptyque Qualité / Coût / Délai qui synthétise les
concepts listés au-dessus :
Qualité
Coût Délai
Figure 1.1 – Le triangle Qualité-Coût-Délai
La figure 1.1 est intéressante parce qu’elle met en évidence le fait qu’un Projet
est un compromis. On ne pourra pas choisir de privilégier un des trois axes sans
influer sur les deux autres. Le Projet aura pour objectif de parvenir à une solution
optimale pour les trois critères, en créant les conditions adéquates.
L’organisation en mode Projet vise à augmenter la productivité pour le dé-
veloppement de solutions 2
.
La productivité se définit de façon générale selon la formule :
Productivité =
Création de valeur
Coût
L’augmentation de la productivité pourra donc se faire suivant 2 axes :
— La diminution du coût.
C’est souvent l’option qui est explorée en premier parce qu’elle permet
d’obtenir des résultats assez rapidement.
2. Un Projet ne se limite pas au travail sur un produit matériel. L’objectif peut tout aussi
bien être une création intellectuelle pourvu que les critères de définition donnés plus haut soient
respectés.

9
Par contre, elle peut aussi présenter des difficultés pour sa mise en œuvre.
Selon le domaine considéré elle pourra nécessiter un travail important sur
les processus, les méthodes et l’organisation. Cela devra être fait dans les
limites autorisées par le maintien de la qualité des produits, et en tenant
compte de facteurs humains. En effet si la réduction des coûts a un im-
pact sur le travail des personnes (par une augmentation de la quantité ou
une dégradation des conditions), elle se heurtera à une forte résistance au
changement.
Enfin la réduction des coûts permettra rarement d’obtenir un avantage com-
pétitif durable. D’autres acteurs du domaine pourront eux aussi travailler
relativement facilement sur leurs coûts et annihiler les effets escomptés 3
.
— L’augmentation de la création de valeur.
Ou autrement dit l’innovation, qui permettra d’offrir plus de valeur et de
se démarquer plus franchement de la concurrence. Bien sûr, il est souvent
beaucoup plus difficile d’innover (surtout de façon disruptive) que de réduire
ses coûts. Mais les bénéfices seront incomparables.
L’innovation demandera la mise en œuvre de différentes compétences "tech-
niques" selon le Projet, au sein d’une équipe souvent pluridisciplinaire. Le
succès sera alors directement lié à la qualité de l’organisation et de la coor-
dination de ces ressources.
C’est là qu’est LA justification d’un travail en mode Projet.
3. Le problème est évidemment flagrant aujourd’hui dans le monde économique en raison de
la mondialisation. Il est facile de trouver moins cher sur le papier, mais le résultat n’est pas
toujours maîtrisé. . .

10 CHAPITRE 1. UN PEU DE THÉORIE...

Chapitre 2
Un Projet en pratique
2.1 Comment est-ce que ça se passe ?
Avec un objectif correctement déﬁni on pourra mettre en place une organi-
sation Projet pour obtenir des résultats satisfaisants.
Comme on l’a vu rapidement au §1, le Projet va être organisé suivant plu-
sieurs axes qui correspondent au triangle QCD :
— La Qualité, qui doit être entendue au sens large, c’est à dire en premier lieu
la conformité des livrables produits par le Projet avec les exigences décrites
dans le cahier des charges.
— Les ressources qui représenteront un Coût dans le bilan du Projet.
— Le calendrier – on cherchera évidemment à respecter les Délais.
Le problème concret qui va se poser au Chef de Projet est que ces trois
critères sont fortement liés, et agir sur l’un pour l’améliorer risque d’en dégrader
un ou deux autres.
Par exemple, on pourra chercher à livrer plus tôt en conservant la même
qualité – soit une amélioration du délai – en mettant plus de ressources (personnes,
machines. . .). Mais il est alors fortement probable que le coût augmentera.
Si on veut livrer plus tôt tout en conservant la maîtrise des coûts, il faudra
généralement accepter une diminution de la qualité du livrable ﬁnal. Encore une
fois, qualité doit ici être pris au sens large puisqu’il pourra s’agir par exemple de
la diminution du périmètre du Projet (abandon de certaines exigences) sans pour
autant toucher à la qualité "perçue" du livrable.
Concrètement, une équipe Projet sera mise en place, qui regroupera les com-
pétences nécessaires pour l’atteinte des objectifs. Les membres de cette équipe ne
le seront pas forcément pendant toute la durée du Projet. On cherche en général
aujourd’hui à optimiser le taux d’utilisation des ressources, et une compétence qui
11

12 CHAPITRE 2. UN PROJET EN PRATIQUE
ne serait plus utilisée par un Projet pourra basculer sur un autre. A noter que c’est
un point de vigilance pour le chef de Projet : il ne faut pas libérer des ressources
trop vite si on a mal anticipé les besoins restants. Le manque de ressources est un
des principaux risques Projet 1
.
Les livrables à produire seront analysés pour déterminer les tâches nécessaires
à leur réalisation; ce qui correspond à la création de la Work Breakdown Structure
communément abrégée en WBS (Voir le §7.2.3). On aura alors une vision claire
de tout ce qu’il faut faire pour arriver au résultat désiré.
Ensuite, on pourra analyser les relations entre les tâches. Certaines devront
être effectuées dans un ordre donné, d’autres pourront être remplies en parallèle. . .
On pourra aussi travailler à cette étape sur l’estimation des durées prévisibles
(minimale, maximale) de chaque tâche et du Projet complet 2
.
Enfin on terminera cette phase de « préparation »par la prise en compte
des ressources. En fonction de leur capacité et de leur disponibilité, on pourra
construire un planning du Projet avec des durées ajustées pour les tâches. Le
Diagramme de Gantt – outil célèbre et symbole de la Gestion de Projet – permettra
de suivre et de gérer l’avancement du Projet 3
.
Lors de la phase d’exécution, la responsabilité du Chef de Projet sera de
faire réaliser les tâches dans le cadre (toujours le QCD. . .) défini. Il y a alors moins
d’éléments spécifiques à la Gestion de Projet. Il faudra toutefois assurer les activités
de suivi et de contrôle pour prévenir toute déviation. Le Chef de Projet veillera
donc en particulier au respect des processus définis en matière de documentation
et de reporting.
A côté de ce rôle de gestionnaire, le Chef de Projet devra être un leader
et maximiser l’efficacité de son équipe. Cet aspect sera primordial pour atteindre
la performance requise. Les membres de l’équipe doivent être motivés, et le cli-
mat de collaboration créé doit favoriser la créativité et l’émergence de solutions
innovantes 4
.
2.2 Quelques détails pas anodins
On a déjà fait remarquer que la conduite d’un Projet nécessitera des compro-
mis en vue d’atteindre un résultat satisfaisant pour toutes les parties impliquées.
Dans cette partie, nous allons souligner quelques points qu’il peut être important
de prendre en compte.
1. Voir le chapitre 10.
2. Cf. §7.5.2
3. Cf. §7.5.3
4. On présente quelques outils dans la partie V.

2.2. QUELQUES DÉTAILS PAS ANODINS 13
2.2.1 Une histoire de courbes
Remarque : les courbes qui sont présentées dans cette section donnent un
exemple (réaliste) d’allure générale mais ne sauraient être étudiées comme des
exemples réels.
L’évolution des dépenses (et donc le coût) d’un Projet est un indicateur
important à suivre.
Les dépenses cumulées sur un Projet augmentent au fur et à mesure qu’il pro-
gresse. Le problème est qu’une grande part de ces dépenses dépend de décisions qui
sont prises tôt au cours du Projet. En effet, dès les phases préliminaires (spécifica-
tion, conception préliminaire/choix de principes), les orientations données peuvent
avoir des conséquences importantes sur les coûts.
Cette situation est expliquée par le graphique suivant :
Temps
Dépenses
Coûts cumulés
Coûts induits par
les décisions
Figure 2.1 – Coûts induits par les décisions et des coûts globaux d’un Projet
La figure 2.1 appelle quelques commentaires :
— La courbe bleue qui représente les dépenses cumulées engagées sur un Pro-
jet est évidemment croissante au fur et à mesure que le Projet progresse.
On note la forme globale en « S »qui montre que les ressources financières
sont engagées lentement en début et en fin de Projet (la préparation et le
début des études nécessitent en général « relativement » peu de moyens,
tout comme les phases finales du Projet). Par contre, les phases de dé-
veloppement et production (milieu de la courbe) demandent un apport en

capitaux beaucoup plus important. C’est habituellement à ce moment qu’in-
terviennent les achats de matière et de production.
— La courbe orange représente les coûts induits par les décisions prises à un
moment donné du cycle Projet. On remarque ici la forme caractéristique
avec un pic qui intervient tôt avant une décroissance progressive.
Qu’est-ce que cela signifie ?
Les décisions prises en début de Projet peuvent avoir des impacts coûts très
importants par la suite. Par exemple, le choix d’une solution technique par
rapport à une autre peut – tout en respectant le cahier des charges dans les
deux cas – entrainer des différences de coûts énormes 5
.
Ces deux courbes montrent mettent donc en évidence un premier écueil que
devra surmonter le Chef de Projet : la majorité des dépenses sont effectuées en
fin de Projet, mais sur la base de décisions prises en début de Projet. Il
faudra donc éviter de choisir les mauvaises options dès le départ. . .
Les problèmes ne s’arrêtent pourtant pas là. Étudions maintenant les 2
courbes suivantes :
Temps
Connaissance
Possibilités
d'action
Figure 2.2 – Capacité d’action et connaissance acquise sur le Projet
Alors que nous venons de souligner l’importance de la nécessité de prendre
de bonnes décisions en début de projet, la figure 2.2 nous montre qu’à ce moment
5. Sans parler du loup, les différentes maisons des 3 petits cochons protègent toutes de la pluie,
mais elles n’ont manifestement pas coûté la même chose en raison des choix de réalisation. . .

2.2. QUELQUES DÉTAILS PAS ANODINS 15
on dispose rarement des connaissances requises. Cela se comprend puisqu’on a peu
travaillé sur le Projet à ce moment !
On voit donc ici encore qu’il faudra être capable de faire des compromis,
d’être flexible et de s’adapter en raison des incertitudes qui persisteront. Ce prin-
cipe d’adaptation est primordial dans une organisation Projet. En effet, on cher-
chera en permanence à organiser, planifier pour minimiser les incertitudes, mais il
sera impossible de tout prévoir 6 7
.
En conséquence, on il faut souligner un aspect essentiel du rôle du Chef de
Projet : la gestion de la connaissance. Il sera indispensable de capitaliser dès que
possible les acquisitions de savoirs (faire, être. . .) et les expériences.
Le chef de Projet devra orienter son travail suivant deux axes : le respect
des processus – qui permettent de documenter de façon standardisée et efficace
– et la gestion humaine parce qu’on devra encourager le partage et la commu-
nication qui permettent de capter l’information « diffuse ». En effet, une grande
part de la connaissance ne s’intègrera pas dans les cadres formels définis. Pourtant
l’expérience, par exemple, constitue un apport inestimable et doit être prise en
compte.
2.2.2 Un rôle plus large que ce qu’on pensait ?
Le point de la gestion de la connaissance illustre une des limites de la for-
mation académique à la Gestion de Projet. L’apprentissage permettra d’acquérir
aisément la maîtrise des processus; par contre les aspects humains ne sont en gé-
néral pas ou peu abordés. Il faut donc un travail personnel, ajouté à l’expérience,
pour se construire des bases solides dans différents domaines :
— Le management d’équipe
Bien que le Chef de Projet ne soit souvent pas un supérieur hiérarchique
de tous les membres de l’équipe, il se retrouve avec un groupe à gérer. Il
devra donc de fait assumer les rôles d’un manager classique (en très résumé :
décider, motiver et développer les talents).
— La communication
Corollaire indispensable aux aptitudes au management, la bonne communi-
cation est nécessaire à la réussite d’un Projet. Qu’elle soit interne (avec les
membres de l’équipe) ou externe (avec les fournisseurs ou les clients), elle
doit être efficace. C’est à dire factuelle et exhaustive.
6. On ne parlera pas de la loi de Murphy puisqu’il paraît qu’il s’agit d’un concept empirique,
sinon fumeux.
7. Il n’empêche qu’elle semble s’appliquer en permanence quand on gère un Projet donc il
vaut mieux réfléchir pour gérer les conséquences.

Factuelle parce que toutes les parties impliquées partagent un objectif com-
mun, et il ne faudra donc pas laisser de place aux interprétations et à
l’incertitude dans la transmission de l’information. Par exemple en interne
cela permettra que tout le monde ait le même niveau de connaissance pour
travailler. En externe, il sera toujours utile de s’appuyer sur des données
concrètes pour les discussions qui peuvent survenir par exemple en situation
de crise.
L’exhaustivité dans la communication est elle nécessaire pour différentes
raisons. Parmi elles il y a en premier lieu le fait de donner à tous toute la
matière nécessaire à leur travail (évident. . .). Mais cela est aussi extrême-
ment important sur le plan humain : ceux qui n’auront pas le même niveau
d’information se sentiront exclus et moins impliqués, d’où une baisse de
motivation.
— Le leadership
Le Chef de Projet gère une équipe et doit en tirer le meilleur pour atteindre
les objectifs. On a parlé du management ci-dessus, mais il devra aller au-delà
en inspirant et en entraînant son groupe.
Dans les situations difficiles, quand on est confronté à des difficultés ou
des blocages, il est indispensable qu’un leader donne l’impulsion et amène
chacun à s’engager pour le succès de l’équipe. Le Chef de Projet doit tenir
ce rôle. Pour cela, il doit incarner son Projet, c’est à dire le connaître, le
maîtriser et s’approprier les objectifs.
Le Chef de Projet doit être un élément stabilisateur et entraînant pour ses
partenaires.
— La gestion d’entreprise
Le Projet s’inscrit dans la stratégie globale de l’entreprise; le Chef de Projet
doit être capable de comprendre le mode de fonctionnement de la société
pour s’assurer que son projet s’y intègre et y participe comme attendu.
Ainsi, il peut arriver que certains choix soient faits suivant des critères
qui auront été définis globalement dans l’entreprise, alors qu’une décision
prise isolément aurait été différente. Il faut donc pouvoir étudier son Projet
selon de multiples points de vues (techniques, comptable, financier) afin de
pouvoir le promouvoir ou le défendre efficacement.
La fonction de Chef de Projet va donc au-delà de l’analyse de tâches et de
la planification. A son échelle et pour le périmètre de son Projet, il est comme un
entrepreneur qui doit pouvoir analyser et prendre des décisions dans de multiples
domaines.

Chapitre 3
Différents types de Projets
3.1 Une première classification qualitative...
Une définition du concept de Projet a été donnée au §1. Elle est cependant
très large et peut couvrir un spectre important d’activités.
On peut par exemple distinguer « qualitativement » différents types de Pro-
jets :
— Les Projets locaux sont mis en place à l’intérieur d’une entité définie, comme
un service. Les conditions d’exécution sont donc bien maîtrisées, et tout le
monde est (normalement) au courant de, et concerné par les objectifs.
— Un Projet transversal fait intervenir plusieurs entités qui amèneront des
compétences variées. On pourra avoir un schéma d’organisation horizontal
quand les intervenants sont de même niveau hiérarchique, ou vertical dans
le cas contraire.
Dans ce type de Projet, on sera confronté plus vite à des problèmes de dispo-
nibilité des ressources, ou de conflits entre le Projet et les entités d’origines
des ressources.
— Les Projets « hors-structure »sont mis en place quand l’objectif est très im-
portant pour l’entreprise. On constitue alors une équipe dédiée et prélevant
les ressources nécessaires dans les différents services. Cette équipe n’est plus
formellement intégrée à l’organigramme hiérarchique de l’entreprise. Cela
lui donne de l’autonomie et plus de pouvoir pour atteindre les objectifs fixés
au Projet.
— Les Projets « externes »mettent en œuvre des coopérations externes à l’en-
treprise (par exemple des co-entreprises, des joint-ventures). Ce montage est
utilisé quand il y a des investissements importants à réaliser, ou si certaines
compétences clés sont exclusives à un intervenant.
17

18 CHAPITRE 3. DIFFÉRENTS TYPES DE PROJETS
3.2 Une classification un peu plus formelle
On vient de voir qu’on peut déjà distinguer différents types de Projets suivant
les intervenants qui y participent. Pourtant cette analyse manque de rigueur parce
que des projets très « simples » pourront par exemple faire appel à des ressources
de différentes entreprises, alors que des projets « complexes » pourraient rester
confinés dans un seul service.
Comment alors classer les différents projets ?
On pourra se baser sur deux critères principaux, a savoir leur taille et leur
complexité.
3.2.1 Qu’est-ce que la taille d’un Projet ?
La taille d’un Projet se définira le plus souvent par son budget. Le budget
inclut toutes les dépenses à engager pour le Projet (salaires des intervenants, achats
matériels, investissements. . .). Plus le budget sera important, plus le Projet sera
considéré comme gros.
Ce critère est donc assez logique et intuitif. Pris seul, on comprendra qu’un
« gros » Projet sera très important pour une entreprise, parce qu’il demandera
d’engager beaucoup de moyens, et donc pourrait constituer un risque si les résultats
espérés ne sont pas au bout.
Pourtant, on conviendra que pour un budget – et donc une taille – donné,
on pourra avoir des typologies de Projets très variées avec des niveaux potentiels
d’impact et de risques très variables.
3.2.2 Et la complexité ?
La complexité d’un Projet sera définie par le niveau d’incertitude qui le
caractérise. L’incertitude est généralement fonction de deux paramètres :
1. Le nombre d’inconnues.
Tout Projet implique un certain nombre d’inconnues, c’est-à-dire d’éléments
qu’il faudra découvrir, créer, inventer. . . Plus il y en aura, plus le Projet
sera considéré comme complexe.
2. Le nombre d’acteurs différents.
On aura d’autant plus d’interactions possibles qu’il y a d’intervenants pour
un Projet. On aura alors une complexité croissante parce qu’il faudra ma-
nager les relations entre les différentes entités qui pourront avoir chacune
des visions propres du Projet. Ce point sera d’autant plus sensible qu’il y
aura des acteurs de différentes entreprises.

3.2. UNE CLASSIFICATION UN PEU PLUS FORMELLE 19
Ainsi on pourra avoir différents types de Projets qui pourront être classés
selon ces deux critères, par exemple :
Taille
Complexité
Projet R&D
Petit Projet
local
Projet
industriel
Nouveau
produit
Projet de
réorganisation
Figure 3.1 – Exemples de différents types de Projets
La figure 3.1 montre que les projets peuvent être classés suivant différentes
typologies. Le chapitre suivant détaille un des outils qui peut être utilisé pour tenir
compte de ces différents cas.
3.2.3 Pour aller plus loin : le profil de Projet
On vient donc de voir qu’on peut déjà se faire une première idée du type de
Projet sur lequel on va travailler en étudiant sa taille et sa complexité. Suivant les
éléments étudiés, on pourra adapter l’organisation et le management.
Cependant, cette première classification reste sommaire. Elle ne pourra pas
rendre compte de la diversité des situations qu’on pourra rencontrer. Il pourra
donc être intéressant de se faire une idée plus précise.
Le profil de Projet
Une approche scientifique classique pour mieux décrire un phénomène consiste
à multiplier les critères d’évaluation pour disposer de multiples points de vue. Il
est possible de procéder de la même façon en gestion de Projet.
Pour aller plus loin que l’approche basique décrite au paragraphe précédent,
peut ainsi définir un Profil de Projet.

Ce profil sera défini sur plusieurs critères :
— La taille
Ce critère a déjà été défini au paragraphe 3.2.1.
— Les enjeux
Les enjeux d’un Projet traduisent l’importance qu’il aura aux yeux des
Clients. En pratique, plus les enjeux seront importants, plus on devra être
attentif aux processus et aux contrôles afin de s’assurer qu’on reste en per-
manence en ligne avec les objectifs. Toute déviation par rapport au plan
initial devra être identifiée au plus tôt.
— Le type de livrables (matériels/immatériels)
Le type de livrables aura des conséquences importantes sur l’organisation
du Projet. En général – attention, ceci ne constitue pas une vérité absolue –
des livrables immatériels autoriseront une plus grande flexibilité et une plus
grande latitude d’organisation. Par contre, des livrables matériels imposent
souvent une rigueur plus importante en raison des flux matériels et de la
qualité à gérer.
— La complexité
De même que la taille, ce paramètre a été abordé plus haut (au paragraphe
3.2.2).
— Le niveau d’innovation
Ce paramètre pourra avoir une influence sur le niveau de risque à gérer pour
le Projet. Un Projet où la composante innovation est prépondérante deman-
dera une attention particulière. En effet, il y aura un risque non négligeable
de ne pas parvenir aux solutions « techniques » requises. Il pourrait donc
falloir affecter des ressources plus importantes en hommes ou en temps.
— L’autonomie de l’équipe
L’autonomie de l’équipe sera liée aux relations de dépendance qu’elle en-
tretient avec le reste de l’entreprise. Plus il y aura de liens, plus les risques
d’interférences seront importants, ainsi que les conflits d’intérêts potentiels.
Un équipe peu autonome, c’est-à-dire avec des ressources qui ne sont pas
explicitement et clairement affectées, souffrira probablement de consignes
contradictoires.
— L’intégration du Projet dans l’organisation
Ce dernier point est important, il traduit l’adéquation entre le Projet et la
stratégie de l’entreprise. Il est évident qu’un Projet qui s’intègre parfaite-
ment dans la vision de l’entreprise bénéficiera d’un soutien plus important.
L’évaluation d’un Projet selon ces critères permet de construire un dia-
gramme synthétique :

3.2. UNE CLASSIFICATION UN PEU PLUS FORMELLE 21
Taille
Enjeu
Livrables matériels
Complexité
Niveau d'innovation
Autonomie
Intégration dans l'organisation
FAIBLE
FORT
Figure 3.2 – Quelques critères de définition d’un profil de Projet
L’intérêt d’une telle étude au lancement d’un Projet pour le Manager sera de
pouvoir être préparé pour adapter sa conduite. En fonction du profil qui aura été
identifié, le Chef de Projet pourra mettre l’accent sur les procédures appropriées.
Il faudra en particulier tenir compte des liens qu’aura l’équipe Projet avec
l’entreprise. Afin d’éviter tout problème potentiel (par exemple conflit de res-
sources), on devra s’assurer que toutes les personnes impliquées ou simplement
affectées par le Projet sont en phase avec les objectifs et les méthodes pour les
atteindre. Le Projet doit faire l’objet d’un consensus.
Le profil de Projet est donc un outil intéressant parce qu’il permet d’orienter
sa vigilance de manière réfléchie en fonction des situations.
Il permet de s’organiser avec pertinence.

Chapitre 4
Comment est structuré un
Projet ?
On a vu au chapitre 1 qu’un Projet est un ensemble de tâches qui se déroulent
par étapes. On va montrer rapidement dans ce chapitre qu’on peut avoir diﬀérentes
organisations qui auront un impact sur la performance.
4.1 Structure séquentielle
La première organisation est un enchaînement chronologique des étapes :
Avant-Projet
Conception
Dé¡nition
Industrialisation
Figure 4.1 – Principe d’une structure séquentielle de Projet
23

24 CHAPITRE 4. COMMENT EST STRUCTURÉ UN PROJET ?
Cette structure intuitive peut convenir pour des Projets simples, constitués
d’étapes identifiées et indépendantes les unes des autres. En pratique, on se heurte
rapidement à des difficultés qui compromettent l’efficacité et parfois même la réus-
site du Projet.
En effet, avec un tel fonctionnement, tout problème obligera au mieux à
temporiser pour apporter une solution, au pire à revenir en arrière s’il s’avère que
des corrections plus lourdes doivent être apportées. Par exemple, si on prend le
cas d’un développement de nouveau produit technique, une mauvaise conception
pourrait conduire à l’impossibilité d’assembler certains composants. Il faudra alors
revenir à la phase de développement pour modifier certains choix techniques et être
finalement en mesure de produire. On comprend donc les difficultés possibles et
les pertes qui pourraient advenir.
Le principal inconvénient tient donc dans l’absence de prise en compte des
besoins des tous les intervenants au cours du processus.
4.2 L’ingénierie simultanée/collaborative
Pour remédier aux problèmes soulevés au paragraphe précédent, les entre-
prises ont cherché à faire en sorte que tous les acteurs du Projet travaillent ensemble
tout au long du processus. Ces travaux ont donné lieu à l’organisation collaborative
(voir figure 4.2).
Avant-
Projet
Conception
Développement
Industrialisation
Figure 4.2 – Principe d’une structure simultanée de Projet
Dans cette organisation, l’objectif est de faire travailler au maximum les
équipes en collaboration. On cherchera donc à développer la communication pour
que les besoins des phases postérieures soient pris en compte. Concrètement, les
équipes de conception seront constituées de concepteurs (évidemment. . .), mais
aussi de représentants de la production, de la maintenance voire des services de
vente. Ainsi, à tout moment, les contraintes de toutes les fonctions impliquées

4.3. COMMENT INTÉGRER TOUT ÇA DANS L’ENTREPRISE ? 25
pourront être prises en compte. Ce mode de fonctionnement demande une certaine
ouverture d’esprit parce que tout le monde doit communiquer les informations
dont il dispose. Il faut donc éviter les silos dus à la rétention d’information 1 2
.
La mise en œuvre d’une organisation collaborative passera fréquemment par
la constitution d’un plateau Projet. Il s’agit alors de regrouper en un même lieu
(le plus souvent physique, mais on peut tirer parti des outils de communication
modernes) l’ensemble des compétences nécessaires. Ce plateau pourra avoir une
durée de vie limitée à des phases définies, ou rester en fonction tout au long du
Projet.
4.3 Comment intégrer tout ça dans l’entreprise ?
On vient de voir qu’il peut y avoir différentes façons de travailler sur un
Projet suivant la façon dont sont organisées les différentes étapes. En pratique, il
faudra donc constituer des équipes qui pourront assurer les travaux requis. Ces
ressources devront être prélevées dans les effectifs de l’entreprise.
On détaille dans ce chapitre quelques structures classiques.
4.3.1 Structure fonctionnelle
La structure fonctionnelle décrite à la figure 4.3 est parmi les plus répandues
parce que très simple à mettre en place.
Directionsmétiers
Ressources métiers
travaillant sur le
Projet.
Figure 4.3 – Organisation fonctionnelle de l’équipe Projet
Les ressources devant prendre part au Projet travaillent dessus dans le cadre
de leurs activités quotidiennes au sein de leur entité d’appartenance. Ce mode
1. De façon générale, la rétention d’information est un mal fréquent aujourd’hui. On explique
que l’information c’est le pouvoir, mais une information non partagée n’a aucune valeur. Pire,
elle peut être à l’origine de graves problèmes.
2. Un point qu’on retrouve en Ingénierie Système – voir le chapitre 12.5.

de fonctionnement est extrêmement simple puisqu’il n’y a aucune organisation
spécifique.
Une analyse rapide amène cependant certains commentaires :
— Il n’y a pas de management de Projet au sens strict dans cette structure.
Il est donc évident qu’on ne pourra pas gérer de façon efficace les arbi-
trages, ni soutenir les intérêts du Projet aussi bien qu’avec une structure de
management dédiée.
— Les personnes travaillant sur le Projet restent rattachées hiérarchiquement
et fonctionnellement à leur entité d’origine. On pourra donc se retrouver face
à des situations de conflit lorsque les besoins du Projet iront à l’encontre
de demandes internes à la structure métier. Il faudra alors que les priorités
soient clairement définies, en tenant compte des conséquences des choix qui
seront faits.
On ne saurait ainsi accepter des critiques sur d’éventuels retards si les per-
sonnes devant travailler sur un Projet sont sans cesse interrompues par des
demandes sans rapport issues de leur service métier.
— Les intervenants sur le Projet risquent de travailler de façon isolée, en raison
du manque de coordination au niveau Projet. De plus on peut faire face à
des problèmes de communication et de partage d’information. Cela pourrait
amener à des déviations par rapport au plan d’action et être à l’origine de
risques pour la tenue du planning.
— Les lots de travail devront être suffisamment indépendants pour pouvoir
être traités isolément. En effet, le manque de flexibilité inhérent à la struc-
ture fonctionnelle fait qu’il pourra être difficile de coordonner les ressources
requises dans le cas de tâches faisant appel à différentes disciplines.
La structure fonctionnelle sera donc adaptée à des Projets simples pour les-
quels la décomposition en tâches pourra être définie clairement.
4.3.2 Structure coordonnée
Dans ce mode de fonctionnement, on met en place une organisation Pro-
jet qui sera composée d’un ensemble de Chefs de Projets métiers assistés d’un
Coordinateur global (voir la figure 4.4 page 27).
Ce mode de fonctionnement permet de s’affranchir du principal inconvénient
d’une organisation fonctionnelle (chapitre 4.3.1) puisque le Projet aura une repré-
sentation officielle via le Coordinateur. En revanche, les liens hiérarchiques restent
internes aux services métiers et on pourra donc toujours être confronté à des conflits
dans les situations difficiles. Le Coordinateur manquera alors de pouvoir.
Ce type de structure pourra toutefois être parfaitement adaptés à certains
Projets transversaux tels que des actions de réduction de coûts, ou la mise en place

4.3. COMMENT INTÉGRER TOUT ÇA DANS L’ENTREPRISE ? 27
Directionsmétiers
Ressources métiers
travaillant sur le
Projet.
Responsables
Projet métiers
Coordinateur
Figure 4.4 – Organisation coordonnée de l’équipe Projet
de nouvelles méthodes (par exemple le déploiement de méthodes Lean à travers
l’entreprise.
4.3.3 Structure avec une Direction de Projet
On reprendra ici la structure coordonnée décrite au chapitre 4.3.2, mais en
donnant de façon oﬃcielle un pouvoir hiérarchique au Coordinateur qui deviendra
réellement un Directeur de Projet :
Directionsmétiers
Ressources métiers
travaillant sur le
Projet.
Responsables
Projet métiers
Directeur
de Projet
Figure 4.5 – Organisation avec un Directeur Projet
La mise en place de relations hiérarchiques oﬃcielles conduit à une orga-
nisation matricielle; c’est-à-dire que les intervenants sur le Projet auront deux
supérieurs 3
. On retrouvera alors les problèmes de gestion de priorités.
3. 2 constitue d’ailleurs un minimum puisque c’est le premier entier supérieur à 1. . . En

Le Directeur de Projet aura beaucoup plus de pouvoir, mais les rattache-
ments métiers restent existants; il n’aura donc pas la responsabilité et l’autonomie
complète pour la gestion de son équipe.
Ce type de structure offre toutefois beaucoup de flexibilité parce qu’il permet
d’adapter le travail de l’équipe Projet suivant les besoins. C’est donc une bonne
façon d’optimiser l’utilisation des ressources.
4.3.4 L’équipe Projet dédiée
Dans le cadre de gros Projet, on ne pourra être limité par les conflits poten-
tiels qui peuvent apparaître avec les structures décrites jusqu’ici. Les entreprises
mettront alors en place des équipes Projet dédiées qui bénéficieront d’une autono-
mie plus importante :
Directionsmétiers
Ressources métiers
travaillant sur le
Projet.
Responsables
Projet métiers
Directeur
de Projet
Figure 4.6 – Organisation avec une équipe Projet dédiée
Les ressources sont alors prélevées dans les différents services métiers en
fonction des compétences qui sont nécessaires sur le Projet. Elle sont entièrement
dédiée au Projet et peuvent s’y consacrer à plein temps.
C’est la situation la plus favorable pour garantir une grande cohésion et
l’avancement du Projet.
Ce type de structure est mis en place pour les gros Projets en mode ingénierie
simultanée.
pratique, on est souvent amené à travailler sur plusieurs Projets à la fois – d’où un nombre de
chefs directs compris entre 2 et n.

4.4. IL RESTE L’HUMAIN 29
4.4 Il reste l’humain
On a vu dans tout ce chapitre différents types d’organisation pour les Projets
qui permettent de structurer le travail de façon plus ou moins autonome. Le choix
devra être fait en tenant compte de différents paramètres :
— Les caractéristiques intrinsèques du Projet (taille/complexité - profil) : plus
le Projet considéré sera important et complexe, plus on aura intérêt à mettre
en place une équipe dédiée qui permettra de sécuriser le déroulement.
— Les moyens disponibles dans l’entreprise : il sera évidemment plus compliqué
de dégager des ressources pour les consacrer à 100% à un Projet dans une
petite entreprise que dans une grande. On retombe ici dans le domaine des
compromis qu’il faudra gérer tout au long du pilotage du Projet.
On devra aussi garder à l’esprit que l’organisation théorique du Projet ne
fait pas tout; elle ne saurait être considérée comme une garantie de réussite.
Au final, compteront bien plus l’engagement de l’équipe et l’assurance de
disposer des moyens nécessaires. Il faudra faire attention, en tant que Chef de
Projet, de ne pas verser dans un travail uniquement procédurier, pour coller aux
exigences définies par les processus de l’entreprise. L’objectif est de parvenir à un
résultat identifié et non de remplir et cocher des formulaires.
Il faudra aussi donner au Chef de Projet les pouvoirs et responsabilités né-
cessaires pour qu’il puisse prendre les décisions nécessaires suivant les situations,
et se faire respecter dans les moments de tension.
Le Chef de Projet devra donc être flexible pour pouvoir s’adapter. Il devra
anticiper au maximum les situations à venir pour pouvoir agir au plus tôt en cas
de besoin. Il est beaucoup plus efficace d’avoir prévu un plan d’action au cas où
un risque identifié se concrétise plutôt que de réagir après coup sans être préparé.
Enfin on reviendra sur l’aspect Leadership : le Chef de Projet devra le faire
vivre et faire que tous les intervenants se sentent concernés et impliqués de la
même façon que lui.

Troisième partie
Le déroulement d’un Projet
31

Chapitre 5
Pourquoi différentes phases ?
5.1 Une question d’organisation
On a brièvement expliqué dans la partie précédente qu’un Projet comportait
en général plusieurs phases. Cette décomposition est nécessaire pour différentes
raisons :
— Il est plus aisé de gérer des éléments de taille maitrisée qu’un Projet mono-
lithique. On verra d’ailleurs plus loin que ce principe s’applique en pratique
de façon récurrente sur un Projet avec l’objectif de diviser les opérations à
effectuer pour obtenir des tâches élémentaires maîtrisables tant pour leur
exécution que pour leur gestion.
— Les différentes phases ont une cohérence avec des objectifs définis. C’est-
à-dire que pour chaque phase, les acteurs pourront se concentrer sur un
type d’actions données (par exemple de la recherche de solutions tech-
niques/innovation, de la gestion de documentation), ce qui va permettre
d’optimiser la gestion de ressources.
Souvent durant les phases de conception préliminaire on impliquera des ex-
perts qui sont à même d’orienter vers des choix innovants, puis ils passeront
la main à des ingénieurs moins expérimentés pour le développement.
— Les phases permettent de s’assurer qu’on reste en ligne avec les prévisions.
Chacune d’entre elles peut être appréhendée comme un mini-projet avec
des exigences et des livrables. On pourra donc à chaque fin de phase avoir
un statut précis de l’avancement du Projet.
5.2 Et donc, comment est-ce mis en place ?
La décomposition des Projets en grandes phases suit souvent le même schéma
général – les dénominations exactes peuvent bien sûr varier – et on retrouvera
33

34 CHAPITRE 5. POURQUOI DIFFÉRENTES PHASES ?
généralement :
Lancement
Conception
Production
Développement
Test
Livraison
Figure 5.1 – Organisation générale des phases Projet
1. La phase de spécification
2. La phase de lancement
3. La phase de conception
4. La phase de développement
5. La phase de production/industrialisation
6. La phase de test
7. La phase de livraison/mise en service
8. La phase de maintenance
9. La phase de documentation
Ces phases se retrouvent globalement dans tous les projets. Elles peuvent
être groupées et ne pas apparaître explicitement, mais tout Projet produira des
livrables qui correspondent à ces étapes.
La fin de chaque phase sera marquée par un jalon qui pourra être symbolique,
ou prendre la forme d’une réunion de revue pour évaluer l’adéquation des résultats
obtenus pour la phase avec les exigences d’entrée 1
. Ces réunions seront souvent
des dates contractuelles avec le Client du Projet. Dans ce cas, on aura en général
une liste de livrables intermédiaires à fournir.
Par exemple, on pourra avoir une Preliminary Design Review (PDR) en fin de
phase de conception, durant laquelle seront passés en revue les principes de concep-
tion définis pour les livrables du Projet. Elle permettra de valider suffisamment tôt
1. On pourra voir à ce sujet le chapitre 11.1

5.2. ET DONC, COMMENT EST-CE MIS EN PLACE ? 35
leur pertinence avant d’engager d’importantes ressources pour le développement
ou la fabrication 2
.
2. On reviendra un peu plus en détail là-dessus au chapitre 8.1.

36 CHAPITRE 5. POURQUOI DIFFÉRENTES PHASES ?

Chapitre 6
La phase de spécification
La phase de spécification n’est pas toujours intégrée au cycle classique du
Projet, pourtant elle est essentielle pour envisager le succès. Il est indispensable
que les exigences de départ soient parfaitement définies pour pouvoir développer
des solutions qui y répondent. Elles définissent ce que devra être le livrable final
du Projet.
6.1 Le Cahier des Charges
6.1.1 Présentation rapide
Le document d’entrée principal pour le Projet sera le Cahier des Charges 1
qui regroupe la liste des exigences que devra satisfaire le livrable. Le Cahier des
Charges est un document qui est souvent fourni par le Client du Projet dont il
décrit précisément le besoin.
Le Cahier des Charges 2
est souvent qualifié de Fonctionnel parce qu’il décrit
le système à fournir en terme de fonctions qu’il devra remplir ou respecter (par
exemple des standards ou des normes – on parle alors de Fonctions Principales)
et de « fonctions » qu’il devra supporter, sinon subir (par exemple la résistance à
des conditions climatiques données) – dites fonctions contraintes.
Le Cahier des Charges est souvent issu d’une démarche d’Analyse Fonction-
nelle 3
, dont l’objectif est de définir les fonctions que doit avoir un système pour
répondre aux besoins d’un utilisateur.
1. Parfois appelé spécification – issu de l’anglais.
2. Il existe des normes pour les Cahiers des Charges, par exemple la NF X 50-151
3. ici ce sera la NF X50-150
37

38 CHAPITRE 6. LA PHASE DE SPÉCIFICATION
6.1.2 Comment l’écrit-on ?
Le principe consiste à définir le système à étudier – sur lequel devra agir le
livrable du Projet – et les acteurs (personnes, autres systèmes, environnement. . .)
qui interagissent avec lui 4
.
On pourra alors construire un diagramme (connu comme la bête à cornes)
qui exprimera les relations entre le système et son environnement :
Dans quel but :
POUR QUOI ?
Sur QUOI le
système agit-il ?
A QUI le
système rend-il
service ?
Système
Figure 6.1 – Diagramme « Bête à cornes » pour l’identification des besoins
Cette représentation aidera à visualiser le système et à identifier les besoins.
Ils devront ensuite être analysés et validés, en particulier pour s’assurer de leur
pérennité dans le temps.
Une fois les besoins répertoriés, on s’intéressera aux relations entre le produit
et l’environnement sous l’angle des fonctions : pour les différents cas d’utilisation,
il s’agira d’identifier les actions du produit en relation avec son environnement (au
sens large, c’est à dire physique et fonctionnel).
On distinguera deux types de fonctions :
— Les fonctions de Transfert, qui décrivent la relation d’un ou plusieurs élé-
ments de l’environnement avec le produit.
— Les fonctions Contraintes qui sont des relations directes entre un des acteurs
de l’environnement et le produit.
L’ensemble de ces fonctions pourront être synthétisées sur un diagramme
« Pieuvre »˜:
4. On parle en fait ici déjà d’Ingénierie Système qu’on détaillera (un peu) au chapitre 12.5.

6.1. LE CAHIER DES CHARGES 39
Produit
Acteur 2
Acteur n
Acteur 1
FTn
FC
Figure 6.2 – Diagramme « Pieuvre » pour recenser les fonctions
On se retrouvera à ce stade avec un inventaire des fonctions auxquelles devra
répondre le produit. Elles devront finalement être analysées afin de définir, pour
chacune d’entre elles, les critères d’acceptation selon un tableau :
Table 6.1 – Table d’analyse des Fonctions
Fonction de Transfert / Contrainte Critère Niveau Flexibilité
FT1 aa1 bb1 cc1
FT2 aa2 bb2 cc2
. . . . . . . . . . . .
FTn aan bbn ccn
FC1 aa1 bb1 cc1
FC2 aa2 bb2 cc2
. . . . . . . . . . . .
FCn aan bbn ccn
Le tableau 6.1 fait référence à quelques notions qu’on doit préciser un mini-
mum :
— Le Critère est un état (logique, valeur numérique, ou quoi que ce soit per-
mettant d’évaluer de façon objective une fonction) qui permet de dire si une
fonction est remplie ou si une contrainte est respectée.
— Le Niveau est la valeur minimale attendue pour accepter le Critère.
— La Flexibilité renseigne sur le caractère impératif ou non de la Fonction
dont il est question. En effet, on a déjà dit qu’un Projet fait toujours l’objet
de compromis (par exemple par rapport au Triangle QCD – voir le chapitre
1.1). La Flexibilité renseignera donc sur les possibilités de relâcher plus ou
moins certaines exigences pour atteindre les objectifs globaux.
La Flexibilité est souvent indiquée de façon synthétique sous forme de
Classes de flexibilité:

— F0 : flexibilité nulle, niveau impératif.
— F1 : flexibilité faible, niveau peu négociable.
— F2 : flexibilité moyenne, niveau négociable.
— F3 : flexibilité forte, niveau très négociable.
L’inventaire exhaustif des fonctions à remplir par le produit va permettre la
rédaction du Cahier de Charges, qui constituera le document contractuel définis-
sant le résultat attendu du Projet.
Ce caractère contractuel amène quelques commentaires :
— La rédaction du Cahier des Charges se fait impérativement avec des
utilisateurs 5
. Ils doivent être les acteurs principaux dans la phase de re-
cueil et d’inventaire des besoins à satisfaire.
On a trop souvent vu des Projets arrivant à leur terme avec la mise en
service du Produit auprès des utilisateurs pour entendre dire « Oui, c’est
très bien, mais pourquoi n’avez-vous pas fait comme ça ? (. . .) ».
Un besoin exprimé dès le départ ne coûte pourtant pas forcément plus cher
(en ressources et en temps).
— Des experts (c’est-à-dire connaissant le domaine du Produit) doivent parti-
ciper au travail sur le Cahier des Charges :
1. Au moment de sa rédaction, en analysant les besoins exprimés par les
utilisateurs pour s’assurer de leur pertinence. C’est là une phase com-
plexe parce qu’il ne faudra pas apporter de modifications qui condui-
raient à un Produit qui ne soit plus conforme aux attentes des utilisa-
teurs.
2. Mais il faudra valider la faisabilité pour éviter d’avoir une spécification
extraordinaire qui ne resterait qu’à l’état d’ouvrage de science-fiction.
— Il est indispensable – au tout début du Projet – de passer en revue de façon
approfondie le Cahier des Charges avec le Client du Projet. Il faut valider
ensemble la prise en compte de chaque exigence et éliminer toute incertitude
ou incompréhension.
Pour ce faire, on construit souvent des Matrices de conformité, tableaux
qui listent les exigences, et pour chacune d’entre elles, un statut associé :
Conforme, Non Conforme, Non Applicable, et éventuellement Partiellement
Conforme, avec les justifications associées. Cette matrice est souvent deman-
dée dans un dossier de réponse à un appel d’offre.
Le Cahier des Charges est un contrat entre le Client et l’équipe Projet. Les
deux parties doivent donc être d’accord sur les termes.
5. On met utilisateurs en gras et souligné parce que que ce point est e s s e n t i e l.
Il n’y a que les utilisateurs qui sont à même de connaître et définir précisément leur besoin.

Le Cahier des Charges une fois validé par les parties impliquées, l’équipe
Projet dispose d’une liste d’exigences qu’elle devra remplir.
6.1.3 Qu’est-ce qu’une exigence ?
Note : On ne va pas ici approfondir les notions de gestion d’exigences. Il
s’agit d’un domaine complexe, qui fait l’objet de standards – normalisés ou de
facto. On aborde simplement les concepts pour savoir de quoi on parle...
Une exigence est une description documentée d’un besoin qui exprime ce
qu’un produit ou un service doit faire. Elle doit permettre de fournir une réponse
ciblée et adaptée. Il ne faut donc pas qu’elle laisse de place à une interprétation
personnelle du sens du besoin. Une bonne exigence laisse de la place à la créativité,
parce qu’elle n’impose pas de solution, mais assure que le besoin sera satisfait.
Pour cela, une exigence devra posséder certaines caractéristiques :
— La cohésion : une exigence ne doit concerner qu’une seule et unique carac-
téristique du produit final du Projet. Toutefois, elle pourra être d’un niveau
plus ou moins élevé. C’est à dire que le fait de s’y conformer pourra néces-
siter une prise en compte dans différents domaines de l’étude du produit.
Par exemple, si un Cahier des Charges indique qu’un produit doit pouvoir
être utilisé dans un environnement tropical, on pourra devoir tenir compte
d’éléments tels que la température élevée, le fort taux d’humidité, ceci pour
des composants mécaniques ou électriques.
L’analyse du Cahier des Charges doit permettre d’identifier ces cas, et
d’écrire une spécification interne – souvent de plus bas niveau 6
. Les exi-
gences pourront alors être précisées si besoin, dérivées (on décompose une
exigence de haut niveau en exigences plus spécifiques – par exemple pour
notre environnement tropical, on pourra spécifier que « les matériaux utili-
sés ne devront pas être sujets à la corrosion » et que « les cartes électroniques
devront être protégées par un vernis »).
— Être complète : elle doit fournir l’information nécessaire et suffisante pour
permettre de développer le produit qu’elle concerne.
— La cohérence : elle ne doit pas entrer en contradiction avec d’autres exi-
gences (explicites dans le Cahier des Charges) ou des normes ou réglemen-
tations à respecter.
— L’indivisibilité : une exigence ne doit lister dans sa rédaction qu’un seul
élément du produit final auquel elle s’applique. Par exemple, une exigence
6. Cet aspect est d’ailleurs codifié dans plusieurs standards. Par exemple, la MIL-STD-961D
définit un cadre complet pour le cycle de vie d’équipements militaires qui comprend explicitement
une Performance Specification de haut niveau qui devra être déclinée en Detail Specifications de
plus bas niveau.

rédigée « Le produit devra résister aux huiles minérales et aux acides »devra
être scindée en deux pour traiter individuellement de chaque liquide.
— La traçabilité : cela signifie qu’une exigence doit venir de quelque part (soit
le besoin d’origine, soit une exigence de niveau supérieur) et que cette struc-
ture doit être documentée pour pouvoir analyser ces dépendances.
En pratique, la documentation se fait souvent au travers de la numérotation
des exigences.
— La validité (temporelle) : une exigence peut avoir une période de validité
définie (par exemple en raison d’évolutions techniques). Elle doit donc être
d’actualité pour sa prise en compte.
Des exigences peuvent ainsi être « annulées »(on parle d’obsolescence) ou
mises à jour. Dans ce dernier cas, la version de l’exigence doit être documen-
tée pour éviter de se référer à une révision obsolète. Cela se fait généralement
au travers d’indices pour la numérotation de l’exigence.
— La clarté : elle ne doit pas être ambiguë. Il faut utiliser un langage clair,
standard et précis. On ne doit pas laisser de place au doute ou à l’inter-
prétation personnelle. Une exigence ne doit traiter que d’éléments factuels
objectifs.
— La flexibilité : ce concept a été défini au chapitre 6.1.2. Il s’agit d’indiquer
dès le Cahier des Charges la latitude dont disposera l’équipe Projet pour
relâcher plus ou moins certaines exigences en cas de difficultés ou de blocage.
— La vérifiabilité : une exigence doit définir un état recherché grâce à des
éléments mesurables, démontrables, observables ou analysables. Le but est
de pouvoir prouver qu’elle est remplie par le produit final.
Plusieurs processus standardisés décrivent un cycle Projet qui requiert que
les exigences soient complètement caractérisées comme dans la liste ci-dessus. On
a déjà cité de la MIL-STD-961D, mais toutes les entreprises ont aujourd’hui des
processus équivalents définis.

On parle un peu en détail des exigences et des processus parce qu’ils ont
souvent en commun le fait de définir un « Cycle en V » pour le développe-
ment. Cet aspect ne sera pas développé dans ce livre, mais il est important
en gestion de Projet.
En effet, il traduit parfaitement le fait qu’à toutes les phases « descen-
dantes » du Projet (globalement la conception et le développement), cor-
respondent des phases « montantes » en vis-à-vis des premières qui cor-
respondent aux tests et vérifications qui permettent de valider le travail
effectué plus tôt :
Test du système
Expression
du besoin
Spéci¡cation
Fonctionnelle
Conception /
Développement
Tests unitaires
Opérations et
maintenance
Production
Véri

cation
Véri
¢
cation
Validation
Figure 6.3 – Schématisation du Cycle en V
La figure 6.3 fait clairement apparaître deux notions importantes – parti-
culièrement en ingénierie des systèmes ou logicielle – qui sont la vérification
et la validation a
.
La vérification consistera schématiquement à vérifier si les livrables d’une
phase donnée répondent aux exigences qui lui sont applicables.
La validation consiste à montrer que les livrables répondent aux exigences
pour un usage ou une application donnés.
La vérification permet de s’assurer que l’on produit bien, alors que la
validation montrera que l’on produit le bon résultat.
a. On parle souvent de V & V.

6.1.4 Pour revenir sur l’aspect contractuel
On a donc vu au chapitre précédent que le Cahier des Charges est un docu-
ment contractuel entre le Client et l’Équipe Projet.
C’est un élément primordial : il faut absolument que tous les acteurs et parties
impliquées du Projet soient d’accord sur les objectifs à atteindre. Trop de Projets
sont en difficulté parce que des exigences sont ajoutées ou modifiées en cours de
processus.
Il est important que le Chef de Projet ait une position ferme (mais juste,
donc factuelle et professionnelle) à la fois face au Client, mais aussi face à son
management dans l’entreprise. Il est le garant du Projet, et doit donc en assumer
la responsabilité. Mais il doit aussi être capable de mettre chacun devant les siennes
quand un Client demande une modification, ou quand sa Direction lui retire des
ressources tout en maintenant les objectifs.
Le Projet revient au final à faire un compromis, c’est-à-dire un équilibre
entre des moyens (ressources, temps) et un objectif. Si l’un des deux éléments est
modifié, l’équilibre sera brisé.
6.2 Utilisation pour la préparation du Projet
La spécification fournie par le client final du Projet constitue la définition du
résultat à atteindre. Il s’agit en général d’une spécification fonctionnelle, qui définit
le résultat attendu en terme de comportement que devra voir le système considéré
en réponse aux besoins des utilisateurs. On parle souvent de spécification de haut-
niveau parce qu’elle ne rentre pas dans les détails de l’implémentation technique.
Pour pouvoir développer une solution adaptée, on aura besoin de décliner
la spécification client en document(s) d’exigence(s) plus spécifique(s) en terme de
solution technique à apporter. On parlera alors de spécification de bas-niveau.
Ce(s) document(s) définiront les principes techniques auxquels devra se confor-
mer la solution pour répondre au cahier des charges du client. Ils n’imposent pas
forcément de choix techniques finaux, mais décrivent les conséquences obligatoires
des exigences fonctionnelles en terme de solutions techniques.
Par exemple, si le client souhaite une sphère étanche (fonction qui correspond
à un besoin utilisateur), la spécification interne pourra définir le besoin d’une en-
veloppe fermée et l’utilisation d’un matériau non poreux. Par contre elle n’impose
pas de choix de conception puisqu’on reste, par exemple, maître du procédé à
employer (soudure de sous-ensembles, fabrication par apport de matière. . .) et du
matériau (métal, plastique. . .). L’exemple est ici simplifié, parce que la création de
cette spécification interne se fera en tenant compte du contexte global. C’est en

6.2. UTILISATION POUR LA PRÉPARATION DU PROJET 45
tenant compte de l’ensemble des exigences fonctionnelles – qui se complètent et
s’enrichissent mutuellement – qu’on parviendra à l’écriture d’une spécification in-
terne. Cette dernière sera plus ou moins précise et proche d’une solution technique
selon le niveau de départ du cahier des charges client.
6.2.1 Comprendre ce qui est demandé
La première étape va consister à comprendre ce qui est demandé par le client;
c’est-à-dire à analyser les documents qu’il aura fourni en entrée.
Pour cela, on devra s’appuyer sur un groupe d’experts qui pourront com-
prendre les exigences. En effet, il faudra pouvoir interpréter les intentions du client
qui connaît (théoriquement) son besoin mais peut avoir une idée préconçue de la
réponse qu’il attend 7
.
Cette lecture doit aussi permettre une première analyse technique en évaluant
les principes qu’on aura à mettre en œuvre pour répondre aux besoins exprimés. Il
ne s’agira évidemment pas de définir précisément les solutions, mais par exemple
de lister les technologies qui devront être utilisées. Cela devra aussi permettre de
valider la faisabilité.
Durant cette phase d’analyse, les participants devront s’attacher à répertorier
les incidences et les conséquences concrètes de chaque exigence formulée par le
client. Le résultat brut de ce travail sera une liste la plus exhaustive possible dont
certains éléments pourront sembler contradictoires ou en conflit.
Il faudra alors lever de façon systématique toutes les ambiguïtés et suppri-
mer les incohérences possibles. Les incertitudes devront être mises en évidence et
portées à l’attention du client pour s’assurer :
— Soit qu’il a consciemment omis de préciser certains besoins parce qu’ils ne
sont pas essentiels pour atteindre les objectifs qu’il vise. Il laisse donc de
façon volontaire toute latitude à l’équipe Projet pour proposer des solutions
tant qu’elles n’entrent pas en conflit avec d’autres exigences.
— Soit que le client va apporter les informations complémentaires qui per-
mettront de combler les manques identifiés et être certain que la solution
proposée correspondra aux besoins.
Il s’agit là d’une bonne occasion de rappeler que la communication est un
critère fondamental pour la réussite d’un Projet 8
, en particulier comme ici avec le
7. Cet état de fait pourra constituer un véritable biais cognitif parce que le client pourra
attendre un solution spécifique et précise au travers d’une exigence fonctionnelle qui peut appa-
raître générale et ouverte.
8. Voir le §8.1.2

client. Il est indispensable de discuter de tout problème au plus tôt pour minimiser
les conséquences néfastes potentielles 9
.
Cette phase d’analyse devra donc donner lieu à de fréquents échanges pour
aboutir à un accord complet sur les objectifs du client. On pensera d’ailleurs à
expliciter les critères qui permettront d’évaluer la qualité des livrables fournis
pour valider de façon objective le fait qu’ils répondent ou non aux exigences 10
.
Ces notions de vérification et de validation, toujours par rapport aux exi-
gences, sont fondamentales en gestion de Projet parce qu’on doit montrer qu’on
répond à un besoin défini.
Le résultat devra donc être un ensemble d’exigences validées avec le client,
mesurables et vérifiables.
6.2.2 Écriture d’une spécification interne
Une remarque avant de traiter plus avant du sujet des exigences : le domaine
est vaste, parfois complexe, et demande de la méthode. On va donc ici s’y intéresser
sans trop de formalisme 11
.
Pour ceux qui voudraient aller plus loin, il existe énormément d’ouvrages qui
développent ce thème (voir [13] et [11]).
Un premier traitement du cahier des charges du client a permis de valider
que ses besoins sont exprimés de façon correcte et complète. Il faut maintenant le
traduire dans un document interne au Projet – un cahier des charges interne – qui
aura deux objectifs essentiels :
— En premier lieu la traduction des exigences fonctionnelles en exigences tech-
niques qui permettront :
1. de définir des principes de conception pour le développement d’une so-
lution.
2. de s’approprier le Projet.
— Ensuite mettre en place une véritable gestion des exigences pour s’assurer
à tout moment de la bonne prise en compte des besoins initiaux du client.
9. On gardera à l’esprit le §2.2.1 qui souligne combien une petite décision (ou imprécision) en
début de Projet peut avoir des conséquences importantes à la fin. . .
10. Ceci se rapproche de la démarche d’évaluation des objectifs qui est permise par leur for-
mulation correcte. Voir à ce sujet le §7.2.2.
11. Ce livre ne constitue qu’un recueil personnel de notes !

Traduire les besoins pour les rendre exploitables
On a déjà rapidement survolé le sujet au paragraphe 6.1.3, mais il faut revenir
un peu plus en détail sur la gestion des exigences.
Les exigences ont un double rôle. Quand on se place dans une perspective
d’analyse descendante, elles permettent de définir ce qui doit être fait. A l’inverse,
une analyse montante permet de valider que ce qui devait être fait l’a été. Il faudra
donc que l’analyse du cahier des charges du client produise un ensemble d’exigences
internes qui soit complet et d’un niveau suffisant.
Ce que le client veut – Ce que l’équipe doit Le client a exprimé son besoin
dans une spécification qui permet de comprendre ce qu’il recherche. Toutefois, il
ne définit généralement pas de modalités d’implémentation. Cela reste du ressort
de l’équipe Projet de définir les solutions techniques.
Il faut donc traduire l’expression du besoin afin qu’elle soit exploitable; c’est-
à-dire en déduire le cadre technique qui permettra de répondre aux attentes. Pour
cela, on part de l’inventaire complet des exigences du cahier des charges, et on
commence par identifier pour chacune les implications et les prérequis techniques.
BESOIN
CLIENT
Caractéristique technique 1
Caractéristique technique 2
Caractéristique technique n
...
implique
Figure 6.4 – Le principe de création des spécifications internes.
La figure 6.4 illustre ce principe d’analyse du cahier des charges client.
— Chaque exigence est analysée pour déterminer les possibilités techniques
d’y répondre, et les contraintes qu’elle impose.

— Les résultats sont analysés pour évaluer leurs relations et leurs interactions.
Certaines exigences prises isolément peuvent conduire à des conclusions qui
seront modifiées au vu de l’ensemble.
On cherche donc à traduire progressivement les besoins de haut niveau en
exigences plus précises et spécifiques. Il s’agit d’une analyse Top-Down, pour la-
quelle on devra être vigilant pour traiter tous les cas. La couverture des exigences
doit être totale : l’ensemble des exigences d’un niveau donné doit répondre aux
exigences du niveau supérieur.
On obtient un document de spécification technique qui définit les caractéris-
tiques que devra posséder la solution pour répondre aux besoins (fonctionnels) du
client.
Par conséquent, il sera essentiel durant cette phase de faire attention à ce
que toutes les données d’entrée du cahier des charges du client aient bien été prises
en compte. L’analyse doit se faire selon une méthode structurée :
1. Pour chaque exigence identifiée dans le document client, on fera un inven-
taire aussi exhaustif que possible des implications, conséquences et corol-
laires dans le contexte du Projet.
Cette phase peut s’apparenter à un brainstorming : il est intéressant de
chercher à analyser les exigences de la manière la plus ouverte et la plus
large possible. Ainsi, on évitera d’oublier certains aspects dont l’absence
réduirait le champ d’étude pour le projet.
L’objectif est d’avoir une vue complète de la question posée. On pourra
pour cela considérer l’exigence à remplir selon différents points de vue 12
:
— Technique :
Quelles sont les implications techniques de l’exigence considérée ?
Y a-t-il des caractéristiques techniques obligatoires pour satisfaire l’exi-
gence ?
Y a-t-il des choix qui seraient au contraire interdits ?
— Réglementaire :
Y a-t-il des normes ou réglementations à respecter impérativement ?
Quelles sont les exigences impliquées par ces textes ?
— Gestion des ressources :
Quelles ressources faudra-t-il mobiliser pour remplir cette exigence ?
Pourra-t-on s’appuyer sur des processus ou des outils existants ?
2. En fonction de l’analyse réalisée, on pourra effectuer une synthèse afin d’or-
ganiser le développement de façon logique et efficace. En effet, on s’aperce-
12. On donne ici quelques exemples, mais il faudra procéder à l’analyse la plus large possible.
D’où l’intérêt de constituer une équipe expérimentée et pluri-disciplinaire pour cette étape.

vra souvent de la possibilité de regrouper certaines exigences du client en
fonction des techniques qu’on envisage de mettre en œuvre.
Cette étape est importante, parce qu’elle constitue une première réflexion
sur l’architecture technique de la solution qu’on va apporter au problème
du client. Elle aura par conséquent un impact fort sur la suite du Projet.
3. Enfin on pourra écrire une spécification interne pour le Projet qui décrira
le système sous forme de solution technique à implémenter.
Bien qu’orientée plus sur la solution que sur les besoins à remplir, on veillera
à ce que les exigences y soient formulées en respectant les mêmes critères
que pour le document client d’entrée (voir à ce propos le §6.1.3).
A l’issue de cette étape, on dispose d’une vue précise du résultat qu’on doit
obtenir. Le Projet devient plus concret, l’équipe en prend la responsabilité.
Gérer son Projet Cette phase d’écriture d’une spécification interne peut avoir
une importance stratégique pour l’organisation qui exécute le Projet.
Le client définit avant tout un résultat à atteindre et laisse souvent une
certaine liberté quant aux moyens à mettre en œuvre pour l’atteindre. Il sera donc
souvent intéressant pour l’équipe Projet de chercher à utiliser les outils et méthodes
avec lesquels elle est habituée à travailler.
En effet, l’équipe Projet peut avoir des objectifs selon différents axes :
— Les objectifs internes au Projet.
— Les objectifs externes au Projet, qui seront souvent des objectifs spécifiques
à l’équipe Projet.
Les objectifs internes au Projet sont normalement correctement définis. Ils
correspondent aux résultats attendus du Projet.
Les objectifs externes ou spécifiques à l’équipe Projet sont différents. les
membres de l’équipe Projet sont issus d’entités (services, départements, entre-
prises) qui ont chacune des objectifs spécifiques. Comme on a pu le voir précédem-
ment, ces objectifs ne sont pas forcément en phase avec ceux du Projet.
De plus, sans même tenir compte de ces objectifs spécifiques, l’équipe Projet
cherchera, et devra chercher à tirer le meilleur profit possible pour elle du Pro-
jet. Concrètement, une entreprise en charge d’un Projet cherchera évidemment à
maximiser le bénéfice qu’elle pourra en retirer. Cela doit se comprendre à la fois
comme la recherche d’un retour sur investissement immédiat maximal, mais aussi
comme la capitalisation des connaissances et méthodes acquises durant le Projet.
Pour cela, elle voudra par exemple mettre en œuvre les processus qu’elle maîtrise
pour travailler rapidement, et capturer les apprentissages. Cela lui permettra de
maximiser son efficacité.

Pour revenir au sujet des exigences, l’écriture d’une spécification interne sera
un outil qui permet de réorienter le Projet afin de remplir à la fois les objectifs du
Client et ceux de l’équipe Projet.
Le résultat final est défini assez précisément, mais les moyens pour l’atteindre
devront être choisis dans la mesure du possible pour remplir les objectifs internes
à l’équipe.
Ainsi, une entreprise qui dispose de processus de gestion de Projet définis
aura intérêt à les appliquer. Elle essaiera aussi d’utiliser par exemple les technolo-
gies particulières qu’elle possède pour aboutir à une solution la plus performante
possible.
Les avantages peuvent être nombreux :
— Un meilleur contrôle du Projet :
Il est évident que l’utilisation de processus auxquels sont habitués les diffé-
rents intervenants du projet facilite le contrôle. Comme avec n’importe quel
outil, on sera plus performant quand on a l’habitude des méthodes qu’on
utilise.
— L’appropriation du résultat :
Ce point est essentiel.
Lorsqu’un Client initie un Projet, il attend généralement une solution qui
réponde à ses besoins, et en exige le plus souvent la propriété intellectuelle.
Cela peut poser problème à long terme parce que l’équipe Projet, ou l’entre-
prise en charge du Projet, ne restera qu’un exécutant dont la valeur ajoutée
sera limitée dans le temps – et par conséquent les bénéfices potentiels le
seront aussi.
Afin de minimiser cet inconvénient, on pourra essayer de mettre en œuvre
des solutions techniques propriétaires qui permettront de rendre le Client
captif. Attention, il ne s’agit pas de créer une relation biaisée – on a déjà
insisté sur la notion de confiance – mais d’aboutir à une situation gagnant-
gagnant en offrant un bénéfice maximum tout en préservant ses intérêts.
Savoir où on en est par rapport aux exigences
Note: J’aborde dans ce paragraphe certains concepts de façon personnelle.
Cette vision correspond à mon expérience, à ce que j’ai pu mettre en pratique.
Cela ne correspond pas forcément aux définitions qui peuvent en être donnés dans
des documents « officiels » 13
.
L’un des objectifs majeurs d’un Projet est de satisfaire les besoins du client.
Cela signifie parvenir à remplir tous les critères qui feront qu’il soit satisfait.
13. Par exemple dans le domaine aéronautique, la norme DO-178C définit de façon précise ce
qu’est une exigence dérivée.

On comprend donc qu’il faut être capable de montrer qu’on répond à toutes
les exigences qui définissent le besoin.
Dans le cadre d’un petit Projet, ces exigences seront en nombre limité; il sera
donc aisé de s’assurer que la solution proposée remplit les objectifs. Par contre,
pour un Projet important, la quantité de critères à respecter rend inopérante une
telle gestion empirique. Le suivi des exigences prend alors toute son importance.
Lors de l’élaboration de la spécification interne, les exigences du client sont
traduites en exigences techniques qui ont un sens concret pour l’équipe Projet.
En pratique, cette traduction se fait selon deux mécanismes principaux :
— La dérivation consiste à déduire d’une exigence initiale des exigences sup-
plémentaires qui précisent le besoin initial.
En simplifiant, une exigence dérivée permet de caractériser l’énoncé initial.
Le Client exprime un besoin, les exigences dérivées permettent de décrire
comment on doit le comprendre.
— La déclinaison consiste à traduire une exigence de haut niveau en une
ou plusieurs exigence(s) de plus bas niveau – c’est-à-dire qui restreignent
l’éventail de solutions possibles. Une exigence déclinée est plus précise que
son exigence parente parce qu’elle définit un peu plus la solution qui devra
être mise en œuvre. Ceci peut se faire soit en définissant le besoin, soit en
précisant le mode d’implémentation.
Au cours du Projet, la spécification interne sert de référentiel par rapport
auquel l’équipe Projet devra évaluer le travail réalisé.
Elle constitue un outil de suivi qui permet de mesurer l’avancement, en com-
plément du planning. Le suivi par rapport à la spécification fournit une information
quantitative quant au volume de travail effectué et restant; le planning permet évi-
demment d’assurer une gestion temporelle.
Il est donc important de gérer correctement les exigences.
Il existe des outils dédiés qui sont parfaitement adaptés aux projets impor-
tants 14
, mais on devra souvent gérer les exigences sans disposer de moyens spéci-
fiques dédiés. Il est alors courant de s’appuyer sur des logiciels plus répandus tels
que les tableurs, ou parfois des bases de données.
On ne développera pas dans ce livre la mise en pratique concrète, parce
qu’elle est très souvent liée intrinsèquement au Projet. Par contre, on devra dans
tous les cas respecter certains principes :
— L’identification des exigences
Pouvoir gérer, c’est à dire recenser, relier, citer des exigences nécessite évi-
demment en premier lieu de pouvoir les identifier sans ambiguïté. Aussi
14. Par exemple – parmi d’autres – IBM Rational DOORS.

chaque exigence devra se voir attribuer un identifiant unique qui permettra
de lui faire référence.
— La traçabilité des exigences
Au cours de la vie d’un Projet, on pourra devoir déterminer d’où provient
une exigence. Dans le cas de spécifications complexes, qui peuvent com-
porter de multiples niveaux, on devra s’assurer que toutes les exigences
secondaires d’une exigence principale sont satisfaites pour valider le niveau
supérieur. Ce sont là deux exemples de cas où on doit pouvoir déterminer
les relations entre plusieurs exigences.
D’autre part, pour une exigence donnée il pourra être utile de déterminer
les références qui y sont faites durant le Projet; c’est-à-dire quand les tâches
ou les livrables lui sont liés.
Enfin une exigence peut évoluer au cours du Projet. Par exemple le Client
peut redéfinir un besoin, ou le développement peut amener à en préciser
ou modifier d’autres. On pourra donc avoir plusieurs versions d’une même
exigence.
Il faut donc situer les exigences :
— Dans le temps, pour suivre leur évolution.
— Dans l’arbre des exigences, pour identifier leurs relations.
— Dans le dossier Projet, pour recenser leurs utilisations.
L’outil de gestion d’exigences mis en place doit répondre à ces trois problé-
matiques.
— La couverture des exigences
Une des activités importantes dans le cycle Projet consiste à s’assurer que
les besoins du Client sont correctement remplis. En pratique, cela reviendra
à s’assurer 15
:
1. Que les exigences permettent bien de répondre au besoin du client.
2. Que les livrables du Projet satisfont bien les exigences.
L’outil de gestion d’exigence devra donc faciliter cette analyse pour s’assurer
de la qualité des livrables du Projet.
Le Chef de Projet aura pour responsabilité de s’assurer que le référentiel
d’exigences est tenu à jour. Il faudra régulièrement effectuer une revue pour évaluer
le statut de chaque élément.
Certaines devront être mises à jour, d’autres seront annulées. Il faut donc
que le référentiel reflète ces états.
Cette revue sera aussi l’occasion d’évaluer la progression du travail en étu-
diant le degré d’avancement pour chaque exigence.
15. Cette méthode est formalisée par le cycle en V - voir le §6.1.3

6.3. GÉRER LES EXIGENCES POUR GÉRER LE PROJET 53
6.3 Gérer les exigences pour gérer le Projet
On a vu précédemment que les exigences permettent de définir le résultat
qui doit être atteint par le Projet. Elles définissent l’objectif. Mais le référentiel a
aussi une autre fonction essentielle pour le Chef de Projet parce qu’il va permettre
d’organiser le travail, c’est-à-dire le processus. On a donc deux points de vue qui
seront importants pour le succès de l’entreprise.
En effet, si on se rappelle du triptyque QCD 16
, on fera facilement le lien
entre la vision « objectifs »des exigences et le paramètre Qualité du triangle QCD.
Mais il est aussi intéressant de noter que la bonne exécution du Projet, la bonne
maîtrise du « processus », est un élément indispensable pour gérer les aspect Coût
et Délai. Il sera donc nécessaire d’organiser le Projet pour traiter au mieux le
référentiel d’exigences.
En fonction de la complexité et de la taille du Projet, on pourra envisager
plusieurs façons de couvrir l’ensemble des exigences:
— Un Projet simple pourra par exemple s’organiser en attribuant la respon-
sabilité d’un ensemble d’exigences à une ressource 17
donnée.
L’arbre d’exigences sera alors couvert par bloc. Charge au Chef de Projet
de s’assurer qu’il n’y a pas de recouvrement et pas d’oublis pour que toutes
les exigences soient correctement remplies.
— Pour un Projet complexe, le Chef de Projet devra mettre en place une
organisation différente, où des ressources pourront intervenir sur différents
aspects du Projet, par exemple pour apporter des compétences spécifiques.
Dans ce cas, le travail de suivi pourra être plus lourd parce qu’une exigence
de haut niveau nécessitera de valider toutes les exigences filles. Ces dernières
pourront être de la responsabilité de ressources différentes. On sera alors
sur un principe d’essaimage.
Ces problématiques sont à relier à la réflexion sur la structuration du Pro-
jet (voir le §4) dont on voit qu’elle est liée fortement au Cahier des Charges du
Client 18
.
L’ensemble des exigences constitue donc la base de la liste d’actions qui
devront être exécutées pour réaliser le Projet 19
.
16. Voir le §1
17. On parle ici de ressource au sens large. Il pourra s’agir d’une personne seule, d’une équipe,
voire d’une machine. . .
18. C’est d’ailleurs un point intéressant dont on reparlera plus tard en évoquant la gestion des
risques d’un Projet – voir la partie 10.
19. Voir le chapitre 11.2 sur la TODO List.

Chapitre 7
Le lancement
Une fois l’accord trouvé sur le Cahier des Charges, une décision officielle doit
être prise par le management de l’entreprise. Il est important que cette décision
soit le fait de responsables ayant suffisamment d’autorité pour garantir la légitimité
du Projet. Comme on l’a déjà expliqué, un Projet nécessite de l’engagement et du
soutien.
Cette décision doit assurer que le Projet ne sera pas considéré comme une
variable d’ajustement pour l’attribution des ressources, qu’elles soient humaines,
techniques ou financières.
Ces conditions remplies, on va pouvoir passer concrètement à la mise en place
du Projet.
7.1 Quelques mots sur le Chef de Projet
Un Projet comporte par définition des phases de nature différentes :
— La conception d’une solution répondant au Cahier des Charges.
— La fabrication du Produit 1
.
— Les essais (ou vérification – on pourra parler de façon générale de la Vali-
dation 2
).
— La livraison puis éventuellement le suivi du Produit au cours de sa vie
(maintenance).
Ces différentes phases demanderont des ressources possédant des compé-
tences variées.
De plus chaque phase pourra impliquer des acteurs issus de différentes dis-
ciplines en fonction de la complexité du Produit considéré. Les Projets sont sou-
1. Qui peut être immatériel.
2. Voir la figure 6.3.
55

56 CHAPITRE 7. LE LANCEMENT
vent mis en place pour développer des systèmes complexes qui intègrent des sous-
ensembles.
Enfin, le volume de travail à fournir et les délais contractuels conduiront à
affecter plus ou moins de ressources pour chaque discipline dans chaque phase.
On comprend donc qu’un Projet nécessitera généralement le travail d’un
groupe qui pourra être très important.
Plus qu’un groupe, le Chef de Projet devra être capable de former une équipe,
c’est-à-dire un ensemble de personnes qui visent le même objectif et se soutiennent
pour y parvenir. Chacun devra prendre sa part et garder à l’esprit que la situation
de tous dépend de son attitude.
7.1.1 Quel est donc le rôle du Chef de Projet ?
On vient de voir que le Chef de Projet doit être capable de faire d’un groupe
une équipe. Plus qu’un chef, il doit être un capitaine – au sens sportif du terme.
Il doit être capable d’orienter les gens, de montrer la voie et de motiver. Son rôle
est donc pluriel.
Il doit par conséquent agir dans différents domaines :
Chef de Projet
Organisation
Technique Gestion
Humain
Figure 7.1 – Les domaines d’action du Chef de Projet
Le Chef de Projet aura des responsabilités dans les quatre plans décrits sur
la figure 7.1 :
— L’organisation :
Cet aspect est celui qui vient le premier à l’esprit quand on parle de Ges-
tion de Projet. Il s’agit principalement de la mise en œuvre des processus
généralement définis dans l’entreprise.
On agira donc principalement sur :
— L’organisation du fonctionnement de l’équipe Projet.
— La mise en place des outils (au sens processus).
— La gestion de la documentation Projet.
— La Technique :

7.1. QUELQUES MOTS SUR LE CHEF DE PROJET 57
Le Chef de Projet doit être un guide pour son équipe, et être capable d’im-
pulser ou de relancer le travail en particulier quand on rencontre des diffi-
cultés.
Il lui faudra donc :
— Être capable d’apporter une expertise métier.
— Anticiper les risques techniques pour pouvoir les minimiser et les gérer
au plus tôt.
— La Gestion :
Le Projet est une organisation dont il faudra gérer le déroulement selon des
règles (les processus) définis :
— Fixer les objectifs.
— Planifier les tâches.
— Gérer le budget.
— Suivre les objectifs (suivant le triangle QCD 3
).
— L’Humain :
L’équipe Projet est comme une petite entreprise. Le Chef de Projet a donc
un rôle de manager avec des missions classiques :
— Constituer et piloter son équipe.
— Prendre (ou faire prendre) des décisions.
— Gérer des réunions.
— Gérer les conflits qui peuvent survenir 4
.
— Communiquer avec tous les intervenants internes et externes.
Le Chef de Projet a donc à la fois un rôle de gestionnaire, de manager et
d’expert technique.
7.1.2 La mise en œuvre – Les compétences générales
On a vu au chapitre 4 différents types de structure qui peuvent être mis en
place pour une équipe Projet. Un des points de différenciation entre les différentes
variantes tient dans l’indépendance plus ou moins grande qu’aura l’équipe Projet
vis-à-vis de l’organigramme de l’entreprise. Pourtant, qu’on mette en place une
structure fonctionnelle ou une équipe Projet dédiée, le Chef de Projet sera toujours
placé entre la Direction de son entreprise et son équipe.
Il sera donc confronté à des attentes de ses supérieurs hiérarchiques, d’autant
plus fortes que le Projet est stratégique. De plus, la Direction n’aura pas toujours
une connaissance précise du contexte et du déroulement du Projet. Il faudra donc
mettre en place un reporting efficace et soigner particulièrement sa communication.
3. Voir le chapitre 1.1
4. Et même vont. . .Toute équipe connaît immanquablement des conflits. C’est la nature hu-
maine, et un autre sujet. . .

Gestion de Projet

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Gestion de Projet

Similar a Gestion de Projet (20)

Gestion de Projet