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. . .

On retrouve là certains aspects déjà évoqués du rôle de Chef de Projet : il doit
vendre son Projet pour en garantir le succès – c’est à dire communiquer dessus de
façon positive – tout en gardant à l’esprit l’environnement global de l’entreprise
pour ne pas la mettre en danger en perdant de vue l’impact que pourrait avoir des
problèmes voire un échec 5
.
À l’opposé, le Chef de Projet devra aussi répondre à son équipe. Comme on
l’a déjà expliqué, les personnes impliquées auront souvent deux rattachements; le
Projet évidemment, mais aussi une hiérarchie fonctionnelle, ou métier. Les deux
peuvent parfois avoir des intérêts contradictoires en apparence. Le Chef de Projet
devra donc faire des choix et faire en sorte de recevoir le soutien nécessaire.
Ce positionnement sera un élément important à prendre en compte.
Concrètement, le Chef de Projet doit avoir un rôle de Manager, qui comprend
en général les aspects suivants :
— La prise de décisions.
— La motivation de son équipe.
— La gestion des talents 6
.
Décider La prise de décisions compte pour une part importante du travail du
Chef de Projet. Tout au long de la vie du Projet, des choix devront être faits, qu’ils
soient d’ordre technique – c’est à dire liés à l’objet du Projet – ou organisationnels.
Ainsi, on sera par exemple régulièrement amené à choisir entre différentes
solutions techniques. La majeure partie du travail sera alors faite par les experts
qui chercheront des éléments objectifs (de performance, qualité ou fiabilité par
exemple. . .) pour sélectionner l’alternative la meilleure en fonction des objectifs.
Toutefois, il arrivera souvent qu’il reste plusieurs options après cette première
phase. Il sera alors du ressort du Chef de Projet de trancher parce qu’une trop
longue absence de décision pourrait amener des risques pour le Projet 7
.
Sur le plan de l’organisation, le Chef de Projet devra régulièrement attribuer
des priorités entre des tâches, ou gérer l’allocation de ressources. Ces deux exemples
de situation correspondent à des prises de décision.
Dans tous les cas, le Chef de Projet devra chercher à collecter et analyser
l’information nécessaire pour faire son choix, pour pouvoir trancher de la façon la
5. On reviendra dessus, mais il faut chercher à communiquer de façon motivante et franche.
Le Chef de Projet doit défendre son travail et celui de son équipe, mais il doit aussi reconnaître
et faire connaître les problèmes qu’il rencontre.
6. Extension de la Gestion des Ressources humaines.
7. On pense instinctivement à des problèmes de tenue de planning, mais on pourrait aussi se
retrouver confronté à des impasses techniques. En effet, avec une organisation de type collaboratif,
différentes études peuvent progresser ensemble, et une décision trop tardive pourrait être cause
d’incompatibilité.

plus objective possible. Il faudra être capable d’expliquer et pouvoir assumer les
décisions prises.
Motiver La motivation est un autre aspect essentiel de la fonction du manager.
Pour le Chef de Projet, il s’agira de faire en sorte que tous les participants s’im-
pliquent au niveau requis pour assurer le succès du Projet. Mais la tâche ne sera
pas évidente parce que le Chef de Projet n’a que rarement de relation hiérarchique
officielle avec les membres de son équipe 8
.
Mais qu’est-ce que la motivation ?
De nombreux travaux ont été faits concernant ce sujet, et vont bien au-delà
du cadre de ce livre 9
.
On peut toutefois tenter de fournir une synthèse très rapide qui permettra
de souligner l’importance du fait de motiver son équipe.
La motivation est un processus qui initie, oriente et développe un comporte-
ment qui vise à atteindre un objectif.
Concrètement, la motivation consistera à développer l’implication et l’enga-
gement. Une personne motivée fournira un travail de qualité, sera plus autonome
et plus créative 10
.
Un manager, qui a des objectifs à atteindre, devra donc évidemment motiver
son équipe pour améliorer sa performance. Cela est important à la fois pour le
court terme – parce que le travail doit être fait – et sur le long terme parce que des
personnes motivées seront plus enclines à s’investir sur la durée dans une équipe
(voir ci-dessous la paragraphe sur la Gestion des talents).
Par contre, il n’existe malheureusement pas de science exacte de la motiva-
tion, qui n’est pas un processus répétitif et reproductible. Il reviendra au Manager
d’être attentif et d’écouter ses collaborateurs pour identifier les leviers qu’il pourra
actionner.
Il est souvent efficace de s’appuyer sur les besoins de reconnaissance et de réa-
lisation que ressentent la plupart des gens. En pratique, le Chef de Projet cherchera
à impliquer réellement les membres de l’équipe en les responsabilisant. Considérer
quelqu’un comme un simple exécutant n’est pas valorisant, lui donner la respon-
sabilité d’une tâche – accompagnée des moyens et de l’autonomie afférentes – est
un puissant facteur de motivation parce qu’il va s’approprier la tâche et faire en
sorte de pouvoir être fier de son travail.
8. La Direction a ici un rôle important en formalisant ces relations et les responsabilités qui
vont avec.
9. Voir par exemple l’article [7] qui est un bon point d’entrée.
10. Là on parle égoïstement depuis le point de vue du Chef de Projet. Une personne motivée
retirera aussi tout simplement plus de satisfaction de son travail.

Un autre levier généralement intéressant à exploiter est la recherche de sens
par les gens dans ce qu’ils font. Il est extrêmement motivant de participer à une
entreprise qui aura un impact durable et bénéfique même quand on ne sera plus
impliqué. On touche là aux limites de la philosophie et de la psychologie, mais
« laisser une trace » de son passage peut amener à se surpasser. Alors bien sûr il
sera souvent complexe de trouver dans un Projet purement industriel par exemple
des éléments qui inspirent autant les participants, mais on pourra s’en approcher
en détaillant le contexte et l’environnement dans lesquels s’inscrit le travail. Un
Projet est rarement isolé et indépendant du monde qui l’entoure. Le Chef de Projet
devra donc là encore expliquer les conséquences bénéfiques à attendre quand les
objectifs seront réalisés pour que tout le monde puisse percevoir l’importance de
réussir.
Gérer les talents La gestion des talents est le dernier pilier du rôle d’un
manager.
Extension d’une problématique spécifiquement liée à la gestion des ressources
humaines, la gestion des talents est stratégique parce qu’elle pérennise les capacités
à long terme de l’entreprise (et de l’équipe Projet) en matière de performance et
d’innovation. L’objectif du Chef de Projet sera d’obtenir puis de conserver les
meilleures ressources pour son Projet.
Un talent peut se définir comme le décrit la figure 7.2 page 61 : une personne
qui présente une combinaison de compétences et de leadership intéressante, et qui
apporte de la valeur ajoutée.
Comment les gérer ?
La première étape consiste à identifier les personnes qui présentent un cer-
tain talent. Il n’y a pas de méthode théorisée, il faudra faire preuve d’intérêt et
d’empathie pour repérer les éléments importants.
Il faudra ensuite attirer (si elles ne sont pas déjà dans l’équipe) les personnes
intéressantes. Pour cela, il faut développer l’attractivité de son Projet, que chacun
ait envie d’y participer. Cela sera d’autant plus simple que le Projet est stratégique
pour l’entreprise. Le travail sera alors similaire à celui nécessaire pour motiver : il
faudra donner envie aux gens de participer au Projet.
Puis il faudra conserver les talents sur le long terme. On ne parlera pas des
aspects qui relèvent principalement des RH, mais en temps que Chef de Projet,
on devra être attentif à reconnaître la qualité du travail fourni et à impliquer les
personnes en leur proposant des responsabilités en rapport avec leurs capacités.
Enfin il faudra permettre aux gens de se développer en leur proposant des
perspectives, des possibilités d’évolution. Une équipe Projet est comme une petite
entreprise 11
et certaines techniques de management peuvent être transposées. Par
11. Concept relatif vue la taille de certains Projets. . .

Figure 7.2 – Une approche de la notion de talent.
exemple il pourra être extrêmement bénéfique de former certaines personnes, sur
des sujets techniques ou de management. Une formation est généralement appréciée
parce qu’elle atteste de l’intérêt de l’entreprise pour une personne.
Le leadership De la même façon que tout manager, le Chef de Projet devra aussi
faire preuve de leadership. Il s’agit d’une compétence importante dès qu’on a la
charge de manager une équipe. En effet, on définit le leadership comme la capacité
à exercer une influence sur un groupe. On conviendra donc que cela facilitera la
motivation et que cela aidera à la réalisation d’objectifs ambitieux.
Le leadership est un sujet d’étude important, qui a donné lieu à un grand
nombre de publications. On va donc simplement présenter les concepts ici.
Pour commencer, il existe différents types de leadership qui ont fait l’objet de
recherches pour leur caractérisation. Par exemple, Robert R. Blake et Jane Mouton
ont proposé la grille managériale (voir [12]) qui permet de classer différents styles
de leadership selon les priorités données au résultat ou aux relations humaines 12
:
12. En schématisant un peu parce que cela à donné lieu à des livres entiers. . .

Intérêt pour le résultat
Intérêtpourlesrelationshumaines
Figure 7.3 – Les styles de management selon Blake et Mouton.
La figure 7.3 est assez claire et logique. En effet, il semble assez évident
intuitivement que les grandes classes de comportement du leader seront liées à
l’importance donnée aux résultats et aux aspects humains :
1. La gestion participative et sociale
Les critères humains sont prépondérants. Le manager cherchera donc à dé-
velopper l’autonomie et l’implication pour motiver son équipe.
2. La gestion démocratique, le style « catalyseur ».
Dans ce cas, le manager cherche à développer des relations de confiance
et de respect. Il accorde toutefois beaucoup d’importance aux résultats.
Le principe sera donc d’avoir des relations franches et sincères avec les
collaborateurs pour qu’ils aient conscience de tous les aspects du Projet.
3. La gestion par compromis
L’appellation est assez explicite, le Manager cherchera dans ce cas en per-
manence à concilier les impératifs de résultat et les aspects humains. Cela
pourrait apparaître comme l’option « idéale », mais elle n’est pas toujours
aisée à suivre.

Il ne faudra pas tomber dans l’inaction en cherchant à tout prix le compro-
mis. On devra garder les objectifs à l’esprit.
4. La gestion laxiste
Ce type de manager existe (malheureusement) et ne semble concerné ni par
les résultats, ni par les relations humaines. Il essaiera souvent de mettre en
place des routines et de développer des habitudes. Il n’est pas concerné par
son Projet.
5. La gestion autoritaire
Quand un manager est concentré sur le résultat sans prêter trop d’attention
aux aspects humains, il aura tendance à prendre beaucoup de décisions seul,
à être très directif.
Ce style de comportement pourra être plus ou moins adapté en fonction
du contexte du Projet. Dans une phase où tout se passe bien, avec une
progression cohérente avec la planification, il vaudra mieux éviter de recourir
à ce type de management. En effet, les membres de l’équipe Projet pourront
être démotivés parce qu’ils seront considérés comme de simples exécutants.
Par contre, quand le Projet traversera des phases difficiles, avec des risques
pour la tenue du planning, il pourra être utile d’imposer le rythme et donc
de passer temporairement à un style autoritaire.
Le Chef de Projet pourra donc s’appuyer sur ces types identifiés en fonction
du poids relatifs qu’il donnera au résultats et aux relations humaines.
L’expertise Parallèlement aux tâches managériales, le Chef de Projet devra sou-
vent assumer un rôle qu’on qualifie parfois d’« expert technique », en particulier
quand il sera chargé de prendre en dernier ressort des décisions. Pourtant on com-
prendra aisément qu’il ne sera pas possible pour un responsable de Projet de
maîtriser parfaitement tous les sujets techniques en lien avec le Projet qu’il gère 13
.
Toute l’habileté du Chef de Projet consistera à connaître suffisamment son Projet
pour comprendre les messages de ses collaborateurs, et être capable de se faire une
opinion sur un sujet donné sans connaître forcément tous les détails.
7.1.3 Le spécifique – les aspects processus
Quand on demande aux gens de définir ce qu’est un Chef de Projet, ils
répondent souvent que c’est quelqu’un qui fait des plannings. On vient de voir
que le périmètre de ses actions est beaucoup plus étendu. Le Chef de Projet devra
en ainsi assurer certaines tâches liées aux processus afin de pouvoir organiser son
Projet.
13. Ce constat est d’autant plus valable que le Projet géré est important.

On citera en particulier :
— Le découpage et la structuration du travail 14
.
— L’agencement des tâches et la planification 15
.
Ces opérations sont importantes, parce qu’elles vont permettre de prévoir et
de planifier l’ensemble des tâches qui seront nécessaires pour atteindre les objectifs.
Le Chef de Projet aura intérêt à y consacrer le temps nécessaire au plus tôt pour
préparer le travail au mieux.
7.2 Donner un cadre clair au Projet
A l’issue de ce temps de préparation, on doit avoir une vision claire de ce que
devra être le Projet, qui pourra être synthétisée dans un document de définition
du Projet.
7.2.1 Le document de définition du Projet
Il s’agit d’une note synthétique qui permet de présenter le Projet, souvent aux
fins de communication, pour en donner une compréhension claire à toute personne
extérieure.
Elle pourra être structurée en plusieurs parties 16
:
— La description des enjeux
L’objectif est d’identifier le besoin et de lister les parties prenantes dont on
devra tenir compte : le client, les partenaires, les fournisseurs. On pourra
alors décrire ce que doit apporter le Projet à chacun d’eux. C’est une don-
née importante qui peut permettre d’éviter un abandon précoce en cas de
difficulté. On pourrait alors mettre en avant les motivations et besoins ini-
tiaux.
— Le contexte
Il permet de comprendre l’environnement dans lequel on va devoir travailler.
Il s’agit de pouvoir tenir compte de l’historique qui a conduit à lancer le
Projet et du contexte dans lequel il se déroulera, lié aux Projets précédents,
aux Projets concurrents. On pourra à cet effet utiliser les outils d’analyse 17
tels que la matrice SWOT et le PESTEL.
14. Voir le §7.2.3
15. Voir le §7.5
16. Liste indicative qui permet à priori de couvrir tous les aspects. Les organisations ont souvent
des règles existantes à ce sujet.
17. On en parle plus en détail au chapitre 12.3.

7.2. DONNER UN CADRE CLAIR AU PROJET 65
On pourra ainsi déterminer quelles seront les liens du Projet avec les dif-
férentes parties prenantes, ses limites et les contraintes auxquelles il sera
soumis.
— Les livrables
Ce sont les résultats attendus du Projet. On pourra établir une liste prélimi-
naire de ce qui devra être produit, en s’appuyant sur une lecture synthétique
du cahier des charges. On pourra aussi lister les critères et les indicateurs
qui devront être surveillés.
Cette partie permet de mettre en évidence la pertinence des objectifs.
— Les risques
Dès le début du Projet, on cherchera à identifier les principaux risques qui
pourront peser sur le Projet pour chercher à en limiter les impacts 18
. On
s’attachera aussi à étudier les conditions et les hypothèses de démarrage
pour maîtriser les dérives potentielles.
— Le budget
Le document de définition du Projet doit rappeler les moyens et les res-
sources qui sont à disposition de l’équipe pour mener sa tâche à bien. Cela
permet de définir une référence pour la structuration du Projet qui devra
être adaptée en fonctions des ressources humaines, matérielles, financières
qui sont disponibles pour réaliser le travail dans les délais impartis. Il ne
faut pas oublier de lister les besoins en ressources critiques, telles que les
experts, qui seront sollicités ponctuellement, mais dont l’absence pourrait
mettre tout le Projet en danger.
— Les acteurs
L’ensemble des personnes qui participeront activement au Projet devra être
identifié. Cela permettra de clarifier les chaînes de validation et de mettre en
place le pilotage du Projet, en tenant compte des hiérarchies. Le document
de définition du Projet détaille l’engagement des membres de l’équipe, et
constitue un contrat interne au Projet.
Le document de définition du Projet donne un cadre clair et permet de s’or-
ganiser. Il faut aussi définir précisément les buts à atteindre.
7.2.2 Des objectifs corrects
Définir précisément les buts consiste à établir des objectifs. Pour pouvoir ali-
gner tous les membres de l’équipe Projet, il faut qu’ils soient clairs et non ambigus.
Peter Drucker a très tôt souligné la nécessité d’avoir des objectifs clairs,
ayant du sens 19
, mais c’est dans les années 80 qu’est apparu le concept d’objectifs
18. Voir à ce sujet le §10.
19. On pourra lire [6].

« SMART »qui est aujourd’hui populaire.
SMART est un acronyme anglais pour Specific, Measurable, Achievable, Re-
levant et Time bound. On trouve d’autres définition, mais le sens général reste le
même.
Il s’agit d’un moyen mnémotechnique pour rappeler tous les critères qu’un
objectif doit respecter pour être efficace.
Un objectif doit donc être :
— Spécifique
Il doit être lié au contexte dans lequel on le définit et à la ressource (per-
sonne, groupe) chargée de l’atteindre. Il doit aussi être clair et précis pour
pouvoir être compris par toutes les parties prenantes.
— Mesurable
Un objectif doit être quantifiable (quantitatif ) ou qualifiable (qualitatif ).Il
faut pouvoir définir un seuil à partir duquel on le considère comme atteint.
— Atteignable
L’objectif doit être ambitieux pour être motivant, mais aussi raisonnable –
c’est-à-dire que les moyens dont on dispose doivent permettre de le réaliser.
— « Relié »
L’objectif s’inscrit dans le Projet global. Il constitue une étape pour la
réalisation de l’ensemble et doit donc y contribuer.
— Temporellement défini
Il est délimité dans le temps de manière précise pour éviter les dérives et
des retards réguliers.
La définition de bons objectifs est un outil puissant qui permet d’indiquer
au membres de l’équipe Projet ce qu’il doivent faire.
7.2.3 La structuration du travail - Que doit-on faire ?
Pris globalement, un Projet apparaîtra certainement comme une entreprise
insurmontable parce qu’on ne saura comment organiser son travail pour produire
un résultat qui correspond aux exigences définies dans le Cahier des Charges. En
effet, pour des cas très simples il sera peut-être possible d’analyser mentalement les
étapes nécessaires 20
, mais l’immense majorité des Projets demanderont une suite
d’actions trop complexes pour être enchaînées efficacement sans organisation.
La solution va consister à découper le travail en lots puis en tâches qui seront
gérables plus facilement 21
.
20. Il faudra vraiment avoir de la chance, parce qu’on se rendra souvent compte durant l’exé-
cution d’un Projet de tâches à faire qui n’avait pas été envisagées dès le départ.
21. C’est en quelque sorte une application du principe Diviser pour mieux régner.

La méthode est simple. On commence par diviser l’objectif global du Projet
en lots de travail puis en tâches.
Les lots seront des sous-ensembles du travail global, qui fourniront des ré-
sultats (des livrables) qui sont cohérents et peuvent être gérés indépendamment
les uns des autres. Ils seront cohérents au sens où le Chef de Projet décidera d’un
critère pour effectuer le découpage. Ainsi, on a souvent des lots de travail tels que
études et fabrication – donc un découpage plutôt fonctionnel – mais on pourrait
tout aussi bien avoir une organisation en lots géographiques qui répartiraient le
travail à effectuer entre différents sites. Les lots peuvent être gérés indépendam-
ment, c’est-à-dire qu’on peut les voir comme une boite noire, avec des entrées
et des sorties, et un ensemble d’opérations internes dont les détails peuvent être
masqués (on pourrait parler d’abstraction). Cela correspond bien au fait que les
lots devront fournir des livrables, et que la combinaison de tous les lots permettra
d’obtenir le livrable global du Projet.
Ce découpage est répété de façon itérative pour définir des lots et sous-lots
de tailles de plus en plus petite, et finalement arriver à des tâches, encore appelées
lots de travail.
Une tâche sera une action menée pour aboutir à un résultat avec des en-
trées (informations, données, matières. . .) et des sorties (re-informations, données,
matières. . .). Une tâche a un objectif clair est peut être assignée à une ressource.
Elle est homogène, parce qu’on peut la caractériser par une unité d’action. Elle est
théoriquement indivisible 22
.
Un Projet a une structure granulaire, et les tâches (ou lots de travail) consti-
tuent l’unité élémentaire la plus petite.
Cette décomposition du Projet peut se représenter sous forme d’organi-
gramme. On parlera alors communément de Work Breakdown Structure, habituel-
lement abrégé en WBS (voir la figure 7.4).
Le WBS est un outil intéressant pour l’organisation, mais aussi le suivi du
Projet, que ce soit pour l’avancement, ou pour le suivi budgétaire. En effet, lors
de la définition de la structure, on pourra allouer à chaque lot une proportion du
budget alloué au lot supérieur (parent).
Comment procède-t-on pour établir cette décomposition ?
Il y a deux dimensions derrière cette question :
— Quels sont les critères à retenir pour diviser le travail ?
On peut ici répondre simplement que c’est au choix du Chef de Projet !
En effet, l’objectif de cette phase et d’établir une liste de lots de travail qui
soient gérables par leur nature, et par leur nombre.
22. On pourra toujours diviser en sous-étapes, mais ces dernières ne seront pas auto-suffisantes;
prises individuellement, elles n’auront pas de valeur ajoutée pour le Projet.

Figure 7.4 – Représentation graphique d’un WBS.
La nature du lot de travail correspond à son contenu, qui doit être homo-
gène. En peut en général la caractériser selon l’un des critères suivants :
— Le métier concerné.
— L’unité géographique – on pourrait dire le lieu, mais avec les moyens de
communication modernes, cette unité peut être virtuelle.
— Le fournisseur (ou sous-traitant) impliqué.
— La fonction.
— L’unité de temps.
Ce choix du critère est une responsabilité du Chef de Projet en fonction
de la façon dont il voudra gérer son Projet. Il pourra par exemple être
plus pratique de choisir un découpage temporel ou par métier selon les cas.
Une tâche qui nécessiterait l’apport de diﬀérentes disciplines, ou qui serait
fractionnée dans le temps sera complexe à gérer.
Ce dernier point est d’ailleurs important. Pour un niveau donné du WBS
(comprendre la décomposition d’un lot donné), on ne devra utiliser qu’un
critère unique parmi les cinq listés ci-dessus. Dans le cas contraire, on se
retrouvera avec des redondances et/ou des oublis. Il faut garder à l’esprit
que la somme des sous-lots est exactement égale au lot considéré.
La construction du WBS se fait en se demandant comment répondre aux
exigences fonctionnelle du Cahier des Charges.
Le nombre de lots de travail sera déﬁni par la profondeur de l’analyse à
laquelle on procédera. Il est évident que plus on divisera le travail et plus

on aura de tâches à la fin. Le corollaire est que ces tâches seront d’autant
plus petites.
Il faudra donc établir un WBS avec une granularité qui implique un nombre
de tâches suffisant pour maîtriser leur taille, mais pas trop important au
risque d’être submergé.
Un indicateur pertinent consiste à vérifier que chaque tâche puisse être
confiée à un responsable unique pour son exécution 23
et qu’il corresponde
à un objectif bien défini 24
.
— Qui peut définir ces lots de travail ?
La construction du WBS doit impliquer un groupe composé d’experts 25 26
.
En effet, bien qu’elle intervienne très tôt au cours du Projet, et donc souvent
avant qu’une analyse approfondie ait été effectuée, il va être nécessaire de
réfléchir aux étapes requises pour remplir chacun des objectifs du Projet.
Le WBS doit être exhaustif dans la mesure du possible parce qu’il va servir
de base pour toute la planification du Projet.
Le WBS permet donc d’avoir un aperçu exhaustif de ce qu’il y aura à faire
pour atteindre les objectifs du Projet. L’objectif final est de parvenir à recenser
toutes les tâches qui seront nécessaires pour terminer le Projet afin de pouvoir
réfléchir aux ressources à mettre en œuvre.
7.2.4 Qui fait quoi ?
Il faut maintenant déterminer les ressources à affecter pour chaque lot de
travail défini dans le WBS. Selon la taille et la complexité du Projet, on pourra se
limiter à identifier un responsable, ou aller plus loin et préciser différents rôles :
— Le Responsable : il sera le coordinateur de la tâche, chargé de s’assurer
de son bon déroulement, contact principal pour les sujets y ayant trait et
garant de bonne exécution. Il garantit le résultat.
— Le(s) Acteur(s) : il(s) exécute(nt) le travail requis.
— Les Consultants : ce sont des ressources qui seront impliquées, en général
avant le commencement, pour préparer le travail. On pense par exemple à
des experts qui pourront définir des solutions techniques à mettre en œuvre.
— Les acteurs Informés à qui on devra transmettre de l’information pendant
la réalisation – par exemple pour du reporting – ou à la fin – pour valider
les livrables.
23. Ce peut être du suivi de sous-traitance, mais il doit pouvoir le faire seul.
24. Voir le chapitre 7.2.2.
25. Enfin au minimum de gens expérimentés.
26. On verra d’ailleurs souvent que le Chef de Projet a intérêt à s’entourer d’un groupe de
personnes expérimentées qui seront précieuses pour piloter l’organisation du Projet.

L’inventaire de ces rôles pourra être fait en remplissant une matrice RACI
qui permet de s’assurer qu’on couvre bien tous les aspects du Projet.
Ce matrice liste en ligne les lots de travail à exécuter, et en colonne l’ensemble
des ressources disponibles. Elle permet ensuite de répartir les rôles :
Table 7.1 – Structure d’une matrice RACI
Lots Sous-lots Ressource 1 Ressource 2 . . . Ressource n
Lot 1 Lot 1.1 A . . . I
Lot 1.2 R A . . . I
Lot 2 Lot 2.1 I . . . R
Lot 2.2 A A . . .
. . . . . .
Lot 2.n . . . A
. . . . . . . . . . . . . . . . . .
Lot n Lot n.1 C R . . .
. . . . . .
Lot n.n . . . A
La construction de la matrice RACI devra observer une règle impérative : on
assigne un et un seul Responsable à chaque lot de travail.
Elle permettra une analyse rapide pour estimer quelle ressource pourrait être
critique, que ce soit au niveau de sa charge (si elle est affectée à de multiples lots)
ou de son rôle (si un risque la concernant met en danger un nombre important de
lots).
Son intérêt principal est qu’elle permet de s’assurer que tous les lots de travail
sont correctement couverts et ont un responsable.
Une fois les ressources et responsabilités définies, on peut construire un orga-
nigramme synthétique : l’Organisation Breakdown Structure (généralement abrégé
en OBS – voir figure 7.5).
L’OBS minimal reprendra la structure du WBS (voir §7.4) en indiquant le
responsable identifié pour chaque lot de travail. En fonction des besoin, on pourra
détailler plus avant la composition de chaque équipe en charge des différents lots.
L’OBS est un outil intéressant pour plusieurs raisons :
— Il permet de communiquer les différents responsables des lots de travail.
Cela est utile au sein de l’équipe Projet, mais aussi vis-à-vis de tous les
partenaires du Projet qui disposent ainsi de contacts identifiés.
— La construction de l’OBS demande un travail d’analyse qui permettra de
préparer la gestion du Projet en identifiant les zones de risques potentiels 27
.
27. On en parlera plus en détail dans la partie 10

7.3. CONSTITUONS L’ÉQUIPE ! 71
Figure 7.5 – Structure d’un OBS.
Arrivé à ce stade, le Chef de Projet aura donc une vision claire de ce qu’il
y a à faire, et des ressources (humaines) qu’il faudra y consacrer. Il pourra donc
construire son équipe pour réfléchir ensuite à la meilleure façon d’agencer les dif-
férents lots de travail 28
.
7.3 Constituons l’équipe !
Un Projet est réalisé par une équipe. Cette caractéristique est en effet la
raison principale qui amène à organiser et structurer le travail de façon aussi mé-
thodique.
Une personne travaillant seule ou une très petite équipe ne nécessiterait pas
la mise en place de processus qui peuvent apparaître lourds au premier abord.
28. Par la meilleure façon, on entend l’optimisation du tryptique QCD -voir §1.1; il faut donc
réfléchir en terme de Qualité – c’est à dire répondre aux exigences, de délai – donc optimiser la
durée des tâches, et de coût – donc utiliser les ressources de la façon la plus efficace possible.

Dans ce cas on aurait plutôt besoin de travailler sur les méthodes d’organisation
et de productivité personnelles 29
.
L’équipe Projet devra principalement posséder deux qualités :
— Rassembler les compétences requises pour atteindre les objectifs du Projet.
— Démontrer un esprit de groupe pour que chacun aille dans la même direction.
Le premier point est évident parce que le Projet doit produire des résultats
(les livrables) dont la production nécessite un savoir-faire. Ce dernier pourra être
intellectuel ou productif 30
, mais il est indispensable pour définir puis matérialiser
les réponses à apporter aux exigences du Projet. Toutefois, toutes les compétences
requises ne seront pas forcément disponibles, ou ne le seront pas à certains moments
clés. On pourra dans ce cas s’appuyer sur des ressources externes à l’équipe en
faisant appel à des consultants et/ou à des experts.
Le second point est extrêmement important car les aspects humains peuvent
être très compliqués à gérer. Une équipe est un ensemble de personnes qui au-
ront des interactions et se comporteront différemment en fonction de leur histoire
personnelle, de leurs besoins, de leurs émotions du moment ou de leur stratégie
personnelle. Par conséquent le Chef de Projet aura un rôle fondamental pour faire
travailler tout le monde ensemble sur les mêmes objectifs pendant la durée de vie
du Projet. Le Chef de Projet doit donc posséder certaines qualités de management
et de leadership dont on a parlé au §7.1.
Le choix des personnes est donc un point essentiel pour la réussite du Projet.
Il faudra s’assurer d’avoir les compétences et les comportements adaptés.
7.3.1 Définir les rôles
La construction du WBS (cf. §7.2.3) a permis d’identifier l’ensemble des
tâches requises pour le Projet; l’OBS (cf. §7.2.4) a permis de déterminer les rôles
qui seront nécessaires pour les exécuter.
Il va maintenant falloir nommer des personnes dans l’équipe pour assumer
les différents rôles.
Le chef de Projet devra pour cela s’appuyer sur ses compétences de mana-
gement et de leadership dont on a déjà parlé. Il faudra les exprimer à la fois en
interne – c’est-à-dire envers les membres de l’équipe en cours de constitution – et
en externe au sein de l’environnement : l’entreprise et en particulier la hiérarchie.
29. Elles sont utiles pour chacun au sein d’une équipe Projet, mais ne sauraient suffire à l’échelle
du groupe.
30. Au sens de production matérielle. . .

7.3. CONSTITUONS L’ÉQUIPE ! 73
Dans le premier cas, on s’appliquera à identifier les profils intéressants tant
sur le plan des compétences que sur les aspects humains. On ne reviendra pas sur
les compétences ; par contre les aspects relationnels sont primordiaux.
Le succès du Projet dépendra de la capacité de tous les intervenants à tra-
vailler ensemble, à la fois pour accomplir leurs tâches respectives, mais aussi pour
faciliter celles de leurs collègues. Chaque membre de l’équipe devra garder en per-
manence à l’esprit à la fois ses objectifs personnels et ceux du groupe pour s’assurer
que le fruit de son travail sera utilisable par les autres. Sur ce point, la matrice
RACI sera utile en permettant de préciser les fonctions et interactions liées à
chaque poste. Par conséquent il faudra choisir des personnes qui ont le sens du
partage et de la communication. Plus encore, on recherchera des personnes qui
font passer l’intérêt commun avant le leur. Dans le cadre d’un Projet, le succès ne
vient que s’il est partagé 31
.
Un caractère individualiste ne pourra pas s’intégrer dans une équipe, d’autant
plus dans les périodes difficiles. Autre exemple, quelqu’un qui ne respecterait pas
les règles et les processus pourrait être un frein (voire pire. . .).
Il faut donc consacrer le temps nécessaire au choix des personnes.
Par rapport à la hiérarchie, le chef de Projet devra être capable de négocier la
mise à disposition des ressources, de formaliser et d’officialiser les responsabilités.
On a déjà évoqué ce point au chapitre 4.
La difficulté tient dans le fait que les intérêts du Projet pourront par moment
paraître contradictoires avec les priorités de certains intervenants dans leur struc-
ture métier. Il faudra alors pouvoir communiquer de façon efficace pour pouvoir
définir des compromis acceptables par tous.
7.3.2 Définir les règles de fonctionnement
Une équipe est d’abord un groupe de personnes, qui ont chacune leurs sensi-
bilités, leurs méthodes et leur mode de pensée. Afin de pouvoir travailler de façon
productive, on devra veiller à ce que tout le monde aille dans le même sens, grâce
à un référentiel commun.
31. Ce n’est pas de moi. . .

Figure 7.6 – La notion de référentiel.
La figure 7.6 permet de comprendre le concept : il s’agit d’un ensemble de
notions acceptées et partagées par l’équipe, qui permet de garantir la cohérence
nécessaire aux travaux :
— Les objectifs doivent évidemment être partagés. Il s’agit du minimum requis.
— Un groupe fonctionne rarement sans des règles qui permettent de cadrer
les relations, en définissant les comportements acceptables et en fixant des
limites.
— Le travail est lui organisé grâce à des méthodes. Il pourra s’agir de processus
formalisés 32
ou de façons de faire codifiées mais plus informelles 33
. Ces
dernières sont souvent issues de l’expérience de intervenants du Projet. Elles
n’auront pas forcément un caractère obligatoire, mais elles permettent que
tout le monde travaille à l’identique et soit (en général) plus productif.
— La communication se fait selon des procédures définies, qui permettent de
s’assurer que tous les acteurs concernés disposent de l’information et as-
surent la traçabilité 34
.
— Enfin, on conviendra qu’un référentiel, qui constitue un cadre contraignant,
ne pourra exister sans une hiérarchie interne à l’équipe Projet qui permettra
la prise de décisions et les arbitrages nécessaires au bon déroulement.
Le référentiel doit être respecté par tous parce qu’une équipe ne peut pas
32. Au niveau de l’entreprise, du milieu (par exemple des processus du domaine de l’aéronau-
tique, ou dans l’industrie militaire) ou légaux.
33. On pense par exemple aux méthodes d’organisation ou de productivité personnelle.
34. De même que pour les exigences (voir §6.1.3), toute communication “officielle” dans la vie
du Projet doit pouvoir être tracée. En effet, elle constitue une mise à jour ou un complément de
la spécification initiale parce qu’elle a une influence sur le travail.

7.4. D’AUTRES TYPES DE RESSOURCES 75
fonctionner de manière optimale si certains ne jouent pas le jeu 35
.
La mise ne place du référentiel commun sera faite dès la réunion de lancement
du Projet 36
parce que toute l’équipe y participe.
On y détaillera les objectifs, en fournissant les explications nécessaires pour
que tout le monde les intègre entièrement.
Les règles seront synthétisées dans une charte qui restera accessible à tous
durant la vie du Projet.
Les méthodes et processus seront détaillées; les documents de référence qui les
définissent seront présentés et laissés à disposition dans la base de documentation
du Projet.
Les canaux de communication seront identifiés en fonction des objectifs. On
pourra ainsi prévoir la fréquence à respecter, le type de support, l’identification
des documents. Certains messages pourront être définis de façon plus précise quant
à leur forme et leur contenu s’ils constituent des données d’entrée indispensables
pour des tâches ou lots de travail. Par exemple une requête pour une analyse
numérique devra intégrer les données d’entrée (conditions initiales), les données
d’interface (conditions aux limites) et l’utilisation postérieure prévue (afin d’indi-
quer comment orienter le travail pour répondre aux attentes).
La structure hiérarchique de l’équipe Projet sera présentée pour que chacun
sache à qui s’adresser en cas de question, de conflit de priorités, et qui devra être
informé de l’avance et des résultats.
7.4 D’autres types de ressources
En plus de l’équipe Projet, on devra utiliser d’autres types de ressources pour
atteindre les objectifs :
— Le temps.
— Les ressources financières.
— Les ressources matérielles.
Les ressources en temps seront souvent contraintes par le délai possible en
fonction des impératifs du client. On dispose d’un d’un certain budget temps,
qui est rarement extensible. Il faudra souvent travailler sur les autres types de
ressources pour en tenir compte.
Les ressources financières correspondent au budget dont on dispose pour
mener le Projet à bien. On détaille un peu cet aspect au chapitre 9.1.
35. J’adore le rugby. Dans une mêlée, les huit joueurs sont liés et recherchent la cohésion
maximale. Si l’un d’entre eux ne respecte pas son rôle et l’organisation, le groupe explose sous
les contraintes extérieures – qui peuvent être douloureusement ressenties dans ce cas précis.
36. Voir §7.2

Enfin les ressources matérielles correspondent aux machines et outils qu’il
faudra mobiliser. Elles peuvent être imposées par des réalisations très spécifiques
qui seraient requises pour l’accomplissement du Projet, mais elles seront en général
contraintes par l’aspect financier.
La combinaison des ressources dont on va pouvoir disposer permet de tra-
vailler à la planification du Projet.
7.5 Planifier le Projet
Une fois qu’on aura construit la liste complète des lots de travail nécessaires
pour exécuter un Projet, on devra les agencer pour pouvoir répondre à différentes
exigences :
— Les relations d’antériorité entre les tâches.
On construit en général les fondations d’un bâtiment avant les murs puis le
toit.
— Les ressources nécessaires à l’exécution des tâches.
Il s’agira de déterminer qui (ou quoi dans le cadre de l’utilisation d’une
machine) va réaliser la tâche. On s’intéressera aussi au taux d’occupation.
En effet, une personne qui n’aurait besoin de consacrer que 50% de son
temps à une tâche pourra utiliser le reste sur un autre lot de travail. Les
deux activités pourraient donc être planifiées en parallèle – du moins en
partie.
Différents outils vont permettre au Chef de Projet de répondre à ces de-
mandes.
7.5.1 Juste avant de planifier : estimer la durée des lots
L’estimation de la durée que nécessitera la réalisation d’une tâche ou d’un
lot est considérée comme complexe, parce qu’il y a toujours une part d’inconnue
avant (et même pendant) la réalisation d’une tâche.
On retrouve cependant ici l’intérêt d’une décomposition correctement faite,
jusqu’à un niveau de détail assez avancé. Il est plus aisé d’estimer le temps qui sera
nécessaire quand on parle d’une tâche élémentaire limitée que du Projet global,
considéré d’un bloc.
On devra alors faire appel à l’expérience, en réfléchissant à ce qui est néces-
saire de faire pour accomplir la tâche, et en recherchant des similitudes avec des
réalisations similaires dans le passé.

7.5. PLANIFIER LE PROJET 77
7.5.2 Le PERT
Le PERT, pour Program Evaluation and Review Technique est un outil qui
a été développé dans les années 50 par la marine américaine.
Il s’agit d’une représentation graphique de la totalité du Projet avec l’en-
semble de ses lots de travail. Pour chacun d’entre eux, il mentionne :
— Des informations de durée
— Les lots prédécesseurs
— Les lots successeurs
On saura donc concrètement avec le PERT quel doit être la succession de
lots à mettre en place et quelle sera la durée prévisible du Projet.
Le PERT dispose d’une technique pour le calcul des dates de commencement
et d’achèvement de chaque lot avec leur marge de réalisation.
Un petit aparté concernant les notions de durées (et donc de dates). . .
La construction du PERT demande de connaître la durée des tâches qu’on
doit y intégrer. Cette durée doit évidemment être estimée.
Pour cela, le Chef de Projet devra faire appel, comme pour la construction
du WBS a
à une équipe d’experts qui pourra estimer leur durée au vu de
la complexité et de la quantité de travail requise par chaque lot de travail.
Ce travail est parmi les plus complexes à réaliser parce qu’il demande de
l’expérience pour pouvoir aboutir à des conclusions valables.
a. Voir §7.4
Comment construit-on ce graphique ?
La première étape est relativement simple : il s’agit d’agencer l’ensemble des
lots de travail en fonction des liens de dépendance qu’ils ont entre eux.
Par exemple, si un Projet comporte quatre lots dont les relations sont :
— Le Lot 2 nécessite d’avoir terminé le Lot 1.
— Le Lot 3 nécessite d’avoir terminé le Lot 1.
— Le Lot 4 nécessite d’avoir terminé le Lot 2 et le Lot 3.
On aboutira à la structure suivante :

Figure 7.7 – Structure de base d’un diagramme PERT.
Le diagramme PERT appelle quelques commentaires :
Le diagramme est constitué d’étapes, représentées ici par les disques, et de
tâches qui sont représentées par des flèches. Les étapes sont numérotées (ou identi-
fiées selon les processus spécifiques qui peuvent être en vigueur); les flèches peuvent
être nommées avec les noms des lots de travail. On obtient donc un réseau qui dé-
crit de façon complète l’enchaînement des lots de travail qui sont nécessaires pour
atteindre les objectifs du Projet.
Les règles de construction sont simples :
— Une tâche part obligatoirement d’une étape pour arriver à une autre.
— Plusieurs tâches peuvent partir d’une même étape.
— Plusieurs tâches peuvent converger vers une même étape.
Le PERT représente le flux de travail en indiquant les tâches qui doivent être
terminées pour pouvoir passer aux suivantes.
L’outil va cependant beaucoup plus loin dès qu’on introduit les notions de
durées de tâches. En effet, on aura remarqué la symbolique particulière de la
représentation des étapes qui comporte l’identification, et deux champs qui vont
être utilisés pour gérer le temps :
Figure 7.8 – Représentation d’une étape dans le diagramme PERT.
Le symbole représentant une étape comporte différentes informations :

— L’identifiant « ID » de l’étape est unique et permet de s’y référer.
— La date au plus tôt représentée par le « t » correspond à la date minimale
à laquelle il sera possible de terminer la (les) tâche(s) qui aboutissent à
l’étape considérée.
— La date au plus tard (le « T ») sera celle à laquelle on achèvera la tâche de
durée maximale qui y conduit.
— Le délai entre la date au plus tôt t et la date au plus tard T correspondra à
la marge de réalisation de la tâche. Ce point est important pour la gestion
des délais globaux du Projet comme on va le voir.
Chaque étape du diagramme PERT comporte donc différentes informations
relatives aux délais, mais comment les détermine-t-on ?
La calcul des valeurs de dates au plus tôt et des dates au plus tard se fait en
deux phases ascendante, puis descendante :
1. On commence par le début du Projet, pour calculer la date au plus tôt t de
chaque étape :
tn = tn−1 + Dn
où on aura :
— tn qui est la date au plus tôt qu’on veut calculer pour l’étape n.
— tn−1 est la date au plus tôt de l’étape précédant l’étape n.
— Dn est la durée de la tâche qui permet de passer de l’étape n-1 à l’étape
n.
Dans le cas où l’étape n a plusieurs prédécesseurs (et donc que plusieurs
tâches convergent vers l’étape n), tn sera égale à la plus grande des valeurs
calculée avec chaque couple [tn−1;Dn] 37
.
De proche en proche, on peut ainsi calculer les dates au plus tôt pour toutes
les étapes.
2. Pour calculer les dates au plus tard, on partira de la fin du diagramme 38
On calculera donc les dates au plus tard T suivant la formule :
Tn−1 = Tn − Dn
avec :
— Tn−1 est la date au plus tard qu’on cherche à calculer pour l’étape n-1.
37. Ce qui est logique, parce qu’on ne peut pas arriver à une étape avant d’avoir achevé toutes
les tâches (dont la plus longue) qui convergent vers elle
38. D’où l’intérêt de respecter l’ordre de la méthode : il faut avoir terminé le calcul de toutes
les dates au plus tôt pour avoir la première donnée d’entrée.

— Tn est la date au plus tard de l’étape n dont on dispose.
— Dn est la durée de la tâche qui permet de passer de l’étape n-1 à l’étape
n.
Ici, on pourra se retrouver à vouloir calculer la date au plus tard pour une
étape qui a plusieurs successeurs – c’est à dire que plusieurs tâches partent
de cette étape. Dans ce cas, la date au plus tard cherchée sera égale à la
plus petite des valeurs calculées pour tous les couples [Tn;Dn].
Comme on l’a évoqué plus haut, une information importante pour le chef de
Projet est la marge qui est associée à chaque tâche. Elle se calcule selon la formule :
∆ = T − t
La marge ∆ représente une période pendant laquelle on pourra terminer une
tâche donnée sans conséquence pour le calendrier global du Projet. En pratique,
le fait de terminer à la date T ne mettra pas tout le Projet en retard 39
D’autre part, le calcul des marges a une importance particulière pour le
Projet global : il existe toujours un enchaînement de tâches dont les marges sont
nulles; on l’appelle le chemin critique (voir ﬁgure 7.9. Tout retard pris sur une
tâche qui en fait partie sera intégralement répercuté sur le Projet complet.
Il faudra par conséquent être vigilant sur le suivi et la gestion des tâches qui
composent le chemin critique.
Figure 7.9 – Visualisation du chemin critique dans un diagramme PERT.
Le chemin critique est ici représenté en rouge. Pour chaque étape, on a alors
bien des dates au plus tôt et au plus tard égales.
39. En général on a malheureusement plutôt tendance à terminer tard que tôt. Voir la loi de
Murphy évoquée brièvement page 15.

Pour résumer, le diagramme PERT est un outil puissant pour le gestion d’un
Projet :
— Le PERT met en évidence clairement les dépendances entre les lots de
travail qui ont été identifiés lors de la création du WBS.
— Le PERT permet d’identifier et de visualiser le chemin critique.
— Le PERT permet d’optimiser la durée du Projet en travaillant sur les tâches
les plus pertinentes. Ce sont les tâches qui aboutissent à des nœuds (étapes)
important(e)s, ou qui sont isolées (quand il n’y a aucune autre tâche simul-
tanée possible.
— Le PERT permettra aussi de repérer les périodes à risque pour la gestion
des ressources quand plusieurs tâches seront en parallèle.
— Enfin le PERT est évidemment un outil de communication intéressant parce
qu’il présente l’ensemble de la structure du Projet de façon graphique.
Le PERT est très utilisé pour les gros projets.
7.5.3 Le diagramme de GANTT
Le second outil qui est fréquemment utilisé pour gérer le calendrier d’un
Projet est le diagramme de GANTT 40
. Il s’agit d’une représentation chronologique
du Projet qui fait apparaître les lots de travail sous forme de barres rectangulaires,
et les jalons sous forme de losanges (voir §5.1) comme sur la figure 7.10 page 82.
Il s’agit d’une synthèse qui regroupe un grand nombre d’informations.
La figure 7.10 synthétise les informations disponibles sur un diagramme de
GANTT :
1. Les lots de travail (ou tâches – 1 ) sont représentés par des barres horizon-
tales donc la longueur représente la durée.
2. Les interruptions du Projet ( 2 ) sont mise en évidence par une zone grisée
verticale qui barre tout le diagramme. La largeur est évidemment propor-
tionnelle à la durée de l’interruption.
Par exemple, ces interruptions peuvent correspondre à des périodes de
congés. Pendant ces périodes, le Projet sera en sommeil.
3. Les marges ( 3 ) des tâches sont représentées par des rectangles vides. On
remarquera que cette représentation graphique montre bien qu’une tâche
pourra être retardée jusqu’à la prochaine tâche appartenant au chemin cri-
tique sans conséquence pour le planning global (voir ci-dessous).
4. Le chemin critique ( 4 ) est clairement visible sur le diagramme de GANTT :
il s’agit de l’ensemble de tâches consécutives dont les dates de fin et de
40. Évoqué pour la première fois en 1910 par l’ingénieur américain Henry L. Gantt

Figure 7.10 – Synthèse des informations sur un diagramme GANTT
début correspondent exactement. On le représente en générale en colorant
les tâches concernées en rouge, ou en les barrant d’un trait horizontal rouge.
5. Le diagramme de GANTT peut indiquer le planning de référence ( 5 ) avec
des lignes horizontales noires qui représentent les lots de travail avec les
dates planiﬁées initialement.
Il s’agit de la version initiale du calendrier du Projet. On verra que le plan-
ning d’un Projet est évolutif 41
. La mention du planning de référence permet
de représenter facilement les écarts par rapport à la référence initiale.
6. Le relations entre les tâches dont représentés par des ﬂèches ( 6 ) qui partent
d’une tâche (prédécesseur) et arrivent à une autre (successeur).
Concrètement, une tâche successeur ne devrait débuter que lorsque tous les
prédécesseurs seront terminés. En pratique on pourra avoir certains lots de
travail qui débutent avant que tous leurs prédécesseurs soient achevés. Par
exemple, on pourra avoir une phase de préparation qui permettra d’exploiter
les livrables d’une tâche antérieure. Cette préparation pourra débuter avant
d’avoir obtenu les résultats pour gagner du temps.
7. Les jalons sont représentés par des losanges ( 7 ). Il s’agit de dates impor-
tantes pour le Projet, qui correspondent souvent à des réunions importantes
où on établit un statut du Projet avec toutes les parties impliquées.
8. L’indicateur de date (une ligne verticale à la date du jour – 8 ) donne
41. En fait il est rare que tout se passe comme prévu, donc on prend du retard, on réorganise. . .

des indications immédiates sur l’état dans lequel devrait être un Projet
à une date donnée. On visualise tout de suite les tâches en cours et leur
avancement théorique (en fonction de la longueur de la barre représentative
déjà passée.
9. L’indicateur d’avancement ( 9 ) permet de vérifier immédiatement si le Pro-
jet avance conformément aux attentes. Il est représenté par un trait noir à
l’intérieur de chaque barre de tâche. Ce trait montre l’avancement réel du
lot de travail considéré.
Si cet indicateur est en retard par rapport à la date du jour (voir élément
8 ), la tâche en question n’avance pas assez vite par rapport aux prévisions.
Le diagramme de GANTT est un outil puissant qui permet de présenter
rapidement une vision synthétique du Projet.
Mais comment le construire ?
Comme pour le PERT 42
, la construction du diagramme de GANTT se basera
sur le WBS 43
du Projet. Une bonne partie de l’analyse est d’ailleurs identique dans
les deux cas.
On commencera donc avec une liste des lots de travail à réaliser pour at-
teindre les objectifs du Projet, puis on déterminera leurs durées prévisibles.
On affectera ensuite les ressources disponibles à chaque tâche. Cette étape
est importante, parce qu’on pourra avoir des ressources appelées à intervenir sur
plusieurs lots. Cela sera une contrainte dont il faudra tenir compte parce qu’on ne
devra pas avoir de taux d’utilisation trop important pour chaque ressource.
On pourra donc à ce moment définir l’enchaînement des tâches, en tenant
compte de leurs relations de dépendance. Le taux d’utilisation des ressources cité
au-dessus prend ici toute son importance : certaines tâches pourront avoir à être
déplacées ou étalées dans le temps quand les ressources nécessaires ne sont pas
disponibles 44
.
Enfin on pourra terminer le diagramme de GANTT en définissant des jalons.
Il s’agit de dates clés du Projet qui permettent d’évaluer son état.
Un jalon peut avoir plusieurs justifications :
— Un point sur l’avancement du Projet.
42. Voir page 77
43. Ce coup-ci, voir la page 7.2.3
44. Une remarque concernant les taux d’utilisation des ressources : il faudra être prudent sur
les prévisions de taux d’occupation. Si on envisage de saturer complètement une ressource (c’est-
à-dire qu’on la charge à 100% en l’affectant à une ou plusieurs tâches, on ira certainement au
devant de problèmes. Il faut garder à l’esprit qu’un Projet comporte invariablement une part
d’imprévu. Il est donc indispensable de garder une petite marge de sécurité.

Il sera souvent nécessaire de définir des points de contrôle pour s’assurer
que le Projet progresse bien comme prévu.
En effet, s’il ne faut pas perdre de vue les objectifs finaux, une avancée
conforme aux attentes est une première garantie du respect final des critères
QCD 45
.
Une méthode couramment utilisée dans ce contexte est celle du Cycle de
Deming 46
(le Plan-Do-Check-Act).
— La fourniture d’un livrable au client du Projet.
Du point de vue du Client, un Projet pourrait être considéré comme une
boîte noire qui fournirait à la sortie un résultat désiré. Si ce fonctionnement
pourrait paraître acceptable en théorie, il l’est moins en pratique. Le Client
engage souvent des moyens importants, en particulier quand le Projet est
complexe. Il est donc naturel qu’il désire suivre les avancées de façon plus
progressive. La fourniture de livrables intermédiaires sera donc souvent mise
en place pour répondre à ce besoin.
Par exemple, un fournisseur pourra devoir livrer un dossier de conception
pour s’assurer que le produit répondra bien aux exigences, puis organiser
une réception 47
du produit en fin de fabrication avant la livraison.
La fourniture d’un livrable intermédiaire correspondra souvent à un jalon
d’acceptation par le client : il devra valider le travail fourni et autoriser la
poursuite du Projet 48
.
Un jalon prendra généralement la forme d’une réunion (appelée revue).
Elle impliquera les parties prenantes du Projet directement concernées par
la phase de Projet en cours :
— L’équipe (et le Chef de) Projet
Les acteurs principaux du Projet seront évidemment impliqués pour présen-
ter le statut et l’état d’avancement du Projet. Au jalon correspondent des
objectifs qui définissent un état d’avancement. Le rôle de l’équipe Projet
sera de montrer que les résultats obtenus sont en ligne avec ceux attendus,
afin de pouvoir obtenir l’accord pour poursuivre les travaux.
Il faudra donc produire des présentations, pour fournir à tous le niveau
d’information requis, et des résultats, pour valider ce qui aura été fait jusque
là.
Par exemple, une revue de fin de développement pour un produit pourra
45. Voir §1.1
46. Plus de détails là-dessus dans la partie V qui listera quelques outils intéressants pour la
gestion de Projet.
47. Inspection/vérification
48. Cette validation constitue aussi un engagement du client. En cas de problème ultérieur,
l’équipe Projet pourra souvent arguer du fait que le client avait accepté les livrables précédents
– ceci en restant de bonne foi bien entendu. . .

7.6. LA RÉUNION DE LANCEMENT 85
s’appuyer sur les calculs démontrant qu’il atteint le niveau de performance
attendu, et sur un dossier de fabrication qui démontre sa faisabilité.
— Les clients du Projet
Internes à l’entreprise ou externe, le client garde le pouvoir de décision
quant au déroulement global du Projet 49
.
Pendant une revue, on vérifiera avec le client que les résultats obtenus sa-
tisfont les exigences du Projet.
Il pourra alors y avoir une décision de poursuite ou non du Projet (on parle
de Go/No go).
Le diagramme de GANTT semblera souvent plus accessible que le PERT
pour les personnes qui ne sont pas impliquées dans le Projet et constitue un très
bon support de communication visuelle. Toutefois, il pourra être très compliqué à
construire pour de très gros Projets.
7.6 La réunion de lancement
Une fois le Projet préparé, le chef de Projet devra organiser une réunion
de lancement (souvent appelé Kick-Off ), regroupant toute l’équipe Projet, pour
donner les objectifs et la vision du Projet, et présenter le plan de réalisation, avec
l’organisation de l’équipe, le planning et les règles de fonctionnement qui seront
mise en œuvre.
La réunion comportera plusieurs temps :
— Le tour de table
Chacun doit se présenter brièvement pour que les gens sachent vers qui
ils pourront se tourner en cas de besoin. Il est important de créer dès le
départ un esprit d’équipe et d’entraide et de concrétiser le début d’un travail
collectif.
— Rappel du contexte et des objectifs
On rappelle au participants les raisons qui ont conduit au lancement du Pro-
jet, et les enjeux et objectifs qui le guideront. Il faut amener tout le monde
au même niveau de connaissance pour que l’équipe Projet soit homogène.
Il est important d’insister sur le pourquoi du Projet. Le fait de donner du
sens à l’action est un levier de motivation très efficace.
On précisera aussi quels seront les principaux livrables qu’il faudra fournir.
— La description des grandes phases du Projet
On détaille à ce moment le planning qui sera mis en place, en faisant le lien
avec l’exécution, c’est à dire les actions à mener au cours de chacune d’elles.
49. Un aparté : il est intéressant de s’intéresser à ce rôle de Client, quelque soit le contexte –
dans le cadre d’un Projet ou de tâches quotidiennes. En effet, la satisfaction de ses besoins est
le meilleur moyen de définir ce qui doit être fait.

Il faut encourager l’échange, pour que la méthode retenue soit acceptée et
validée par tout le monde.
— La présentation de l’équipe
On présente maintenant les rôles et responsabilités de chacun pour que tout
le monde comprenne ce qu’il aura à faire et ce que feront les autres. C’est
aussi un point essentiel pour la cohésion : le fait de comprendre l’apport de
chacun à l’entreprise commune favorise la solidarité et l’entraide.
On peut mettre en place à ce moment un répertoire qui permettra d’avoir
à disposition les coordonnées des personnes.
— L’identification et la gestion des risques
On établit avec l’équipe une liste des risques potentiels et on réfléchit à ce
qu’il faudra mettre en place pour les gérer 50
. A ce stade, on réfléchit aussi
par rapport au contexte et à l’environnement du Projet pour identifier les
personnes ou groupes extérieurs qui pourraient constituer des freins.
— Le plan de communication
On détaille les modalités et règles de circulation de l’information au sein de
l’équipe Projet : qui sera informé, quand et par quel moyen 51
.
— Les indicateurs d’avancement
Les indicateurs sont importants pour disposer d’outils pour mesurer l’avan-
cement vers des objectifs fiables et incontestables.
— La planification des prochaines réunions
Donner une liste des prochaines échéances permet tout de suite d’inscrire
l’équipe dans l’action en donnant une perspective sur ce qui devra être fait.
La réunion de lancement effectuée, le Projet entre alors dans sa phase d’exé-
cution.
50. Voir à ce sujet le chapitre 10.
51. Voir le §7.3.2.

Chapitre 8
L’exécution du Projet
8.1 Le développement
Le Projet une fois lancé, l’équipe doit développer des solutions qui répondent
aux besoins exprimés dans le Cahier des Charges du client.
Il n’existe évidemment pas de méthode infaillible pour arriver à un résultat
satisfaisant. Le propre d’une phase de recherche est qu’il n’y a pas de certitude de
trouver LA solution qui satisfasse toutes les parties. Pourtant, on retrouve souvent
certaines étapes clés :
— La recherche d’informations
— L’identification de principes de conception
— La définition d’une architecture
— La conception détaillée
Le chef de Projet doit ici tenir un rôle de leader pour créer une dynamique,
en proposant des idées, des initiatives. Le risque au cours de ces phases et que tout
le monde se regarde sans trop savoir par où prendre le problème, et en attendant
une mise en action qui doit venir d’un autre. C’est en pratique une sorte d’équilibre
instable parce qu’il suffit souvent d’apporter une idée, ou de lancer une action de
recherche, pour que les membres de l’équipe aient de nouvelles idées et s’impliquent
pour réfléchir et expérimenter.
Le chef de Projet doit être un aiguillon, puis avoir en plus un rôle de support
en apportant son expertise (propre ou déléguée à des experts) pour orienter les
recherches dans certaines voies.
87

88 CHAPITRE 8. L’EXÉCUTION DU PROJET
8.1.1 Connaître l’existant - connaître le possible
Le contexte
L’objectif de tout Projet est de fournir au client une solution qui répond aux
besoins qu’il a exprimé. Il y a alors deux alternatives :
— Une solution existe déjà.
Il s’agit alors de l’identifier, la valider et la proposer au Client.
— Il faut créer une solution.
Il faut alors acquérir tous les pré-requis qui permettront de développer la
solution, puis piloter l’équipe pour mener une démarche d’innovation.
Les deux démarches sont sensiblement différentes, et leur description sort du
cadre de ce livre. Pourtant, le Chef de Projet doit dans les deux cas assumer un
rôle de leader pour orienter son équipe et la rendre la plus performante possible.
Ce rôle comporte différentes facettes.
Comme toute organisation, une équipe Projet possède une certaine inertie; le
Chef de Projet devra impulser le mouvement pour amener ses collègues à le suivre
dans un premier temps, puis à prendre de plus en plus d’initiatives dans le cadre
de travail défini.
Le mode Projet est par essence collaboratif. Pour obtenir les meilleurs résul-
tats possibles, il faut que les compétences individuelles puissent s’exprimer pleine-
ment, et que les interactions favorisent l’émergence d’idées et de créativité.
Enfin, l’innovation impose généralement de faire des choix. S’il est évidem-
ment préférable qu’ils soient le fait du groupe, — c’est-à-dire que l’analyse des faits
et de la situation et la discussion amènent au consensus — il arrivera régulière-
ment qu’on ne puisse aboutir à un accord de tous les participants. Chacun pourra
avoir son interprétation de la situation pour des raisons personnelles (expérience,
compétences, voire croyances ou goûts 1
). Le Chef de Projet devra alors prendre
la responsabilité de faire avancer le travail en prenant des décisions sous la double
casquette de dirigeant de son équipe, et garant des résultats du Projet vis-à-vis du
Client et de l’entreprise.
En résumé, le Chef de Projet devra donc :
— Conduire son équipe.
— Manager son équipe.
— Prendre des décisions.
Ces rôles ont déjà été évoqués au chapitre 7.1, et il prennent une importance
particulière durant ces phases préliminaires.
1. On ne négligera pas les aspects humains dans la conduite de Projet. Il est naturel pour
un intervenant de privilégier des solutions qu’il maîtrise. Une personne très expérimentée pourra
aussi être réfractaire à la nouveauté.

8.1. LE DÉVELOPPEMENT 89
Il est indispensable de partir sur des bases solides avant de commencer à
réfléchir à créer de nouveaux concepts. Il est donc primordial de faire un état des
lieux fiable pour disposer de tous les éléments utiles pour la suite.
Pour revenir aux deux alternatives évoquées plus haut 2
, on devra parvenir
à la fin de cette pré-étude à une situation qui va permettre de répondre au besoin
exprimé par le Client :
— Une solution existante a été identifiée et devra être proposée au Client.
On pourra alors se heurter à des réticences parce que l’issue logique aurait
été de livrer une nouveauté. Il appartient au Chef de Projet d’expliquer à
son Client les bénéfices qu’il tirera de l’alternative offerte. Les arguments
les plus immédiats pourront être le coût (on économise évidemment un dé-
veloppement qui aurait pu être coûteux) et la fiabilité (parce que la solution
est connue et maîtrisée; du moins dispose-t-on de retour d’expérience à son
sujet).
— Aucune solution existante n’a été trouvée.
La phase de recherche devra dans ce cas permettre d’identifier des principes
de conception. Sans définir encore complètement la solution finale, ils vont
permettre d’effectuer les choix d’architecture.
Une méthode
Cette étape de recherche est importante pour la réussite finale, mais elle
présente aussi certains dangers potentiels qu’il faudra savoir déceler pour les éviter.
On devra garder constamment à l’esprit les objectifs finaux pour éviter de
diverger sous prétexte de recherche de solutions nouvelles. Il est fréquent qu’on
repousse encore et encore le début de l’étude parce qu’on veut explorer une dernière
possibilité qui semble prometteuse.
La finalité du Projet n’est pas d’avoir un inventaire exhaustif de toutes les
solutions possibles, mais d’apporter au Client une solution qui répond à ses besoins
avec le meilleur compromis QCD 3
. Le Chef de Projet devra donc faire la synthèse
entre le besoin de liberté requis par la recherche et l’innovation, et le besoin de
cadrage du Projet.
Il faudra par conséquent allouer une durée maximale pour la recherche de
solutions tout en maximisant les opportunités. Le talent du Chef de Projet se
traduira dans sa capacité à stimuler le processus de création.
L’analyse et la connaissance approfondie des exigences vont à la fois per-
mettre de limiter le champ des recherches en évitant d’étudier des pistes vouées
2. Une solution existe ou aucune solution n’existe.
3. Voir le paragraphe 1.

à l’échec, mais elles donneront aussi une vision exhaustive des possibilités parce
qu’on aura une définition fonctionnelle des solutions.
Durant cette phase, le Chef de Projet fera appel à différentes techniques et
méthodes qui relèvent des domaines de la veille technologique et de la créativité.
Observer l’existant La veille technologique doit être un processus permanent
qui permet à l’équipe Projet – plus largement la structure dans laquelle elle s’in-
tègre – de rester au fait de l’état de l’art des disciplines et des domaines dans
lesquels elle opère. La finalité du Projet étant de livrer la meilleure solution qui
correspond au besoin du client, il est indispensable de posséder les connaissances
qui permettront d’analyser les situations et de s’orienter vers les bons objectifs.
La veille technologique donnera la culture et le socle de connaissance qui
aideront à cadrer la phase de recherche. Sans connaître encore ce qui résultera du
Projet, elle permettra d’évaluer à priori si certaines pistes méritent d’être travaillées
ou resteront sans issue et donc de borner l’espace des solutions possibles.
À l’inverse, la veille technologique permettra aussi de multiplier les opportu-
nités. En augmentant les connaissances, elle favorisera les associations d’idées et
ouvrira des possibilités nouvelles.
L’expérience des membres de l’équipe Projet est ici importante et nécessaire.
C’est un point dont il faut tenir compte quand on constitue l’équipe 4
pour disposer
de l’expertise à ce moment crucial.
On ne traitera pas en détail de la mise en œuvre qui fait l’objet d’une do-
cumentation abondante, mais on soulignera juste que de nombreux outils et de
nombreuses sources sont facilement accessibles sur Internet pour suivre l’actualité
d’un domaine donné 5
.
Imaginer le possible Une fois fait l’état des lieux, l’équipe Projet doit imaginer
ce que pourraient être des solutions 6
et initier une démarche d’innovation et de
créativité.
Là encore, la littérature et la documentation sont abondantes, mais on peut
mettre en évidence certains éléments essentiels.
— Un critère important d’innovation est lié à la constitution de l’équipe Projet
qui doit être multidisciplinaire et intégrer toutes les compétences pour
couvrir le domaine du Projet. Il ne s’agit pas simplement de pouvoir adres-
ser toutes les implications techniques des exigences, mais de s’assurer que
chacun enrichira la synthèse commune grâce à son point de vue spécifique.
4. Voir le §7.3.
5. Une simple recherche Web, l’abonnement à des flux RSS, des newsletters. . .
6. Enfin des principes, à ce stade. . .

Afin de pouvoir innover, il faut aller au-delà d’une simple juxtaposition des
compétences, et parvenir à une collaboration efficace qui permet l’émergence
d’idées nouvelles. La collaboration permet d’obtenir un résultat supérieur
à la somme des parties 7
parce que les mises en relation de concepts en
génèrent de nouveaux.
— Cette phase de créativité prendra souvent la forme d’un brainstorming.
C’est une technique classique pour l’innovation, qui demande de laisser aux
intervenants la liberté d’exprimer toutes leurs idées.
On peut aussi préciser que dans le cadre d’un Projet, il sera indispensable
de respecter toutes les idées. Ce respect doit se comprendre sous deux
angles différents.
Le premier, le plus immédiat, est de garantir la liberté dont on vient de
parler.
Le second est moins intuitif mais tout aussi important : il faut pourvoir
s’opposer à une idée ! On doit garder à l’esprit que le Projet est contraint
dans le temps. Il sera donc primordial d’éliminer au plus tôt toute idée
qui mènerait à une impasse. Respecter l’idée consistera à l’écarter de façon
argumentée en se basant sur des faits concrets pour être certain de ne pas
passer à côté de solutions potentielles viables.
— Enfin, les idées doivent être évaluées et analysées rapidement pour
lister leurs conséquences et implications, et élargir le domaine de travail.
Chaque idée nouvelle ouvre de nouvelles pistes et multiplie les possibilités
d’innovation, construisant ainsi une arborescence de solutions.
En tant que leader de son équipe, le chef de Projet devra absolument jouer
un rôle moteur durant cette phase. Il lui sera donc utile de se former pour acquérir
les bases de l’innovation et de la créativité. Il devra être capable d’orienter et de
dynamiser les recherches, de relancer les efforts quand cela s’avèrera nécessaire.
Quelques techniques peuvent être utiles. Sans les lister toutes, on peut citer :
— La recherche des effets contraires qui peut permettre, en étudiant comment
parvenir à un résultat opposé à celui recherché, de mettre en évidence des
leviers d’action qui pourront être efficaces.
— Le transfert de connaissances entre des domaines d’applications est vecteur
d’innovation. Transposer un concept peut lui donner de nouveaux usages
dans un domaine autre que celui d’origine.
Des méthodes d’innovation plus formalisées ont aussi été développées, comme
TRIZ 8
ou le Design Thinking qu’on évoque brièvement au chapitre 12.4.2.
Enfin, il est nécessaire de souligner que l’innovation demande un environne-
7. c Aristote ?.
8. Voir le site www.triz.org ou la page Wikipedia.

ment propice. Le terrain doit être fertile. Pour cela, il faut être curieux et s’intéres-
ser à l’actualité des domaines dans lesquels on travaille en particulier, mais aussi
des domaines connexes et des domaines « structurants ».
Les domaines connexes peuvent être sources d’idées directement transpo-
sables parce que les techniques et les connaissances sont similaires.
Les domaines structurants offrent des outils qui permettent des avancées fon-
damentales. Par exemple, l’informatique ouvre de nouvelles possibilités grâce à la
puissance de calcul qui ne cesse d’augmenter, ou aux possibilités de communication
qui créent de nouveaux usages.
8.1.2 Orienter la conception
Le Chef de Projet est le garant de la réussite de son équipe. Comme on l’a
déjà évoqué au paragraphe 7.1, il doit orienter le groupe, piloter les actions pour
parvenir au résultat souhaité.
Cet aspect est essentiel durant la phase de développement parce que les
décisions prises alors ont un impact important pour la suite 9
. Pourtant, le Chef de
Projet ne possède souvent pas l’expertise technique qui lui permettrait d’analyser
de façon objective et fiable les situations et les solutions pour pouvoir prendre les
bonnes décisions.
Il faut alors être capable de s’appuyer sur les compétences de ses collègues
pour obtenir les synthèses et analyses nécessaires pour faire les choix requis.
Cela revient donc en pratique à déléguer une partie de son pouvoir de dé-
cision parce qu’on ne peut se prononcer sur ce qu’on ne connaît pas. Même si
formellement la décision est le fait du Chef de Projet, elle est directement déduite
des informations qu’on lui aura fourni.
Il sera donc indispensable que tous les intervenants soient informés des enjeux
du Projet afin qu’ils fournissent les éléments qui permettront d’aller dans la bonne
direction. Un expert technique devra par exemple recommander une solution parce
qu’elle est la meilleure pour le projet même si une alternative intrinsèquement plus
performante existe.
La conception préliminaire
Le développement d’un produit se déroule suivant différentes phases ou plu-
tôt différents états. Concrètement, le produit va passer par différents niveaux de
définition et de maturité; on partira d’un résultat grossier pour arriver par affinages
successifs à une version finalisée.
9. Voir le §2.2.1 à ce sujet.

La conception préliminaire permet de dégrossir le travail de l’équipe, en iden-
tifiant les principes généraux que devra respecter la solution.
Le Chef de Projet doit chercher à orienter son équipe pour atteindre les
objectifs fixés. On vient de voir qu’il faut concilier en permanence le besoin de
liberté de l’équipe – pour favoriser l’innovation et la créativité – et le besoin de
cadrage pour respecter les contraintes du Projet – on pense en premier lieu aux
délais et aux coûts.
On cherchera par conséquent à économiser les efforts en sélectionnant au plus
tôt des solutions potentiellement intéressantes.
Lors de cette phase, le Chef de Projet aura donc intérêt à favoriser l’explo-
ration rapide de multiples solutions pour sélectionner les plus intéressantes 10 11
.
Le Chef de Projet devra particulièrement faire attention à la prise en compte
des exigences définies dans le Cahier des Charges. Une erreur, ou des choix qui
ne seraient pas compatibles avec les exigences pourraient avoir des conséquences
importantes pour la suite du Projet 12
.
Il doit donc maîtriser complètement les spécifications client pour identifier
au plus vite toute déviation par rapport aux fonctions attendues ou au périmètre
du Projet. C’est un point essentiel de sa fonction parce qu’il ne peut être question
d’assumer la responsabilité de décisions sans connaître parfaitement le contexte
du Projet.
Deux cas de figure peuvent se présenter ici :
— Le Chef de Projet a été impliqué depuis le début – c’est-à-dire qu’il a parti-
cipé à la phase de spécification dans le cadre d’un Projet interne, ou qu’il a
participé à la construction de l’offre dans le cas d’un Projet pour un client
externe.
Cette expérience est alors évidemment un atout précieux pour la maîtrise
de l’environnement global du Projet constitué d’éléments internes (le cahier
10. Point déjà abordé au chapitre 8.1.1
11. On pourrait aussi parler ici des méthodes agiles qui, bien que opposées en apparence à la
gestion de Projet « classique » qui est plus ou moins à la base de ce livre, peuvent tout à fait la
compléter et l’enrichir au cours de phases qui demandent des résultats rapides et exploitables.
— Le manifeste agile explique les principes de ces méthodes. A voir sur
http://agilemanifesto.org/iso/fr/manifesto.html.
— Parmi les différents méthodes agiles existantes, SCRUM peut être très intéressante, parce
que son principe même est de livrer rapidement des itérations fonctionnelles. Elle permet
de tester concrètement des solutions techniques pour ne conserver que celles qui ont le
plus de potentiel.
Voir par exemple le livre [2] qui présente la méthode de façon pratique.
12. Voir à ce sujet la figure 2.1 pour comprendre qu’une décision prise en début de projet a un
impact important par la suite.

des charges, les ressources disponibles. . .) et externes (le client et la relation
avec lui, le domaine technique, l’environnement concurrentiel. . .).
— Le Chef de Projet a été nommé pour l’éxécution du Projet uniquement,
sans les antécédents développés ci-dessus.
Il faudra alors fournir un effort qui peut être important pour parvenir au
plus vite à un niveau de connaissance avancé de l’environnement global du
Projet. Il faudra aussi être capable de s’appuyer sur les experts disponibles 13
dans l’équipe pour obtenir les informations clés à surveiller ou prendre des
décisions.
A la fin de la conception préliminaire, l’équipe Projet doit être en mesure de
présenter une ébauche de solution qui permet de valider la conformité des choix
effectués.
L’intérêt est d’avoir prototypé les fonctions principales de la solution tech-
nique finale. Les éléments qui sont dimensionnants en termes de coût, de complexité
ou de délai doivent avoir été étudiés et leur méthode d’implémentation décidée.
Dialoguer fréquemment avec le Client
Si le Cahier des charges du client ne doit pas laisser de latitude à l’équipe
Projet quant aux fonctions que doit offrir le produit final, les possibilités de mise
en œuvre peuvent être multiples et variées.
L’objectif du Projet est de fournir une réponse totalement conforme à la
spécification. Toutefois, cette conformité technique peut souvent être obtenue par
le biais de solutions qui ne satisferont pas pleinement le Client, que ce soit en
termes d’ergonomie, de design, de fonctionnement 14
. . . Ces éléments ne coûtent
pas forcément plus cher à implémenter si on en tient compte dès le début du Projet.
Or ils font partie de ce qu’on pourrait appeler une zone grise d’exigences non
formulées explicitement parce qu’elles sont initialement inconnues, ou n’ont pas de
sens fonctionnellement. L’équipe Projet peut donc avoir à prendre en compte des
exigences additionnelles – et non contractuelles – en plus du socle de base.
On peut alors se retrouver face à un paradoxe apparent puisque le périmètre
du Projet, prérequis essentiel qu’on s’efforce de figer, de geler, en début de Projet,
13. 2 remarques à ce propos :
— Le terme d’« expert »est peut-être un peu fort. Il s’agit simplement d’avoir l’humilité de
demander leur avis à ceux qui ont plus d’expérience sur le Projet.
— Il faudra aussi souvent gérer le manque de ressources disponibles. On a généralement le
sentiment qu’une équipe Projet vit en permanence en pénurie de moyens. Le Chef de Projet
ne trouvera parfois tout simplement personne à qui demander les informations recherchées.
14. Liste non exhaustive. La spécification ne décrit que le besoin fonctionnel, mais on peut
avoir des souhaits additionnels.

semble devenir variable et évolutif. Il faut alors savoir faire preuve de souplesse et
de flexibilité 15
.
Que veut-on dire par là ?
On comprend évidemment qu’il ne peut s’agir d’accepter toutes les demandes
que pourrait avoir le client. Un des problèmes classiques est justement qu’il ne sait
pas forcément exprimer correctement ses besoins – quand ils sont bien définis à la
base. Dans ce cas, on ne pourra se permettre de modifier indéfiniment ses données
d’entrée, sans certitude que le résultat final ne soit satisfaisant. Cela pourrait
sembler pertinent parce qu’on cherche la satisfaction du client, mais on se heurte
très rapidement aux réalités liées à l’environnement du Projet; en premier lieu au
besoin de limiter les coûts.
Comment alors gérer ces situations ?
En un mot : le compromis.
Compromis parce qu’il va falloir construire un mélange efficace de méthodes
contractuelles, c’est-à-dire « légales », et de méthodes douces à travers le dialogue
et la gestion de la relation client.
Le contrat est essentiel en ce sens qu’il fixe des limites, un cadre, à l’intérieur
duquel le travail devra être effectué. Il est indispensable. Mais il sera toujours
incomplet puisque toutes les situations ne peuvent être prévues et anticipées, et y
recourir est souvent coûteux :
— En temps évidemment, parce qu’il présage souvent d’un conflit incluant de
multiples recours possibles.
— Financièrement en nécessitant l’immobilisation de moyens pour contrôler
l’application du contrat et gérer les conflits le cas échéant.
— Enfin en confiance, parce que dans beaucoup de situations courantes, il
détruit instantanément la relation et la coopération qui avaient pu être
bâties entre deux parties.
Le contrat est donc un outil essentiel, mais il doit être utilisé intelligemment.
On doit réussir à penser au-delà de la situation à court-terme pour évaluer les
bénéfices mutuels qu’apporterait une solution concertée.
C’est ici qu’intervient le dialogue avec le client.
Dans toute relation contractuelle, les parties impliquées cherchent à obtenir
un bénéfice. Dans la majorité des cas, ils ne sont pas exclusifs, c’est à dire que
chacun ne pourra prétendre obtenir totalement son gain potentiel parce que cela se
ferait au détriment de l’autre. On aura donc intérêt à rechercher le point d’équilibre
où la satisfaction sera maximale pour tous 16
.
15. D’agilité en fait. . .
16. La situation Win-Win.

Pour parvenir à cet objectif, il est nécessaire de connaître à minima les at-
tentes de l’autre et donc de communiquer. On ne parle pas de dévoiler toutes les
informations, mais il ne faut pas faire de la rétention d’éléments qui peuvent être
utiles au Projet. Il s’agit d’une entreprise de collaboration entre les intervenants,
et la collaboration demande de partager l’information.
Une situation de déséquilibre trop flagrant entre les intervenants d’un Projet
finira par nuire à l’ensemble des participants. On pourrait se dire instinctivement
qu’on peut chercher à tirer (égoïstement) un profit maximal d’une situation, au
final en exploitant les autres, mais cela se ressentirait sur les résultats.
Même si on a une relation Client-Fournisseur, avec un donneur d’ordre contrac-
tuellement identifié, on comprendra facilement qu’il sera difficile, voire impossible,
d’obtenir un investissement correct si on abuse d’une position « de pouvoir ».
L’objectif du Client est d’obtenir le produit de son Projet correspondant à son
besoin. L’objectif du fournisseur est de livrer une solution conforme aux exigences
tout en obtenant un bénéfice 17
. Ces deux buts peuvent apparaître antagonistes
parce que le Client voudra le meilleur produit, au meilleur prix dans les meilleurs
délais quant le fournisseur devra rechercher un prix maximum (mais acceptable)
tout en gérant le triptyque QCD 18
.
On est donc en face d’une contradiction apparente qui pourrait mener au
désastre si chacun s’arc-boute sur ses positions.
Le travail en mode projet requiert donc de la collaboration. Il faut que
toutes les parties prenantes prennent conscience que le succès de l’entreprise dé-
pend de l’implication de tous. Si certains se sentent exploités, ils ne participeront
pas à la hauteur de ce qui est nécessaire et tous en paieront les conséquences. Le
Projet ne tolère pas l’égoïsme.
Il faut donc garder à l’esprit que le Projet est une entreprise conjointe, et
que tout le monde a intérêt à ce qu’il se déroule dans les meilleures conditions.
Cette collaboration doit permettre de structurer rapidement la solution en
définissant les principes à appliquer, et en éliminant au plus tôt les options qui
conduiraient à une impasse.
Être vigilant par rapport aux solutions habituelles
Pour terminer cette partie sur les phases initiales du développement de la
solution, il est important de faire quelques remarques relatives à l’innovation et à
la créativité.
17. Au sens très large : financier dans le domaine professionnel, satisfaction ou formation dans
le domaine personnel ou associatif, etc. . .
18. Voir à ce sujet le §1.1

On a suggéré au chapitre 6.2.2 qu’il peut être intéressant de chercher à privi-
légier – dans le respect du Cahier des Charges – des solutions connues et éprouvées
afin de limiter les risques et de maximiser les bénéfices.
Le conseil reste, mais il faut le compléter en soulignant la nécessité de rester
objectif, en particulier dans les situations où on cherche à aller vite et à gagner du
temps. Une solution existante pourrait sembler pertinente en premier lieu si on ne
prend pas le temps de l’analyser suffisamment. Il ne faut pas se laisser griser par
l’impression s’être proche du but.
Plus généralement, la recherche de solutions innovantes demande d’être ca-
pable de se détacher de ses habitudes pour pouvoir créer de la nouveauté. Il ne faut
pas se limiter à répéter ce qu’on fait tout le temps. L’innovation vient rarement
de la répétition 19
.
Mais il faut être détaché de façon intelligente et consciente, en ce sens qu’il
faut quand même garder à l’esprit son expérience et sa connaissance qui sont
nécessaires pour évaluer et juger. Il faut s’adapter. L’innovation, même si elle peut
arriver de façon inattendue, demande en général du travail. Il est difficile de créer
sans avoir un socle solide de connaissance pour éviter les erreurs.
Le début de la conception est donc un moment crucial pour le chef de Projet,
qui devra être capable à la fois de stimuler son équipe pour favoriser la créativité,
mais aussi de garder à l’esprit les contraintes de son rôle. Le respect du cadre est
primodial pour espérer livrer une solution satisfaisante au client.
8.1.3 Finaliser la conception
Au fur et à mesure que le Projet avance, l’équipe va maîtriser de mieux en
mieux les exigences du client et les solutions techniques qu’elle développe pour y
répondre. La connaissance augmente, et avec elle les possibilités et les opportuni-
tés 20
. Pourtant, le Projet doit se terminer dans un temps défini afin de respecter
les délais. Le chef de Projet doit donc veiller à ce que l’équipe ne se disperse pas
dans des études trop longues, et finisse par converger vers un résultat optimum.
La phase de développement peut être un moment enthousiasmant, parce que
son objectif est de créer. L’invention, l’innovation sont gratifiantes et motivent
l’équipe projet. Mais il ne faut pas perdre de vue que le Projet doit déboucher sur
un résultat concret. Il faudra passer des idées au produit.
On a expliqué au chapitre 5.1 qu’un Projet comporte plusieurs phases. Ces
phases ne sont pas forcément successives et/ou exclusives, elles s’enchaînent mais
19. Ou alors c’est le hasard, mais c’est une méthode un peu trop aléatoire par définition.
20. On pourra revoir le chapitre 2.2.

peuvent se superposer par moment. Elles ne sont en aucun cas cloisonnées. Cela
veut dire qu’à tout moment au cours du Projet il faut garder à l’esprit ce qui
viendra après, et les besoins qui vont avec.
Le chef de Projet doit donc faire en sorte de fournir ce qui est nécessaire à la
production, en s’assurant de répondre de la façon la plus efficace possible à tous
les besoins.
L’objectif est de produire
Le chef de Projet est responsable et garant de la livraison du résultat at-
tendu par son client. On a expliqué qu’il doit créer un environnement propice à
l’innovation en ouvrant le champ des possibilités. Mais s’il doit susciter chez les
membres de son équipe une forte curiosité et la recherche de solutions variées, il
doit, personnellement, rester concentrer sur l’objectif de son entreprise.
Le but ultime de tout projet est de livrer un résultat. Il faut donc passer de
la phase théorique qu’est la conception à la mise en œuvre pratique des idées et
concepts développés. IL faut donc produire qu’il s’agisse d’un produit physique ou
d’un travail intellectuel.
Vérifier quels sont les besoins de la production
Le passage de la phase de développement à celle de production correspond
à la livraison d’un produit par un fournisseur (l’équipe de développement) à un
client (l’équipe de production). Sans développer trop le propos – cela déborderait
très largement du cadre de ce petit livre – il est intéressant de travailler dans un
esprit Lean 21
.
Très concrètement et très (très) succinctement, il s’agit, pour toute tâche,
de connaître ce qui a de la valeur pour son client et de travailler en flux tiré,
c’est-à-dire qu’on doit fournir au client tout et uniquement ce dont il a besoin.
Cet état d’esprit est particulièrement adapté à la gestion de projet parce
qu’il conduit à optimiser naturellement les efforts de son équipe pour parvenir au
meilleur résultat de la façon la plus efficace possible.
Le chef de Projet devra donc chercher à connaître au plus vite les exigences
liées à la production :
— Durant la phase de spécification 22
, l’analyse des besoins du client devra
conduite à des exigences fonctionnelles pour le produit, et concommitam-
ment, à une réflexion sur les moyens qui seront nécessaires à la production.
Bien sûr, il ne sera probablement pas possible de définir exactement à ce
21. On pourra quand même se référer au livre fondateur [16] et à la page Wikipedia
22. Voir à ce sujet le chapitre 6.

stade les données nécessaires à la fabrication, ou encore les moyens à mettre
en œuvre.
Mais cette première approche participera à la sensibilisation de l’équipe
Projet, tant au niveau des fournisseurs (l’équipe de développement) qui
devront chercher à transmettre des résultats exploitables directement, que
du côté de l’équipe de production qui devra travailler à partir de la définition
du produit dès que possible pour concevoir le processus de fabrication.
— Durant la phase de développement, le chef de Projet a bien sûr un rôle cen-
tral en raison de sa fonction de coordinateur. Il lui appartiendra de mettre
en place des canaux de communication efficaces pour que l’information soit
partagée de la façon la plus transparente possible.
C’est un processus bidirectionnel et itératif:
— L’équipe de développement fournit des informations sur la conception
pour répondre aux exigences du client.
Cela permet à l’équipe de production de concevoir le moyen de réaliser
le produit.
— Cette analyse en vue de la fabrication peut mettre au jour des contraintes
(QCD, voir le chapitre 1.1) qui pourraient avoir un impact fort sur le
projet global. Cette information devra évidemment être remontée aux
concepteurs.
En conclusion, la prise en compte des besoins des clients internes a à la fois
une finalité d’efficacité, comme dans une démarche Lean, mais aussi de contrôle,
en évitant de s’orienter vers des options qui s’avéreraient coûteuses par la suite
(re-Lean). Elle permet de converger globalement vers une solution :
Développement
Production
Solution
Figure 8.1 – Relations entre le développement et la production.

Faciliter le travail des autres
Les différentes phases d’un Projet doivent être vues comme autant de sous-
projets qui ont chacun des exigences définies et des livrables à fournir.
On devra donc à chaque étape faire en sorte de fournir des résultats exploi-
tables :
— Avec les caractéristiques (au sens des fonctions) requises.
— Documentés de façon correcte, pour qu’ils puissent être utilisés à leur plein
potentiel.
Le déroulement global doit se faire de la manière la plus fluide possible pour
éviter tout gaspillage inutile. Beaucoup de Projets se caractérisent par un manque
apparent de ressources puisque le but est d’obtenir des résultats maximum avec
le minimum d’effort. Or tout « problème » demandera du travail – non prévu
à l’origine – pour être résolu. On comprend donc qu’il est important de limiter
autant que possible les contretemps, et donc de s’assurer à tout moment que les
intervenants qui dépendent de son travail soient dans les conditions les meilleures.
Le but sera donc que chacun dispose au moment propice des données dont il
a besoin. On retrouve ici la notion de client interne, déjà évoquée brièvement. Il
doit comme tout client être satisfait.
8.2 La production
La production est la raison d’être de tout Projet. C’est le moment où on va
rendre concrets les résultats de la phase de développemnt.
C’est une étape qui doit être préparée correctement parce qu’elle demande
souvent un investissement important en capital. Qu’il s’agisse de moyens de fa-
brication, ou de main d’œuvre, il faut pouvoir disposer des ressources nécessaires.
Cela peut représenter un enjeu important parce que l’entreprise, ou la structure en
général, peut ne pas pouvoir se permettre d’avoir cette capacité en permanence :
— Le Projet peut être ponctuel, auquel cas il n’est pas forcément intéressant
d’investir dans des ressources permanentes.
— Le Projet avoir une taille trop importante pour qu’il soit possible de pro-
duire en interne. Comme pour le cas précédent, on se retrouverait à la fin
avec des ressources qui pourraient être difficilement utilisables par la suite.
— Enfin on peut aussi décider de ne pas consacrer de ressources internes à la
production, parce qu’elles ne sont pas disponibles au bon moment, parce
qu’elles sont trop chères, ou tout simplement par choix , parce que la pro-
duction n’est pas considérée comme une activité qui fait partie du cœur
de métier. Dans ce dernier cas, on cherche à concentrer ses efforts sur les

8.2. LA PRODUCTION 101
phases qu’on considère comme stratégiques, parce que ce sont celles où on
peut apporter le plus de valeur ajoutée.
Ce constat montre qu’il faut mener une réflexion préalablement au lancement
en production.
En pratique, cette analyse débute normalement avant même que le projet ne
commence ! En effet, dès la phase de réponse au cahier des charges du client, dans
le cadre d’un appel d’offre par exemple, ou durant l’établissement des spécificatons,
dans le cadre d’un projet interne, on peut choisir ou devoir choisir d’externaliser
tout ou partie de la réalisation. Dans ce cas évidemment, une enveloppe budgétaire
et une organisation auront été mises en place, réglant ainsi la question.
Si ce n’est pas encore fixé, il va par contre falloir l’organiser rapidement.
8.2.1 Décider si on fabrique en interne
On a donc compris qu’il faut réfléchir suffisamment tôt à l’organisation qu’on
va mettre en place pour produire, et la décision principale à prendre sera de le faire
en interne ou en externe.
Les critères sont multiples, et le processus de réflexion doit être construit
pour être fiable.
En premier lieu, il peut être impossible d’assurer soi-même la production
pour des raisons techniques. L’exemple évident est le cas où on doit utiliser une
technologie qu’on ne maîtrise pas. Il arrive fréquemment que le Projet fasse appel
à de multiples disciplines, qui sont rarement toutes maîtrisées par l’équipe. Le
recours à une ressource externe s’impose alors de lui-même.
Ensuite, si on est théoriquement capable d’assurer la production, on pourra
se poser la question de la pertinence. C’est à ce moment qu’on doit se pencher sur
les critères de décision pour définir ce qui sera fait.
On reviendra alors aux notions de Coût et de Délai 23
:
— Le budget alloué pour le Projet offre une enveloppe définie pour la produc-
tion.
On doit donc évaluer les différentes options suivant l’angle financier en
prenant en compte les taux internes de sa structure, c’est-à-dire le coût
de production, qu nécessite des ressources humaines (donc probablement
des salaires), de ressources matérielles (machines, matières premières. . .)
et du temps. Ces éléments devront être mis en face des coûts d’achat que
représenterait le recours à un prestataire extérieur.
Il faudra alors estimer si une différence (positive) éventuelle peut :

1. Être compatible avec le budget du projet.
2. Se justifier au regard d’une qualité supérieure.
Dans ce cas on pourra éventuellement décider de sélectionner l’alternative
la plus onéreuse.
— Le planning peut lui aussi imposer des contraintes.
Si les ressources internes ont un taux de charge trop important pour pouvoir
assurer la production dans les délais impartis, on devra chercher une solution
extérieure.
En résumé, les décisions liées à l’externalisation ou non de la production
devront se faire en cherchant le meilleur compromis permettant d’atteindre les
objectifs du Projet.
8.2.2 Choisir des partenaires / sous-traitants
Dans le cas où la décision de produire en extérieur a été prise, il faut s’atteler
à la sélection de partenaires fiables.
Par fiable, on entend qui seront à même de respecter toutes les contraintes du
Projet. Il ne s’agit pas d’un choix anodin parce qu’en se reposant sur une ressource
étrangère à l’organisation, on délègue aussi une partie des responsabilités. On doit
donc avoir une confiance maximale dans le partenaire choisi.
Définir une relation de confiance
Comme on l’a déjà évoqué au chapitre 8.1.2, les relations entre parties pre-
nantes d’un Projet se définissent à plusieurs niveaux.
Un fournisseur (ou un sous-traitant plus généralement) n’échappe pas à la
règle étant donné l’influence qu’il peut avoir sur l’atteinte des objectifs.
Comme avec le client, on n’aura généralement aucun problème dans le cas
d’un déroulement normal des opérations. Il existe un contrat, qui précise les mo-
dalités et les résultats à atteindre et doit théoriquement suffire à encadrer les
travaux.
La situation sera probablement différente si des difficultés surviennent. Cha-
cun cherchera alors naturellement à minimiser les risques et les impacts pour lui,
ce qui peut conduire à une dégradation globale.
Comme avec le client, il faudra donc chercher à impliquer toutes les parties
et à leur faire prendre conscience que les performances de tous sont liées. Les four-
nisseurs doivent se sentir concernés par la réussite du Projet global. Une relation
coercitive ne permettra pas une collaboration optimale.

Mettre en place un benchmarking même simplifié
La sélection de fournisseurs performants pour le Projet revêt donc une grande
importance et nécessite de s’appuyer sur une méthode fiable.
Il s’agit à la base d’un problème de relations humaines, qui se base beaucoup
sur le ressenti qu’on peut avoir à propos de l’autre. Il sera donc difficile de mettre
en place un processus infaillible 24
.
Mais on aura tout de même intérêt à chercher à fiabiliser la démarche.
Cette méthode pourra se baser sur un ensemble de critères qui permettront
à minima d’avoir un socle de référence pour évaluer les partenaires potentiels.
Ray Carter a par exemple défini dans un article en 1995 7 critères (plus tard
enrichis à 10) qui définissent un référentiel permettant de minimiser les risques[4] :
Communication
Compétences
Capacités
Commitment
(Engagement)
Contrôle qualité
Cash
(Finance)Coût des produits
Constance
Culture
"Clean"
Figure 8.2 – Évaluation d’un fournisseur selon les 10Cs de Carter
1. Compétence
Il faut en premier lieu s’assurer que le fournisseur possède bien les compé-
tences nécessaires pour effectuer la prestation qu’on va lui confier. Il faut
donc mettre en place une méthodologie rigoureuse d’évaluation pour s’as-
surer de la validité de ses engagements.
2. Capacité
La réalisation du Projet demande ensuite d’être capable de produire le
volume demandé. Il peut s’agir d’approvisionnements répétitifs d’éléments
identiques, ou de la fourniture ponctuelle de gros ensembles. Dans les deux
cas, il faut s’assurer que le fournisseur a la capacité requise en terme d’or-
ganisation et de moyens (capital, machines).
24. Voire impossible : une personne isolée pourra toujours mettre à mal une sélection rigoureuse
si elle ne coopère pas, quelques soient ses raisons.

Enfin cette capacité à livrer le bon volume s’entend aussi dans le temps : le
fournisseur doit pouvoir garantir de suivre le rythme sur la longueur mais
aussi en cas de variation. Il doit être flexible pour ne pas imposer son rythme
au Projet :
— Trop rapide, il aura un impact sur l’organisation parce qu’il faudra sto-
cker et gérer le surplus de livrables en attendant qu’il soit utilisé.
— Trop lent. . .Il faudra bien évidemment l’attendre, ce qui pourra être à
l’origine de retards.
3. Commitment (Engagement)
Le fournisseur doit être capable de s’engager pour le succès du Projet.
Cet engagement sera probablement contractuel, mais il s’agit comme on l’a
déjà vu d’un minimum. Il est plus important pour le succès de l’entreprise
que le fournisseur soit intrinsèquement motivé pour réussir – qu’il se sente
pleinement partie du processus.
Un fois encore, cela ne peut se faire que par une relation de confiance et
intègre.
4. Contrôle qualité
Quand elle se voit confier le Projet, l’équipe s’engage envers le client sur un
niveau de qualité à atteindre. Il est indispensable que tous les intervenants,
qu’ils soient internes ou externes respectent ce niveau d’exigence.
Il faut donc s’assurer que le fournisseur met en place des procédures adap-
tées, et qu’il les maîtrise.
5. Cash (Finance)
Le Projet peut constituer un engagement de longue durée et toutes les
parties prenantes devront avoir une pérennité suffisante pour le mener à
bien.
On doit donc vérifier que tous les partenaires sont suffisamment solides et
possèdent les ressources nécessaires pour accompagner l’équipe.
6. Coût des produits
Afin de maîtriser la situation financière de son Projet, le responsable doit
connaître les tarifs de ses fournisseurs, ainsi que ses conditions commerciales.
Attention toutefois d’apprécier ces données en relation avec les études re-
latives à la qualité et à la fiabilité. Un prix bas ne doit pas induire des
problèmes qui seraient à l’origine de surcoûts futurs. . .
7. Constance
Le fournisseur qui s’engage pour accompagner l’équipe Projet doit garantir
qu’il assurera ses obligations de façon constante dans le temps. Il faut donc
s’intéresser aux moyens qui sont mis en œuvre pour y parvenir sur le long
terme.

8. Culture
Afin de bâtir une relation de confiance, il est pertinent de s’intéresser à la
culture d’entreprise des partenaires potentiels. Il sera beaucoup plus simple
de travailler avec des personnes qui partagent les mêmes objectifs et façon de
penser. Il vaudra donc mieux privilégier des fournisseurs qui ont les mêmes
orientations.
9. “Clean” (environnement)
Le Projet doit respecter les exigences du client, mais aussi l’ensemble des
normes qui peuvent lui être applicables.
L’environnement est aujourd’hui un aspect essentiel; on devra donc être
attentif à son respect. De même les normes éthiques et sociales prennent de
plus en plus d’importance et doivent faire partie des critères dd’évaluation.
10. Communication
Une collaboration efficace demande une communication efficace. Il faut
donc s’assurer de prévoir des moyens de communication adaptés, mais aussi
d’identifier les personnes à contacter pour avoir des réponses rapides selon
les sujets.
Il s’agit d’un exemple de référentiel qui peut être utilisé pour évaluer les
fournisseurs potentiels.
On devra donc demander aux candidats pressentis de fournir les informa-
tions nécessaires, en remplissant des questionnaires, mais aussi en fournissant des
références de travaux réalisés précédemment.
C’est un travail qui peut être anticipé en préparant un panel de fournisseurs
potentiels en amont.
8.2.3 Le suivi de fabrication
Une fois la fabrication lancée, le chef de Projet doit continuer à exercer un
contrôle régulier.
Ce n’est pas parce que l’opération est déléguée qu’il perd toute responsabilité.
Il faut se rappeler qu’un problème qui n’apparaît qu’au moment de la production
est souvent beaucoup plus coûteux à résoudre que s’il avait été identifié plus tôt.
On doit donc mettre en place une procédure de suivi rigoureuse.
Définir des jalons
En général, la production est planifiée comme un sous-projet du principal :
elle est séquencée, avec des étapes définies qui doivent s’enchaîner dans un ordre
précis.

Il sera donc pertinent de valider les produits à l’issue des étapes principales
pour s’assurer qu’ils sont dans un état conforme aux besoins du Projet :
— L’avancement doit être compatible avec le respect du calendrier du Projet.
Durant la planification globale, on alloue un capital-temps pour la produc-
tion. Cette dernière est organisée pour respecter le délai imparti, en tenant
compte des contraintes de liaison entre les tâches puisqu’elles utilisent gé-
néralement en entrée les sorties des précédentes.
Par conséquent, un tâche qui dérive dans le temps pourrait causer un dé-
calage du processus complet de fabrication 25
.
— La qualité doit permettre l’utilisation du produit pour la suite.
On parle ici de qualité au sens propre, mais aussi en terme de performance.
Un produit dégradé ou qui n’offrirait les caractéristiques attendues pourrait
ne pas permettre de respecter les exigences globales pour les livrables finaux
du Projet.
Cette validation aux moments importants correspond à la définition de ja-
lons, c’est à dire des dates clés auxquelles on attribue une valeur contractuelle.
De la même façon qu’on définit des revues durant la phase de développement, on
fixera donc des échéances de vérification durant la fabrication.
Tester les sous-ensembles dès que possible
Comment fixer ces échéances ?
Il suffit en général d’être pragmatique. La phase de fabrication permet de
concrétiser le travail de l’équipe Projet. On obtient régulièrement des produits –
ou des sous-produits – fonctionnels et qui peuvent donc être testés.
Il est alors pertinent de fixer des revues de fabrication dès qu’on a à dispo-
sition des éléments fonctionnels :
— On peut avoir un composant (ou un sous-ensemble) qui peut fonctionner
par lui-même. Dans ce cas, il est facile de le tester en lui fournissant les
conditions d’entrée auxquelles il sera soumis une fois intégré dans le système
opérationnel.
— Parfois il ne s’agira pas d’un élément qui soit fonctionnel pris individuelle-
ment. Il peut par contre s’agir d’un nouvel état dont la qualité peut déter-
miner l’issue finale du processus 26
. Dans ce cas, il faudra prévoir de tester
les parties produites par rapport aux exigences d’intégration.
25. Comme pour le Projet global en fait puisqu’on vient de dire qu’on peut la considérer comme
un sous-projet. . .
26. Par exemple en métallurgie, si la fonte ou le forgeage ne sont pas exécutés correctement, une
pièce mécanique pourrait ne pas avoir les caractéristiques mécaniques requises pour l’utilisation
à laquelle elle est destinée.

En résumé, le chef de Projet devra prévoir des vérifications des livrables tout
au long du Projet, et en particulier durant la phase de fabrication.
Revues chez le fabricant avec le Client
Le besoin de vérification va se traduire par des rencontres régulières avec
le fournisseur afin de s’assurer de l’avancement de la fabrication. Ce besoin de
confiance existe dans toute relation client-fournisseur et donc évidemment (à une
translation près) entre le client final et l’équipe Projet 27
.
On comprendra donc qu’il y a tout intérêt à impliquer le client final dans
les revues chez le fournisseur pour développer une relation forte entre toutes les
parties impliquées.
Le chef de Projet devra toutefois être vigilant quant à l’organisation de ces
réunions, parce qu’il ne faudra pas qu’elles se bornent à la vérification uniquement.
Il s’agit d’une occasion de collaboration où tous les intervenants sont réunis, ce
qui permet :
— De vérifier que tout est normal 28
en examinant les éléments produits, l’avan-
cement par rapport au planning, les problèmes rencontrés, etc. . .
— De discuter, partager et réfléchir ensemble sur les points durs et le futur
du Projet. Il s’agit des seuls instants où tous les intervenants sont réunis. Il
faut en tirer parti pour traiter de façon productive des points bloquants.
La communication pourra se faire sans filtre, en direct, et doit permettre
de trouver des compromis acceptables par tous.
Les revues sont donc très importantes; elles donnent parfois lieu à des ave-
nants contractuels quand on parvient à s’accorder sur des positions communes qui
ne concordent pas forcément avec les spécifications initiales.
Il sera opportun d’organiser des revues aux moments important du processus
de fabrication. Par exemple à la fin de la production d’un composant critique, dont
on pourra s’assurer qu’il remplit parfaitement ses fonctions. Ou encore à la fin de
la phase d’intégration afin de s’assurer que le produit répond aux exigences avant
sa livraison au client.
27. Qui est dans le rôle du fournisseur maintenant...
28. Oui quand même. . .

8.3 Les Tests – voir si tout fonctionne comme
prévu
Les tests et les essais devront être menés règulièrement dès qu’on en a la
possibilité pour pouvoir identifier au plus tôt les problèmes potentiels.
On a déjà expliqué que la phase de production peut être considérée comme
un sous-projet, mais elle reste un projet. Elle en a donc les caractéristiques, et
en particulier la structure de coût (voir le paragraphe 2.1) qui fait que les choix
initiaux engagent une part prépondérante des frais. C’est pourquoi on a intérêt à
vérifier dès que possible l’absence de problème.
8.3.1 Savoir ce qu’on doit tester
Il est important de définir correctement les tests à effectuer pour qu’ils soient
pertinents. Il faudra en effet s’assurer de tester tout ce qui doit l’être, et de le faire
correctement en préparant un plan de test.
Il aura en général deux objectifs :
— Vérifier que toutes les exigences de la spécification sont bien couvertes.
— Vérifier que le produit remplit correctement les fonctions demandées.
Ces deux axes correspondent à ce qui est défini en Ingéniérie Système sous
le sigle IVVQ : Intégration, Vérification, Validation, Qualification dont on a briè-
vement parlé au chapitre 6.1.3.
Comme pour le produit lui-même, il faut donc définir un ensemble de spé-
cifications pour les tests. Elles seront dérivées des spécifications produit afin de
s’assurer qu’on couvre tous les cas requis.
La construction du plan de test doit se faire en analysant toutes les exigences
de la spécification pour déterminer les essais à mener afin de confirmer que le
produit y répond. On observera alors en général deux cas possibles :
— Les exigences définissent des fonctions utilisateur.
— Les exigences concernent des fonctions qui ne seront pas visibles par l’uti-
lisateur final du produit.
Dans le premier cas, le plan de test devra définir ce qu’on appelle des cas de
test 29
. Il s’agit de situations représentatives de l’utilisation réelle du produit qui
permettront de vérifier qu’il se comporte comme attendu.
On devra donc mettre le composant (qui peut être le produit complet) dans
des conditions représentatives :
29. Use cases en anglais, terme qu’on rencontre souvent dans la littérature.

8.3. LES TESTS – VOIR SI TOUT FONCTIONNE COMME PRÉVU 109
Environnement
Entrées Sorties
Figure 8.3 – Configuration de test d’un composant
On remarque sur la figure 8.3 qu’il s’agit donc de :
— Reproduire l’environnement qui sera celui d’utilisation du composant pour
le placer dans des conditions réelles d’utilisation. En effet, si elles ne consti-
tuent pas à proprement parler des entrées du système testé, les conditions
peuvent influer sur son fonctionnement. Elles peuvent d’ailleurs être définies
précisément dans le cahier des charges du produit, à travers la conformité
exigée à des normes environnementales par exemple 30
. Dans ce dernier cas,
les conditions de test sont donc imposées.
Dans le cas où les conditions ne sont pas définies explicitement, il sera néces-
saire d’analyser comment le produit sera utilisé pour déterminer comment
le tester. On devra alors s’assurer de discuter avec le client pour valider les
choix qui seront faits pour qu’il soit satisfait.
— Simuler les entrées – qui constituent les stimuli qui déclencheront les com-
portements attendus du système. Ici encore on pourra se trouver face à dif-
férentes situations. Soit on teste le système complet ou son sous-composant
d’entrée; dans ce cas il est évident qu’on appliquera les entrées nominales,
soit on traite un composant interne. On devra alors faire un travail d’analyse
de la séquence pour identifier la entrées auxquelles soumettre le composant.
Ce travail sera basé sur les spécifications, qui peuvent fournir des éléments
théoriques, et sur les résultats de la phase de conception/développement qui
a permis de définir l’architecture de la solution et les interfaces internes.
Le plan de test définira l’ensemble des vérifications à effectuer. On peut
apporter quelques précisions à ce sujet.
En premier lieu, on a parlé de test – et de vérification juste au dessus – qu’on
30. On peut citer la RTCA DO-160G qui fait référence dans le domaine aéronautique, ou encore
les normes militaires comme la MIL-STD-810.

doit interpréter au sens large. Il s’agira concrètement de prouver par tout moyen 31
disponible que le produit répond bien aux exigences. On pourra donc faire appel
à un essai, mais aussi à une démonstration théorique par exemple.
Ensuite il faudra vérifier que l’ensemble des exigences applicables au compo-
sant testé sont bien couvertes par le plan de test.
On peut alors conseiller de présenter le plan de test au client pour l’impliquer
une fois de plus et lui donner un aperçu concret de ce qu’il obtiendra à la fin du
Projet. Á ce propos, on peut en profiter pour négocier avec lui la participation des
utilisateurs à la campagne de tests. Cela permettra d’obtenir des retours fiables
de la part de ceux qui connaissent le besoin en pratique.
Le produit une fois testé sera pratiquement prêt à être livré au client final.
8.4 Livrer son Client
Le produit une fois fabriqué et testé, il faut le livrer au client.
Il ne s’agit pas d’une opération anodine limitée à la mise à disposition. Il
s’agit d’un transfert de responsabilité, ce qui a plusieurs implications parce qu’il
n’y a pas de pire moment pour abimer la relation longuement construite :
— L’équipe Projet doit être absolument certaine de la qualité du produit
qu’elle livre.
Il a été testé donc il doit normalement fonctionner correctement. Mais il
faut le vérifier encore quand on le prépare pour la livraison. Ce point est
important parce qu’il s’agit souvent du dernier moment où existe une rela-
tion directe avec le client. Il faut donc essayer de laisser une bonne image !
— Le client lui ne doit pas avoir de mauvaise surprise.
Il a demandé à l’équipe projet de lui fournir un produit pour répondre à un
besoin qui doit – en général – lui apporter un bénéfice 32
. Donc s’il ne peut
pas l’utiliser, il va ressentir un manque, ce qui n’est pas satisfaisant.
D’autre part, ce qui donne de la valeur au produit est le fait de l’utiliser.
Selon la nature du produit cela peut ne pas être évident parce qu’il peut être
nécessaire de :
— Configurer le produit pour l’intégrer dans un ensemble, ou le mettre dans
son état d’utilisation.
— Expliquer le fonctionnement, voire former le client si le produit peut appa-
raître complexe à utiliser.
L’idée de base est simple : il faut pouvoir utiliser le produit de façon auto-
nome.
31. Légal :D
32. Pas forcément financier selon la nature du projet, mais il espère en tirer quelque chose.

8.5. LA DOCUMENTATION DU PROJET 111
8.5 La documentation du Projet
Un Projet est souvent une entreprise complexe qui passera par de multiples
phases. Il est important de pouvoir conserver une vision d’ensemble, construite,
afin d’avoir en permanence la maîtrise des évènements.
Pour ce faire, il faut que le Projet soit documenté, c’est à dire qu’on doit être
capable d’analyser et de comprendre comment on arrive à un état donné.
Ce besoin va s’appliquer à différents niveaux :
— Les résultats intermédiaires et les livrables doivent être décrits cor-
rectement pour qu’on puisse s’appuyer dessus et construire le Projet de
manière logique.
— Les décisions doivent pouvoir être comprises pour comprendre la logique
qui conduit à une situation donnée.
On doit donc répondre à des objectifs opérationnels et des objectifs de tra-
çabilité 33
, mais l’intention sera dans les deux cas de permettre la compréhension
du Projet.
En pratique, cette documentation se composera :
— Des compte-rendus de réunions, qui permettent de tracer les décisions prises.
— Des documents livrables : rapports d’analyse, rapports de conformité aux
exigences. . ., qui définissent les caractéristiques de ce qui est produit.
— Des documents requis pour le suivi des processus, qui permettent de se
conformer aux exigences des systèmes qualité applicables.
Cette liste n’est pas exhaustive. En général, les organisations ont des systèmes
qualités formalisés qui listent ce qui doit être produit à chaque étape.
Le point essentiel est qu’on doit â tout moment savoir dans quel état se trouve
le Projet, et être capable de reconstituer l’historique qui à permis d’y arriver.
8.6 La clôture du Projet
Une Projet est une entreprise qui est limitée dans le temps, même si certains
livrables feront l’objet d’un suivi tout au long de leur cycle de vie. On doit donc à
la fin clôturer le Projet.
Les procédures peuvent différer selon les entreprises ou les organisations, mais
on retrouve en général :
— Le classement et l’archivage de toutes les données Projet qui permettent
d’en reconstituer le déroulement. On entend par là les documents d’en-
trée (cahier des charges, spécifications, normes. . .), les documents de travail
33. Voir à ce sujet le chapitre 9.3.2.

(dossiers d’analyses, plans de tests, compte-rendus de réunions. . .) et les
livrables (plans finaux, dossiers de justification, rapports de conformité. . .).
— Une réunion de clôture, qui réunit toute l’équipe Projet, et parfois le client,
et dont l’objectif est d’analyser le déroulement du Projet pour en tirer des
enseignements et suivre une démarche d’amélioration continue.
C’est là une des conditions pour maximiser le bénéfice qu’on peut tirer d’un
Projet.

Quatrième partie
Limiter les problèmes
113

Chapitre 9
Le contrôle
Le rôle du chef de Projet est de le gérer. Par là on entend qu’il doit le piloter,
au sens du pilotage d’un processus 1
Une des composantes essentielles du pilotage est le contrôle parce qu’il faut
s’assurer qu’on ne diverge pas et qu’on reste dans le cadre nominal du Projet. Le
contrôle doit se faire suivant différents critères :
— Les coûts.
— Les délais.
— La qualité.
Rien que de très classique en somme puisqu’on retrouve le référentiel de base
du Projet.
Le rôle du chef de Projet va donc être de surveiller ces trois indicateurs pour
vérifier qu’ils ne sortent pas de leur zone nominale. Un dérive nécessitera de mettre
en place des mesures correctrices pour revenir à une situation acceptable.
9.1 Maîtriser les coûts
9.1.1 Les bases
Le Projet dispose d’un budget qui est fixé au départ. On doit donc par
principe faire en sorte de réaliser les tâches demandées en restant dans l’enveloppe
maximale allouée pour ne pas perdre d’argent.
Le budget est censé couvrir l’ensemble des frais qu’il faudra engager pour
atteindre les objectifs fixés, qui peuvent se répartir dans différentes catégories
décrites ci-dessous :
1. On ne s’étendra pas là dessus, mais ceux qui sont intéressés peuvent lire quelques bouquins
sur l’Ingéniérie Système, par exemple [10].
115

116 CHAPITRE 9. LE CONTRÔLE
— Les ressources humaines
Il s’agit souvent d’un poste de dépense très important.
— La logistique et les équipements
On comptabilise dans cette catégorie l’ensemble des frais qui correspondent
à de la location ou de l’amortissement. On pense par exemple à la loca-
tion de salles, ou l’achat de machines ou ordinateurs qui seront amortis en
comptabilité.
— Les dépenses de trésorerie 2
Cela correspond aux frais qu’il faudra engager en puisant dans les liquidités
du Projet.
Durant le déroulement du Projet, il faudra donc tenir un relevé des dépenses
pour s’assurer qu’elles restent en phase avec les prévisions 3
.
Le pilotage des dépenses demandera souvent de prendre des décisions qui
peuvent influencer le déroulement du Projet parce qu’elles peuvent avoir un impact
financier (évidemment), mais aussi un impact sur le planning et/ou la qualité des
livrables.
Cela amène une remarque.
La gestion financière est par nature une activité qui demande de la discipline
et de la rigueur, mais il ne faut pas non plus faire preuve d’une rigidité exces-
sive. Certaines décisions qui ne concernent pas un volume important et n’ont pas
de conséquences énormes gagneront à être prises rapidement. Si engager des frais
limités permet d’avancer rapidement et d’obtenir des résultats exploitables et né-
cessaires, on aura intérêt à les engager vite. Il ne faut pas oublier que mobiliser
des ressources pour une réunion coûte cher financièrement et en délai parce que
cela pourra retarder d’autant la suite des opérations. Il vaut donc parfois mieux
prendre une décision rapide, qui permet de vérifier une hypothèse par exemple, que
tergiverser trop longtemps sans pouvoir avancer. Le chef de Projet a ici un rôle de
leader; il doit garder à l’esprit l’objectif global de son Projet. On ne passe pas 2
jours à discuter à 3 personnes d’un achat de 500e qui pourrait faire avancer...
9.1.2 Instruments de pilotage
On vient donc de voir très rapidement la théorie du suivi des coûts d’un
Projet, mais comment s’y prend-on en pratique ?
2. Les achats... C’est à dire les fournitures nécessaires à la fabrication par exemple. Ou un
achat de sous traitance.
3. D’ailleurs on ne s’étend pas ici sur les méthodes d’élaboration de ces prévisions durant les
phases d’avant-projet. Le chiffrage permet d’estimer les coûts pour pouvoir faire une proposition
commerciale au client. Mais il faut garder de la matière pour une seconde édition !

9.1. MAÎTRISER LES COÛTS 117
Comme pour tout processus de pilotage, on va avoir deux interactions prin-
cipales avec le processus :
1. Une action de contrôle qui consistera à vérifier que le déroulement se passe
selon le plan prévu.
2. Une action de pilotage à proprement parler, qui permet d’agir sur le dé-
roulement en fonction des informations à sa disposition.
Pour pouvoir contrôler, on a besoin d’une référence. On connait le budget
global disponible pour le Projet, mas cette information est insuffisante. En effet,
si on dépense durant la phase de développement la totalité du budget alloué au
Projet, on ne sera bien évidemment plus en capacité de produire ensuite.
On comprend par là que la gestion du budget doit inclure une dimension
temporelle pour pouvoir s’assurer en permanence qu’on ne dépense pas son budget
trop vite 4
.
Cet échéancier de paiement est établi en début de Projet à partir du planning
en se basant sur le travail qui a été réalisé durant le chiffrage. On devra évaluer,
pour chaque phase, les dépenses qui devront être engagées pour accomplir le travail
requis.
Pour pouvoir piloter, le chef de Projet dispose de quelques leviers d’action
qui pourront être utilisés principalement dans deux situations :
— En préventif, quand on se rend compte d’un risque de dérive à venir des
coûts, il faudra mettre en place des mesures pour revenir à des conditions
de stabilité.
— En correctif, quand les écarts sont avérés, on devra analyser rapidement les
raisons et les impacts pour déterminer si on peut les accepter parce qu’ils
correspondent à un avancement réel, ou si on doit faire des économies pour
revenir à une situation budgétaire normale.
Dans le second cas, il faudra examiner la situation en détail parce qu’une
situation de trésorerie négative peut potentiellement mettre le Projet en danger.
Si le déficit s’explique parce que des dépenses ont étées engagées plus tôt que
prévu, on doit s’assurer que les livrables sont en accord. Il s’agit d’un moindre mal,
mais on doit réagir rapidement.
Une fois le constat établi, il existe deux alternatives : soit on augmente les
recettes, soit on diminue les dépenses.
4. Ou trop lentement, parce que contrairement à ce qu’on pourrait penser, cela peut être un
problème. Si on n’engage pas suffisamment tôt certaines dépenses, le Projet peut courir un risque
de retard.

Obtenir plus de fonds demande de pouvoir négocier avec le client en justifiant
la situation pour qu’il accepte d’augmenter sa contribution. Il s’agit d’un cas com-
pliqué parce qu’il faudra pouvoir montrer au final que la responsabilité incombe
au client – ce qui est en général difficile.
On devra donc souvent chercher à réduire les dépenses, ce qui peut être fait
de différentes façons :
— Revoir le périmètre du Projet.
On pourra discuter avec le client pour qu’il accepte de diminuer ses exi-
gences pour alléger la charge et les dépenses qui y sont liées.
— Différer certaines dépenses
En fonction de l’avancement, il pourra être possible de reporter certaines
tâches ou certains achats pour permettre de dégager des liquidités.
— Réduire les ressources engagées
On pourra décider de réduire le nombre de personnes ou les moyens affectés
à une tâche si on estime pouvoir la réaliser correctement. Il faudra toutefois
faire attention à ne pas se mettre en danger parce que les moyens seront
mis en tension.
— Négocier avec les fournisseurs
Selon la situation, il sera pertinent de se tourner vers les fournisseurs pour
obtenir une baisse de leurs coûts. Ceci évidemment dans le cas où un four-
nisseur serait responsable d’un retard ou d’un problème de qualité, mais
aussi parfois dans le cadre d’une relation de collaboration. On peut en effet
être dans une optique stratégique avec des partenaires qui participent au
projet tout en ayant des ambitions à plus long terme.
On vient de voir qu’il est primordial de pouvoir évaluer de manière fiable
l’état financier du Projet. Il faut dire quelques mots à ce propos parce que ce n’est
pas forcément un problème trivial.
Il faut en fait s’intéresser un minimum à certains aspects financiers.
Le problème (potentiel) vient de la durée de certains projets, ou du fait que
les investissements réalisés ne porteront leurs fruits que longtemps après avoir été
engagés. La question centrale est alors de savoir ce que vaudront ces investissements
après plusieurs années parce que les conditions économiques globales sont alors
importantes.
Un exemple, si on doit investir pour une machine, il peut être plus intéressant
d’emprunter la somme si les taux sont inférieurs à l’inflation que d’utiliser les
liquidités dont on dispose.
Comment alors gérer ces choix ?
L’outil essentiel est alors l’actualisation financière. Il s’agit de prendre en
compte la valeur temps de l’argent, c’est à dire de tenir compte des taux d’actua-

9.1. MAÎTRISER LES COÛTS 119
lisation qui rentrent alors en jeu pour pouvoir comparer la valeur de l’argent à
différentes dates.
La méthode consiste à additionner les flux de trésorerie sur la période consi-
dérée, en les pondérant par le taux d’actualisation.
On dit alors qu’on calcule la Valeur Actuelle Nette 5
:
V AN =
T
t=0
Ft(1 + k)−t
où 6
:
— t désigne la période en cours, t = 0 étant le moment de la prise de décision.
— T désigne la dernière période, dite horizon.
— Ft est le flux net de trésorerie pour la période t : recettes moins dépenses.
— k est le taux d’actualisation choisi.
Le taux d’actualisation k est composé d’un taux d’intérêt (que l’on emprunte
ou que l’on prête de l’argent) et d’une part qui correspond au risque éventuel.
Cette formule permet donc de calculer la valeur à une date donnée (en général
au moment où on décide d’un investissement) de flux financiers futurs :
t=0 t=1 t=2 t=3
Flux financiers ramenés à t=0
Figure 9.1 – Principe des flux financiers actualisés
La figure 9.1 illustre le principe du calcul de la valeur actuelle nette. A savoir
qu’on ramène l’ensemble des flux financiers (positifs pour une rentrée, négatifs
pour une dépense) de la période donnée à une date de référence. Concrètement,
5. Une équation crédibilise mon propos.
6. Repris de la page Wikipedia sur la Valeur Actuelle Nette puisque tout y est très bien
expliqué.

cet ajustement fait que toutes les sommes considérées sont exprimées avec une
devise qui a la même valeur financière; il permet de retrouver l’homogénéité dans
le calcul.
Il est alors possible de faire l’analyse d’investissements dans le temps pour
disposer d’éléments de décision :
— Si la Valeur Actuelle Nette est négative, l’investissement ne sera pas ren-
table. La somme des dépenses dans le temps est supérieure aux rentrées
attendues.
— Si la Valeur Actuelle Nette est nulle, l’investissement sera à l’équilibre.
— Si la Valeur Actuelle Nette est positive, l’investissement sera financièrement
intéressant puisqu’il rapportera plus dans le temps que les frais engagés.
Cette formule permet d’établir une règle de principe pour la gestion des
finances d’un Projet :
— Si les taux d’intérêts sont faibles, il sera souvent pertinent d’emprunter pour
financer ses investissements parce que les rentrées d’argent futures perdront
moins de valeur.
— A l’inverse, avec des taux d’intérêts forts, on devra chercher des investis-
sements qui soient rentables rapidement (les rentrées financières doivent se
faire le plus tôt possible) parce que les flux financiers perdront d’autant
plus de valeur qu’ils arriveront tardivement.
Le chef de Projet doit donc être attentif à la gestion de sa trésorerie pour
éviter de se trouver en difficulté pour financer ses travaux. les problèmes pourraient
mettre le Projet en danger et nuire à la relation avec le Client.
9.2 Gérer les délais
Quand un client notifie l’attribution d’un Projet à une équipe, il commande
en pratique un triptyque QCD 7
(oui, pour changer. . .) : l’équipe Projet s’engage
à livrer un produit qui répond aux exigences, pour un coût défini et dans un délai
donné.
On vient de parler de l’aspect financier, il nous reste donc les deux autres
points à aborder.
La gestion des délais est analogue à la gestion du budget financier. D’ailleurs
on peut considérer qu’on gère un budget temps avec des recettes – c’est-à-dire le
délai initial alloué par le client, augmenté d’‘éventuels reports et prolongations –
et des dépenses qui sont constituées du temps affecté à la réalisation de chaque
tâche.

9.2. GÉRER LES DÉLAIS 121
Concernant les coûts, on s’appuie sur un échéancier construit en début de
Projet puis mis à jour régulièrement ; pour les délais, on s’appuiera sur le planning.
9.2.1 Utiliser le planning pour assurer le suivi
Le principe du suivi des délais consiste simplement à surveiller l’avancement
des tâches pour s’assurer qu’il est conforme au nominal requis pour livrer le produit
dans le temps imparti.
Le suivi se fait de manière analogue à celui du budget : on doit chercher à
définir des points de référence et à vérifier que les progrès sont conformes aux états
attendus à ces instants.
Jalonnement formel et informel
On a déjà parlé au chapitre 8.2.3 de la nécessité de définir des jalons – alors
dans le cas du suivi de la fabrication – mais le principe s’applique tout au long
du Projet. Quand on établit le plan Projet, le planning, on définit des revues qui
rythment toutes les phases 8
et les livrables associés.
Le chef de Projet aura donc pour responsabilité de contrôler que le travail
avance comme attendu.
Cependant, en plus de ces jalons officiels, on pourra avoir intérêt à définir
avec les parties prenantes des étapes intermédiaires pour éviter ce qu’on appelle
l’effet tunnel.
Quand on alloue une tâche et le délai associé à quelqu’un, on pourrait se
contenter d’attendre la livraison du résultat, sans visibilité sur le déroulement
(le « tunnel »). Pour des opérations simples et courtes, cela peut ne pas poser
de problèmes. Par contre, quand on confie par exemple la réalisation d’un sous-
ensemble complet, ou d’un composant critique, il peut être dangereux de perdre
la visibilité et le contrôle qui va avec. On préférera donc définir des étapes, qui
même si elles ne sont pas contractuelles comme peuvent l’être les revues formelles,
permettront de s’assurer que tout est conforme aux attentes.
Mesurer l’avancement
Le fait d’avoir séquencé le Projet par la mise en place de jalons permet
de définir des unités gérables pour le suivi. Pourtant, il ne suffira pas de valider
8. On ne va pas rentrer ici dans le détail, beaucoup d’ouvrages traitent du sujet. On peut
simplement citer par exemple les Preliminary Design Review (PDR) qui permet de valider la
conception préliminaire, et la Critical Design Review (CDR) qui clôt la phase de conception
détaillée avant le lancement en production.

ponctuellement le franchissement de ces étapes, là encore pour éviter les problèmes
de l’effet tunnel. Il est primordial pour le chef de Projet de conserver une visibilité
permanente sur l’avancement et donc d’avoir des indicateurs.
La nature des indicateurs est importante; ils doivent constituer en soi des
objectifs 9
qui pourront être évalués de façon fiable.
Le problème est qu’il n’est pas toujours évident de définir ces objectifs quand
on s’intéresse à l’avancement de tâches continues, qui ne consistent qu’en un travail
d’étude par exemple pour innover ou développer un produit. Dans ce cas, il n’y a
pas de granularité évidente qui permettrait un vérification étape par étape.
Une des possibilités pourra être de travailler à partir des fonctions que doit
avoir le produit final.
Durant les étapes, l’équipe cherche des solutions qui permettent la réalisation
des fonctions. Il faudra donc, durant la préparation de chaque phase, réfléchir au
processus de réalisation de chaque fonction, c’est-à-dire identifier la suite d’actions
nécessaire.
On pourra alors établir un micro-planning qu’on pourra suivre plus facile-
ment pour vérifier que l’avancement est conforme aux besoins du Projet.
Il est important pour cela de s’appuyer sur les experts qui ont la capacité
d’évaluer les besoins en terme de travail pour aboutir à un résultat cible. On pourra
ainsi mesurer avec eux les progrès afin de communiquer avec les parties concernées.
Effectuer un reporting
On a déjà souligné le fait que la communication est un élément essentiel pour
la réussite d’un Projet. Bien sûr à l’intérieur de l’équipe, mais aussi vers le client
– qui doit être au courant de ce qui se passe et pourrait avoir des implications
pour lui – et les responsables 10
– qui doivent s’assurer que le Projet se déroule
correctement sans générer de risques pour l’organisation globale dont fait partie
l’équipe.
Le reporting se fait généralement selon des modalités qui sont définies en dé-
but de Projet lors de la réunion de lancement avec le client, et selon des procédures
prédéfinies dans l’organisation. Il est important de ne pas le percevoir uniquement
comme un moyen de contrôle qui ne servirait qu’à surveiller, mais plutôt comme
un outil de gestion qui permet en particulier d’informer au plus tôt des problèmes
identifiés. La détection précoce est le meilleur moyen de limiter les conséquences
parce qu’elle permet de mettre en place au plus vite des mesures de correction. Un
problème pris en compte rapidement est plus facilement résolu et ses conséquences
circonscrites.
9. Voir à ce sujet le §7.2.2
10. La hiérarchie.

9.3. CONTRÔLER LA QUALITÉ 123
Il faut par contre que le reporting soit honnête, en incluant à la fois les bonnes
et les mauvaises nouvelles. Il est extrêmement dangereux de masquer, voire pire
d’enjoliver, les mauvaises nouvelles. Les destinataires du reporting pourraient se
faire une idée erronée de l’état d’avancement et de la situation du Projet et donc
ne pas réagir comme il serait nécessaire.
Il faut garder à l’esprit l’importance de la confiance. Il est préférable d’annon-
cer au plus tôt les mauvaises nouvelles pour réagir dès que possible. Un reporting
complaisant ne fera que masquer les difficultés et repousser les améliorations né-
cessaires. Il ne faut pas compter sur la chance ou le hasard pour que la situation
s’améliore d’elle-même 11
, mais fournir tous les éléments nécessaires à une prise de
décision efficace.
9.3 Contrôler la qualité
On vient de s’intéresser au contrôle suivant deux des trois axes de gestion
d’un Projet, il faut donc maintenant parler de la qualité.
On ne va pas ici traiter le sujet suivant les aspects normatifs 12
mais sur le
plan très pratique.
Il faut en premier lieu rappeler que la finalité du Projet est d’abord de sa-
tisfaire le client. Si ce prérequis n’est pas respecté, il est peu probable que la
rentabilité entre autres soit assurée. Il faut donc commencer par poser des bases
solides.
La satisfaction nécessite de fournir un résultat qui remplit ou dépasse les
exigences du client et de pouvoir le justifier. Pour cela il est pertinent de structurer
le travail pour disposer d’un cadre de travail efficace.
On cherchera donc à travailler sur les quelques axes suivants :
— Définir des processus.
— Tracer les décisions prises.
— Valider les livrables.
— Capitaliser les connaissances.
— Gérer les relations avec les parties prenantes.
La maîtrise de la qualité reposera sur une mise en application constante de
principes dans les domaines listés ci-dessus.
11. “Mais l’important c’est pas la chute, c’est l’atterrissage” – La Haine de Mathieu Kassovitz
12. Tels que l’ISO 9001:2015 – qui est un peu trop grosse pour rentrer dans ce livre.

9.3.1 Les processus
Un processus est un ensemble organisé d’activités afin d’arriver à un résultat.
L’intérêt est qu’il permet de garantir la prédictabilité de ce qu’on obtiendra en
définissant à chaque étape les entrées et les sorties.
Cela s’obtient grâce à la formalisation des actions qui ne doit pas laisser de
place à l’improvisation durant l’exécution de tâches 13
. La finalité sera de répéter
les bonnes pratiques pour pouvoir viser un niveau minimum de qualité à chaque
fois. Minimum n’est évidemment pas à lire au sens de plus petit possible, mais de
ce qui est demandé par le client.
D’autre part, un processus définit en général des éléments de communication
autour des tâches; par exemple des résultats et mesures lors de tests, des rapports
d’analyse, etc. . .
Ce sont des points importants qui permettent de gérer les interfaces du Projet
avec son environnement extérieur. Ils permettent de valider qu’on est toujours sur
une trajectoire nominale pour atteindre les résultats souhaités. On complétera cet
aspect dans les chapitres à venir.
Le chef de Projet a ici un rôle important de leader. Il existe énormément
de processus déjà définis pour encadrer des activités de développement. Beaucoup
sont décrits dans la littérature, et la majorité des organisations (qu’il s’agisse
d’entreprises, d’associations ou de tout groupe organisé) a aussi des règles définies.
On devra veiller à leur bonne application tout en ayant un regard critique pour
évaluer en permanence si on emploie les bonnes méthodes. Un processus est un
outil efficace pour ce pour quoi il a été construit, mais il faut toujours être capable
d’être flexible. En effet, le corollaire d’un enchaînement organisé peut être une
sensibilité à l’imprévu. Un événement inattendu peut gripper l’organisation et
pourrait s’avérer compliqué à résoudre si on ne dispose pas de degrés de liberté
suffisants.
Dans ce cadre, il faudra donc être capable de modifier les façons de travailler
pour continuer à progresser vers les objectifs du Projet. Une fois encore il faut
savoir s’adapter et ne pas s’enfermer dans un respect aveugle de procédures qui
compliqueraient les opérations plus qu’elles ne les fluidifieraient.
9.3.2 La traçabilité de l’information
Un principe essentiel à la maîtrise de la qualité est de pouvoir comprendre
ce qui est et a été fait. Pour cela, il faut pouvoir à chaque instant retrouver les
13. On insiste sur exécution parce que le processus ne doit pas être vu comme un frein à
l’innovation. L’activité est organisée pour être efficace, mais elle n’est pas bridée. C’est souvent
en organisant les tâches répétitives qu’on dégage du temps pour l’innovation.

raison(nement)s et les choix qui ont amené les décisions prises sur le Projet. Ainsi
il est possible en cas de problème de rechercher les causes pour pouvoir trouver
des solutions.
Cette traçabilité des informations est obtenue grâce à une gestion rigoureuse
et au partage des documents créés au cours du Projet. Par document on entend
toute information qui puisse être utile au Projet, qu’elle soit structurée et codifiée
– tel qu’un contrat – ou plus générique, comme des emails par exemple.
Un point important à garder à l’esprit est qu’il faut archiver ce qui a de la
valeur informationnelle. En effet, on observe par exemple souvent des habitudes de
sauvegarde systématique et exhaustive des échanges au sein d’une équipe Projet. Si
l’on est évidemment certain ainsi de ne pas perdre d’information potentiellement
utile, on crée par contre de la complexité qui peut faire perdre de la valeur à
l’information stockée. Il pourra ainsi être beaucoup plus compliqué de réutiliser
des idées, ou de bâtir des réflexions à partir d’éléments conservés :
— Il sera difficile de retrouver les éléments utiles et pertinents.
— L’information ne sera pas structurée et donc difficilement exploitable.
Il est alors utile de se rappeler qu’on doit toujours chercher à faciliter le
travail de ses clients internes ou externes 14
et que toute production – qu’il s’agisse
d’un élément du résultat final du Projet, ou de documentation annexe – doit se
faire en ayant à l’esprit les besoins de l’utilisateur.
Ce dernier point est important parce que si la traçablité est évidemment
indispensable pour pouvoir analyser à posteriori le déroulement du Projet afin
d’identifier les causes d’un problème ou les raisons d’un choix, elle est aussi utile
pour pouvoir capitaliser la connaissance qui est créée au cours du Projet.
C’est un aspect dont on doit aujourd’hui tenir compte car on évolue de plus
en plus dans un monde de la connaissance 15
qui implique de pouvoir bâtir – au
sens propre – à partir des briques intellectuelles qu’on aura pu produire.
Il souligne par ailleurs la nécessité de définir un système de gestion de l’in-
formation performant pour pouvoir retrouver facilement les éléments dont on a
besoin selon différents critères :
— Mots-clés
— Auteur
— Sujet
— Date
— . . .
Ces critères de classement sont par ailleurs souvent décrits dans les référen-
tiels qualité qui existent dans les entreprises ou les organisations pour s’assurer de
14. Exactement dans le même esprit que ce qui a été dit au chapitre 8.1.3
15. La remarque est évidente dans le domaine économique, mais elle est tout aussi valable dans
l’associatif voire le personnel.

la cohérence entre les différents Projets réalisés au cours du temps.
9.3.3 La validation
On a jusqu’à maintenant beaucoup insisté sur le fait que les livrables doivent
être conformes aux exigences qui sont définies dans les spécifications du client.
Il faut toutefois se rappeler que ces exigences sont la traduction d’un besoin
concret dont la satisfaction reste la finalité du Projet (point de vue du client). Ces
deux visions sont à la base des activités dé Vérification et Validation dont on a
parlé très rapidement au chapitre 6.1.3.
Pour rappel :
— La Vérification consiste à s’assurer que ce qui est fait correspond aux exi-
gences. C’est une activité qui permet de contrôler à chaque étape du Projet
la prise en compte correcte des spécifications issues de l’étape précédente;
ce qui a été fait l’a été conformément à ce qui avait été défini.
— La Validation concerne l’atteinte du résultat espéré, c’est-à-dire la satisfac-
tion du besoin du client. Le point est ici de confirmer que le service attendu
est fourni.
En pratique, la Vérification doit permettre de confirmer que ce qui est réa-
lisé fonctionne correctement pour répondre aux exigences fonctionnelles. Plusieurs
méthodes pourront alors être utilisées :
— Des revues impliquant les parties prenantes concernées permettent une
présentation du travail réalisé pour partager les retours et s’assurer que
tous les aspects requis pour la fonction sont pris en compte.
— Des inspections et analyses sont utilisées pour vérifier l’implémentation
des solutions techniques et détecter de possibles erreurs ou manques.
— Des tests fonctionnels et structurels sont réalisés pour vérifier que la
fonction ou le composant en question fonctionne correctement en fournissant
les résultats attendus en vue de son intégration dans le produit final. On
note ici qu’on s’intéresse au fonctionnement interne du composant. S’il n’est
pas correct, le module ne pourra fournir les entrées/sorties attendues pour
être intégré dans son ensemble supérieur. On parle en Ingénierie Système
d’une vision en boîte blanche.
La validation consiste par contre à montrer que le produit remplit les besoins
des utilisateurs en assurant les fonctions requises.
Concrètement, on ne va pas vérifier que le fonctionnement interne est correct,
mais que les réponses correspondent à ce qui est attendu. On va donc travailler
selon le principe de la boîte noire pour effectuer des tests fonctionnels. Les détails
de l’implémentation restent masqués.

En théorie, cette étape devrait être réalisée par les utilisateurs qui prendraient
en main le produit pour le tester en conditions réelles. En pratique, on va s’appuyer
sur le cahier des charges pour définir des tests d’acceptation 16
. Il faudra, dans le
plan de test, spécifier des cas d’utilisation représentatifs à partir des exigences du
cahier des charges.
9.3.4 Bâtir pour le futur
On a déjà évoqué le fait de devoir capitaliser les connaissances créées au cours
du Projet 17
. Bien qu’un Projet soit limité dans le temps, il ne faut pas qu’il soit
considéré comme une initiative isolée, mais il doit s’inscrire dans une démarche
d’amélioration continue.
À ce titre, on devra pouvoir tirer des enseignements et réutiliser des acquis
suivant deux axes :
— Méthodologique : le Projet doit permettre de travailler sur une organisation,
des procédures et développer un mode collaboratif de travail.
— Technologique : le Projet donne lieu au développement de briques fonction-
nelles qui peuvent être réutilisées dans le cadre d’initiatives nouvelles.
Sur le plan de la méthode, le Projet peut être considéré comme un labora-
toire qui permet d’évaluer en conditions réelles une organisation et une façon de
travailler. Il ne faudra évidemment pas perdre de vue les objectifs, mais il reste
intéressant d’évaluer ce qui pourra être conservé et réutilisé dans le futur. En effet,
le Projet demande de rechercher l’efficacité et la performance, et les méthodes qui
auront été mises en œuvre avec succès auront été par définition validées.
On devra donc s’assurer de tracer ce qui est fait pour constituer un référentiel
de techniques éprouvées 18
.
Sur le plan des techniques, le Projet permet de développer des éléments qui,
s’ils sont correctement définis, pourront être réutilisés par la suite, permettant ainsi
des économies. Économies financières immédiates parce qu’on pourra travailler
plus rapidement en ayant besoin de moins de délai puisqu’une partie du travail est
déjà fait. Mais aussi économies indirectes parce qu’on basera son travail sur des
concepts déjà éprouvés et testés, donc à priori plus fiables. Enfin on libère aussi
un potentiel de gain puisqu’on pourra consacrer le temps nouvellement disponible
à la recherche de solutions plus performantes, à l’innovation.
16. Méthode déjà évoquée rapidement au chapitre 8.3.1
17. Voir le chapitre 9.3.2
18. On lit souvent à ce sujet la nécessité de capitaliser les bonnes pratiques, best practises en
anglais. Il s’agit bien de l’idée, mais on ne doit pas comprendre bonnes dans le sens où c’est ce
qu’il faut systématiquement faire. Même si elles fonctionnent, elles ne sont pas nécessairement
les mieux adaptées en toute situation, et la répétition ne favorise pas vraiment l’innovation. . .

Dans les deux cas, on comprend qu’il est indispensable de documenter cor-
rectement le travail réalisé pour qu’il soit facilement réutilisable :
— En retrouvant aisément ce qui a été fait et pourrait être utile dans un
nouveau contexte.
— En étant capable de comprendre rapidement comment fonctionnent les com-
posants pour pouvoir les intégrer de façon efficace à un nouvel ensemble.
On a là deux exigences que doit respecter le système mis en place pour
conserver et organiser l’information créée.
D’une part elle doit être caractérisée, catégorisée. Cela peut être fait en dé-
finissant une structure logique pour le dépôt qui peut être basée sur des critères
fonctionnels (on répond à un besoin utilisateur), techniques (selon les concepts mis
en œuvre) ou autre suivant l’intérêt du Projet et de l’organisation. Ce marquage
peut aussi être réalisé grâce à des tags qui qualifient les éléments d’information sur
différents axes et permettent des recherches plus fines.
D’autre part, les éléments de cette base documentaire doivent être construits
de manière standard pour permettre une utilisation et une intégration faciles dans
le cadre de nouveaux projets. On veillera donc à décrire complètement les interfaces
(entrée et sorties), l’objectif, mais aussi les limites et conditions d’utilisation spéci-
fiques qui pourraient s’appliquer. Il s’agit concrètement de construite un ensemble
de briques qu’on pourra choisir et réutiliser sans effort en fonction des besoins.
Ces premiers éléments concernent en premier lieu l’équipe Projet en lui per-
mettant d’être plus efficace pour livrer des résultats de bon niveau, mais la gestion
de la qualité favorise aussi la communication extérieure.
9.3.5 Gérer les relations
On a déjà insisté plusieurs fois sur l’importance de la communication pour
le succès d’un Projet. Disposer de l’information au bon moment est indispensable
pour prendre les décisions dans les moments de tension. Fournir un état clair
et réaliste à toutes les parties prenantes est un prérequis incontournable pour
anticiper les difficultés et les gérer au plus tôt.
Il faut donc communiquer de façon efficace. Les processus de gestion de la
qualité ont un rôle essentiel dans ce cadre.
Pour permettre le pilotage du Projet et montrer au client que l’avancement
est conforme aux objectifs, il est nécessaire de fournir régulièrement des informa-
tions fiables et pertinentes. Ce reporting est souvent une tâche essentielle du rôle

du chef de Projet 19
qui peut être assisté de PMO (Project Management Officer 20
)
pour les gros Projets. Dans ce cas l’information transmise a une valeur essentielle –
contractuelle même – et elle doit donc être formalisée de façon précise pour éviter
les incompréhensions et les interprétations personnelles.
L’information transmise définit un référentiel qui caractérise l’état du Projet.
Les règles de construction de ce référentiel sont définies dans le système qualité
qui régit le Projet pour éviter toute contestation ou mise en doute.
Le corollaire du point ci-dessus est que l’avancement du Projet est documenté
de manière exhaustive. L’équipe est en mesure de prouver à tout moment son état
de réalisation et donc de valider en particulier la finalisation des différentes étapes
prévues au planning. C’est un point essentiel contractuellement puisque les jalons
définis correspondent souvent à des paiements de la part du Client.
On pourra donc fournir avec les factures les livrables, et les éléments de
preuve pour montrer qu’ils ont été correctement et entièrement réalisés.
19. Voire l’unique pour certains Projets mal gérés où le chef de Projet n’est qu’un responsable
de communication sans aucun pouvoir de décision. . .
20. Chargés de récupérer et de synthétiser des indicateurs.

Chapitre 10
La gestion des risques
Le déroulement d’un Projet est régi par un plan, qui comme tout plan se
déroule rarement tel qu’il est prévu 1
.
Le Projet est soumis à des risques qui le perturbent et peuvent éventuellement
mettre son succès en péril.
En pratique, on peut affirmer sans prendre trop de risque (. . .) que l’on est
certain de rencontrer des problèmes à partir du moment où on débute un Projet.
Une fois qu’on a posé ce constat, on conviendra de la nécessité de gérer les
risques, c’est-à-dire :
— Les définir.
— Les analyser et les évaluer pour les prioriser.
— Les maîtriser.
Concrètement, on va donc chercher à bien comprendre les risques pour pou-
voir mettre en place un plan de gestion efficace qui permette de minimiser leurs
effets.
L’objectif sera de les lister de la façon la plus complète possible pour prévoir
tout ce qui est prévisible 2
.
Cette phase d’analyse devra être débutée dès l’étude du Cahier des Charges.
L’analyse, combinée à l’expérience de l’équipe Projet, permettra de repérer au
plus tôt les risques potentiels : exigences peu claires, points durs techniques, forts
consommateurs de ressources.
1. À part dans l’Agence tous risques.
2. Et uniquement. On ne gère pas le hasard, mais on en reparlera.
131

132 CHAPITRE 10. LA GESTION DES RISQUES
10.1 Qu’est-ce qu’un risque ?
Un risque en gestion de projet est constitué par tout ce qui peut menacer
le bon déroulement. Il ne faut toutefois pas prendre cette définition au pied de la
lettre parce qu’elle est (un peu) large. En pratique, la gestion des risques pour un
Projet concernera uniquement les menaces qui pèsent sur les ressources. On gère
ce sur quoi on peut avoir une influence 3
.
Il ne faudra pas non plus se laisser prendre à gérer ce qui ne doit pas l’être.
Cela signifie que certains problèmes qui arrivent ne sont pas des risques, mais des
erreurs. En effet, si les spécifications initiales du Projet sont mauvaises, ce qui
peut rendre les objectifs irréalistes, il n’y aura pas de gestion possible. Certains
cas doivent simplement être consciemment laissés de côté.
Il existe donc quatre grands types de risques qui sont liés aux quatre types
de ressources qui sont nécessaires pour la réalisation d’un Projet :
— Les ressources humaines
Il s’agit des hommes (et femmes évidemment) qui vont réaliser le travail
qui est demandé pour atteindre les objectifs du Projet.
Cela se traduit sur les trois axes classiques de gestion du Projet.
Pour la qualité, les personnes impliquées amènent leurs compétences qui
doivent permettre de répondre aux besoins, au sens technique, en dévelop-
pant les fonctions qui permettent de répondre au cahier des charges. Il faut
donc s’assurer d’avoir à disposition le niveau de savoir nécessaire pour créer
ce qui doit l’être. Une équipe qui ne dispose pas des compétences nécessaires
ne saura pas créer les fonctions innovantes demandées.
Les personnes travaillent ensuite contre une rémunération (qui peut être
directe ou indirecte) qui représente un coût pour le Projet qui se traduira
ensuite en un coût pour le client final. En fonction du budget disponible, on
pourra se retrouver dans une impasse si les ressources qu’on a à disposition
sont trop chères.
Enfin les délais seront affectés par la capacité qui caractérisent les res-
sources. Ce point peut être particulièrement important quand on fait appel
à des personnes disposant de compétences spécifiques et travaillant sur plu-
sieurs Projets en même temps. Une surcharge de travail pourra alors les
conduire à décaler certaines tâches et mettre en danger le planning du Pro-
jet.
— Les ressources matérielles
On entend par là les machines, les locaux, les logiciels. . .
L’analyse est alors similaire à celle concernant les ressources humaines.
3. Sans caricaturer, le fait que la probabilité qu’une météorite s’abatte sur le lieu de travail
de l’équipe n’est pas nulle ne doit pas conduire à en tenir compte pour la gestion des risques.

10.1. QU’EST-CE QU’UN RISQUE ? 133
La qualité requise pourrait être inatteignable si les machines n’ont pas les
performances nécessaires pour répondre aux exigences du client. Il faut
disposer des moyens corrects pour faire (c’est-à-dire fabriquer), mais aussi
contrôler.
L’aspect coût est assez immmédiat à concevoir puisque directement lié aux
prix des ressources auxquelles on fait appel.
Enfin les délais ne pourront ête tenus que si les outils employés ont la
capacités de produire suffisamment rapidement les quantités demandées.
— Les ressources financières
On a déjà abordé le sujet du budget du Projet 4
et on conviendra aisément
que le Projet demandera certainement des liquidités pour sa réalisation.
Afin d’atteindre la qualité demandée, il faut être en mesure d’utiliser des
moyens (ressources. . .) qui ont les performances requises. Qu’il s’agisse de
machines ou d’hommes, le Projet devra donc investir au bon niveau pour
atteindre ses objectifs. Un manque de financement constituera une menace
s’il impose d’utiliser des moyens dégradés par rapport au besoin.
Sur le plan des coûts, la situation est paradoxale. On pourrait penser qu’un
Projet dont les moyens financiers sont limités permettra de limiter les coûts.
S’il s’agit effectivement d’une possibilité – pourvu que la limitation ne soit
pas trop forte et que la gestion soit rigoureuse – un manque de moyens
conduit la plupart du temps à des problèmes parce qu’il sera difficile de
remplir les objectifs.
Un nombre trop limité de personnes dans l’équipe se traduira par des com-
pétences qui manquent, ou une surcharge de travail nuisible à la qualité des
résultats.
Des économies trop fortes sur le matériel amèneront invariablement des diffi-
cultés voire l’impossibilité d’atteindre les exigences par exemple de précision
ou de rapidité.
— Le temps
Toute entreprise demande un certain temps pour pouvoir être exécutée. De
son côté, le client demande souvent des délais les plus courts possibles. Ce
constat souligne l’existence de tensions intrinsèques qu’il va falloir gérer.
Par conséquent, un manque de temps peut rapidement devenir un risque
majeur.
La qualité des résultats fournis pâtira certainement d’un travail trop rapide.
Il arrive un stade où les gains de temps ne deviennent possibles qu’en omet-
tant certaines tâches. On peut donc en arriver à supprimer certains tests,
certaines vérifications, ce qui introduit des incertitudes.
Les coûts engagés sur le Projet risquent alors de dériver parce qu’il va falloir
4. Voir le chapitre 9.1.

allouer plus de ressources productives pour essayer d’économiser du temps.
Enfin, la tenue des délais est en danger. Le travail dans la précipitation est
un frein au respect des méthodes et de la planification, ce qui peut générer
du désordre qui amène rarement à l’efficacité.
Il est intéressant de noter que les risques sont souvent liés entre eux; toujours
ce fameux triangle QCD ! Comme toujours en gestion de Projet, on devra donc
chercher le meilleur compromis possible pour atteindre les objectifs.
10.2 Quels sont les risques à gérer ?
On vient donc de montrer que tout Projet est soumis à certaines menaces
dont on va devoir gérer une partie. Comment identifier ce qui doit être pris en
compte ?
Il est utile de s’appuyer sur une démarche structurée qui permet de limiter
les cas où on surveillerait des paramètres à mauvais escient. Le principe est basé
sur un processus qui comprend trois étapes :
Identifier les risques
Prioriser les risques
Prévenir les risques
Plan de prévention
des risques
PérimètreduProjet
Environnement
extérieur
Figure 10.1 – 3 étapes pour identifier les risques à gérer

10.2. QUELS SONT LES RISQUES À GÉRER ? 135
10.2.1 Identifier les risques
La documentation Projet constitue un outil puissant pour réfléchir aux risques
qui peuvent potentiellement se matérialiser. L’exploitation des documents créés
pour la gestion du Projet permet d’identifier des problèmes potentiels.
Le cahier des charges permet d’analyser les exigences du client et d’anticiper
les moyens (les ressources) qui devront être mis en œuvre pour y répondre.
Le diagramme PERT 5
met en évidence le chemin critique du Projet. Tout
problème qui le toucherait mettra invariablement le Projet en retard. Par consé-
quent on devra être particulièrement vigilant quant aux ressources qui sont néces-
saire à l’exécution des tâches sur le chemin critique.
Le planning permet de remarquer les phases qui ont un jalonnement insuffi-
sant et sont donc sujettes à l’effet tunnel 6
. Un manque de visibilité prolongé peut
amener à ignorer des problèmes qui apparaissent.
Le WBS 7
et le RACI 8
permettent de mettre en évidence les tâches sans
responsable. Il s’agit d’un danger potentiel parce que personne ne se sentira chargé
de vérifier que les travaux se déroulent conformément au plan.
L’exploitation des ces différents outils doit être faite de manière méthodique
et rationnelle. Il sera nécessaire de s’appuyer sur une équipe pluridisciplinaire qui
sera plus à même d’avoir une vision large et complète des menaces qui pèsent sur
le Projet.
L’équipe pourra mettre en œuvre différentes techniques pour y parvenir :
— Des réunions de brainstorming permettront de s’appuyer sur les expertises
des différents membres de l’équipe. Il est alors pertinent de rechercher à
caractériser au maximum les risques identifiés, par exemple en utilisant les
outils d’arbre des causes, ou les diagrammes causes-effets.
— Des checklists, qui peuvent avoir été enrichies des retours d’expériences de
Projets précédents, aideront à s’assurer que tous les aspects ont été évalués
et de ne pas passer à côté d’éléments importants 9
.
10.2.2 Prioriser
Une fois les risques identifiés, il est nécessaire de définir des priorités pour
leur gestion. Il n’est pas possible – et pas judicieux – de traiter tous les risques
ensembles et au même niveau.
5. Voir le paragraphe 7.5.2.
6. Évoqué au paragraphe 9.2.1.
9. On peut aussi se baser sur certains standards tels que l’ISO 31000:2009, Management du
risque – Principes et lignes directrices.

On va donc les classer selon leur criticité qui est définie par la formule :
criticité = fréquence × gravité
Cette formule permet de classer les risques et de définir ceux qui doivent être
gérés et ceux qui ne doivent pas l’être :
Gravité
Fréquence
Risques de fréquence
Risques de gravité
Risques intolérables
Risques négligeables
Domaine de la
gestion des risques
Figure 10.2 – Les niveaux de risques à gérer.
Le classement qui est illustré par la figure ci-dessus met en évidence le fait
qu’il existe une zone de risque qu’on doit gérer, mais aussi plusieurs situations
pour lesquelles ce n’est pas le cas.
Les quatre coins représentent en effet des circonstances extrêmes qui sont :
— Soit sans solution, et donc ne doivent pas faire l’objet d’effort.
— Soit demanderaient beaucoup d’efforts pour un résultat qui n’apporte au-
cune valeur en pratique.
Il est donc important de bien savoir identifier ces zones pour éviter de se
laisser entraîner dans leur prise en compte :
— Les risques négligeables ne surviennent que rarement et ont concrètement
peu de conséquences. Il faudrait donc fournir beaucoup d’efforts de vigilance
pour les identifier et leur apporter une solution n’améliorerait pas le Projet
dans des proportions notables.
Par conséquent, on doit simplement les ignorer.

— Les risques de fréquence qui arrivent très souvent mais ne sont pas graves
sont en fait des problèmes qui doivent être résolus.
En effet, les occurrences nombreuses excluent de fait la part d’aléatoire qui
caractérise un risque. La répétition crée une charge de travail imprévue qui
ne pourra être compatible avec la poursuite des objectifs du Projet.
Il faut donc résoudre les problèmes pour supprimer leur impact sur le Projet.
— Les risques de gravité peuvent avoir des conséquences catastrophiques s’ils
venaient à se réaliser. Pourtant la très faible probabilité que cela arrive fait
qu’il faut simplement les accepter. On ne peut pas se permettre de consacrer
des ressources pour minimiser ces risques qui ont peu de chance de survenir
et mettraient de toute façon un terme au Projet si cela arrivait.
— Les risques intolérables mettent en péril la survie du Projet, et ont une
probabilité importante de survenir.
On comprend donc qu’il s’agit d’obstacles trop importants à la réussite, qui
n’ont pas été identifiés lors des phases préliminaires d’analyse.
Concrètement, ces risques imposent soit l’abandon du Projet dans le pire
des cas, soit la redéfinition du périmètre et des conditions pour les exclure
de facto.
L’évaluation de la criticité d’un risque demande donc d’être capable d’évaluer
sa fréquence possible d’apparition et sa gravité potentielle.
La fréquence peut idéalement être calculée sur la base de relevés qui per-
mettent de disposer de données fiables et d’inventorier les problèmes. Un échan-
tillon représentatif permet alors d’établir des statistiques qui donnent une valeur
réaliste de la fréquence d’occurrence des problèmes.
Mais il est parfois impossible de s’appuyer sur un historique disponible. Dans
le cas d’un Projet innovant, on n’a pas forcément d’expérience exploitable qui
permette de recenser les problèmes potentiels. Il faudra alors s’en remettre aux
avis d’experts qui auront à établir à la fois une liste des risques possibles, et une
estimation des fréquences associées. Il se baseront pour cela sur leur expérience
afin d’identifier des situations similaires qu’ils auraient pu rencontrer.
Le cas de la gravité peut être plus complexe parce que les conséquences
d’un risque concrétisé peuvent être de différents types : financiers, qualitatifs ou
temporels.
Le besoin de pouvoir établir des comparaisons impose donc d’avoir une réfé-
rence commune. On peut alors traduire les éléments dont on dispose en équivalents
financiers en se basant sur les taux horaires du Projet, sur les coûts budgétisés pour
les fonctions impactées et sur d’éventuelles pénalités de retard contractuelles 10
. . .
10. Liste non exhaustive, il faudra être créatif.

Une fois les risques évalués en termes de criticité et de gravité, il faudra
mettre en relation les ressources qui sont liées aux situations concernées afin de
déterminer les cas à traiter en priorité.
Comme pour les risques, les ressources peuvent être classées selon deux axes :
— Les ressources sensibles sont celles qui sont fréquemment mises à contribu-
tion. Elles pourraient donc être à l’origine de nombreuses situations diffi-
ciles.
— Les ressources névralgiques sont spécifiques, particulières. Elles sont diffi-
cilement substituables ou remplaçables, et ont donc un impact potentiel
important.
On remarque donc pour les ressources une analogie avec le classement des
risques, en retrouvant des concepts proches de la fréquence et de la criticité.
En pratique, il faudra donc donner la priorité à la gestion des risques qui
sont liés à des ressources elles-mêmes sensibles : on a une superposition entre les
matrices des risques et celle des ressources.
Enfin, la priorisation des risques peut s’appuyer sur la Loi de Pareto :
20% des risques sont responsables de 80% de la criticité
L’idée consiste à classer tous les risques sur un diagramme en fonction de
leur criticité décroissante (voir figure 10.3 page 139).
Il s’agit donc d’une méthode plus rapide de priorisation qui permet de concen-
trer les efforts sur les risques qui auraient l’impact le plus fort sur le Projet.
Une fois les risques identifiés et classés, l’équipe Projet aura intérêt à mettre
en place des mesures pour limiter leur apparition, et leur effets s’ils devaient se
concrétiser.
10.2.3 Prévenir les risques
Les risques ayant été positionnés sur la matrice fréquence-criticité 11
, on va
pouvoir choisir une stratégie de gestion selon le critère prédominant : fréquence,
gravité, ou les deux. . . :
— Réduire la gravité d’un risque va consister à prendre des mesures de pro-
tection dans le cas où il se concrétiserait.
— Réduire la fréquence reviendra à utiliser des mesures de prévention qui
visent à éviter l’apparition du risque.
Ces actions reviennent à déplacer le risque dans la matrice pour qu’il devienne
acceptable (voir figure 10.4).
11. Voir figure 10.2.

Criticité80%
20%
Figure 10.3 – Principe d’application de la loi de Pareto.
Gravité
Fréquence
Risques
acceptables
Risque
initial
Prévention
Protection
Figure 10.4 – Principes de gestion des risques.

IL est donc important d’anticiper pour pouvoir identifier les moyens de ges-
tion les plus adaptés.
La prévention des risques repose sur la mise en place de mesures spécifiques
en fonction de la nature des problèmes potentiels.
On pourra citer :
— Des mesures techniques afin d’éviter les erreurs : Poka Yoke, codes couleurs.
— Des clauses contractuelles spécifiques (par exemple des pénalités de retard,
ou une assurance pour transférer le risque) quand les risques sont de nature
juridique.
— La polyvalence permettra de réaffecter les membres de l’équipe en cas de
problème organisationnel.
On comprend donc qu’il faut analyser les risques avec méthode. Plusieurs
existent qui permettent de rechercher les causes possibles.
On peut par exemple citer :
— Le diagramme cause-effet 12
permet d’inventorier l’ensemble des causes pos-
sibles d’un effet en travaillant sur différents axes :
— La méthode
— La main d’œuvre
— Les moyens
— La matière
— Le milieu
Il est aussi parfois appelé diagramme des 5M :
Problème
Main d'oeuvre
Méthode
Matière
MoyenMilieu
Cause 2
Cause 1
Cause 3
Cause 2
Cause 1
Cause 3
Cause 2
Cause 1
Cause 3
Cause 2
Cause 1
Cause 3
Cause 2
Cause 1
Cause 3
Figure 10.5 – Le diagramme Ishikawa.
Ce type de diagramme permet de réfléchir de façon méthodique et exhaus-
tive pour identifier les causes possibles d’un problème. Il se construit en
équipe, pour disposer du maximum d’avis et tenir compte de tous les do-
maines.
12. Connu aussi sous le nom de Diagramme d’Ishikawa.

Une fois recensées toutes les causes possibles, on devra distinguer les causes
contrôlables (celles sur lesquelles on a une influence) de celles qui ne le sont
pas. On cherchera aussi à évaluer l’impact relatif des causes sur l’effet consi-
déré afin de pouvoir prioriser les actions. Cela pourra se faire en pondérant
les causes d’un facteur défini afin de pouvoir les classer :
Table 10.1 – Pondération des effets
Note Impact sur l’effet
0 Sans effet
1 Négligeable
3 Notable
6 Majeur
9 Très élevé
On pourra ensuite rechercher la cause racine qui est à l’oigine du problème.
— La méthode des 5 pourquoi est utile pour remonter à la cause réelle d’une
situation. Elle consiste – comme son nom l’indique – à se poser de manière
répétée la question pourquoi? afin d’approfondir récursivement sa recherche.
Cette technique permet d’éliminer progressivement les symptômes, qui sont
parfois perçus comme des causes, pour aboutir à une explication rationnelle
du problème qu’on étudie.
La méthode peut apparaître triviale, mais elle est assez puissante quand on
l’utilise correctement :
— Il faut impliquer les personnes directement concernées par le problème
pour s’appuyer sur la meilleure connaissance possible.
— Il faut rester factuel, en se basant sur les faits réels et éviter les inter-
prétations.
— Il ne faut pas faire de déduction ou de supposition. L’absence de réponse
à la dernière des questions « pourquoi ? »signifie soit que la réponse à la
question précédente est la cause recherchée, soit qu’il n’y a pas de cause
identifiable au problème étudié, soit qu’on a mal cerné le problème.
— Il faut se limiter à un périmètre sur lequel on peut avoir un contrôle.
— Le QQOQCCP 13
est un sigle qui désigne une méthode de questionnement
visant à obtenir une connaissance complète d’une situation.
Il signifie Qui, Quoi, Où, Quand, Comment, Combien, Pourquoi.
Cela donne une démarche systématique et exhaustive pour mener une ana-
lyse avec l’objectif de maîtriser tous les aspects d’une question. On collecte
ainsi toutes les données pour obtenir un état des lieux fiable.
13. Connu en anglais comme la méthode des Five W’s (5W, pour « Who, What, Where, When,
Why ?) ».

Une fois les risques bien identifiés, il faut se donc se préparer au maximum
pour minimiser leurs conséquences.
Une méthode utile peut être de chercher à réagir automatiquement au mieux.
On peut pour cela s’appuyer sur deux techniques :
— Le Mental Contrasting 14
, qui consiste à visualiser le succès, les bénéfices
qu’on espère tirer d’une situation, puis les obstacles qui se dressent sur le
chemin pour y parvenir. On peut alors réfléchir à ce qu’il faudra faire pour
les éliminer ou les surmonter.
— Les plans si...alors (connus dans les livres et articles en anglais comme
if...then. . .) consistent justement à réfléchir aux actions qui devront être
mises en œuvre selon les situations. L’objectif est de développer des réflexes
en cas de conditions spécifiques. On évite ainsi les problèmes qui pourraient
être dus à l’incertitude ou aux tergiversations qui apparaissent souvent en
cas de situations où l’inconnu occupe une place importante.
On a donc vu dans cette partie quelques préconisations pour pouvoir identi-
fier et minimiser les risques sur un Projet.
Il faut toutefois s’assurer de mettre en place un suivi rigoureux pour maîtriser
les dérives éventuelles.
10.3 Suivre les risques
On vient de parler de la gestion des risques sous l’angle de la préparation,
mais il est rare 15
qu’on parvienne à dérouler tout un Projet sans problème. On doit
donc réfléchir à la façon dont on va pouvoir surmonter les aléas qui surviendront.
Le chef de Projet devra avant tout chercher à être proactif. Il doit chercher à
éviter les problèmes avant qu’ils ne surviennent plutôt que de réagir à des situations
de crise. Cela demande de l’expérience pour être capable d’identifier les situations
à risque avant qu’elles ne dégénèrent.
Cette expérience viendra par la pratique, il est donc important de développer
des habitudes structurantes pour l’acquérir progressivement.
Concrètement, dès qu’une dérive est constatée grâce aux indicateurs de suivi
du Projet, il va falloir prendre des décisions palliatives rapidement pour éviter les
conséquences néfastes. On doit alors être vigilant pour ne pas se laisser enfermer
dans le traitement de l’urgence, mais se concentrer sur les aspects importants pour
le Projet. Il s’agit là d’une situation rencontrée fréquemment qu’on peut gérer par
14. La technique est décrite par Heidi Halvorson dans la Harvard Business Review et son livre
[8].
15. Même impossible. . .

10.3. SUIVRE LES RISQUES 143
exemple en s’appuyant sur la matrice d’Eisenhower 16
:
Urgent
Important
ELIMINER PLANIFIER
DELEGUER FAIRE
Figure 10.6 – La matrice de décision d’Einsenhower.
Il s’agit d’un outil de priorisation simple à utiliser pour peu qu’on ait pris le
temps de caractériser correctement les risques.
Il faut en effet évaluer l’importance du risque, qui est liée à sa gravité poten-
tielle, et son urgence, c’est-à-dire le délai sous lequel ses conséquences vont nuire
au Projet. On aura alors quatre possibilités :
— Le risque est peu important et peu urgent.
On est alors dans une situation où on peut simplement ignorer cet aléas.
On décide d’assumer les conséquences s’il devait finalement se confirmer. Il
n’y a pas de danger pour le Projet.
— Le risque est peu important mais urgent.
Il faut alors déléguer la gestion du problème. L’imminence fait qu’on ne
peut espérer que la situation s’améliore progressivement, mais il serait trop
coûteux au vu des bénéfices espérés de se consacrer à sa résolution(se si-
gnifiant ici soit le chef de Projet personnellement, soit l’équipe ou un de ses
membres).
16. Développée à partir d’une citation d’Einsenhower : Ce qui est important est rarement urgent
et ce qui est urgent rarement important. Je ne sais pas s’il a personnellement utilisé l’outil.

On choisira donc de charger quelqu’un d’autre du travail pour rester concen-
tré sur les objectifs du Projet.
— Le risque est important, mais peu urgent.
La recherche de solution doit devoir être organisée pour être efficace. On ne
peut pas se permettre de souffrir de conséquences graves. On va donc plani-
fier la gestion du risque pour maîtriser au mieux l’aléa. Ce cas s’apparente
souvent à la mise en place d’un petit Projet spécifique pour garantir autant
que possible le succès.
— Enfin le risque peut être important et urgent.
Il n’y a alors pas d’autre alternative que de faire ce qui est requis pour
pallier au danger. La gravité potentielle interdit d’ignorer la situation qui
pourrait mettre en danger tout le Projet. Et l’urgence ne laisse pas le temps
de rechercher des ressources externes pour limiter l’impact sur le planning.
La situation est potentiellement (très) grave; il faut régler les problèmes au
plus tôt.
Avec l’expérience, le chef de Projet apprendra à évaluer rapidement et avec
fiabilité les situations qui se présentent. Cela permettra de limiter au maximum
les risques.
Mais on ne parviendra généralement pas à les éliminer complètement, il fau-
dra donc gérer certaines situations de crise.
10.4 Les difficultés arrivent
Malgré toute la préparation, le Projet traversera probablement des moments
difficiles.
Il est soumis à des influences multiples de son environnement, qu’elles viennent
du client, des fournisseurs ou de l’organisation elle-même.
Un des cas les plus fréquemment rencontrés est le manque de ressources.
Il peut s’agir d’une situation intrinsèque, si la préparation a été mal effectuée
et a conduit à une sous-évaluation des besoins, ou d’un évènement imprévu, par
exemple si d’autres Projets requièrent des ressources indispensables. On se re-
trouve alors à devoir gérer des conflits. Cela demande du travail et n’offre pas de
perspective garantie de succès.
On peut aussi être confronté à une évolution des besoins exprimés par le
client. Il s’agit d’une situation qui ne devrait théoriquement pas exister, puisque
les spécifications constituent une part du contrat qui lie l’équipe Projet et le client.
Pourtant cela arrive en pratique assez fréquemment et doit être géré.
Il s’agit de deux exemples parmi d’autres de difficultés qui peuvent conduire
à des blocages sérieux du Projet. On ne peut se permettre de rester sans réaction.

10.4. LES DIFFICULTÉS ARRIVENT 145
N’ayant plus la possibilité de prévenir pour éviter, le chef de Projet va devoir
discuter du problème avec le client pour trouver une solution qui soit acceptable
pour les deux parties. On retrouve donc un nouvel exemple du besoin impératif
de construire une relation de confiance solide, qui doit permettre d’analyser objec-
tivement la situation. Un risque qui se concrétise est une menace pour le Projet,
mais il laisse la possibilité d’y réagir. S’il devait causer un blocage, il n’y aurait
plus d’échappatoire possible.
En conséquence, l’équipe Projet devra rapidement agir 17
:
1. Procéder à une analyse de la situation pour vérifier qu’il n’existe pas de
solution à coût supportable qui permettrait de solutionner le problème.
Cela demandera probablement à ce stade un investissement, mais cela doit
être envisagé pour éviter une dégradation supplémentaire.
2. Présenter clairement la situation au client pour discuter avec lui d’éventuels
aménagements possibles :
— Le périmètre pourrait être allégé via la suppression de certaines exi-
gences. On pourra pour cela s’appuyer sur les criticités qui pourront
avoir été associées aux fonctions requises dans le cahier des charges.
— Le délai de réalisation pourrait être augmenté afin de permettre la prise
en compte exhaustive des demandes.
— On peut enfin demander un financement supplémentaire, en particulier
quand les problèmes découlent de nouvelles demandes client.
En tout état de cause, ces hypothèses constituent des compromis. Les deux
parties acceptent de relâcher conjointement leurs exigences pour aboutir à
un résultat acceptable par tous qui soit le moins dégradé possible. Il est
souvent plus pertinent de livrer un produit qui réponde aux 80% de fonc-
tions vitales que de livrer en retard un produit non abouti censé répondre
à tous les besoins (avec tous les risques d’erreurs dûs au travail bâclé qui
en découle).
Les gestion des risques d’un Projet demande donc d’être pragmatique et
serein. Il faut avant tout chercher à travailler en collaboration avec toutes les
parties impliquées parce que les choix faits dans un moment de crise ont souvent
des conséquences plus fortes que ceux issus de réflexions construites.
17. Comme souvent, trois leviers d’action : QCD.

Cinquième partie
Des outils pour la gestion de
Projet
147

149
La gestion de Projet ne demande en théorie que d’utiliser une démarcche
structurée et méthodique. On a a évoqué tout au long de ce livre certains outils
utiles; ce chapitre formalise un peu plus une liste pour permettre de se construire
une boîte à outils.
On va donc s’intéresser dans cette partie à diﬀérents niveaux :
— Organisationnel
— Technique

Chapitre 11
L’organisation
Le sujet de l’organisation a déjà été évoqué dans ce livre 1
et il a été fait
mention du besoin d’organiser de fréquentes réunions pour partager et réﬂéchir.
Or une réunion ne se fait pas n’importe comment.
11.1 Réunions
On a probablement tous participé à des réunions qui ont pu sembler être
une perte de temps parce que mal organisées, mal structurées et ne donnant lieu
à aucune décision permettant d’avancer sur des sujets pourtant à l’ordre du jour.
Pour être plus concret, on peut mettre en avant les coûts que peut représenter
une réunion puisqu’elle mobilise des personnes pendant un temps donné et des
moyens qui sont parfois importants (salle, matériels, déplacements éventuels. . .).
Il est donc indispensable de les organiser et de les mener correctement. On
doit pour cela respecter quelques règles :
1. On doit organiser la réunion uniquement lorsque cela est nécessaire. Beau-
coup de décisions peuvent être prises en petits groupes, dans le cadre
d’échanges habituels au sein de l’équipe Projet.
Une réunion sera nécessaire pour les points importants qui peuvent avoir
une inﬂuence structurante sur le Projet. Dans ce cas, il faudra alors choisir
un moment adapté, pour éviter de faire des choix trop tardifs.
2. Le choix des participants est essentiel pour assurer le succès d’une réunion.
Le premier point important est de convier les personnes qui sont indispen-
sables à la prise de décision. Il faut que ceux qui sont concernés – c’est-à-dire
qui devront agir ou subiront les conséquences des décisions – soient présents.
1. Par exemple au chapitre 5.
151

152 CHAPITRE 11. L’ORGANISATION
En outre, on devra vérifier que les participants possèdent les compétences
requises pour traiter d’éventuels problèmes techniques. Les décisions qui
seront prises doivent s’appuyer sur des faits concrets et non contestables. Il
faut éviter que les résultats de la réunion puissent être remis en cause par
des absents sous prétexte que les participants n’étaient pas qualifiés. Cela
s’applique aussi à la prise de décision elle-même : on doit compter parmi
les personnes assistant à la réunion les décideurs qui ont le pouvoir et la
responsabilité correspondants aux décisions à prendre.
Enfin, il ne faut pas tomber dans l’excès qui consisterait à inviter un nombre
très important de personnes pour s’assurer – par défaut – que toutes les
concernées seront là. On ne doit convoquer que les personnes liées au sujet
à traiter. D’autres pourraient polluer le débat, voire amener à prendre de
mauvaises décisions car prenant en compte un périmètre qui ne serait pas
pertinent.
3. Une réunion doit être préparée pour aboutir à un résultat positif. On a
évoqué ci-dessus le coût inhérent à l’organisation; il faut donc faire en sorte
d’avoir un retour sur investissement qui corresponde aux moyens engagés.
Cette préparation doit se faire sur différents axes.
En premier lieu, une bonne logistique constitue un prérequis indispensable.
On entend par là qu’on devra réserver une salle adaptée, inviter les partici-
pants en les informant du contenu et du déroulement, réaliser les supports
de présentation.
Ensuite il faut travailler sur le contenu. Ce point est primordial pour garan-
tir le succès de la réunion. On peut en effet décider d’organiser une réunion
de travail qui visera à produire du contenu pour permettre une prise de
décision ultérieure. Dans ce cas, il faudra fournir aux participants les infor-
mations et les moyens dont ils ont besoin pour travailler. Mais la réunion
peut aussi constituer un jalon de décision. On doit alors se concentrer sur
l’analyse de travaux et de résultats déjà produits. On ne pourra alors pas
se permettre de consacrer du temps à refaire un travail de préparation qui
aurait déjà du être fait. Par conséquent, on fournira avec la convocation à
la réunion les éléments de décision disponibles, pour que les participants
puissent se concentrer sur l’analyse et le débat avant de trancher.
4. Durant la réunion, on doit s’efforcer de structurer les débats pour rester
concentré sur les objectifs.
Il est utile de rappeler les buts à atteindre pour s’assurer qu’ils sont bien
compris et acceptés par les participants, mais aussi les livrables attendus
pour que tout le monde puisse se concentrer sur le travail à accomplir.
On peut aussi profiter de cette introduction pour donner un statut clair
de l’état d’avancement du Projet, et rappeler les décisions qui avaient été

11.1. RÉUNIONS 153
prises lors de réunions précédentes pour vérifier que les actions liées ont
bien été exécutées et mettre à jour le suivi de Projet.
L’ordre du jour devra être présenté; les points les plus importants doivent
être traités en priorité pour éviter qu’ils ne soient négligés en fin de réunion
par manque de temps.
Une réunion bien préparée ne regroupe normalement que les acteurs di-
rectement concernés par le sujet traité. On devra donc faire en sorte de
consulter tout le monde pour intégrer tous les points de vue. Cela permet
aussi de vérifier s’il y a eu des oublis – donc des points complémentaires
à traiter – ou des incompréhensions qui pourraient amener à prendre de
mauvaises décisions.
Il existe énormément de ressources disponibles sur Internet pour organiser
des réunions efficaces 2
qui vont de sites académiques traitant du management
aux blogs personnels. Toutes ne sont évidemment pas du même niveau, mais on
peut synthétiser les idées clés assez simplement. Une réunion doit être cadrée par
une bonne préparation pour éviter que les participants ne se dispersent en dis-
cussions certes intéressantes mais inutiles voire contre-productives pour le Projet.
Une réunion est un évènement borné dans le temps, le périmètre de travail et les
personnes impliquées 3
.
On va donc détailler un peu tout cela.
11.1.1 Préparer efficacement
On vient de voir très succinctement que l’avant-réunion est très important.
On va préciser dans ce chapitre.
Avant de travailler à l’organisation d’une réunion, il est déjà primordial de
valider qu’elle est justifiée. La meilleure façon de ne pas perdre de temps est de ne
rien faire si rien n’est nécessaire !
Quand on arrive à une situation qui nécessite la prise d’une décision en
commun, il faut commencer par contacter les personnes concernées afin de prendre
leurs avis et leurs opinions. Il est possible qu’un consensus apparaisse et permettre
de trancher rapidement. Dans ce cas, une simple conférence téléphonique peut être
suffisante pour valider les conclusions.
Dans le cas contraire, ou si la réunion implique de travailler, analyser des don-
nées, discuter de résultats, on comprend qu’il est nécessaire de pouvoir s’appuyer
2. Voir tout simplement https://www.google.fr/search?q=organiser+des+réunions+efficaces
et toutes les variantes.
3. Ce qui rappelle un certain triangle QCD !

sur des documents ou des éléments matériels. On peut alors réfléchir à utiliser des
moyens de visioconférence qui permettent de partager efficacement l’information
et de travailler à plusieurs sur les documents. Cela peut permettre une organisa-
tion bien plus légère à la fois en terme de temps si des déplacements sont évités,
mais aussi financièrement. Accessoirement, un des avantages de telles réunions à
distance est que cela supprime le risque – généralement avéré. . .– d’avoir des « par-
ticipants »rivés sur leur ordinateur portable à faire autre chose que ce pour quoi
la réunion est prévue.
Le point à retenir est qu’il faut communiquer avant la réunion pour valider
le besoin. Une réunion doit être justifiée et nécessaire; c’est en quelque sorte un
investissement qu’on fait sans être à priori certain de la rentabilité.
Une fois acté l’intérêt de se réunir, on doit préparer l’évènement pour maxi-
miser les résultats. Il faut donc cadrer précisément les débats pour s’assurer qu’ils
convergent vers les résultats nécessaires.
On devra commencer par analyser le problème à traiter afin de déterminer
quels sont tous les éléments liés et influents. Il s’agit ici de s’assurer qu’on a bien
compris la portée du problème qu’on souhaite résoudre. Ce premier point est indis-
pensable parce qu’il va permettre ensuite de sélectionner les participants à convier.
Il faut d’ailleurs souligner que cette étape est itérative. Les premières réflexions
peuvent être menées par le chef de Projet et quelques interlocuteurs proches, ce
qui permet de dresser une première liste de participants potentiels. Mais ces par-
ticipants doivent ensuite être consultés pour valider le résultat et l’enrichir le cas
échéant. Un complément qui pourra mettre au jour la nécessité d’inviter des per-
sonnes supplémentaires. . . L’objectif est de parvenir, avant la réunion, à une vision
partagée du problème à traiter – le périmètre. On connaît alors les sujets à aborder,
et avec qui le faire.
Il faut ensuite réfléchir à la construction d’un ordre du jour qui permettra
d’encadrer le déroulement. C’est une étape importante qui peut prendre du temps.
En effet, cela s’apparente à la construction d’un raisonnement qui doit mener
aux conclusions recherchées, mais qui sera déroulé conjointement par plusieurs
participants. On comprend donc qu’il doit être structuré.
On doit commencer par établir la liste de toutes les données d’entrée qu’on
aura à disposition pour travailler :
— Les compte-rendus de réunion(s) précédente(s).
— L’état d’avancement du Projet.
— Les résultats de travaux antérieurs pertinents.
— Les documents à prendre en compte.
Cette liste indicative n’est peut-être pas exhaustive. Il faut essayer de lister
tous les éléments qui permettent d’avoir une vision qu’on estime suffisamment
déterministe pour pouvoir prendre des décisions sur le sujet à traiter.

11.1. RÉUNIONS 155
Les compte-rendus de réunions précédentes permettent d’analyser les déci-
sions qui ont été prises à ces occasions. Cela permet de s’assurer de la cohérence
de ce qui est prévu avec les choix antérieurs. C’est une condition nécessaire pour
cadrer le travail qui devra être fait.
On peut alors examiner si les actions qui avaient été décidées ont été réalisées
conformément aux plans établis précédemment. C’est un point essentiel parce que
cela permet de vérifier que le déroulement du Projet est nominal. On aura donc
une connaissance fiable de la situation qui permettra de prendre des décisions sur
des bases solides.
Les résultats de travaux ou d’analyses déjà réalisés peuvent constituer des
données d’entrée importantes. Il faut les analyser et déterminer s’il est pertinent
de les prendre en compte.
Enfin on s’attachera à rassembler l’ensemble des documents qui devront servir
à la réflexion.
Une fois compilé toutes ces données, on va devoir réfléchir à structurer et
organiser la réflexion, c’est-à-dire construire un raisonnement.
Il est préférable si possible de faire ce travail avant la réunion, pour pouvoir
ensuite dérouler un processus réfléchi. Mais on ne pourra parfois pas le faire si tôt
et on devra attendre la réunion à proprement parler.
Il s’agit d’un travail souvent important qui constitue la base indispensable
à la réussite de la réunion. C’est la phase productive du processus. En effet, si
la prise de décision elle-même est importante parce qu’elle formalise un choix qui
doit permettre d’avancer pour le Projet, elle s’appuie sur les éléments disponibles
et une réflexion qu’on espère logique. On doit donc s’efforcer de produire tout ce
qui sera nécessaire avant.
L’objectif est de disposer des résultats fiables et incontestables qui permet-
tront des choix éclairés.
L’ensemble de ces éléments étant disponible, on peut s’atteler à la définition
de l’ordre du jour proprement dit, qui consiste à lister les thèmes qui seront à
aborder et à structurer le temps de la réunion en blocs correspondants :
— Une brève présentation du sujet pour fournir le contexte.
— La liste des faits pertinents pour la décision.
— Un temps de discussion qui doit être cadré.
— La prise de décision.
On doit souligner concernant le second point que la présentation des faits ne
doit pas être biaisée : elle doit être exhaustive, complète et non partisane. Il ne
faut pas orienter les réflexions en fonction d’opinions préconçues.
Cette phase de préparation se termine par la communication de l’ordre du
jour accompagné des documents supports de travail à l’ensemble des participants

invités.
11.1.2 Piloter la réunion
Le déroulement de la réunion elle-même doit être contrôlé avec soin pour
s’assurer que l’évènement soit productif. On subit trop souvent aujourd’hui des
rencontres qui ne sont pas structurées, avec des participants qui ne sont pas di-
rectement concernés par les sujets à discuter et qui peuvent même aller jusqu’à
polluer 4
les débats en s’éloignant des sujets à discuter.
On veillera par conséquent à appliquer certaines règles.
Premièrement, une réunion doit être dirigée. C’est à dire qu’il doit y avoir
un responsable identiﬁé – en général l’organisateur – qui aura principalement la
charge de s’assurer que l’ordre du jour est suivi. En pratique, cela veut dire qu’il
devra cadrer les discussions pour éviter les digressions et les pertes de temps. C’est
lui qui donnera le rythme et gérera l’enchaînement des sujets.
Ensuite, comme on le verra dans le chapitre suivant, la réunion devra faire
l’objet d’un compte-rendu qui doit être alimenté par les points de discussion im-
portants et les décisions prises. Il faut donc une personne qui note ces éléments.
Il est souvent préférable que ce ne soit pas l’animateur parce qu’il serait perturbé
dans sa conduite des débats.
Concernant le déroulement, quelques points sont à souligner :
— Il faut respecter les horaires et le plan prévu.
La première cause de dérive et de réunions improductives est le non-respect
de l’ordre du jour. Il est important de se tenir au programme établi pour
que tous les sujets soient traités avec le soin requis.
— Tous les avis doivent être pris en compte.
Suite à la préparation rigoureuse de la réunion, on ne doit normalement
n’avoir présentes que des personnes concernées par le sujet du jour et qui
ont une réelle plus-value à apporter. L’organisateur doit faire attention à
ce que tout le monde puisse participer et donner son avis sur les sujets
pertinents. Plusieurs raisons à cela :
— Tout d’abord, la politesse la plus élémentaire.
Une réunion est avant tout un rassemblement de personnes, et les règles
usuelles de la vie en société s’appliquent. Cela peut paraître surprenant
de devoir le rappeler, mais on observe souvent des personnes qui veulent
se mettre en avant, pour des raisons qui ne sont pas forcément répré-
hensibles, au détriment de l’équilibre et de la richesse des discussions.
La réunion a pour but de parvenir à un accord et à une synthèse pour
pouvoir prendre des décisions. Il faut donc respecter tous les avis.
4. Généralement pas de façon volontaire toutefois !

11.1. RÉUNIONS 157
— Les gens se sont rendus disponibles pour participer.
On met donc des moyens en œuvre qu’il ne faut pas gaspiller.
— Les décisions prises doivent être incontestables.
C’est un point essentiel. Si au sortir de la réunion les décisions sont
remises en cause, on aura là encore gaspillé des ressources. C’est un
argument de plus pour s’assurer que tout le monde intervienne et ait
l’opportunité d’apporter ses arguments et opinions.
— Une certaine discipline est nécessaire.
Comme on l’a déjà évoqué à travers le choix des personnes à inviter, on doit
d’abord traiter en réunion les points qui sont à l’ordre du jour. L’agenda a
été établi avec l’objectif de faire avancer le Projet en adressant les points
potentiellement bloquants qui demandent que des décisions soient prises.
S’ils ne devaient pas être pris en compte, de nouvelles actions devraient
être mises en œuvre.
Par conséquent, il est conseillé de suivre l’ordre du jour de manière rigou-
reuse. Si des sujets nouveaux apparaissent au cours des discussions, on peut
les noter pour en parler en fin de réunion ou à défaut planifier une nouvelle
rencontre qui leur sera dédiée. Le but est de ne pas perturber la planification
prévue.
L’animateur doit avoir un rôle de catalyseur durant la réunion. Il doit faire
en sorte que chacun puisse prendre toute sa place, et relancer le débat quand la
discussion perd de l’intérêt. Son objectif est d’amener le groupe à converger vers
des points d’accords qui seront formalisés en décisions pour pouvoir poursuivre le
Projet.
Tout au long de la réunion, le secrétaire devra prendre des notes pour pouvoir
construire un compte-rendu qui constituera le livrable de la réunion.
11.1.3 La conclusion
La réunion se termine quand tous les points à l’ordre du jour ont été traités,
ou – ce qui arrive parfois – quand le temps imparti est écoulé sans que tout ait pu
être discuté.
Dans tous les cas, on réservera un créneau à la fin pour faire une synthèse
des discussions et valider que tout le monde est d’accord sur le résultat. Il faudra
pour cela passer en revue les notes qu’aura pris le secrétaire de séance :
— La transcription des débats
Le secrétaire aura noté les principaux points de discussion, en particulier les
arguments importants de chaque participant, et les éléments d’articulation
du raisonnement. Cela permet après coup de retrouver les raisons à la base

d’une décision pour pouvoir la justifier 5
.
Cette chronologie, qu’on appelle communément les minutes de la réunion
est une transcription brute des débats, sans interprétation.
— Les décisions prises
La réunion a été organisée pour débloquer une situation et a donc pour but
la prise de décision. On intégrera donc au compte-rendu la liste des points à
traiter qui étaient à l’ordre du jour, avec les décisions qui auront été prises
dans chaque cas.
Dans le cas d’une réunion longue, dont les minutes constitueraient une
masse d’information importante, on pourra rappeler à ce moment les élé-
ments de justification pertinents. Dans le cas contraire, un renvoi vers les
minutes suffira.
— Les actions décidées
La réunion ne sera productive que si elle amène à la construction d’un plan
d’action qui doit permettre de répondre aux problèmes qui étaient posés.
Les actions décidées doivent avoir certaines caractéristiques :
— Elles doivent être correctement définies
Cela signifie qu’elles doivent être explicites et décrire précisément le
travail à effectuer.
— Elles doivent avoir un responsable identifié
Un action qui n’est attribuée à personne aura peu de chances d’être
réalisée parce que personne ne se sentira responsable de son exécution.
— Elles doivent avoir une date limite de réalisation
Les actions décidées s’intègrent dans le planning Projet global. Pour
éviter toute dérive, il faut s’assurer qu’elles seront effectuées dans des
délais qui sont compatibles avec le déroulement de Projet. Les résultats
qu’elles doivent produire devront être disponibles au moment où on en
aura besoin.
— Une date éventuelle pour la réunion suivante
Dans le cas où tous les sujets à l’ordre du jour n’auraient pas pu être
traités, ou si des actions demandent un suivi particulier, on peut prévoir
dès le compte-rendu une date pour une réunion ultérieure.
Ce compte-rendu devra être revu en séance avec tous les participants pour
valider que tout le monde est d’accord sur les conclusions de la réunion et possède
le même niveau d’information afin de pouvoir travailler par la suite. C’est un point
important parce que les personnes présentes à la réunion auront souvent à faire
redescendre l’information à leur équipe pour la mise en œuvre.
5. On ne parle pas ici de justification au sens de prouver que la décision prise est la bonne. Il
s’agit uniquement de comprendre pourquoi elle a été prise. Il arrivera malheureusement toujours
que de mauvaises décisions soient prises.

11.2. LE SUIVI DES ACTIONS – LA TODO LIST 159
Le compte-rendu formalise le livrable de la réunion. Il traduit en plan d’action
les conclusions et initie un nouveau cycle de travail qui doit permettre de faire
avancer le Projet. C’est un document qui a une valeur contractuelle ; les conclusions
qui y sont incluses deviennent des exigences pour le Projet dès qu’elles sont agréées
par toutes les parties.
11.2 Le suivi des actions – la TODO list
Le cœur d’un Projet consiste à exécuter des tâches pour construire les li-
vrables attendus par le client. Toute l’organisation qui est mise en place vise à
permettre un flux de réalisation le plus régulier possible. La recherche de l’ef-
ficacité consiste à éliminer toutes les frictions possibles qui introduiraient de la
viscosité.
On doit donc avoir une vision claire de ce qu’il y a à faire en se basant sur
un référentiel bien défini.
La liste de tâches 6
va permettre de recenser de façon exhaustive tout ce
qu’il faut faire et d’ordonnancer les actions. Elle est complémentaire des outils
macroscopiques 7
en proposant une granularité plus fine qui permettra un pilotage
au quotidien.
La planning définit un enchaînement de phases, mais il ne permet pas une
visibilité suffisamment précise pour éviter l’effet tunnel par exemple 8
. On va donc
s’appuyer sur une liste d’actions qu’il faudra faire vivre.
On a défini au chapitre 7.2.3 une tâche comme une unité de travail ayant
certains attributs :
— Un objectif
— Un responsable
— Des entrées/sorties
On peut en général ajouter à ces données une date limite pour l’exécution
du travail. C’est un attribut important qui peut être explicite, quand il existe des
raisons qui imposent de réaliser une chose avant une date définie, ou implicite
quand la date de réalisation est imposée par les relations de dépendance avec
d’autres tâches. Dans les deux cas il faudra donc en tenir compte pour organiser
les travaux.
Le chef de Projet va donc devoir tenir à jour une liste des actions à réaliser en
spécifiant ces éléments clés : l’objectif, le responsable et la date limite de réalisation.
6. Généralement appelée la TODO List.
7. La planning Projet, en particulier le diagramme de Gantt.
8. Évoqué au chapitre 9.2.1.

Cette liste devra être accessible à toute l’équipe Projet, elle constitue une référence
qui définit ce qu’il y a à faire.
Une liste d’actions bien construite est un outil puissant parce qu’il suffit de
traiter les éléments dans l’ordre où ils sont indiqués. Elle doit en effet être ordonnée,
selon différents critères.
En premier lieu la priorité de la tâche sera définie en fonction de la date
limite si elle existe, et/ou de l’importance pour l’atteinte des objectifs 9
. Ensuite
la mention d’un responsable désigné permet à chacun de savoir ce qu’il a à faire
pour faire avancer le travail.
On peut contre faire face à certaines situations de conflits quand plusieurs
actions doivent à priori être entreprises au même moment en faisant appel aux
mêmes ressources. Il faudra alors procéder à un arbitrage et prendre une décision
quant à un ordre de réalisation. Un critère de choix intéressant est d’évaluer le
bénéfice que procurera la tâche au client, qu’il s’agisse du client final ou d’un
client interne au Projet. C’est une méthode qu’on retrouve beaucoup dans le cadre
des méthodes agiles dont on parlera au chapitre 12.4.
11.3 La gestion documentaire
On a pu voir qu’un des critères prépondérants pour la réussite d’un Projet
tient à la disponibilité de l’information. On doit permettre à tous les membres de
l’équipe Projet, et au-delà à toutes les parties prenantes, d’avoir accès aux données
qui leur sont nécessaires pour avancer dans leur travail. Or un Projet produit sans
cesse de l’information qu’il va falloir gérer pour qu’elle soit utilisable. La gestion
de la documentation créée est donc essentielle.
Il y a plusieurs objectifs à la gestion documentaire :
— Être capable de retrouver une information quand on en a besoin.
— Pouvoir assurer la traçabilité des décisions.
— Capitaliser la connaissance pour les Projets futurs.
Cet ensemble d’objectifs met en évidence certains paramètres dont on va
devoir tenir compte pour la gestion des documents produits par le Projet.
Tout d’abord, la possibilité de retrouver une information, qu’il s’agisse d’une
donnée nécessaire au travail, d’une référence à faire ou de la recherche d’une jus-
tification à une décision prise.
On doit donc être capable de rechercher dans le référentiel documentaire, ce
qui doit pouvoir se faire selon différentes clés :
9. Sur le principe de la Matrice d’Eisenhower, voir au chapitre 10.3, qui recommande de
traiter en priorité les tâches importantes

11.4. LA COMMUNICATION AU SEIN DE L’ÉQUIPE PROJET 161
— Des mots-clés quand on cherche une information relative à un concept ou
une idée.
— Des tags, ou étiquettes qui permettent de circonscrire la recherche à un
thème.
— Une date, pour ce qui a été produit à un moment donné.
— Une référence pour cibler un document précis.
— Le créateur et/ou le responsable du document.
Idéalement, on mettre donc en place un système de stockage de la docu-
mentation qui supporte toutes ces caractéristiques. Il pourra s’agir d’un répertoire
ou d’un disque partagé sur un réseau, d’un serveur dédié au Projet ou d’un outil
spécifique à la gestion documentaire 10
.
Pour finir sur l’aspect technique, certains Projets profiteront en plus de la
possibilité de gérer les versions des documents et de toutes les opportunités liées
(diff, patch, ...). C’est un aspect souvent très utile, en particulier pour le dévelop-
pement logiciel, mais il peut être intéressant pour tout type de Projet quand on a
à gérer le travail simultané de plusieurs personnes sur un même document 11
.
Le rôle du chef de Projet sera donc de veiller à ce que tous les documents du
Projet soient stockés correctement dans le référentiel. Il ne faut pas se restreindre
uniquement aux livrables identifiés, mais inclure l’ensemble des données qui ont
de la valeur pour le travail de l’équipe, à savoir (et sans être forcément exhaustif)
les documents d’études, les compte-rendus de réunion, les documents de référence
tels que les normes ou standards applicables, les mails importants qui contiennent
de l’information utile ou des décisions, etc. . .
C’est une discipline à respecter par tous les participants pour pouvoir être
certain de l’intégrité du référentiel afin que toute référence qui y est faite soit
réputé comme correcte.
11.4 La communication au sein de l’équipe Pro-
jet
Un point annexe à la gestion documentaire est la communication au sein de
l’équipe. Il faut que tous les membres soient au courant, et au même niveau de
connaissance de ce qui se passe sur le Projet.
La communication est donc importante pour pouvoir mettre en place la co-
ordination et la collaboration qui permettent de travailler le plus efficacement
10. La solution technique sort du cadre de ces notes. Pour les entreprises, il y a souvent des
outils déjà existants pour répondre à ce besoin.
11. Là encore on ne développera pas dans ces pages, mais on peut chercher sur Internet : CVS,
SVN, Git, . . .

possible. On pourra disposer pour cela de différents moyens qui pourront être syn-
chrones (c’est-à-dire immédiats) ou asynchrones. D’autre part, leur gestion et leur
archivages seront différents selon les cas :
— Une discussion directe est très souvent le moyen le plus rapide de traiter
un problème parce qu’elle peut être immédiate. C’est un moyen synchrone
dans un contexte individuel.
— Le téléphone, lui aussi synchrone et individuel, est un moyen très rapide
d’obtenir une information ou de traiter un point particulier.
— La conférence téléphonique permet de s’adresser à un groupe. Il s’agit
d’un canal synchrone et collectif. Elle permet de faire intervenir plusieurs
personnes pour éviter les risques de critiques de la part de ceux qui auraient
pu être absents d’une discussion.
— L’email est envoyé à un moment choisi mais ne sera lu que quand le
ou les destinataire(s) le décide(nt). Il est asynchrone et mixte indivi-
duel/collectif parce qu’on peut l’envoyer à plusieurs personnes avec dif-
férents niveaux (destinataire principal, copie, copie cachée). L’email est un
moyen de communication pratique mais qui comporte ses défauts.
— Les compte-rendus de réunion sont des documents qui ont une valeur
contractuelle pour l’équipe Projet. Il s’agit évidemment d’un moyen de com-
munication asynchrone avec une cible collective.
— Les notes techniques/de management sont de la même façon que le
compte-rendu de réunion des canaux asynchrones et collectifs. Une Note
Technique est un moyen pour le chef de Projet ou le responsable d’un do-
maine du Projet d’officialiser certains points.
Il faudra choisir le moyen de communication le mieux adapté à chaque situa-
tion en fonction de l’usage qui devra être fait de l’information. Concrètement, on
ne confiera pas à un membre de l’équipe une tâche très importante simplement au
détour d’une conversation téléphonique. Cela peut être une première étape, pour
ne pas perdre de temps et fluidifier les relations, mais cela devra être tracé dans
un compte-rendu ou une note 12
Il est important d’instaurer un certain niveau de confiance au sein de l’équipe,
pour ne pas être bloqué par des procédures trop rigides où chacun attendrait un
document officiel contresigné par tous les supérieurs hiérarchiques avant d’agir.
Un appel téléphonique ou un email doivent permettre d’initier une action. Mais la
recherche de l’efficacité ne devra pas se faire au détriment d’exigences Qualité qui
requièrent une capacité de traçabilité et la possibilité de justifier des décisions ou
des actions. On devra donc confirmer les informations importantes par un moyen
adapté.
12. Et dans ce cas précis dans le fichier de suivi des actions aussi.

Chapitre 12
Les techniques et méthodes
On a eu l’occasion au long de ce livre de mentionner certaines techniques
utiles au chef de Projet. On va dans ce chapitre en dresser une liste un peu plus
complète.
12.1 Le Cycle de Deming (PDCA)
Le cycle de Deming est une méthode de gestion de la Qualité qui synthétise
une démarche d’action rationnelle. Initialement pensée pour la Qualité, elle s’ap-
plique en pratique à toute action complexe ou importante. Elle permet en effet de
rationaliser le travail pour le rendre plus efficace.
La démarche est structurée en quatre étapes (voir la figure 12.1):
1. Plan est une étape de réflexion pour préparer le travail.
Elle débute généralement par une analyse du problème à traiter pour qu’il
soit correctement défini et compris par tous. C’est un prérequis indispen-
sable pour comprendre ce qu’il y a à faire.
On peut s’appuyer pour cela sur différentes techniques qui aident à la ré-
flexion et permettent d’avoir une réflexion plus exhaustive :
— Le QQOQCCP 1
— Le SIPOC 2
Ces méthodes permettent d’avoir une vision assez complète du problème à
traiter, et de tout ce qui peut être en lien avec lui 3
.
Une fois le périmètre délimité, on peut s’attacher à rechercher les causes
qui pourraient en être à l’origine. Là encore, certains outils peuvent aider :
1. Voir le chapitre 10.2.3.
3. A la base aussi de l’Ingénierie Système – Voir le chapitre 12.5.
163

164 CHAPITRE 12. LES TECHNIQUES ET MÉTHODES
Figure 12.1 – Le principe du Cycle de Deming

12.2. LE SIPOC 165
— Le diagramme de Pareto, déjà évoqué au chapitre 10.3.
— Le diagramme d’Ishikawa, cité lui au chapitre 10.5.
L’inventaire des causes possibles permet de délimiter le travail à effectuer
et d’orienter les analyses à mener.
On pourra alors écrire une spécification et établir un planning pour le tra-
vail. Ce cahier des charges peut être très léger, mais il est utile de formaliser
ce qui doit être fait.
2. L’étape Do consiste alors à réaliser le Projet défini en suivant les règles et
méthodes applicables.
On peut à ce moment faire remarquer que ce processus peut être récursif.
On entend par là qu’un problème complexe, traité grâce à la méthodologie
PDCA pourra être décomposé en éléments plus simples, qui pourront eux
aussi faire l’objet de la même méthode 4
.
3. L’étape Check va permettre d’évaluer le résultat obtenu pour vérifier s’il
est conforme à ce qui est attendu et répond au problème posé. On peut
alors étudier les données recueillies pour voir si certaines des options testées
marchent mieux que d’autres et réorienter les phases suivantes. Le processus
PDCA est itératif – ce qui est logique pour un outil d’amélioration continue.
4. Enfin, la dernière étape Act permet de mettre en œuvre les améliorations
définies durant la phase Plan et testées avec Do si les résultats de Check
ont montré une amélioration. Le plan devient alors la nouvelle référence de
travail pour les cycles PDCA à venir si les résultats ne sont pas encore ceux
attendus.
Dans le cas où Check montrerait au contraire une dégradation, on devra
reprendre le cycle avec une nouvelle phase Plan pour redéfinir de nouvelles
pistes de travail.
Le Cycle de Deming permet donc de structurer le travail de l’équipe Projet
quand elle rencontre des problèmes ou des situations difficiles.
12.2 Le SIPOC
Le SIPOC est un acronyme de Supplier, Inputs, Process, Outputs, Customer
et désigne un outil de description de processus :
4. Et ainsi de suite, même s’il faut être vigilant parce qu’un algorithme récursif ne doit pas
rentrer dans une boucle infinie.

Processus
Fournisseurs
(Suppliers)
Clients
(Customers)
Entrées
(Inputs)
Sorties
(Outputs)
Figure 12.2 – Modélisation d’un processus avec le diagramme SIPOC.
Le SIPOC est un outil intéressant parce qu’il permet d’identifier rapidement
les parties prenantes d’une opération et leurs interactions en terme de flux de
données. Cela permet d’avoir une vision macroscopique de ce dont on dispose et
de ce qui doit être fourni.
Le résultat de cette analyse est généralement présenté sous forme de tableau :
Table 12.1 – Exemple d’analyse SIPOC
Supplier Inputs Process Output Customer
Fournisseur 1 Données,
pièces, ...
Description des
opérations
Données,
pièces, ...
Client 1
. . . . . . . . . . . . . . .
La conduite de cette analyse permet d’obtenir une bonne vision d’une situa-
tion et d’appréhender le contexte du problème qu’on va chercher à résoudre.
En pratique, on devra procéder en plusieurs étapes pour obtenir un premier
aperçu qui doit donner une référence et un point de vue objectif. Cela pourra se
faire en confrontant l’étude de la documentation qui décrit les opérations avec l’ob-
servation sur le terrain. Ces deux points sont importants pour saisir les différences
qui existent souvent entre la théorie et la pratique.
Il faudra ensuite discuter avec les acteurs pour vérifier et préciser les pre-
mières constatations. Le dialogue permettra de saisir les subtilités qui ne sont pas
apparues précédemment, en particulier tout ce qui peut être lié à l’expérience et
au savoir faire. Cela permettra d’avoir une perception exhaustive de la réalité.
12.3 La matrice SWOT
La résolution d’un problème peut se faire de différentes manières :
— En le supprimant purement et simplement – c’est une méthode très effi-
cace, mais attention à ne pas nier l’existence du problème initial, ce qui en
causerait de nouveaux.

12.3. LA MATRICE SWOT 167
— En trouvant une solution qui permette de le résoudre. C’est initialement ce
qu’on pense être la meilleure solution, mais elle peut être coûteuse et ne
garantit pas le succès.
— En agissant sur l’environnement pour que les conséquences du problème
soient minimisées au maximum.
La matrice SWOT, pour Strengths, Weaknesses, Opportunities and Threats
(soit en bon français les Forces, Faiblesses, Opportunités et Menaces) est un outil
qui peut aider à orienter ses actions pour décider d’une stratégie de travail sur un
problème. Elle se présente comme sur la figure ci-dessous :
Strengths Weaknesses
Opportunities Threats
OrigineinterneOrigineexterne
Utile Néfaste
Figure 12.3 – Structure d’une matrice SWOT.
La matrice SWOT est structurée en quatre zones dans lesquelles on va cher-
cher à classer les facteurs influents sur la situation qu’on étudie.
Le premier critère à prendre en compte est l’origine de l’influence qui peut
être interne quand elle est liée à une caractéristique intrinsèque de l’organisation ou
de l’équipe Projet. Il s’agit donc d’un point sur lequel on peut éventuellement agir
et qui pourrait donc avoir un impact positif. Un influence externe, au contraire,
est en dehors de la zone d’influence du groupe. Il serait donc vain de chercher à
travailler dessus.
Concernant l’impact des influences, il peut évidemment aller du positif au
négatif, et on aura tout intérêt à se rapprocher le plus possible de la première
extrémité.

On doit donc procéder à une analyse interne et externe pour recenser tous
les éléments à positionner dans la matrice. Il est pour ce utile de travailler avec
une équipe large qui permettra de multiplier les points de vue.
Pour les facteurs externes, on peut s’appuyer sur différentes méthodologies 5
:
— L’analyse PESTEL (Politique, Économique, Sociologique, Technologique,
Écologique, Légal) permet d’avoir une vision exhaustive de la situation en
évitant d’oublier des facteurs qui pourraient être importants.
— Le modèle des 5 forces de Porter est souvent utilisé dans le domaine du
Conseil. Il s’agit d’identifier l’ensemble des « concurrents » qui pourraient
diminuer la performance qu’on vise :
Concurrence
directe
Nouveaux
Entrants
Produits de
substitution
Fournisseurs Clients
Figure 12.4 – Les 5 forces de Porter.
Comme l’analyse PESTEL évoquée juste avant, les 5 forces de Porter aident
à recenser de façon complète tout ce qui est susceptible d’influencer une
situation. L’addition de grilles d’analyse différentes permet de multiplier
les angles de vue.
Une fois listées les situations à prendre en compte, on pourra réfléchir aux
conséquences qu’elles pourraient avoir sur le Projet, et prévoir des réponses adap-
5. Une description complète sort du cadre de ces notes, mais il est facile de trouver des
informations sur Internet.

12.4. LES MÉTHODES AGILES (SCRUM, SAFE, . . .) 169
tées pour amplifier – dans le cas d’une influence positive – ou limiter – pour une
influence négative – les conséquences.
Les facteurs d’influence listés peuvent alors être classés dans la matrice
SWOT pour servir de base à la définition d’une stratégie dont le principe est
simple. Il s’agit de saisir les opportunités en s’appuyant sur ses forces, tout en
limitant l’impact des faiblesses et en évitant les menaces. Le travail se fait à l’in-
térieur de sa zone d’influence, qu’on va chercher à étendre. On doit se rappeler
qu’on ne peut agir directement que sur les facteurs internes.
12.4 Les Méthodes Agiles (SCRUM, SAFe, . . .)
Les méthodes de gestion de Projet dont on a parlé jusqu’ici sont structurées
selon un processus principalement séquentiel 6
. Une conséquence est que les déci-
sions prises en début de Projet peuvent avoir un impact extrêmement fort par la
suite, alors qu’on a généralement une connaissance limitée du problème à traiter 7
.
En pratique, on ne commence pas une phase sans avoir achevé la précédente.
Cela signifie qu’on prévoit ce qu’on doit obtenir durant la spécification du produit,
mais qu’on ne peut théoriquement vérifier que le résultat est correct que durant
la phase de recette, quand on teste un produit fonctionnel. Même si on essaie de
faire ces tests au plus tôt durant le processus de développement 8
pour limiter les
risques, l’idée reste d’organiser une succession d’étapes chronologiques.
Cette approche implique trois facteurs de complexité principaux :
— Elle demande de faire travailler ensemble des équipes pluridisciplinaires
pour tenter de prendre en compte au plus tôt toutes les contraintes. Cela
est souvent rendu difficile par des différences de culture, de formation, de
vision, d’âge, . . .
— La technologie évolue en permanence. Cela peut avoir deux conséquences
dans le cadre d’un Projet mené traditionnellement :
— Soit on sélectionne initialement des technologies à utiliser, et on s’y tient
tout au long du déroulement. On a alors l’avantage de s’appuyer sur des
concepts qui seront – à priori – mieux maîtrisés, mais on prend le risque
qu’ils soient rapidement obsolètes, et de ne pas obtenir un résultat final
qui soit au niveau de l’état de l’art dans son domaine.
— Soit on essaie de s’adapter à l’évolution, en ajustant au fur et à mesure les
choix technologiques. On s’expose alors à des problèmes dûs au fait qu’on
6. Même si on a souvent expliqué qu’il est intéressant d’itérer, la colonne vertébrale reste une
suite de phases successives.
7. Voir à ce sujet les figures 2.1 et 2.2 au chapitre 2.2.1.
8. Voir le §9.3.3.

n’aura pas toujours une connaissance optimale des techniques qu’on veut
utiliser.
— Enfin, le besoin de l’utilisateur n’est pas toujours parfaitement défini
en début de Projet, parce qu’il (l’utilisateur) n’a justement pas toujours la
connaissance suffisante pour l’appréhender et le définir correctement. On
risque alors de partir sur des bases incertaines. C’est un constat souvent
vérifié dans le cas du développement de systèmes interactifs, pour lesquels
l’incertitude est inévitable puisque le comportement devra nécessairement
dépendre de l’utilisateur et de ses réactions. Le besoin n’est alors pas tou-
jours parfaitement connu avant d’utiliser le produit.
Ce sont, entre autres, ces constats qui sont à l’origine des réflexions sur les
méthodes agiles qui reposent sur un changement de paradigme, en cherchant à
mettre en œuvre des méthodes empiriques, mais pragmatiques. Les activités du
projet ne changent pas, mais c’est la façon dont on les organise qui évolue.
On va présenter brièvement dans ce chapitre deux méthodes agiles de gestion
de Projet.
Ces méthodes sont basées sur le Manifeste Agile 9
qui définit quatre valeurs
et douze principes.
Les valeurs sont :
1. Les personnes et les échanges avant les Processus et les outils
La discussion et les échanges permettent de mieux comprendre le besoin
du client afin de fournir un produit qui correspond réellement au besoin,
sans se laisser enfermer par des règles figées et/ou limité par les capacités
d’outils.
2. Un produit fonctionnel avant la documentation pléthorique
Il vaut mieux se concentrer sur la fourniture d’un résultat qui satisfait les
besoins plutôt que de passer du temps à documenter pour expliquer et
justifier des concepts non fonctionnels.
3. La collaboration du client avant la négociation des contrats
L’implication du client permet de prendre en compte les besoins de manière
plus profitable pour toutes les parties que la définition préalable de règles
de gestion des problèmes.
4. La réactivité au changement plutôt que le suivi d’un plan
L’adaptation au changement est plus pertinente pour supporter les évolu-
tions inhérentes à un processus d’innovation que le suivi d’un plan défini
initialement.
9. Déjà évoqué au §8.1.2, et à voir sur http://agilemanifesto.org/iso/fr/manifesto.html.

On ne nie pas l’importance des éléments de droite dans les affirmations ci-
dessus. Ils sont fondés pour avoir une certaine stabilité; mais on donne la préférence
à ceux de gauche.
Ces valeurs trouvent une traduction concrète dans douze principes de mise
en œuvre :
1. Satisfaire le client en livrant régulièrement des fonctionnalités à
haute valeur ajoutée.
2. Accueillir favorablement le changement.
3. Livrer fréquemment en cycle court.
4. Les utilisateurs et les développeurs doivent travailler ensemble.
5. Réaliser les projets avec des gens motivés.
6. Transmettre l’information en dialogue en face à face.
7. Un produit opérationnel est la principale mesure d’avancement.
8. Le rythme de développement doit être soutenable.
9. Toujours veiller à l’excellence technique et à une bonne concep-
tion.
10. La simplicité est essentielle (minimiser la quantité de travail).
11. Les équipes sont auto-organisées.
12. L’équipe doit réfléchir pour devenir plus efficace.
Cela requiert un management spécifique avec confiance, soutien, respect d’un
rythme de travail soutenable et de l’auto-organisation.
Le planning d’un projet agile ne comporte pas les grandes phases tradition-
nelles. On s’appuie à la place sur deux grands principes :
— Diviser pour mieux maîtriser
Le temps est découpé en intervalles courts (ce seront les itérations) qui
permettent chacun d’obtenir un résultat utilisable (appelé incrément). On
donnera alors la priorité au développement de fonctionnalités à forte valeur
ajoutée au court de chaque itération.
Il sera important de garder à l’esprit la vision globale.
— L’itération
Il ne s’agira pas de réaliser à chaque fois un "mini" cycle en V. On sélection-
nera les éléments depuis une liste de fonctionnalités à réaliser (le Product
Backlog afin de pouvoir réaliser dans le temps imparti et de planifier leur
réalisation. La conception, la réalisation et le test d’éléments unitaires de-
vront toujours aboutir à un résultat utilisable à la fin de l’itération.

12.4.1 La méthode SCRUM
La méthode SCRUM est basée sur les principes qu’on vient d’évoquer et se
distingue par les choix d’implémentation qui sont faits.
C’est un processus qui a été formalisé 10
:
Souhaits des clients,
de l'équipe,
du management, ...
Product Owner
1 -
2 -
3 -
n -
Product Backlog Réunion de planification
du Sprint
Equipe
Equipe
Backlog du Sprint
Sprint
1-4 semaines
Sprint
quotidien
SCRUM Master
Burn Down/Up chart
Réunion
quotidienne
express
Revue du
Sprint
Livrable
exploitable
Rétrospective
du Sprint
Figure 12.5 – Description générale du processus SCRUM.
La figure 12.5 met en évidence les caractéristiques principales de SCRUM
qui structurent le déroulement de la méthode :
En premier lieu, on identifie trois rôles distincts :
Product Owner
Utilisateurs
SCRUM Master Equipe
Equipe
SCRUM
Figure 12.6 – Les trois rôles du processus SCRUM.
— Le SCRUM Master est le garant de la méthodologie.
Il se comporte comme un chef de Projet pour appliquer le processus défini.
Il en est le garant, et peut enseigner les méthodes et avoir une fonction de
coach. Il facilite les interactions entre toutes les parties prenantes du Projet.
10. Voir [15, 14]

— Le Product Owner est le représentant des utilisateurs finaux (les clients). Il
porte la vision du produit dont il doit maximiser la valeur pour les utilisa-
teurs.
— L’équipe développement réalise le travail pour aboutir à un incrément uti-
lisable et potentiellement livrable. Elle est auto-organisée. Personne en lui
indique comment transformer les éléments du Product Backlog en incrément
livrable.
Elle est pluridisciplinaire : elle possède toutes les compétences requises. Cela
la rend souple et résistante à l’imprévu.
Par expérience, une équipe comporte en trois et neuf personnes, pour avoir
toutes les compétences requises, mais garder une taille gérable.
Pour les gros Projets, on mettra en place plusieurs équipes de taille standard
travaillant en parallèle plutôt qu’un groupe plus important qui perdrait en
agilité.
Ensuite, on remarque qu’il existe des concepts spécifiques :
— Le Product Backlog est un inventaire des fonctions que l’on souhaite im-
plémenter dans le produit. C’est une liste ordonnancée qui est compilée à
partir des cas d’utilisation et des souhaits identifiés par les utilisateurs.
On identifie aussi les utilisateurs cibles et les caractéristiques visées.
— Le Sprint correspond à une itération de durée définie et fixe. En début de
Sprint, on sélectionne les éléments qu’on pense pouvoir réaliser durant le
temps imparti. L’objectif est d’aboutir à un incrément, un sous-ensemble
utilisable. Le nombre d’éléments qu’on traite pendant chaque Sprint s’ap-
pelle la vélocité.
Un Sprint a habituellement une durée de quatre semaines maximum. Les
objectifs et les critères de qualité qui leur sont associés sont invariables
durant cette période. Par contre, le périmètre peut être renégocié entre
l’équipe développement et le Product Owner.
Enfin on note que le déroulement est rythmé par cinq évènements :
— Le Sprint, dont on vient de parler.
— La réunion de planification de Sprint qui se tient au début de chaque Sprint.
Sa durée est de une journée au maximum pour un Sprint de quatre semaines.
Elle peut être adaptée pour des périodes plus courtes. Le Product Owner
et l’équipe développement (parfois assistés du Scrum Master) y organisent
le travail à faire en répondant principalement à trois questions :
1. Quel est l’objectif principal du Sprint ?
2. Quels éléments prioritaires du Product Backlog doivent être traités ?
3. Comment va-t-on convertir les éléments sélectionnés en un incrément
utilisable ?

— Le Sprint est rythmé par des réunions quotidiennes : les Daily meetings (ou
Mélée quotidienne). Elles durent quinze minutes au maximum et servent à
organiser très rapidement le travail de chaque journée. L’équipe de dévelop-
pement y indique ce qu’elle pense réaliser, ainsi que les difficultés auxquelles
elle fait face pour que tout le monde puisse chercher des solutions.
On se base pour cela sur trois questions :
1. Qu’ai-je fait hier qui me rapproche de l’objectif du Sprint ?
2. Que vais-je faire aujourd’hui ?
3. Quels sont les obstacles qui pourraient empêcher d’atteindre l’objectif ?
— La Revue de Sprint est une réunion de clôture du Sprint qui permet à
l’équipe de développement et au SCRUM Master de présenter les résultats
au Product Owner.
D’une durée limitée à une demi-journée environ, elle est importante pour
renforcer la collaboration et la qualité du travail commun. On y analyse
les difficultés rencontrées, avec un objectif d’amélioration continue. On fait
aussi un point sur l’avancement, et on prépare le Sprint suivant en tenant
compte du retour d’expérience.
— Enfin, le Sprint se termine par la rétrospective, qui est une réunion de ca-
pitalisation pour bénéficier du retour d’expérience.
Il s’agit d’un moment d’introspection pour l’équipe au complet, qui s’ins-
pecte elle-même pour s’améliorer et mettre en place des actions d’amélio-
ration. Sa durée est elle aussi limitée à une demi-journée.
Cela étant posé, il faut dire quelques mots sur le management d’un Projet
selon la méthode SCRUM.
Le processus est formalisé sur la base des concepts dont on vient de parler,
mais son animation se fait sur la base de trois piliers qui font partie intégrante de
la méthode :
— La transparence, qui signifie que les informations doivent être accessibles
à toutes les parties concernées, et que les relations doivent reposer sur la
confiance et la bienveillance 11
. La transparence permet de rendre les pro-
blèmes visibles.
— L’inspection consiste à analyser à intervalles réguliers que le Projet est en
phase avec les demandes du client, représenté par le Product Owner. Cela
permet d’identifier au plus tôt tout risque de dérive et de réagir rapidement.
— L’adaptation constitue justement le processus de réponse quand un écart
est constaté. il faut encourager l’équipe à corriger les problèmes plutôt que
chercher à les masquer.
11. Des notions qu’on a déjà citées dans le cadre du fonctionnement d’une équipe Projet « stan-
dard ».

Les trois piliers constituent des principes qui guident le chef de Projet (le
SCRUM Master) pour orienter le travail. On ne parle pas à proprement parler de
pilotage, parce que SCRUM est une méthode empirique. Cela signiﬁe que c’est
l’inspection quotidienne qui va orienter les décisions pour agir en fonction de faits
et non un plan préétabli qui ne serait pas le mieux adapté. On procède donc par
essais successifs en appliquant les trois principes pour converger vers une solution
satisfaisante.
Il ne s’agit pas d’une perte de temps, chaque cycle permet d’apprendre et de
renforcer sa connaissance du problème traité et de la méthode de travail.
Le suivi de l’avancement est primordial pour déterminer les retards qui se-
raient en train d’apparaître. Il est basé sur un indicateur ﬁable : le produit lui-
même, qui est constitué d’une somme de fonctionnalités ajoutées au fur et à mesure.
On peut alors construire deux courbes :
— L’avancement à court terme est suivi grâce à l’indicateur d’avancement du
Sprint qui permet de tracer le Burn-Down Chart :
10
20
30
40
50
60
70
Resteàfaire
Sprint 1 Sprint 2 Sprint 3 Sprint n...
Avancement théorique
Avancement réel
Avance
Retard
Figure 12.7 – Le graphique d’avancement décrivant le reste à faire.
La courbe bleue est basée sur la vélocité théorique et correspond à un
avancement nominal du Projet : l’équipe de développement livre les éléments
du Product Backlog au rythme prévu en début de processus.
La courbe jaune correspond aux éléments restants dans le Product Backlog
après chaque Sprint.
On sera donc en avance si la courbe jaune est en-dessous de la courbe bleue
(c’est-à-dire qu’on aura traité plus d’éléments que prévu), et en retard sinon.

On trace souvent au départ deux courbes de référence (bleues) qui corres-
pondent à des prévisions pessimistes et optimistes du déroulement du Pro-
jet. Elles forment le cône d’incertitude qui doit se rétrécir quand le Projet
avance et donc la connaissance progresse. Cela se fait en étudiant l’histo-
rique de vélocité – le nombre d’éléments livrés à chaque Sprint – qui permet
de calculer la vélocité moyenne de l’équipe développement et d’affiner ainsi
la prévision.
Pour ces calculs, on utilisera évidemment l’unité de charge élémentaire qui a
permis d’estimer le coût de chaque élément du Product Backlog afin d’éva-
luer de manière objective des éléments qui n’ont pas forcément le même
poids.
— L’avancement à long terme est visualisé grâce à un second graphique : le
Burn-Up Chart :
10
20
30
40
50
60
70
Backlogàréaliser
Sprint 1 Sprint 2 Sprint 3 Sprint n...
Backlog actualisé
Avancement cumulé
11
28
42
Figure 12.8 – Le graphique d’avancement indiquant le travail réalisé.
La courbe bleue représente le volume total du Product Backlog. Il peut évo-
luer, normalement à l’initiative du Product Owner, quand des fonctionnali-
tés sont ajoutées, ou supprimées, à l’occasion des réunions de planification
de Sprint ou des rétrospectives.
La courbe jaune indique les éléments livrés – c’est-à-dire complètement
terminés – à chaque fin de Sprint. C’est une courbe cumulative. L’objectif
est de l’amener le plus rapidement possible au niveau de la courbe bleue.
Le chef de Projet devra par contre s’attacher à ce que tout le monde soit
suffisamment sensibilisé à la méthode, pour que les itérations ne soient pas ressen-

ties comme des échecs. Il devra donc être particulièrement vigilant pour mettre en
place une communication efficace :
— En se reposant sur un langage commun, qui soit partagé par tous les acteurs.
— En utilisant un management visuel, qui permettra de donner une informa-
tions claire et accessible. Elle doit être libre d’accès pour favoriser la trans-
parence. Il faut par contre s’assurer qu’elle est pertinente et utile, pour ne
pas diluer les messages.
— Elle doit être bienveillante et conviviale, pour encourager les personnes à
exprimer leurs problèmes qui ne doivent pas rester sans attention.
Le succès d’une démarche SCRUM se construit principalement à l’occasion
des évènements, en particulier durant la préparation des Sprints.
L’objectif est à ce moment de décider ce qui pourra être traité durant la
séquence à venir. On se base pour cela sur deux éléments :
— L’estimation des charges de travail requises pour chaque fonctionnalité listé
dans le Backlog.
— La quantité de travail que l’équipe développement estime pouvoir réaliser
durant un Sprint.
Ces deux données sont déterminées collectivement en se basant sur les connais-
sances et l’expérience de l’équipe. Elles permettent, en début de Projet, de déter-
miner le nombre théorique de Sprints qui seront nécessaires pour réaliser tout ce
qui est demandé.
On remarque alors la nécessité d’un mécanisme d’adaptation pour tenir
compte des cas où de nouveaux besoins pourraient apparaître à l’occasion des
réunions de l’équipe, en particulier avec le Product Owner.
La méthode SCRUM propose à cet effet une réponse élégante, compatible
avec l’exigence d’invariabilité de la durée des Sprints : le troc. Il s’agit – avant
que le Sprint n’ait débuté, car son contenu doit rester constant – d’échanger un
élément de son Backlog avec un autre qui représente la même charge de travail.
On souligne alors l’importance d’une estimation partagée 12
de la charge re-
quise pour traiter chaque élément du Product Backlog.
Une technique répandue d’estimation des charges est le planning poker.
La technique repose sur l’utilisation de cartes dotées d’une valeur 13
crois-
sante qui permettront d’attribuer des points aux éléments du Product Backlog.Le
déroulement se fait alors comme suit :
— Le Product Owner présente un élément du Product Backlog.
12. Partagée plutôt qu’exacte, parce que cela reste une estimation. On pourra rarement être
certain de l’exactitude, mais une valeur partagée donne une référence qui s’appliquera à tous, y
compris pour le Product Owner.
13. Par exemple celles de la suite de Fibonacci {Fn}∞
n=1 avec Fn = Fn−1 + Fn−2. Cette suite
permet de définir des « poids » croissants qui s’éloignent de plus en plus.

— Chaque participant choisit une carte dont la complexité correspond à la
fonctionnalité.
— Tout le monde retourne sa carte en même temps pour ne pas influencer. Les
estimations éloignées doivent être expliquées et tendre vers un compromis
si possible.
— On fait plusieurs tours pour converger.
Le Product Owner peut alors ordonnancer son Product Backlog et planifier
les versions du produit.
L’intégralité du Product Backlog est estimé au début pour déterminer com-
bien de points peuvent être traités à chaque sprint et le nombre de sprints.
La méthode SCRUM, comme beaucoup de méthodes agiles, offre des avan-
tages par rapport à un processus de développement classique.
La structuration en Sprints permet d’avoir une meilleure visibilité en évitant
l’Effet Tunnel 14
. La valeur est créée plus tôt et régulièrement grâce à l’odonnan-
cement du Product Backlog et aux incréments.
Les risques sont levés, ou du moins réduits, dès les premières itérations grâce
aux revues avec les utilisateurs.
Les changements en cours de Projet sont plus faciles en mode Agile. Seul le
périmètre du Sprint est fixé.
Les délais de livraison son fortement réduits parce que l’équipe se concentre
sur une approche minimaliste 15
pour adresser les besoins essentiels au client. Cela
permet de livrer rapidement un produit avec des fonctions utiles qui permet :
— De vérifier la pertinence du produit.
— D’obtenir des gains au plus vite.
— De recueillir du feedback.
— D’accroître la motivation de l’équipe.
Ce dernier point est intéressant, parce que l’agilité repose généralement sur
la confiance accordée aux individus. Le fait qu’ils estiment eux-même la charge de
travail à réaliser et qu’ils gèrent leur organisation renforce la responsabilisation.
Enfin, SCRUM intègre un droit à l’erreur : le fait de se tromper lors d’un
Sprint est une occasion d’apprendre, et permet de tirer des enseignements pour
les itérations suivantes. Cela favorise l’innovation. Ce rythme cadencé est propice
à l’expérimentation.
SCRUM est donc une méthode intéressante qui est de plus en plus utilisée.
On lui reproche parfois de ne pas être suffisamment structurée pour les très gros
15. Une sorte de LEAN. . .

Projets. Certaines méthodes agiles ont été développées pour cette raison tel le
Scaled Agile Framework - SAFe.
12.4.2 La méthode SAFe R
SAFe 16
est un cadre dont l’objectif est d’étendre les méthodologies agiles
aux grandes organisations.Il vise à permettre de livrer de nouveaux produits, ou
services, avec les meilleures qualités et valeurs possibles et dans un temps minimal.
SAFe est décrit de façon approfondie sur le site www.scaledagileframework.com
qui présente des posters de synthèse pour la méthode 17
. On y trouvera par exemple
celui décrivant la version la plus complète :
Figure 12.9 – Le poster de la méthode SAFe la plus complète.
SAFe combine des principes agile et Lean dans une démarche d’Ingénierie
16. SAFe R est une marque déposée, on le dit mais je ne mettrai plus le R partout pour ne
pas surcharger.
17. Ces posters sont en fait des images cliquables qui renvoient vers une documentation très
complète des diﬀérents éléments de la méthode.

Système 18
.
La méthode est basée sur la synchronisation de multiples équipes agiles pour :
— La planification.
— La collaboration.
— La production et la livraison.
Les configurations de SAFe
SAFe propose quatre configurations qui permettent de couvrir un large spectre
de situations :
— Essential SAFe constitue la base de la méthode et décrit les éléments
essentiels pour en tirer des bénéfices.
— Portfolio SAFe est utile pour aligner l’exécution d’un portefeuille de Pro-
jets avec la stratégie de l’entreprise. Cela se fait en organisant les déve-
loppements Agiles selon les flux de valeur. Le cadre fournit des principes
pour une stratégie de gestion de portefeuille, le financement, le pilotage de
programme Agile et la gouvernance Lean.
— Large Solution SAFe est une variante pour les projets complexes avec
plusieurs groupes d’équipes travaillant en parallèle et de multiples fournis-
seurs, mais qui ne demandent pas de gestion de portefeuille de solutions.
— Full SAFe est la version la plus complète du framework. Elle est destinée
aux entreprises qui gèrent de très grands Projets, impliquant des centaines
de personnes avec différents niveaux de gestion (équipes, programmes, so-
lutions et portefeuille de solutions). Plusieurs instances de différentes confi-
gurations de SAFe peuvent être nécessaires pour de très gros Projets.
Essential SAFe Essential SAFe est l’implémentation la plus simple de la mé-
thode. Elle est combine les niveaux équipe et programme pour apporter les élé-
ments critiques de la méthode et obtenir les principaux bénéfices.
L’équipe et le programme forment ensemble une structure organisationnelle
– le Agile Release Train (ART) – qui dédie des moyens à une mission importante
pour la solution. Un ART délivre des incréments de valeur testés toutes les deux
semaines. Les Program Increments (PI) constituent des échéances de cadencement
plus espacées.
Les solutions peuvent être livrées sur demande, pendant ou à la fin d’un PI,
selon les besoin du client.
ART utilise la mise en cohérence de plannings de PI pour assurer la col-
laboration et l’alignement. Il met en place un pipeline continu de livraison pour
18. Voir à ce sujet le chapitre 12.5.

développer et livrer régulièrement de petits incréments de valeur. ART fournit une
approche standardisée de l’expérience utilisateur grâce aux principes du Lean UX.
Des DevOps 19
supportent la communication, l’intégration, et la coopération de
tous les intervenants.
Les rôles suivants aident à aligner des équipes multiples sur une mission et
une vision commune :
— System Architect/Engineer : ils utilisent l’ingénierie système pour définir
l’architecture du système et aident à définir les exigences dérivées non-
fonctionnelles.
— Product management : ils représentent la Voice of customer pour com-
prendre les besoins, définir les fonctionnalités système et participer à la
validation.Ils sont responsables du Program Backlog.
— Release train Engineer : c’est le SCRUM Master du ART. Ils aident à
améliorer le flux de valeur.
— Business Owners : ils sont responsables du RoI des solutions développées
par un ART.
— Client : ils sont les décideurs ultimes de la valeur. Ils ont des responsabilités
spécifiques dans SAFe.
Essential SAFe est basée sur dix éléments essentiels :
— Les principes Lean-Agile.
— De véritables équipes agiles et ART.
— Le cadencement et la synchronisation;
— Le planning des PI (évènement le plus important de SAFe).
— Les DevOps et la disponibilité.
— Les démonstrations du système toutes les deux semaines.
— L’inspection et l’adaptation.
— L’itération Innovation et Planning.
— La préparation de l’architecture.
— Le Lean-Agile leadership.
Portfolio SAFe Le Portfolio SAFe permet d’aligner l’exécution d’un portefeuille
de solutions avec la stratégie d’entreprise en organisant le développement Agile
autour de flux de valeur.
Les points essentiels sont :
— Les budgets Lean permettent des décisions rapides et fiables avec la respon-
sabilisation liée.
— Les flux de valeur sont financés et fournissent des systèmes qui délivrent
continuellement de la valeur.
19. Équipes intégrées de développement et d’administration des infrastructures;

— Le Kanban du portefeuille rend l’activité du portefeuille visible et crée des
limites sur le Work-In-Progress pour que la demande n’excède pas les ca-
pacités de production.
Les rôles suivants sont essentiels :
— Management Lean du portefeuille. Ce sont les décideurs exerçant les plus
hautes responsabilités, responsables de trois domaines :
— Le financement de la stratégie et de l’investissement.
— La conduite agile du programme.
— La gouvernance Lean.
— Les propriétaires d’Epics sont responsables de la coordination d’Epics de
portefeuille grâce au Kanban du portefeuille.
— L’architecte d’entreprise fournit une direction technique stratégique pour
optimiser les résultats du portefeuille. Il est souvent le propriétaire d’Epics
enablers.
Large Solution SAFe La configuration Large Solution SAFe est adaptée au
développement de solutions importantes et complexes qui nécessitent généralement
plusieurs ART mais pas de gestion de portefeuille.
Les éléments notables sont :
— Le Solution Train qui est l’élément d’organisation clé en permettant d’ali-
gner tous les intervenants sur une vision, une mission et un Backlog com-
muns.
— Le fournisseur est une organisation interne ou externe qui développe et livre
des composants, des sous-systèmes ou des services qui aident les Solution
Trains à fournir des solutions aux clients.
— Le cadre économique fournit les limites qui s’appliquent lors des prises de
décision.
— Le Solution Intent est un dépôt pour les comportements actuels et futurs
de la solution, qui peuvent être utilisés pour la vérification, la validation et
la conformité. Il est utilisé pour la mise en œuvre de pratiques de qualité
intégrée avec les disciplines d’ingénierie système.
— Le contexte de solution décrit comment le système s’interfacera avec l’en-
vironnement, et comment il sera packagé et déployé.
— Le Solution Kanban permet de visualiser et de fluidifier le flux des outils et
des enablers pour la solution.
Large solution SAFe s’appuie aussi sur certains rôles pour aligner de multiples
ARTs et fournisseurs :
— L’architecte/ingénieur de solution définit une vision technique et architec-
turale de la solution.

— Le manager de solution a une responsabilité sur le contenu de la solution.
Il travaille avec les clients pour comprendre leurs besoins.
— L’ingénieur Solution Train facilite et guide le travail de tous les ARTs et
fournisseurs.
Trois activités majeures permettent de coordonner de multiples ARTs et
fournisseurs :
— Pre- et Post-PI planning sont des évènements utilisés pour préparer et
suivre les PI plannings dans un Solution Train.
— La démonstration de solution permet de monter aux clients une solution
fonctionnelle.
— L’inspection et l’adaptation est un évènement durant lequel l’état des flux
de valeurs d’une solution est exposé et évalué. Les représentants de tous les
ARTs et les fournisseurs se réunissent pour analyser et identifier les éléments
du Backlog dans une démarche structurée de résolution de problèmes.
Full SAFe La configuration Full SAFe est la plus complète, et inclut tous les
niveaux de SAFe. Elle est destinée aux entreprises qui développent et maintiennent
des solutions complexes et intégrées qui nécessitent des équipes de plusieurs cen-
taines de personnes.
Les éléments constitutifs de SAFe
Toutes les configurations peuvent faire usage en fonction des besoins des
éléments qui sont listés dans la palette à gauche (la Spanning Palette en version
originale), et s’appuyer sur les principes fondamentaux qui apparaissent dans le
cadre inférieur du poster SAFe (figure 12.9).
La Spanning Palette Elle contient les rôles et artefacts qui peuvent être utilisés
quelque soit la configuration SAFe choisie. On y retrouve :
— La Vision qui décrit la solution à développer, en mettant en évidence les
besoins des clients et les fonctionnalités envisagées pour y répondre.
— L’Équipe Système qui aide à mettre en place l’environnement agile.
— Le Lean UX consiste à appliquer les principes du Lean à la conception de
l’expérience utilisateur (inspiré du Design Thinking 20
).
20. Une méthode visant à favoriser l’innovation, structurée en cinq étapes :
— Empathize
— Define
— Ideate
— Prototype

— Les indicateurs (Metrics) permettent une évaluation continue de l’avance-
ment en plus de la livraison des solutions fonctionnelles.
— Les services partagés représentent les rôles de spécialistes requis pour
développer des solutions mais qui ne peuvent pas y être dédiés à plein
temps.
— Les CoP ou Community of Practice – Communautés métiers – sont des
groupes informels qui partagent des connaissances et savoir-faires.
— Les Milestones sont des jalons qui peuvent être planifiés ou correspondre
à des objectifs ou évènements spécifiques.
— La Roadmap permet de partager le calendrier des livrables et des jalons.
Les principes fondamentaux Ils sont présentés dans le cadre inférieur du poste
SAFe :
— Les Lean-Agile leaders sont les managers qui doivent maîtriser les prin-
cipes agiles et Lean.
— Les Core Values sont au nombre de quatre : alignement, qualité intégrée,
transparence et exécution de programme.
— L’Etat d’esprit Lean-Agile.
— Les neuf principes SAFe inspirent et guident les différents acteurs.
— La Roadmap d’implémentation guide les organisations pour la trans-
formation Lean qu’elles ont à effectuer.
— Les SPC – SAFe Program Consultant – facilitent la conduite du change-
ment grâce à leur connaissance technique de SAFe et à la volonté d’améliorer
les produits et processus de l’organisation.
Les leaders Lean-Agile Les cadres, les leaders et les managers de l’en-
treprise sont responsables de l’adoption et du succès du Lean-Agile. Il doivent être
formés à ces modes de pensée Lean.
Ils doivent avoir certains comportements :
— Piloter le changement : ils définissent un plan et gèrent les problèmes. Les
leaders doivent connaître le management de la conduite du changement et
adopter une vue systémique.
— Test
Il s’agit d’un processus de type agile durant lequel on capte le besoin et l’état d’esprit des
utilisateurs (Empathize), pour établir la meilleure manière d’aborder le problème (Define). On
passe ensuite à une phase de génération d’idées Ideate, qui sont rapidement mise en pratique
(Prototype) puis testées (Test). L’objectif est d’obtenir rapidement des retours utilisateurs pour
affiner les idées et en générer de nouvelles.

— Connaître le chemin, apprendre en permanence : ils doivent mettre en place
un environnement qui encourage l’amélioration continue, et inciter les per-
sonnes à partager avec les clients et les fournisseurs. Il doivent être en veille
permanente.
— Développer les personnes : il faut se concentrer sur le développement des
compétences et encourager la collaboration.
— Inspirer et aligner sur la mission : il doivent proposer une vision inspirante
et éliminer ce qui est démotivant.
— Décentraliser la prise de décision pour développer les personnes.
— Révéler le potentiel intrinsèque des personnes en supprimant les compéti-
tions internes et en favorisant la coopération. ils fournissent un but aux
personnes.
Les valeurs de base Quatre valeurs définissent un référentiel pour la mé-
thode SAFe.
— L’Alignement vise à coordonner le management et les équipes vers un ob-
jectif commun en faisant en sorte que tout le monde comprenne la stratégie
et le rôle qu’il a à jouer pour l’appliquer.
— La Qualité intégrée permet de rendre déterministe le processus de créa-
tion de valeur en minimisant les aléas et les risques. Elle favorise l’innovation
et la prise de risques maîtrisés et garantit que tous les éléments de solution,
à chaque incrément, sont conformes aux standards attendus.
— La Transparence est une valeur fondamentale des méthodes agiles, et vise
à bâtir la confiance. Elle est essentielle pour permettre d’être performant,
en libérant les personnes qui peuvent prendre des décisions à leur niveau et
sont plus engagées dans le Projet.
— L’Exécution du programme doit se faire selon des principes du Lean et
permettre une adaptation rapide aux changements.
Ces valeurs visent à casser les silos en mettant en place des équipes agiles
stables : les Agile Release Trains (ART). Ces structures travaillent selon
un mode réseau, affranchi des contraintes hiérarchiques formelles. Elles s’auto-
organisent et s’auto-gèrent. Cela permet de réduire la complexité des chaînes de
décision et de circulation de l’information (voir la figure 12.10).
L’esprit Lean-Agile Les leaders Lean-Agile doivent avoir une démarche
d’apprentissage permanent pour eux-mêmes, et de formation pour les autres. Cet
état d’esprit est résumé dans la Maison du Lean et s’appuie sur une partie du
Manifeste Agile 21
(figure 12.11).
21. Voir http://agilemanifesto.org/iso/fr/manifesto.html.

Figure 12.10 – Un ART est une organisation multidisciplinaire qui brise les silos
et optimise la création de valeur.
Figure 12.11 – Les composantes de l’état d’esprit Lean-Agile.
Cette dernière ﬁgure résume les concepts importants :
— La Valeur représente l’objectif à atteindre grâce à l’attention portée aux
employés et à la satisfaction du client. Elle est supportée par quatre piliers :
1. Le respect pour les personnes et leur culture consiste à leur donner les
moyens de progresser, tout en alignant tout le monde sur des principes
communs.
2. Le ﬂux de travail doit être continu et permanent.
3. L’innovation est permise par la mise en place de moments dédiés favo-
risant la liberté de recherche (Innovation and Planning – IP).
4. L’amélioration continue doit être une démarche volontaire et perma-
nente pour saisir les opportunités de progrès, et répondre rapidement

au changement.
— Le leadership est à la base de la Maison du Lean. Les leaders sont formés
et affichent ces valeurs et principes
Le Manifeste Agile définit un cadre global pour les démarches agiles, basé
sur un système de valeurs (voir la figure ci-dessus), et douze principes 22
.
Les principes de SAFe SAFe s’appuie sur neuf principes qui sont is-
sus des pratiques et des méthodes agiles, du développement Lean, de l’approche
système et de l’observation des pratiques à succès des entreprises.
1. Adopter une vision économique permet de prendre les bonnes décisions
en fonction du contexte et de construire un cadre qui définit des éléments
de décisions utiles lors des trade-offs.
2. L’application de la pensée système est utile pour gérer la complexité
des situations qui dépendent de contraintes et de facteurs multiples. Cette
démarche est appliquée dans SAFe à la fois au produit développé et à l’or-
ganisation qui le développe pour prendre en compte tout le contexte de
l’utilisateur final.
3. Assumer la variabilité, préserver les options permet de conserver des
alternatives de conception plus longtemps qu’avec un processus de déve-
loppement traditionnel où on choisit très tôt une hypothèse qui peut être
coûteuse à corriger si elle s’avère erronée.
4. Construire rapidement de manière incrémentale, avec des cycles
intégrés d’amélioration permet de livrer à chaque fois un incrément fonc-
tionnel du système (les Minimum Viable Product ou MVP) qui permet de
tester et valider la solution et représente un point de réorientation si néces-
saire.
5. Des jalons basés sur une évaluation objective de systèmes fonc-
tionnels permettent de mettre en place une responsabilité partagée et une
gouvernance du Projet orientée vers les objectifs.
6. La visualisation et la limitation des travaux en cours, la réduction
des lots de travaux et la gestion des Backlogs visent à maintenir un
flux de travail continu qui permet d’apporter rapidement les fonctionnalités
requises au système.
7. Cadencer le rythme et synchroniser les plannings entre tous les
domaines apporte de la prévisibilité et la compréhension des différentes
perspectives du Projet.

8. Révéler le potentiel des intervenants augmente l’implication et la per-
formance collective.
9. Décentraliser la prise de décision permet d’être réactif et de maintenir
le flux de travail. Les décisions prises au plus près de l’action augmentent
l’innovation. Elles rentrent dans un cadre qui donne de la cohérence quand
elles doivent s’inscrire dans une stratégie globale.
SAFe est donc un cadre très structuré pour tenter de déployer des méthodes
agiles à grande échelle. Cette structuration importante est d’ailleurs au centre des
critiques qu’elle subit : il est reproché à SAFe de ne pas être une méthode agile,
parce qu’elle ne laisse aucune place à l’imprévu et à l’inconnu.
On ne rentrera pas plus dans ces débats, mais il est bon de savoir qu’ils
existent.
On vient d’aborder rapidement les méthodes agiles, et on aura remarqué qu’il
est souvent question d’Ingénierie Système. On va donc développer un peu ce sujet
qui prend lui aussi de plus en plus d’importance.
12.5 L’Ingénierie Système
Beaucoup de Projets s’intéressent aujourd’hui à la conception de systèmes qui
sont de plus en plus complexes. Ils font intervenir de nombreuses parties prenantes,
et subissent l’influence de beaucoup de facteurs externes.
Cette complexité a pu se traduire de différentes manières :
— Des produits 23
créés qui ne répondent pas aux besoins des clients parce
qu’ils ont été mal compris ou interprétés.
— Les Projets durent de plus en plus longtemps, ce qui nuit à la réactivité.
— Les produits créés sont plus complexes qu’ils ne le devraient parce qu’ils
doivent être modifiés en permanence pour tenir compte d’exigences non
anticipées.
Ces exemples ont fait ressortir le besoin de nouvelles méthodes de travail
pour le développement.
On présente donc ici quelques points importants, mais ceux qui sont intéressés
pourront lire avec profit les ouvrages de référence sur le sujet. Sans prétendre être
exhaustif, on renverra vers [9], [3] et [1].
23. On parle de produits au sens large, il peut s’agir de produits physiques ou intellectuels.

12.5. L’INGÉNIERIE SYSTÈME 189
12.5.1 Qu’est-ce qu’un système ?
Selon l’AFIS, un système est « Un ensemble d’éléments en interaction entre
eux et avec l’environnement, intégré pour rendre à son environnement les services
correspondants à sa finalité ».
On comprend donc qu’il s’agit d’un tout, composé de parties qui dialoguent
entre elles et avec l’extérieur, qui fonctionne dans un but défini. Cette définition a
plusieurs conséquences :
— Un système a un objectif précis, qu’il faudra donc connaître et comprendre
pour pouvoir y répondre efficacement. Le besoin devra être décrit précisé-
ment, via des exigences 24
.
— Le système intègre plusieurs composantes, qui feront généralement appel à
des disciplines différentes. Il y a donc la nécessité de mener des études de
développement dans plusieurs domaines, et de s’assurer de la coordonner à
la fois temporellement (pour maîtriser et réduire les délais), et technique-
ment (pour que ces composants dialoguent et collaborent entre eux afin de
remplir l’objectif global.
Un système est donc un ensemble cohérent de composants qui sont liés par
des interfaces. Cette structure impliquera très rapidement une augmentation de la
complexité en raison des dépendances mutuelles dont on devra tenir compte lors
de la conception.
Un système est défini par plusieurs caractéristiques :
— Son but, qui correspond à sa raison d’être.
— Sa limite, qui le sépare de son environnement.
— Les liens qu’il entretient avec des entités identifiées de son environnement.
— Son organisation, qui décrit son fonctionnement interne.
Les caractéristiques listées ci-dessus permettent de définir deux visions du
système.
Une vision boîte noire correspond aux trois premiers points. On observe le
système comme un tout, en s’intéressant à ses interactions avec son environnement,
sans connaître son fonctionnement interne.
Une vision boîte blanche, où on examine l’intérieur du système pour décrire
son organisation et son fonctionnement.
24. Voir le chapitre 6.

Système Système
Environnement Environnement
Vue Boîte noire Vue Boîte blanche
Figure 12.12 – Les vues boîte noire et boîte blanche.
Ces deux vues illustrent un principe fondamental de l’ngénierie Système :
l’abstraction. En fonction du niveau d’information et de compréhension dont on a
besoin pour réaliser une tâche spécifique, ou quand on a un rôle défini, on utilisera
un niveau de représentation adapté du système, qui constitue un modèle.
12.5.2 La démarche d’Ingénierie Système
L’Ingénierie Système est une démarche pluridisciplinaire structurée qui couvre
tout le cycle de vie d’un produit pour traduire les besoins et les contraintes en un
produit qui les satisfait au mieux 25
Il s’agit donc d’un concept et d’un ensemble de méthodes qui permettent
d’atteindre les objectifs qu’on s’est fixés.
Le processus se compose généralement des étapes suivantes :
— La définition du système.
— L’analyse des relations avec les parties prenantes.
— La définition de fonctions permettant de répondre au besoin.
— La structuration en modules.
Ces activités constituent la phase d’architecture du système. Elles sont sou-
vent supportées par des diagrammes formalisés, qui constituent un langage codifié
permettant de partager l’information 26
. On ne traitera pas ici de tout cela en dé-
tail, de nombreux livres existent – dont certains listés dans la bibliographie – et
on se limitera à une brève introduction.
25. On trouvera une définition normalisée dans [9] ou dans [5], exemples parmi d’autres.
26. On pourra voir par exemple la méthode du CESAMES.

La définition du système et des parties prenantes
La première étape du processus consiste à définir ce qu’on va considérer
comme système à étudier. Cela correspond en pratique à choisir ce qui va constituer
la frontière du système, et donc ce qui sera à l’intérieur et ce qui sera à l’extérieur.
Cette affirmation peut apparaître triviale, mais elle a de fortes implications
sur ce qui sera développé. Quel que soit le système choisi, il devra répondre aux
besoins et contraintes de son environnement (vision boîte noire). La conception
interne devra être faite en conséquence, et les options seront limitées au domaine
qu’on aura délimité préalablement. Cela ne sera pas forcément gênant pour un
système simple, mais dans le cas de problème complexe, on pourra passer à côté
d’opportunités d’amélioration et d’optimisation.
On peut prendre comme exemple la conception d’une solution de transport.
Si on considère comme système le véhicule, on sera contraint par les voies de
circulation possibles, l’offre de carburant existante, etc. . .
Si on choisit d’étudier la solution globale, on pourra travailler à la fois sur le
véhicule, les voies de circulation, ainsi que les stations de départ et d’arrivée. On
pourra alors réfléchir à des optimisations en allouant certaines fonctions à l’un ou
l’autre de ces sous-systèmes suivant les avantages que cela pourra apporter. On
augmentera donc les possibilités, mais en augmentant la complexité en contrepar-
tie 27
.
La définition du système doit se faire en fonction des objectifs qu’on vise
à atteindre pour qu’il puisse constituer un élément intégré qu’on peut étudier
comme un composant. On devra alors étudier les relations avec toutes les parties
prenantes, pour déterminer leurs besoins et l’influence qu’elles pourront avoir sur
le système.
L’analyse des relations avec les parties prenantes
Le système une fois délimité il faut faire l’inventaire exhaustif de toutes les
parties prenantes qui interagissent avec lui. On pourra distinguer :
— Les acteurs, qui agissent sur ou avec le système, pour le piloter ou l’utiliser
pour tirer parti de ses capacités.
— Les systèmes externes, qui influencent ou qui contraignent. On peut citer
par exemple l’environnement – au sens physique – qui peut imposer des
conditions de température, ou une énergie spécifique à utiliser.
— Les clients, qui tirent parti du système, sans l’influencer de manière active,
mais qui ont des besoins que le système doit satisfaire.
27. On cherche dans un certain sens à optimiser, ce qui suppose de rechercher le meilleur
compromis en dégradant certains paramètres pour en améliorer d’autres.

Cette liste se construit en examinant tout ce qui est en interaction avec le
système qu’on étudie. On pourra distinguer différents types, en lien avec les parties
prenantes (voir la figure 12.13).
Système
externe
Système
externe
Système
Client
Acteur
Besoin
Service
Contrainte
Contrainte
Contrainte
Figure 12.13 – Les différents types de relations du système avec son environne-
ment.
L’objectif est d’avoir une vision complète du système dans son environne-
ment. C’est une étape majeure du processus parce qu’elle doit permettre de tout
prendre en compte pour obtenir la meilleure définition possible. Elle permet de
définir la spécification 28
du système qui listera l’ensemble des besoins qui devront
être satisfaits, et des contraintes qui pèseront sur le système.
La définition de fonctions
Une fois les besoins et les contraintes clairement identifiés, on va définir les
fonctions du système qui sont nécessaires pour y répondre.
Le principe est de partir des relations du système avec son extérieur, pour
commencer par la définition de fonctions de service, qui ont une valeur directe
pour le client. On étudiera ainsi, pour chaque fonction :
28. Sujet déjà abordé sous un angle un peu différent au chapitre 6.

— Ses entrées (il peut s’agir de données et d’informations, d’un état initial du
système. . .).
— La description de son rôle, de sa finalité.
— Ses sorties.
On commencera par une analyse de haut niveau, avec des fonctions assez gé-
nérales, puis une démarche itérative permettra d’affiner la description en décrivant
des sous-fonctions plus élémentaires qui permettront de construire celles de niveau
supérieur :
Besoin
Fonction
Fonction
Fonction
Fonction
Figure 12.14 – On identifie les fonctions qui permettent de répondre aux besoins..
Quelques critères permettront d’orienter le travail et d’évaluer la qualité du
résultat :
— Les fonctions définies auront une forte cohésion interne. Elles seront consa-
crées à une seule opération, et pourront être optimisées pour celle-ci.
— Le couplage entre sous-fonctions sera faible, c’est-à-dire qu’elles seront in-
dépendantes au niveau de leur fonctionnement interne, les liens uniques
étant leurs entrées et leurs sorties. On limitera les interfaces à ce qui est
strictement nécessaire.
— Les exigences de performances seront réparties de manière équilibrée entre
les sous-fonctions, ce qui pourra permettre des optimisations du système
global en les distribuant sur différents composants.
L’analyse fonctionnelle doit descendre à un niveau de granularité suffisam-
ment précis pour que chaque fonction définie soit aisément compréhensible et maî-
trisable. En pratique, chaque fonction devrait réaliser une opération unique (mo-
dulo la préparation éventuelle de données qu’elle serait la seule à devoir faire). Cela

permet de définir des fonctions élémentaires qui pourront être mutualisées entre
différents composants ou fonctions de niveau supérieur.
Cette analyse pourra donner lieu à des comparaisons entre différentes alter-
natives pour rechercher le meilleur compromis.
Il faudra à ce stade être attentif à ce que l’ensemble de fonctions défini couvre
tous les besoins des parties prenantes. C’est l’un des objectifs d’une démarche
structurée comme l’Ingénierie Système.
On pourra ensuite étudier en détail les interactions entre les fonctions, qui se
matérialiseront par les flux d’information et d’objets entre elles. Cela permettra de
caractériser de manière plus précise le comportement des fonctions, et de modéliser
la dynamique de leurs états qui changeront en fonction des données en entrée.
L’ensemble de ces informations sont synthétisées sur des diagrammes qui
constituent un langage commun 29
. On pourra alors construire une architecture
physique du système 30
.
La structuration en modules
Pour passer à la réalisation en pratique du système, il va falloir le structurer
à base de composants – ou modules – qui rempliront les fonctions. On pourra
s’appuyer sur des composants existants, ou développés spécialement.
On va donc allouer les fonctions, d’abord à des composants logiques, en les
regroupant par domaines, par type de données traitées, par finalité. . .
Deux objectifs aideront à construire ces ensembles :
— La modélisation de constituants existants qu’on pourra se procurer sur éta-
gère (COTS).
— La modélisation de constituants qu’on pourra réaliser sur mesure pour rem-
plir les fonctions nécessaires.
Ces composants logiques permettent de mieux appréhender ce que doit être
le système final, en donnant un niveau d’abstraction qui permettra de le structurer
de manière efficace.
On devra s’assurer d’avoir alloué l’ensemble des fonctions et des contraintes
de performance du système global (la couverture fonctionnelle doit être complète
comme on a pu le voir précédemment). Il faudra aussi vérifier que toutes les in-
terfaces du système sont bien réparties sur les composants adéquats, et vérifier la
consistance des interfaces internes au système pour qu’il soit cohérent.
29. Voir par exemple SysML sur le site officiel www.omgsysml.org.
30. Par physique on entend concrète, à base de composants réels, qu’ils soient logiciels ou
matériels.

La dernière étape consistera à en déduire les spéciﬁcations de chaque com-
posant physique, qui permettra soit leur fourniture, soit leur développement.
On aura alors un système totalement déﬁni qui pourra être produit.

Annexe A
La gestion de Projet en un coup
d’œil
199

200 ANNEXE A. LA GESTION DE PROJET EN UN COUP D’ŒIL
Préparation
duProjet
-Livrables
-Documentation
-Retour
d'expérience
Clôturedu
Projet
-Objectifs
-Périmètre
-Principauxlivrableset
jalons
-...
Documentdedéfinition
deProjet-Périmètre
-WBS-OBS
-Livrables
-Planification
-Gestiondesrisques
-...
PlanProjet
Contrat
Elémentsexistants
Initialisation
Opportunité
Besoin
-Avancement
-Gestiondes
changements
-Gestiondes
problèmes
-...
Exécutiondu
Projet
Contrôle
Livrables
Changem
ents
validés
Plan
Projet
Plan
Projet
Livrables
Rapports
D
ocum
entation

Annexe B
À propos de l’auteur
201

202 ANNEXE B. À PROPOS DE L’AUTEUR

Table des figures
1.1 Le triangle Qualité-Coût-Délai . . . . . . . . . . . . . . . . . . . . . 8
2.1 Coûts induits par les décisions et des coûts globaux d’un Projet . . 13
2.2 Capacité d’action et connaissance acquise sur le Projet . . . . . . . 14
3.1 Exemples de différents types de Projets . . . . . . . . . . . . . . . . 19
3.2 Quelques critères de définition d’un profil de Projet . . . . . . . . . 21
4.1 Principe d’une structure séquentielle de Projet . . . . . . . . . . . . 23
4.2 Principe d’une structure simultanée de Projet . . . . . . . . . . . . 24
4.3 Organisation fonctionnelle de l’équipe Projet . . . . . . . . . . . . . 25
4.4 Organisation coordonnée de l’équipe Projet . . . . . . . . . . . . . . 27
4.5 Organisation avec un Directeur Projet . . . . . . . . . . . . . . . . 27
4.6 Organisation avec une équipe Projet dédiée . . . . . . . . . . . . . . 28
5.1 Organisation générale des phases Projet . . . . . . . . . . . . . . . . 34
6.1 Diagramme « Bête à cornes » pour l’identification des besoins . . . 38
6.2 Diagramme « Pieuvre » pour recenser les fonctions . . . . . . . . . 39
6.3 Schématisation du Cycle en V . . . . . . . . . . . . . . . . . . . . . 43
6.4 Le principe de création des spécifications internes. . . . . . . . . . . 47
7.1 Les domaines d’action du Chef de Projet . . . . . . . . . . . . . . . 56
7.2 Une approche de la notion de talent. . . . . . . . . . . . . . . . . . 61
7.3 Les styles de management selon Blake et Mouton. . . . . . . . . . . 62
7.4 Représentation graphique d’un WBS. . . . . . . . . . . . . . . . . . 68
7.5 Structure d’un OBS. . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.6 La notion de référentiel. . . . . . . . . . . . . . . . . . . . . . . . . 74
7.7 Structure de base d’un diagramme PERT. . . . . . . . . . . . . . . 78
7.8 Représentation d’une étape dans le diagramme PERT. . . . . . . . 78
7.9 Visualisation du chemin critique dans un diagramme PERT. . . . . 80
7.10 Synthèse des informations sur un diagramme GANTT . . . . . . . . 82
203

204 TABLE DES FIGURES
8.1 Relations entre le développement et la production. . . . . . . . . . . 99
8.2 Évaluation d’un fournisseur selon les 10Cs de Carter . . . . . . . . . 103
8.3 Configuration de test d’un composant . . . . . . . . . . . . . . . . . 109
9.1 Principe des flux financiers actualisés . . . . . . . . . . . . . . . . . 119
10.1 3 étapes pour identifier les risques à gérer . . . . . . . . . . . . . . . 134
10.2 Les niveaux de risques à gérer. . . . . . . . . . . . . . . . . . . . . . 136
10.3 Principe d’application de la loi de Pareto. . . . . . . . . . . . . . . 139
10.4 Principes de gestion des risques. . . . . . . . . . . . . . . . . . . . . 139
10.5 Le diagramme Ishikawa. . . . . . . . . . . . . . . . . . . . . . . . . 140
10.6 La matrice de décision d’Einsenhower. . . . . . . . . . . . . . . . . 143
12.1 Le principe du Cycle de Deming . . . . . . . . . . . . . . . . . . . . 164
12.2 Modélisation d’un processus avec le diagramme SIPOC. . . . . . . . 166
12.3 Structure d’une matrice SWOT. . . . . . . . . . . . . . . . . . . . . 167
12.4 Les 5 forces de Porter. . . . . . . . . . . . . . . . . . . . . . . . . . 168
12.5 Description générale du processus SCRUM. . . . . . . . . . . . . . . 172
12.6 Les trois rôles du processus SCRUM. . . . . . . . . . . . . . . . . . 172
12.7 Le graphique d’avancement décrivant le reste à faire. . . . . . . . . 175
12.8 Le graphique d’avancement indiquant le travail réalisé. . . . . . . . 176
12.9 Le poster de la méthode SAFe la plus complète. . . . . . . . . . . . 179
12.10Un ART est une organisation multidisciplinaire qui brise les silos et
optimise la création de valeur. . . . . . . . . . . . . . . . . . . . . . 186
12.11Les composantes de l’état d’esprit Lean-Agile. . . . . . . . . . . . . 186
12.12Les vues boîte noire et boîte blanche. . . . . . . . . . . . . . . . . . 190
12.13Les différents types de relations du système avec son environnement. 192
12.14On identifie les fonctions qui permettent de répondre aux besoins.. . 193

Liste des tableaux
6.1 Table d’analyse des Fonctions . . . . . . . . . . . . . . . . . . . . . 39
7.1 Structure d’une matrice RACI . . . . . . . . . . . . . . . . . . . . . 70
10.1 Pondération des eﬀets . . . . . . . . . . . . . . . . . . . . . . . . . 141
12.1 Exemple d’analyse SIPOC . . . . . . . . . . . . . . . . . . . . . . . 166
205

Bibliographie
[1] AFIS, Serge Fiorèse, and Jean-Pierre Meinadier. Découvrir et comprendre
l’ingénierie système.
[2] Claude Aubry. SCRUM : Le guide pratique de la méthode agile la plus popu-
laire. DUNOD, 2015.
[3] BKCASE. Guide to the System Engineering Book of Knowledge. BKCASE,
www.sebokwiki.org, 2017.
[4] Ray Carter. The seven cs of eﬀective supplier evaluation. Purchasing and
Supply Management, pages 44–44, 1995.
[5] Mary Beth Chrissis, Mike Konrad, and Sandra Shrum. CMMI for develop-
ment: guidelines for process integration and product improvement. Pearson
Education, 2011.
[6] Peter Drucker. The practice of management. Collins, New York, NY, 2006.
[7] Sandra Graham and Bernard Weiner. Theories and principles of motivation.
Handbook of educational psychology, 4:63–84, 1996.
[8] H.G. Halvorson. 9 Things Successful People Do Diﬀerently. Harvard Business
Review Press, 2012.
[9] INCOSE. INCOSE Systems Engineering Handbook: A Guide for System Life
Cycle Processes and Activities. Wiley, 2015.
[10] Sous Serge Fiorèse Jean-Pierre Meinadier (Auteur) la direction de et AFIS :
Association Française d’Ingénierie Système (Auteur). Découvrir et comprendre
l’ingénierie système. AFIS. Cépaduès Éditions, 2012.
[11] Elizabeth Larson and Richard Larson. The Practitioners Guide to Require-
ments Management 2nd Edition. Watermark Learning, 2013.
[12] Blake & Mouton. The managerial grid. Houston : Gulf Pub., c1994.
[13] PMI, editor. A Guide to the Project Management Body of Knowledge (PM-
BOK Guide). Project Management Institute, Newtown Square, PA, 5 edition,
2013.
[14] Ken Schwaber. Agile Project Management with Scrum. Microsoft Press, Red-
mond, WA, 2004.
207

208 BIBLIOGRAPHIE
[15] Hirotaka Takeuchi and Ikujiro Nonaka. The new new product development
game. Harvard business review, 64(1):137–146, 1986.
[16] J.P. Womack and D.T. Jones. Lean thinking: banish waste and create wealth
in your corporation. Lean Enterprise Institute. Simon & Schuster, 1996.

Gestion de Projet

Contenu connexe

Tendances (20)

Similaire à Gestion de Projet (20)

Dernier (19)

Gestion de Projet