Ingénierie de

GESTION DE PROJETS
Guide non exhaustif pour scientifiques & ingénieurs

V9.0 Révision 1679 (2015-04-29)

{oUUID 1.674}
[Link]
Vincent ISOZ
 Vincent ISOZ

 Please consider the environment - do you really need to print this document!?
Remarques:

Pour qu'il soit utilisable d'une manière rationnelle et sans danger ce support, qui constitue un
"super condensé" d'un exposé qui tiendrait très facilement sur plusieurs milliers de pages (voir
les ouvrages de cette taille disponible sur le commerce), doit absolument être complété par de
nombreuses notes et exposés oraux, au cours desquels les notions nouvelles sont présentées au
moyen de situations (exercices) concrètes et illustrées par de nombreux exemples dont le
choix dépend essentiellement du déroulement de la formation afin d'exciter l'esprit critique
des apprenants. Ce support correspond à une formation d'environ 50 jours à 6.5 heures par
jour pour un groupe de 6 à 8 personnes.

Attention!!! Pendant les séminaires et conférences de moins ou égal à 3 jours je prends

oralement et délibérément des raccourcis dangereux voire parfois partiellement faux
délibérément à cause du manque de temps pour aller dans les détails. Ce support permet donc
aux participants intéressés de corriger le tir d'éviter des P.F.D.A.1.

Je tiens également à préciser que ce document est censé être utilisé conjointement avec celui
sur le logiciel de gestion de projets MS Office Project contenant uniquement les captures
d'écran de la version anglophone de MS Project 2000/2002/2003/2007/2010/2013. Le choix
de la langue anglaise intervient quant au fait que:

1. C'est celle dont il est fait le plus usage dans la littérature spécialisée et dans la pratique
il ne serait donc pas convenable d'essayer de s'y soustraire. Par ailleurs, les pays
francophones ont souvent un demi-siècle de retard par rapport aux méthodes et
techniques de gestion de projets publiées dans la langue de Shakespeare.

2. Il y a plusieurs erreurs de traduction dans la version française du logiciel qui sont en

partie ridicules et certaines même dangereuses!

3. Travailler dans un environnement multilingue avec ce logiciel est peu agréable, donc
l'anglais s'impose de lui-même

4. L'anglais est la langue de référence depuis plus d'un siècle pour les scientifiques et
ingénieurs. Il s'agit donc un acquis minimum pour tout diplômé.

Il y a de nombreuses marques déposées qui sont nommées dans le présent support. Plutôt que
d'utiliser le symbole du trademark sur chaque occurrence de marque nommée, j'ai choisi
d'utiliser le nom seul uniquement dans un souci d'esthétique éditoriale (ce qui devrait aussi
bénéficier au propriétaire de la marque), sans aucune intention de violer une quelconque
réglementation ou législation. Certaines images sont prises d'Internet sans avoir pu identifier
en identifier avec certitude les auteurs. Dans le cas d'une réclamation de violation de droits
d'auteurs, nous retirerons bien évidemment immédiatement l'illustration du présent document.

Il faut donc considérer d'une façon générale, tous les produits ou illustration cités dans
l'ouvrage concernant un acteur du marché font l'objet d'un copyright par leurs éditeurs/auteurs
respectifs et qu'ils ont le droit d'en demander le retrait.

1
Projets Foutus D'Avance

Ingénierie de Gestion de projets 1/523

[Link]
 Vincent ISOZ

Pour terminer, je souhaiterais remercier ici les quelques collègues et clients qui ont bien voulu
me faire part de leurs remarques pour améliorer le contenu de ce livre électronique. Il est
cependant certain qu'il est encore perfectible sur de nombreux points...

Si vous souhaitez être informé des nouvelles versions majeures de ce document n'hésitez pas
à m'écrire un e-mail dans ce sens: isoz@[Link].

Ingénierie de Gestion de projets 2/523

[Link]
 Vincent ISOZ

Table des matières

Table des matières ...................................................................................................................... 3
Index des tableaux .................................................................................................................... 9
Index des équations ................................................................................................................ 10
1. Introduction .......................................................................................................................... 12
1.1 À propos du rédacteur..................................................................................................... 13
1.2 Avertissements................................................................................................................ 14
1.3 Comment utiliser ce livre ............................................................................................... 15
1.4 Change Log..................................................................................................................... 16
1.5 Marques déposées ........................................................................................................... 18
1.6 Votre avis nous intéresse! ............................................................................................... 18
1.7 Liens internet .................................................................................................................. 18
1.8 Bibliographie .................................................................................................................. 21
2. Quelques chiffres .................................................................................................................. 33
3. Erreurs… .............................................................................................................................. 38
4. N.R.M.M .............................................................................................................................. 43
4.1 IREB ............................................................................................................................... 48
4.2 ISO 10006:2003 .............................................................................................................. 48
4.3 PMI ................................................................................................................................. 53
4.4 Six Sigma (ISO 13053-1:2011) ...................................................................................... 56
4.4.1 Lean Six Sigma ....................................................................................................... 59
4.5 CMMi ............................................................................................................................. 60
4.6 AFITEP ........................................................................................................................... 62
4.7 IPMA .............................................................................................................................. 62
4.8 ITIL................................................................................................................................. 63
4.9 COBIT ............................................................................................................................ 64
4.10 AMDEC ........................................................................................................................ 65
4.11 PRINCE2 ...................................................................................................................... 66
4.12 BPF ............................................................................................................................... 67
4.13 5S .................................................................................................................................. 68
4.14 SWOT ........................................................................................................................... 69
4.15 IFCAM.......................................................................................................................... 69
4.16 SPICE ........................................................................................................................... 70
4.17 Hermes .......................................................................................................................... 70
4.18 MCTS ........................................................................................................................... 71
4.19 EFQM ........................................................................................................................... 71
4.20 Dimension 4 .................................................................................................................. 73
4.21 MBA ............................................................................................................................. 74
4.22 ENS ............................................................................................................................... 74
5. Logiciels ............................................................................................................................... 76
6. Documents (modèles) ........................................................................................................... 80
7. Processus et représentatives ................................................................................................. 83
7.1.1 Objectifs .................................................................................................................. 86
7.1.2 Types de représentatives ......................................................................................... 91
[Link] Mind Mapping .................................................................................................. 91
[Link] Diagramme d'Ishikawa ..................................................................................... 92
[Link] Organigrammes (O.B.S./W.B.S./P.B.S./R.B.S.) .............................................. 94
[Link] Gantt ................................................................................................................. 96
[Link] PERT ................................................................................................................ 96

Ingénierie de Gestion de projets 3/523

[Link]
 Vincent ISOZ

[Link] Time-Line ......................................................................................................... 97

[Link] Diagramme de flux ........................................................................................... 98
[Link].1 Fiche processus........................................................................................ 103
[Link].2 Diagramme de flux SIPOC ..................................................................... 105
[Link] Analyse par arbres d'erreurs (A.A.E.) ............................................................ 107
[Link] Total Quality Management (TQM) ................................................................ 108
[Link] Business Process Management Notation ...................................................... 110
[Link] IDEF0 ........................................................................................................... 111
[Link] Arbres de décision ........................................................................................ 113
[Link] Options réelles .............................................................................................. 113
[Link] Tableau de bord (dashboard) ........................................................................ 116
7.1.3 Optimisation des processus ................................................................................... 119
8. Conduite et gestion de projets ............................................................................................ 125
8.1 Historique de la gestion de projets ............................................................................... 130
8.2 Intervenants .................................................................................................................. 132
8.3 Types de responsables de projets.................................................................................. 139
8.3.1 Le principe de Peter............................................................................................... 141
8.3.2 Sélectionner un bon responsable de projet ............................................................ 143
[Link] Compétences .................................................................................................. 144
[Link] L'interview ...................................................................................................... 146
8.3.3 Profil d'entreprise type .......................................................................................... 147
8.4 Formation de l'équipe de projet .................................................................................... 149
8.4.1 SCRUM ................................................................................................................. 150
8.4.2 Équipe de projet .................................................................................................... 152
[Link] Forming .......................................................................................................... 153
[Link] Storming ......................................................................................................... 155
[Link] Norming ......................................................................................................... 156
[Link] Performing ...................................................................................................... 156
8.4.3 Hiérarchie/Organisation ........................................................................................ 156
8.4.4 Profils .................................................................................................................... 158
8.4.5 Comportements ..................................................................................................... 160
8.4.6 Caractères .............................................................................................................. 168
8.4.7 Théorie X et Y ....................................................................................................... 169
8.4.8 Conflits .................................................................................................................. 170
[Link] Syndrome de Calimero ................................................................................... 175
8.4.9 Souffrance au travail ............................................................................................. 176
8.4.10 Suggestions du personnel .................................................................................... 178
8.4.11 Standardisation entre les ressources .................................................................... 179
8.4.12 Matrice des responsabilités ................................................................................. 180
8.4.13 Rencontres/Réunions ........................................................................................... 182
[Link] Types de participants .................................................................................... 184
8.4.14 Congés Maladie ................................................................................................... 185
8.4.15 L'espace blanc ..................................................................................................... 187
8.5 Communication ............................................................................................................ 188
8.5.1 Les quatre styles de communication ..................................................................... 191
[Link] Le rationnel .................................................................................................... 192
[Link] L'affectif ......................................................................................................... 193
[Link] L'actif .............................................................................................................. 193
[Link] Le conceptuel ................................................................................................. 195
8.5.2 Des mesures pour réduire le nombre d'e-mails ..................................................... 195

Ingénierie de Gestion de projets 4/523

[Link]
 Vincent ISOZ

8.6 Cycle de vie d'un projet ................................................................................................ 196

8.6.1 Postulats et corollaires ........................................................................................... 210
8.6.2 Identification ......................................................................................................... 211
[Link] Options ........................................................................................................... 213
[Link] Niveau de criticité .......................................................................................... 222
[Link] M.I.P ............................................................................................................... 224
[Link].1 Sommaire exécutif................................................................................... 225
[Link].2 Problématique.......................................................................................... 226
[Link].3 Description du projet (Analyse fonctionnelle) ........................................ 227
[Link].4 Analyse structurelle ................................................................................. 230
[Link].5 Identification et analyse des options ....................................................... 234
[Link].6 Estimation des intrants et extrants ........................................................... 235
[Link].7 Évaluation des risques/menaces .............................................................. 237
[Link].8 Stratégie de réalisation ............................................................................ 242
[Link].9 Dimensions de l'environnement .............................................................. 242
8.6.3 Planification .......................................................................................................... 244
[Link] Structure de fractionnement de travail ........................................................... 245
[Link] Structure de fractionnement du produit .......................................................... 247
[Link] Techniques d'ordonnancement ....................................................................... 248
[Link].1 Tâche ....................................................................................................... 251
[Link].2 Gantt ........................................................................................................ 252
[Link].3 Méthode des potentiels métra (CP/RCP)................................................. 259
[Link].3.1 Chemin critique mathématique VS Chemin critique contraint par date
............................................................................................................................ 262
[Link].3.2 Chemin critique multiple.................................................................. 263
[Link].3.3 Chemin critique contraint par liaison ............................................... 265
[Link].3.4 Chemin critique par avancement ...................................................... 266
[Link].4 Méthode de la chaîne critique (critical chain) ......................................... 266
[Link].5 Recherche opérationnelle ........................................................................ 269
[Link].6 Gestion des risques .................................................................................. 271
[Link].6.1 AMDE(C) ......................................................................................... 275
[Link].6.2 Estimation du temps (et des coûts) ................................................... 276
[Link].6.2.1 Loi Bêta (approche paramétrique) .......................................... 278
[Link].6.2.2 Théorème central limite .......................................................... 290
[Link].6.2.3 Méthode de Monte-Carlo (approche simulatoire) .................. 292
[Link].6.2.4 Bootstrapping (approche simulatoire) .................................... 312
[Link] Coûts du projet ............................................................................................... 314
[Link].1 Actifs financiers ...................................................................................... 314
[Link].2 Centre de coûts ........................................................................................ 314
[Link].3 Ratio Bénéfice Coût (RBC)..................................................................... 315
[Link].4 Economic Value Add (EVA) .................................................................. 315
[Link].5 Return On Invested Capital (ROIC) ........................................................ 315
[Link].6 Net Present Value (NPV/VAN) et Internal Rate of Return (IRR/TRI) ... 316
[Link].6.1 NPV/VAN et IRR/TRI en avenir certain ......................................... 316
[Link].6.2 Net Future Value (NFV) en avenir certain ....................................... 319
[Link].6.3 NPV/VAN et IRR/TRI en avenir incertain par scénarios ................ 320
[Link].6.4 NPV/VAN par processus binomial .................................................. 322
[Link].7 fV@R et tV@R ....................................................................................... 323
[Link].8 Méthodes d'appréciations (décisionnelles) en avenir incertain ............... 324
[Link].8.1 Le critère de Laplace-Bayes ............................................................. 325

Ingénierie de Gestion de projets 5/523

[Link]
 Vincent ISOZ

[Link].8.2 Le critère de Wald ............................................................................ 325

[Link].8.3 Le critère du Maximax ..................................................................... 326
[Link].8.4 Le critère de Savage ou du Minimax Regret .................................... 326
[Link].8.5 Le critère d'Hurwitz.......................................................................... 326
[Link].8.6 Analyses par arbres d'événements (AAE) ........................................ 329
[Link].8.7 Analyses par arbres de décision (ADE) ........................................... 330
[Link].8.8 Analyses procédurale hiérarchique .................................................. 331
8.6.4 Réalisation (pilotage) ............................................................................................ 341
[Link] Engineering .................................................................................................... 346
[Link] Gestion du changement .................................................................................. 347
[Link] Le suivi du temps ........................................................................................... 348
[Link] Le suivi des coûts ........................................................................................... 350
[Link].1 Les données de référence ........................................................................ 351
[Link].2 Les grandeurs à comparer (CRTE, CBTP, CBTE...) .............................. 351
[Link].3 Écart de planning (SV) ............................................................................ 353
[Link].4 Écart de coût (CV)................................................................................... 354
[Link].5 Indices de performances .......................................................................... 355
[Link].6 Les grecques ............................................................................................ 356
[Link] Tests ............................................................................................................... 363
[Link] Gestion de la qualité ....................................................................................... 364
[Link].1 Les 14 points de Deming ......................................................................... 372
[Link].2 Exigences générales ................................................................................ 375
[Link].3 Défauts/Erreurs ........................................................................................ 377
[Link].4 Indices de performance et de contrôle qualité ......................................... 383
[Link] Bilans .............................................................................................................. 385
8.6.5 Terminaison (clôture) de projet ............................................................................. 387
9. Vente d'un projet ................................................................................................................ 390
9.1 Dix commandements .................................................................................................... 390
9.2 Démarchage .................................................................................................................. 392
9.3 Profils............................................................................................................................ 393
9.4 Discours ........................................................................................................................ 394
9.4.1 Termes à éviter/utiliser .......................................................................................... 394
9.4.2 Phrases types ......................................................................................................... 395
9.5 Synergologie ................................................................................................................. 396
9.6 Supports visuels ............................................................................................................ 397
9.7 Gérer les objections ...................................................................................................... 397
10. Éthique ............................................................................................................................. 399
11. Gestion de la connaissance ............................................................................................... 400
12. Applications numériques .................................................................................................. 401
12.1 Exemples en gestion ................................................................................................... 401
12.1.1 Critères décisionnels classiques .......................................................................... 401
12.1.2 Arbre de décision ................................................................................................ 404
12.1.3 Gantt .................................................................................................................... 406
12.1.4 Chemin critique & Marges .................................................................................. 409
12.1.5 PERT Probabiliste (PNET) Bêta ......................................................................... 410
12.1.6 Coût non qualité selon modèle Taguchi .............................................................. 414
12.1.7 tV@r et fV@r ...................................................................................................... 415
12.1.8 Rendement global combiné de processus............................................................ 416
12.1.9 Rendement global combiné de procédé de fabrication ....................................... 418
12.1.10 Analyse de Pareto .............................................................................................. 419

Ingénierie de Gestion de projets 6/523

[Link]
 Vincent ISOZ

12.1.11 Indice de Gini .................................................................................................... 424

12.1.12 Prévision des ventes .......................................................................................... 425
12.1.13 Recherche opérationnelle dans l'optimisation de la production ........................ 427
12.1.14 Recherche opérationnelle dans l'optimisation de bénéfice ................................ 430
12.1.15 Recherche opérationnelle dans l'optimisation de commandes .......................... 432
12.1.16 Recherche opérationnelle dans l'optimisation de la production ........................ 434
12.1.17 Recherche opérationnelle dans l'optimisation des priorités .............................. 436
12.1.18 Corrélation des compétences ............................................................................. 439
12.1.19 Matrice des corrélations .................................................................................... 442
12.2 Exemples en finance ................................................................................................... 443
12.2.1 Intérêts simples.................................................................................................... 444
12.2.2 Taux géométrique moyen .................................................................................... 447
12.2.3 Taux proportionnel et moyen sur intérêts simples .............................................. 448
12.2.4 Investissements composés ................................................................................... 449
12.2.5 Taux équivalents sur intérêts composés .............................................................. 451
12.2.6 Taux moyen équivalent composé ........................................................................ 452
12.2.7 Emprunt Indivis à échéance fixe ......................................................................... 453
12.2.8 Emprunt Indivis à amortissements constants ...................................................... 454
12.2.9 Emprunts à annuités constantes........................................................................... 455
12.2.10 Amortissement linéaire ..................................................................................... 457
12.2.11 Amortissement arithmétique dégressif .............................................................. 458
12.2.12 Amortissement dégressif géométrique .............................................................. 460
12.2.13 Valeur actuelle nette .......................................................................................... 462
12.2.14 Valeur actuelle nette (tabulaire) ........................................................................ 464
12.2.15 Taux de rendement interne (Internal Rate of Return) ....................................... 466
12.2.16 Valeur actuelle nette espérée ............................................................................. 469
12.2.17 VAN et TRI apériodiques ................................................................................. 470
12.2.18 Analyse probabiliste des ventes et de la production ......................................... 472
12.2.19 Modèle de Wilson ............................................................................................. 474
12.3 Exemples en qualité .................................................................................................... 475
12.3.1 Tirage non-exhaustif (loi binomiale)................................................................... 475
12.3.2 Acceptation/Rejet de lot par tirage non-exhaustif (loi binomiale) ...................... 476
12.3.3 Probabilité de panne (loi binomiale) ................................................................... 477
12.3.4 Tirage exhaustif (loi hypergéométrique) ............................................................. 477
12.3.5 Tirage exhaustif/non-exhaustif (loi binomiale, hypergéométrique) .................... 478
12.3.6 Réussites avant 1er échec (loi géométrique) ........................................................ 479
12.3.7 Réussites avant n-ème échec (loi binomiale négative)........................................ 480
12.3.8 Test binomial de la proportion ............................................................................ 480
12.3.9 Écart-Moyen VS Écart-Type ............................................................................... 481
12.3.10 Intervalles de qualité ......................................................................................... 483
12.3.11 Indices de fiabilité ............................................................................................. 483
12.3.12 Défaillance AMDEC (loi exponentielle)........................................................... 484
12.3.13 Défaillance AMDEC: MTTF (loi exponentielle) .............................................. 485
12.3.14 Tirage avec défaillance temporelle AMDEC (loi de Poisson) .......................... 485
12.3.15 Probabilité de panne AMDEC (loi de Poisson) ................................................ 485
12.3.16 Défaillance AMDEC: MTBF (loi exponentielle).............................................. 486
12.3.17 Défauts dans lots (loi Normale) ........................................................................ 487
12.3.18 Garantie de durée de vie (loi Normale) ............................................................. 487
12.3.19 Moyenne et variance de variables normalement distribuées ............................. 488
12.3.20 Intervalle de confiance de la moyenne (test Z à 1 échantillon) ......................... 488

Ingénierie de Gestion de projets 7/523

[Link]
 Vincent ISOZ

12.3.21 Intervalle de confiance de la proportion ............................................................ 489

12.3.22 Intervalle de confiance de l'écart-type............................................................... 490
12.3.23 Nombre d'échantillons pour une mesure ........................................................... 491
12.3.24 Nombre d'échantillons pour une proportion ...................................................... 492
12.3.25 Comparaison de deux proportions .................................................................... 492
12.3.26 Test d'hypothèse t-student bilatéral ................................................................... 493
12.3.27 Méthode ABC avec courbe de Lorenz .............................................................. 494
12.3.28 SPC de projets ................................................................................................... 496
13. Glossaire ........................................................................................................................... 502

Ingénierie de Gestion de projets 8/523

[Link]
 Vincent ISOZ

TABLE DES FIGURES

Figure 1 Cartographie normes et référentiels (source ISBN 978-2-212-54388-9)................... 44
Figure 2 Cartographie méthodes et modèles (source ISBN 978-2-212-54388-9).................... 45
Figure 3 CMM .......................................................................................................................... 60
Figure 4 Modèle PRINCE2 ...................................................................................................... 66
Figure 5 Cinq niveaux de la hiérarchie des documents qualité (pyramide) ............................. 87
Figure 6 Exemple de W.B.S ..................................................................................................... 95
Figure 7 Exemple fiche processus .......................................................................................... 104
Figure 8 Principe de découpage analyse TPM ....................................................................... 109
Figure 9 Logique de traitement des incidents (source: ISBN 2708130226) .......................... 124
Figure 10 Oeil du IPMA ......................................................................................................... 127
Figure 11 Métiers de la gestion de projets ............................................................................. 138
Figure 12 Procédure de mise en place de groupes de travail.................................................. 153
Figure 13 Degrés de délégation .............................................................................................. 154
Figure 14 Ressource idéalisée ................................................................................................ 168
Figure 15 Ressource inadaptée ............................................................................................... 169
Figure 16 Matrice RACI......................................................................................................... 181
Figure 17 Ingérence de la communication (source: ISBN 2708130226) ............................... 190
Figure 18 Ce qu'une bonne analyse fonctionnelle permet d'éviter ......................................... 225
Figure 19 Maison de la qualité Six Sigma (Matric de Pugh) ................................................. 232
Figure 20 Matrice de relation (source: ISBN 2708130226) ................................................... 233
Figure 21 Maison de la qualité (source: ISBN 2708130226)................................................. 234
Figure 22 Service Level Agreement (source: Wikipédia) ...................................................... 242
Figure 23 Jalonnement ........................................................................................................... 249
Figure 24 Phasage .................................................................................................................. 249
Figure 25 Planning détaillé..................................................................................................... 250
Figure 26 Processus n°6 du PMI/PMBOK pour la gestion du temps .................................... 251
Figure 27 Plan de charge type (source: ©ANCORE
Management|[Link]) ........................................................................... 269
Figure 28 Tracé loi Bêta ......................................................................................................... 284
Figure 29 Choix des distributions dans Risk + ...................................................................... 298
Figure 30 Convergence de la modélisation dans Risk+ ......................................................... 298
Figure 31 Formulaire de Risk + ............................................................................................. 299
Figure 32 Distribution probabiliste des coûts (Risk+) ........................................................... 299
Figure 33 Distribution probabiliste de la date de complétude du projet (Risk+) ................... 300
Figure 34 Rendements d'actifs ............................................................................................... 317
Figure 35Résumé phase identification ................................................................................... 341
Figure 36 Exemple de différence entre avancement physique et en délai ............................. 350
Figure 37 Extrapolation linéaire du groupe de développement du logiciel GIMP ................. 357
Figure 38 Cycle Qualité ......................................................................................................... 365
Figure 39 Graphique des coûts relatifs à la non-qualité (source: ISBN 978-2-297 01111-2)366
Figure 40 Résumé élémentaire des composants de base de la qualité ................................... 377

Index des tableaux

Tableau 1 Erreurs rencontrées .................................................................................................. 42
Tableau 2 NRMM .................................................................................................................... 46

Ingénierie de Gestion de projets 9/523

[Link]
 Vincent ISOZ

Tableau 3 Niveaux de responsables de projets ....................................................................... 138

Tableau 4 Conduite (Leadership) ........................................................................................... 161
Tableau 5 Engagement et motivation ..................................................................................... 162
Tableau 6 Maîtrise de soi ....................................................................................................... 163
Tableau 7 Relaxation et maîtrise du stress ............................................................................. 163
Tableau 8 Ouverture d'esprit .................................................................................................. 164
Tableau 9 Créativité ............................................................................................................... 165
Tableau 10 Orientation résultats............................................................................................. 166
Tableau 11 Efficience ............................................................................................................. 166
Tableau 12 Conflits et crises .................................................................................................. 167
Tableau 13 Fiabilité ................................................................................................................ 168
Tableau 14 Pyramide de Maslow ........................................................................................... 177
Tableau 15 Liste de risques typiques potentiels (non exhaustive) ......................................... 238

Index des équations

Équation 1 Fonction Bêta ....................................................................................................... 280
Équation 2 Fonction Gamma.................................................................................................. 280
Équation 3 Loi Bêta................................................................................................................ 280
Équation 4 Mode Loi Bêta ..................................................................................................... 283
Équation 5 Variance Loi Bêta ................................................................................................ 284
Équation 6 Espérance Loi Bêta .............................................................................................. 284
Équation 7 Risque d'action ..................................................................................................... 285
Équation 8 Convolution 2 Lois Normales .............................................................................. 292
Équation 9 VAN ..................................................................................................................... 316
Équation 10 Linéarité espérance ............................................................................................ 320
Équation 11 Formule de Huyghens ........................................................................................ 321
Équation 12 DPO ................................................................................................................... 378
Équation 13 DPMO ................................................................................................................ 379
Équation 14 Loi binomiale ..................................................................................................... 379
Équation 15 Loi de Poisson .................................................................................................... 380
Équation 16 Variance, Espérance de la loi de Poisson........................................................... 380
Équation 17 Loi de Gauss-Laplace ........................................................................................ 381
Équation 18 ESB .................................................................................................................... 381
Équation 19 Cp ....................................................................................................................... 383
Équation 20 Cpk ..................................................................................................................... 384
Équation 21 CPU, CPL .......................................................................................................... 385

Ingénierie de Gestion de projets 10/523

[Link]
 Vincent ISOZ

REMERCIEMENTS
Je tiens à remercier les personnes suivantes pour leur soutien, aide ou contribution ainsi que
corrections du document:

 Vincent Giard: Spécialiste en gestion de la production, Professeur rattaché au LAMSADE

auteur de nombreux livres aux Éditions Economica pour avoir fourni les exemples sur la
méthode de Monte-Carlo.

 Christian Pache: Ancien formateur MS Project et coordinateur de projets pour son aide
dans l'élaboration du fil rouge du document.

 Jan De Messemaker: Microsoft Project Standard et Server Most Valuable Professional

(MVP) pour son intervention sur de nombreux points flous concernant MS Project et sa
contribution active à la dynamique du newsgroup du logiciel.

 Hervé Thiriez: (Ph. D. MIT Professeur à HEC Paris) Spécialiste MS Excel et en

modélisation décisionnelle et de Monte-Carlo et en management scientifique pour ses
retours d'expérience de l'application de ces outils dans les domaines de l'industrie et des
services.

Pour terminer, je voudrais remercier ici les quelques collègues et clients qui ont bien voulu
me faire part de leurs remarques pour améliorer le contenu de ce livre électronique. Il est
cependant certain qu'il est encore perfectible sur de nombreux points.

Je fais ce qui est écrit,

j'écris ce que je fais
je donne la preuve de ce que j'ai fait!

Ingénierie de Gestion de projets 11/523

[Link]
 Vincent ISOZ

1. Introduction
La mise en place d'un projet est un des enjeux fondamentaux pour les entreprises et les
organismes soucieux d'optimiser l'utilisation de leurs ressources humaines et matérielles.

Ce support a pour objectif d'introduire aux techniques quantitatives et méthodes de gestion de

projets dont la "maîtrise" est indispensable aux cadres de l'entreprise moderne et s'adresse
principalement aux étudiants en 2ème et 3ème cycles universitaires dans un domaine scientifique
ou de gestion de projets d'ingénierie (selon le standard franco-français. Il intéressera
également les praticiens d'entreprises, responsables de projets ou personnes participant à un
projet, désireux d'acquérir ou de compléter leurs connaissances en gestion (car aller au fond
des choses est une vertu bien rare...) particulièrement pour la partie quantitative
(mathématique). Ce support a l'intérêt majeur aussi de présenter des boîtes à outils
opérationnelles, traitant d'aspects méthodologiques mais aussi comportementaux, dans
lesquelles les différents professionnels peuvent piocher afin de déployer leurs dispositifs de
gestion.

J'insiste particulièrement sur la partie quantitative car comme disait un prix Nobel
d'Économie: Ceux qui ne peuvent faire de la science, font de la méthodologie. Raison pour
laquelle le 95% des ouvrages de gestion de projets ne font que de la méthodologie... Donc il
n'est pas étonnant que la majorité des projets soient mal gérés quand on sait que la majorité
des gestionnaires actuels ont appris des méthodes dont le niveau intellectuel d'apprentissage et
d'application ne nécessite pas un niveau supérieur à celui du lycée... (et je peux prouver que
c'est le cas!).

Tant que la gestion de projets n'utilisera pas des méthodes scientifiques, nous en resterons à
des méthodes qu'utilisaient la médecine, l'astronomie, la biologie, la chimie (alchimie), à la
fin du 17ème siècle... et cela ne leur avait pas réussi puisqu'elles régressaient au lieu d'évoluer.
Ce n'est qu'après avoir adopté les méthodes scientifiques que tous les domaines précités ont
explosé en termes de fiabilité, d'innovation et de rigueur.

Le contenu de cet ouvrage est un livre de recettes, mais cependant il est peut-être bon de
rappeler qu'une bonne mise en pratique des outils de la gestion de projets nécessite les
conditions cadres minimales suivantes:

1. Le soutien de la direction (sinon quoi toutes les autres conditions tombent à l'eau)
2. La formation des personnes impliquées
3. Des rôles tenus par les meilleurs spécialistes pour une bonne évaluation du travail
4. La même compréhension par le donneur d'ordre et le responsable du projet
5. Une grande clarté au niveau de ressources utilisables et de leurs restrictions
6. La mise en place des prérequis au déroulement du projet (processus, modèles, etc.)
7. L'adaptation de ces outils à la situation spécifique du projet (tailoring)

Ceci étant dit... allons-y!

Toujours avoir au moins 3 coups d'avance

Ingénierie de Gestion de projets 12/523

[Link]
 Vincent ISOZ

1.1 À propos du rédacteur

Nom Prénom: ISOZ Vincent
Domicilié à ce jour à Lausanne (Suisse)

Formation: Ingénieur Physicien HES ([Link].)

Équivalence Internationale: Bachelor of Science

Année de naissance: 1978

E-mail: isoz@[Link]

J'ai une formation scolaire que l'on peut qualifier comme étant spécialisée dans la physique et
chimie nucléaire. C'est un domaine où la gestion de projets, les processus, le contrôle des
risques, la rigueur et le niveau de compétence est probablement le plus élevé à ce jour sur
notre planète (j'y reviens plus en détails dans la partie dédiée à la gestion des risques).
Actuellement, je suis consultant trilingue (français, anglais et allemand) en mathématiques
appliquées dans le tutorat d'analystes quantitatifs (niveau Bac+5 à Bac+7) et auteur de
plusieurs livres électroniques dans les domaines suivants:
- maîtrise statistique des processus/procédés (méthodes paramétriques et non paramétriques)
- modélisation prévisionnelle/décisionnelle avancée (arbres de décisions, chaînes de Markov)
- recherche opérationnelle (simplexe, algorithmes génétiques, algorithme GRG)
- data mining (réseaux de neurones, ACP, AFC, régressions, scoring, clustering, etc.)
- modélisation du risque en gestion de projets et finance d'entreprise (monte-carlo, etc.)
- gestion de projets (modèles et best practices théoriques EFQM+Six Sigma, MS Project)
- ISO 9001:2008, 5807:1985, 10015:1999, 31000+31010:2009, 8258:1991, 10017:2003, etc.
- Adobe Photoshop et Illustrator
- 12 applications de la suite Microsoft Office System (Project, Visio, SharePoint, Access, etc.)
À ce jour interventions dans plus de ~200 entreprises dont 10 du Fortune 500 selon listing
2009 et 3 universités et écoles d'ingénieurs suisses dans des cours de modélisation de bases de
données et simulations stochastiques du risque. Formation de plusieurs dirigeants de
multinationales en one to one.
Accessoirement j'interviens pour des formations sur des logiciels comme MS Project,
MS Visio, MS Access et une vingtaine d'autres dont je délègue l'organisation à des entreprises
spécialisées dans la formation continue en bureautique (niveau licence et en-dessous).
Enfin, je conseille aussi vivement à toute personne souhaitant vraiment maîtriser le sujet de
lire mon e-book sur MS Office Project (~850 pages) ainsi que celui sur les Mathématiques
Appliquées (~5'000 pages) et Minitab (~1'000 pages).

Ingénierie de Gestion de projets 13/523

[Link]
 Vincent ISOZ

1.2 Avertissements
Le contenu du présent support est élaboré par un processus de développement par lequel des
experts de la gestion de projets parviennent à un consensus. Ce processus qui rassemble des
participants bénévoles recherche également les points de vue de personnes intéressées par le
sujet de cet ouvrage. En tant que responsable du présent support, j'assure l'administration du
processus et je fixe les règles qui permettent de promouvoir l'équité dans l'approche d'un
consensus. Je me charge également de rédiger les textes, parfois de les tester/évaluer ou de
vérifier indépendamment l'exactitude/solidité ou l'exhaustivité des informations présentées.

Je décline toute responsabilité en cas de dommages corporels, matériels ou autres de quelque

nature que ce soit, particuliers, indirects, accessoires ou compensatoires, résultant de la
publication, de l'application ou de la confiance accordée au contenu du présent support. Je
n'émets aucune garantie expresse ou implicite quant à l'exactitude ou à l'exhaustivité de toute
information publiée dans le présent support, et ne garantit aucunement que les informations
contenues dans cet ouvrage satisfassent un quelconque objectif ou besoin spécifique du
lecteur. Je ne garantis pas non plus les performances de produits ou de services d'un fabricant
ou d'un vendeur par la seule vertu du contenu du présent support.

En publiant des textes, il n'est pas dans l'intention principale du présent support de fournir des
services de spécialistes ou autres au nom de toute personne physique ou morale ni pour mon
compte, ni d'effectuer toute tâche devant être accomplie par toute personne physique ou
morale au bénéfice d'un tiers. Toute personne utilisant le présent support devrait s'appuyer sur
son propre jugement indépendant ou, lorsque cela s'avère approprié, faire appel aux conseils
d'un spécialiste compétent afin de déterminer comment exercer une prudence raisonnable en
toute circonstance. Les informations et les normes concernant le sujet couvert par le présent
support peuvent être disponibles auprès d'autres sources que le lecteur pourra souhaiter
consulter en quête de points de vue ou d'informations supplémentaires qui ne seraient pas
couverts par le contenu du présent document.

Je ne dispose (malheureusement...) d'aucun pouvoir dans le but de faire respecter la

conformité au contenu du présent ouvrage, et je ne m'engage nullement à surveiller ni à faire
respecter une telle conformité. Je n'exerce (à ce jour...) aucune activité de certification, de test
ni d'inspection de produits, de conceptions ou d'installations à fins de santé ou de sécurité des
personnes et des biens. Toute certification ou autre déclaration de conformité en matière
d'informations ayant trait à la santé ou à la sécurité des personnes et des biens, mentionnée
dans le présent support, ne peut aucunement être attribuée au contenu du présent support et
demeure sous l'unique responsabilité de l'organisme de certification ou du déclarant concerné.

Ingénierie de Gestion de projets 14/523

[Link]
 Vincent ISOZ

1.3 Comment utiliser ce livre

Dans le cadre des études supérieures, ce livre peut être utilisé pour des séminaires de niveau
licence, master ou doctorat dans de nombreux domaines des sciences pures et exactes. Les
séminaires dans lesquels nous utilisons ce matériel est une partie intégrale des programmes de
Scientific Evolution Sàrl, où les apprenants ont déjà derrière eux un cursus universitaire ni
licence ou maîtrise dans leur spécialisation.

Parce que les méthodes des mathématiques appliquées s'apprennent par la pratique et
l'expérience, nous concevons un séminaire sur MATLAB comme un processus
d'apprentissage par la pratique. Nous structurons nous séminaires de modélisation
mathématiques autour d'un ensemble de problèmes qui requière aux apprenants de construire
des modèles qui aident à s'organiser et à prendre des décisions. L'important est que les
modèles doivent être consistants avec la théorie et back-testés. Pour répondre à cet impératif,
il est nécessaire pour l'apprenant de combiner les mathématiques théoriques avec la
modélisation. Le résultat est que l'apprenant maîtrise la théorie et, plus important, qu'il
acquière les méthodes permettant d'appliquer la théorie à des cas pratiques réels. La capacité
de critiquer et identifier les limitations d'outils mathématiques sensibles est la valeur ajoutée
la plus importante de nos séminaires.

Les problèmes avec solutions dans le texte fournissent une opportunité d'appliquer les notions
théoriques à de petits cas pratiques tirés ou inspirés pour la majorité de cas réels. À la fin des
séminaires les apprenants ont amélioré leurs compétences et connaissances des outils
théoriques et computationnels majeurs.

Il est vraiment difficile de traiter toute la matière de ce livre en un semestre. Il faut beaucoup
de temps pour expliquer la finesse des concepts aux apprenants. Le lecteur est alors encouragé
de choisir les sujets qui lui sont nécessaires pendant son temps d'étude. Ainsi, il n'est pas
obligatoire de parcourir les chapitres dans l'ordre dans lesquels ils sont présentés mais cela
peut toutefois aider de façon significative…

En un mot, ce livre offre une large variété de sujets qui se prêtent à la modélisation.

Ingénierie de Gestion de projets 15/523

[Link]
 Vincent ISOZ

1.4 Change Log

Suite à plusieurs demandes, j'ai décidé de faire pour ce document ce que j'enseigne pour les
documents importants d'un projet: un journal des changements importants du document
avec un bref descriptif et daté. C'est tout nouveau donc pour l'instant donc forcément vide…

Ce document reflète aussi mes propres limites intellectuelles. Bien que je m'efforce d'étudier
autant de domaines scientifiques et mathématiques que possible, il est impossible de tous les
maîtriser. Le document indique clairement mes propres intérêts et expériences en tant que
consultant, mais aussi mes points forts et mes points faibles. Je suis responsable du choix des
entrées, ainsi que, bien sûr, des éventuelles erreurs et imperfections.

Version Description Dates

V4.12 R1647 Ajout de quelques pistes pour recruter ou identifier un responsable de projet 2011-03-12
selon Adecco Suisse et quelques lignes concernant l'analyse structurelle +
types de comportements de base en réunion.

V4.12 R1648 Ajout de la check-list de la méthode Hermès comme exemple pertinent de ce 2011-03-20
qu'il est possible de faire pour la gestion du cycle de vie d'un projet.

V4.13 R1649 Corrections orthographiques diverses et ajouts de quelques phrases ici et là 2011-03-07
concernant la qualité et la finance de projets.
Ajout de compléments d'informations concernant la partie terminaison
(clôture) de projets et suivi du changement.
Enfin, ajout de quelques remarques au début de la partie bibliographie.

V4.14 R1650 Dans le chapitre où je présente les méthodologies courantes, j'ai complété un 2011-04-08
tout petit peu la partie AMDEC en indiquant les trois grands types d'actions de
maintenance. Toujours dans le même chapitre, j'ai complété dans la partie
concernant les standards ISO la liste des standards que j'utilise presque tous les
jours dans mon travail (suite au fait que la question revient relativement
souvent dans mes cours).

V4.15 R1651 Ajout d'une mini-section concernant l'approche qualitative du risque selon la 2011-04-17
méthode empirique de l'AMDE(C) et listing des normes ISO que je
recommande d'utiliser dans le cadre de projets à forte valeur ajoutée.

V4.15 R1652 Informations mon indépendance relativement aux noms de marques, logiciels, 2011-04-23
livres, normes, etc. que je mentionne dans le présent document.
Ajout d'un chapitre concernant la vente d'un projet lors de la recherche de
partenaires ou d'investisseurs.

V5.0 R1653 Ajout des exercices de basés sur la finance de projets. 2011-05-01

V5.1 R1654 Compléments rajoutés concernant les normes ISO et CEI ainsi que sur 2011-06-20
l'analyse par arbres de défaillance et le bootstrapping.

V5.2 R1655 Ajout d'applications numériques sur la gestion de la qualité et petite 2011-08-01
introduction à la gestion de la connaissance.
Ajout également des 4 styles de communication selon le modèle du
psychologue Jung.

v5.3 R1656 Ajout d'un chapitre concernant l'analyse par arbres d'événements et ajout de 2011-08-04
compléments d'informations concernant les arbres de défaillances
probabilistes.

Ingénierie de Gestion de projets 16/523

[Link]
 Vincent ISOZ

v5.4 R1657 Ajout d'une page me présentant et compléments sur la préface. J'ai également 2011-12-24
revu certains textes concernant Monte-Carlo et la v@r qui pouvaient prêter à
confusion car pas clairement rédigés (j'espère que cela est mieux maintenant).

V5.5 R1660 Correction de quelques fautes d'orthographe et grammaticales + restructuration 2012-01-13

d'un chapitre et ajout de quelques compléments d'informations sur les BPF
(bonnes pratiques de fabrication) et le 5M.

V5.5 R1662 Suite à la demande de clients j'ai rajouté pour chaque méthodologie de gestion 2012-03-16
de projets présentée et que j'ai étudiée en détails le niveau scolaire
correspondant requis pour comprendre et maîtriser la matière.

V5.7 R1664 Ajout de quelques compléments dans différentes chapitres relativement au 2012-04-16
PMBOK ainsi pour @Risk de Palisade dans la partie concernant la simulation
du risque.

V7.0 R1675 Ajout de quelques informations concernant l'utilisabilité des outils de gestion 2013-07-13
de projets conformément à la norme ISO 9241-11 et recommandations dans la
cadre de la phase de storming de l'équipe de projet.
Ajout de quelques illustrations concernant le domaine de la qualité et de la
planification.
Report de quelques exercices du cours sur l'optimisation opérationnelle dans la
section d'exercices (afin de rationaliser le nombre de documents distribués en
cours).

v8.0 R1677 Corrections orthographiques et grammaticales diverses

Ajout d'un tableau des risques courants à considérer dans un projet

v9.0 R1679 Ajout de figures complémentaires concernant ITIL.

Ajout du modèle mathématique décisionnel de l'analyse procédurale
hiérarchique.
Ajout du modèle mathématique de VAN (NPV) par processus binomial
(options réelles).
Changement de l'ordre de certains chapitres

V10. R1680 Ajout de compléments concernant les X.B.S.

Modification du titre du PDF pour indiquer que le contenu est vraiment orienté
pour les scientifiques, ingénieurs et techniciens

Ingénierie de Gestion de projets 17/523

[Link]
 Vincent ISOZ

1.5 Marques déposées

En tant que rédacteur du présent document, je tiens à signaler que je n'ai aucun contrat,
partenariat, affiliation, clause commerciale ou intérêt financier avec les marques déposées ou
noms d'entreprises, méthodes, logiciels et livres que je mentionne dans le présent ouvrage
électronique.

J'ai n'ai donc pas été agréé par qui que ce soit ou quoi que ce soit lors de la rédaction et ma
motivation se situe uniquement dans le but de partager mes opinions et idées personnelles
gratuitement sur quelques sujets élémentaires dans la gestion de projets pour les ingénieurs et
scientifiques.

Si un représentant ou auteur d'une marque, entreprise, logiciel, livre ou image

nommée/représentée dans le présent ouvrage souhaite que j'en supprime toute mention ou
représentation, je m'exécuterai alors immédiatement et m'excuse d'avance de ne pas avoir
demandé l'autorisation faute d'avoir un département juridique à ma disposition pour effectuer
ces démarches.

1.6 Votre avis nous intéresse!

En tant que lecteur de ce document, vous êtes le critique et le commentateur le plus important.
Votre opinion compte et il est très intéressant de savoir ce qui est bien, ce qui peut être mieux
et les sujets que vous souhaiteriez voir être traités.

Vous pouvez m'envoyer un e-mail pour partager ce que vous avez aimé ou détesté dans le
présent document afin d'en assurer une amélioration continue.

Notez que malheureusement, je ne peux pas répondre gratuitement à des questions techniques
d'ingénierie ou de problématique d'entreprise par e-mail pour des raisons professionnelles
évidentes.

E-mail: isoz@[Link]

1.7 Liens internet

Évidemment, le présent ouvrage et MS project ne constituent qu'un référentiel et outil parmi
les nombreux qui existent sur le marché. Pour plus d'informations à ce sujet, nous
recommandons la visite des sites Internet suivants vous proposant diverses informations sur
la gestion de projets ainsi que des plug-ins (payants ou gratuits) pour MS Project Standard/Pro
ou Server:

[Link]
Site de référence concernant les standards dans de nombreux domaines dont la gestion de
projets et de la qualité!

[Link]
Association Française de NORmalisation. Référence en terminologie, méthodologies et
techniques de management dans de nombreux domaines d'activité.

Ingénierie de Gestion de projets 18/523

[Link]
 Vincent ISOZ

[Link]
The Microsoft Project User Group is a dynamic professional association that serves as the
preeminent resource for Microsoft® Office Project. We help a worldwide community
comprised of thousands of individual and corporate members better leverage their investment
in Microsoft Project in their businesses and careers.

[Link]
Site web pour les développeurs MS Project Pro et Server. Attention niveau Expert!

[Link]
Excellent site. Contient en particulier un forum libre d'accès de très bon niveau avec de bons
conseils.

[Link]
Project Management Institute (connu par tous!)

[Link]
Site en français qui ayant pour objectif de regrouper différents travaux de Gaël Gueguen
portant sur les recherches et les enseignements d'un chercheur en sciences de gestion. Il a
donc pour vocation principale le management stratégique des entreprises, leur rapport avec
l'environnement et l'utilisation d'Internet à des fins stratégiques.

[Link]/project
Site en anglais partenaire Microsoft (MVP signifiant: Microsoft Valuable Professional) avec
des liens, des logiciels compagnons, des tutoriaux sur MS Project

[Link]
Site en français portail de la communauté des managers de projets, colloques, conférences,
forums,…

[Link]
Site en français, allemand et italien de l'association Suisse d'Organisation et de Management
(A.S.O.), séminaires, actualité, …

[Link]
Site en français de la société suisse de management de projet, congrès, bibliographies,
actualité,…

[Link]
Site en anglais proposant un logiciel concurrent de MS Project parmi d'autres (intègre une
analyse des risques selon la méthode du PMBOK)

[Link]
Excellent système de gestion de projets en ligne sur Internet. Un bon moyen de substitution à
MS Project Server qui lui nécessite de gros investissements en matière de maintenance
informatique.

[Link]
Logiciel client (qui a priori n'est malheureusement pas disponible au format web) qui semble
être pas mal du tout (en tout cas mieux que la version cliente de MS Project). Mais à vérifier
car je n'ai jamais eu de démonstration détaillée du produit.

Ingénierie de Gestion de projets 19/523

[Link]
 Vincent ISOZ

[Link]
International Project Management Association

[Link]
Forums officiels de Microsoft et en particulier sur MS Project toutes version confondues (une
cinquantaine de langues sont disponibles)

[Link]
Site francophone de référence mondiale sur – entre autres – les techniques mathématiques de
gestion de projets et de production.

[Link]
Site anglophone se décrivant comme société active dans l'étude de la recherche opérationnelle
et les modèles mathématiques de management. La majorité des chercheurs connus dans le
management ont publié dans leur revue.

[Link]
Association Francophone des Ingénieurs Techniciens en Planification et Gestion des risques.

[Link]
Project server expert community site

[Link]/products/ganttnet/projectviewer/[Link]
[Link]/english/Products/PoW/APV_2_6.php?navid=7
Quelque viewers gratuits pour les fichiers MS Project (il en existe des payants aussi en plus
grand nombre…)

[Link]
Un outil de reporting pratique (un petit plus) pour les coordinateurs de projets utilisant MS
Project et souhaitant générer des vues particulières de manière automatique.

[Link]
Un outil venant se greffer à MS Project pour la gestion de risques selon différentes modèles
mathématiques à choix.

[Link]
Un plug-in très intéressant pour MS Project utilisant la méthode Àrince (PM Methodology). A
voir absolument!

[Link]
Propose un utilitaire sympa pour les utilisateurs de MS Office Project Serveur qui font du
Time Tracking.

[Link] / [Link]
Business Process Management Notation pour MS Visio (mais je recommande plutôt le
logiciel BizAgi pour faire cela)

[Link] / [Link]
Excellents outils de modélisation et de dématérialisation de processus (bien meilleur que
MS Visio)

Ingénierie de Gestion de projets 20/523

[Link]
 Vincent ISOZ

[Link]
Très bon site qui explique de manière interactive la gestion de projets en utilisant la technique
de la chaîne critique.

[Link] / [Link] / [Link]

Solution de calculs de gestion des risques et arbres de décision ainsi que d'analyse quantitative
en utilisant les méthodes de Monte-Carlo

[Link] / [Link]
Solution web et multilangue de la gestion de la qualité (processus, indicateurs,
documentation) conforme à ISO 9001 et 14001.

[Link]
Société qui développe le logiciel QuickControl Pro de gestion des contrôles statistiques par
échantillonnage NQA selon les normes ISO 2859 et 3951, correspondant aux normes AFNOR
et MILITARY STANDARD.

[Link]
Pour ceux qui veulent rigoler un bon coup car Adams caricature parfaitement la gestion de
projets, la gestion des ressources humaines et la gestion de la qualité et des relations en
entreprise.

1.8 Bibliographie
Voici la liste de quelques ouvrages parmi une cinquantaine sur la gestion en général que j'ai lu
ces 15 dernières années et dont je me suis fortement inspiré et que je recommande
chaudement (d'ailleurs certains m'avaient aussi été recommandés par des clients ou élèves et
j'ai voulu en vérifier la qualité) soit parce qu'ils sont globalement excellents soit parce qu'ils
contiennent parfois juste quelques pages avec des informations pertinentes (les autres ne
valant pas la peine d'être mentionnés).

Je tiens également à préciser que je ne cache pas que ma contribution se limite en grande
partie à ce jour à celle d'un collectionneur qui glane ses informations dans les ouvrages des
maîtres ou dans les publications ou pages Internet d'anonymes et qui complète et argumente
les développements en les améliorant quand ceci est encore possible. Quant à ceux qui
voudraient m'accuser de plagiat, ils devraient bien réfléchir au fait que les modèles présentés
dans la plupart des ouvrages payants et disponibles dans le commerce ont été découverts et
rédigés par leurs illustres prédécesseurs et que leur propre apport personnel a aussi constitué,
comme le mien, à mettre toutes ces informations sous une forme claire et moderne quelques
centaines d'années plus tard.

Le lecteur aura donc compris que je recommande très fortement de compléter la lecture du
présent e-book (non exhaustif sur le domaine de la gestion de projets) par la liste de lecture ci-
dessous.

Ingénierie de Gestion de projets 21/523

[Link]
 Vincent ISOZ

Guide du Corpus des connaissances en mangement de projet (Guide

PMBOK) / 389 pages / Editions PMI
ISBN: 1930699700

Commentaire: Donne de très bonnes bases conceptuelles et de

vocabulaire sans avoir à consacrer des mois d'études et pour
commencer du bon pied! Très utile pour la culture générale. À garder
dans sa bibliothèque en cas de conflit de principe de méthodes avec
un client ou un collègue.

Référentiel de compétence VZPM (Verein zur Zertifizierung von

Personen im Management) pour le management de projet, de
programme et de portefeuille en conformité avec les compétences
IPMA
ISBN: 9783859280762

Commentaire: Contient des dizaines de pages utiles relatives au

comportement professionnel d'un responsable de projets dans le cadre
de conflits ou de gestion de crise (tables reprises dans le présent
document PDF).

Six Sigma et Minitab (QSB Consulting) / 235 pages / Editions

Quentin Book
ISBN: 9780954681340

Commentaire: Donne un excellent petit aperçu de ce qu'est la

méthode Six Sigma avec des exemples pratiques Minitab.
Malheureusement, les développements mathématiques sont absents
donc le livre n'est pas à mettre entre toutes les mains sinon quoi il
peut être fait un mauvais usage. Un "must" quand même que j'ai
toujours dans ma bibliothèque.

Techniques d'analyse de projets (Gilles Vallet) / 199 pages / Editions

Dunod
ISBN: 2100489127

Commentaire: Donne un bon fil rouge pour l'analyse de projets.

Malheureusement, tire parfois en longueur certains sujets triviaux,
mais complète bien le PMBOK. Quelques pages sur l'ensemble valent
la peine d'être parcourues.

Ingénierie de Gestion de projets 22/523

[Link]
 Vincent ISOZ

Techniques de planification de projets (Gilles Vallet) / 288 pages /

Editions Dunod
ISBN: 2100071807

Commentaire: Très orienté pratique il permet au lecteur de connaître

les techniques de base courantes de la planification comme le Gantt
ou le PERT. Malheureusement, il ne traite que des bases et ne va pas
au-delà de connaissances qui nécessiteraient une licence universitaire.
On trouve facilement l'équivalent gratuitement sur Internet.

Techniques de suivi de projets: Assurer les conditions d'achèvement

d'un projet (Gilles Vallet) / 298 pages / Editions Dunod

Commentaire: Contient quelques "astuces" qui semblent être des

retours d'expérience utiles… Sinon comme tous les ouvrages sur le
sujet, c'est très théorique et applicable uniquement par ceux qui font
de la gestion de projets à 100% de leur temps de travail

Statistique appliquée à la gestion (Vincent Giard) / 560 pages /

Editions Economica
ISBN: 271784659X

Commentaire: Excellent ouvrage pour savoir quels sont les outils

statistiques qui s'appliquent à ce domaine. Seul gros défaut: la
rédaction est trop vieille et la qualité typographique des équations fait
que c'est très difficilement lisible (c'est même parfois
cauchemardesque).

Gestion de la production et des flux (Vincent Giard) / 1128 pages /

Editions Economica
ISBN: 2717844988

Un énorme ouvrage, malheureusement j'ai lu la version de 1988 qui

bien que très intéressante était illisible au niveau des développements
mathématiques. Il paraît que la nouvelle version a été
considérablement revue et augmentée d'exemple pratique avec des
logiciels. Seul petit hic… c'est que dans les organisations en Suisse
quasiment personne ne connaît ses outils statistiques chez les
dirigeants, ce qui fait qu'il est difficile de les appliquer vu le manque
d'intérêt.

Ingénierie de Gestion de projets 23/523

[Link]
 Vincent ISOZ

Processus productifs et programmation linéaire (Vincent Giard) /

112 pages / Editions Economica
ISBN: 2717834931

Recherche Opérationnelle et management des entreprises (Daniel

Thiel) / 183 pages / Éditions Economica
ISBN: 2717819304

Commentaire: Pour moi il s'agit du meilleur ouvrage compréhensible

et applicable dans le domaine de la recherche opérationnelle sans
avoir besoin d'un doctorat en poche. Son seul point noir est d'utiliser
un logiciel spécialisé pour les exemples alors qu'il aurait été mieux de
se restreindre à MS Excel selon moi. Il existe cependant des PDFs
gratuits plus complets avec MS Excel sur le web à notre époque.

Statistique appliquée à la gestion avec exercices corrigés et

utilisation d'Excel (Vincent Giard) / 552 pages / Éditions Economica
ASIN: 2717829628

Statistique descriptive pour les gestionnaires (Vincent Giard) / 122

pages / Éditions Economica
ISBN: 2717828893

Gestion de projets (Vincent Giard) / 160 pages / Éditions Economica

ISBN: 2717821686

Ingénierie de Gestion de projets 24/523

[Link]
 Vincent ISOZ

Mathématiques financières et actuarielles (Jean-Pierre Favre) / 269

pages / Éditions Digilex
ISBN: 29700108110

Commentaire: Excellent livre sur le sujet. Très détaillé, pédagogique

avec des exemples MS Excel ou macros à chaque fois. Un "must" que
j'ai toujours dans ma bibliothèque tellement l'ouvrage est bon.

Investment Under Uncertainty (Avinash K. Dixit) / 482 pages /

Éditions Princeton University Press
ISBN: 9780691034102

Commentaire: De mon point de vue très personnel c'est la bible pour

ceux qui veulent apprendre à évaluer les options d'investissement
dans des projets en utilisant les options réelles.

Calculs commerciaux et bancaires ([Link]. Corbaz, D. Goetschi) / 232

pages / Imprimerie Vaudoise

Commentaires: Excellent petit livre utilisé à l'école obligatoire

Vaudoise dans les années 1980 que j'utilise pour former des employés
ou cadres supérieurs dans les organisations qui ne savent plus
comment faire des règles de trois, des pourcentages, des taux de
change, des rabais et autres calculs élémentaires de ce type… qui
représentent environ 84% du niveau des employés dans les
organisations.

La modélisation du risque et simulations de Monte-Carlo (Hervé

Thiriez) / 214 pages / Éditions Economica
ISBN: 2717848223

Commentaire: C'est un sujet difficile à présenter sans un

accompagnement en classe et un logiciel. Mais Hervé Thiriez s'en
sort pas trop mal pour présenter le sujet. Je n'ai pour l'instant rien vu
de mieux en français à ce sujet. Par contre, une formation présentielle
aura une plus value non négligeable que la simple lecture de cet
ouvrage qui reste très superficiel pour comprendre les subtilités du
domaine de la modélisation.

Ingénierie de Gestion de projets 25/523

[Link]
 Vincent ISOZ

Initiation à la théorie des jeux (Jean-Louis Boursin) / 188 pages /

Éditions Montchrestien
ISBN: 227511069

Commentaire: Bon le livre est intéressant, car il donne quelques cas

pratiques basiques et quelques idées. Malheureusement, sa lecture est
indigeste et la thématique pas très bien structurée ni orientée
entreprise. Je lui préfère nettement le livre sur la modélisation du
risque et simulation de Monte-Carlo de Hervé Thiriez qui contient
aussi des exemples sur la théorie des jeux mais beaucoup plus
réalistes.

Théorie des jeux et analyse économique (G. Demange, J.-P.

Ponssard) / 233 pages / Éditions Economie
ISBN: 2130459730

Techniques de gestion (F. Hémici, M. Bounab) / 234 pages / Éditions

Dunod
ISBN: 210003345X

Commentaire: C'est l'ouvrage avec lequel j'ai commencé dans le

domaine de la gestion de projets, car il est utilisé en licence dans les
Fac de France. Il est orienté calculs uniquement avec très peu
d'explications, mais donne quelques bonnes idées à appliquer dans le
cadre d'un vrai projet. Il est complémentaire aux ouvrages de
statistiques déjà données plus haut.

Éléments de mathématiques appliquées (Vincent ISOZ) / ~4'900

pages / Éditions [Link] (gratuit sur le web)
ISBN: 978283999327

Commentaire: Mon livre sur les mathématiques appliquées. Il n'est

pas encore complet et contient encore quelques coquilles, mais il a
l'avantage de contenir quasiment tous les sujets techniques que le
responsable de projet de niveau Bac+5 en logistique, statistique,
risques et qualité.

Ingénierie de Gestion de projets 26/523

[Link]
 Vincent ISOZ

Contrôle de la qualité - MSP, Analyse des performances, Contrôle de

réception (L. Jaupi) / 284 pages) / Éditions Dunod
ISBN: 2100042645

Commentaire: La référence mondiale francophone sur le sujet selon

moi. Tellement bon et précis qu'il est toujours dans ma bibliothèque à
portée de main (alors que les autres ouvrages que j'ai acheté sur le
sujet ont tout de suite passé dans des magasins de seconde main…).
Cela dit le niveau de lecture requière parfois un bac+3 pour
comprendre toutes les subtilités. Un petit hic cependant: les
démonstrations mathématiques détaillés ne sont pas disponibles (ne
serait-ce qu'en annexe) et il y a quelques petites coquilles mais
facilement identifiables!

A management guide: The EFQM Excellence model for assessing

organizational performance (Chris Hakes) / 110 pages / Éditions Van
Haren
ISBN: 9789087530273

Commentaire: J'avais peur de m'ennuyer en lisant ce référentiel, mais

enfin de compte j'ai été assez agréablement surpris à la fin de
l'ouvrage. Effectivement, j'apprécie beaucoup l'initiative d'un système
de pondération (notes) permettant de juger d'un niveau de
performance comparable d'une organisation au niveau européen.

Statistique chronologique et prévision (Michel Vate) / 254 pages /

Éditions Economica
ISBN: 271782507X

Méthodes de prévision à court terme (Guy Mélard) / 537 pages /

Université de Bruxelles
ISBN: 2800414081

Ingénierie de Gestion de projets 27/523

[Link]
 Vincent ISOZ

Risk and decision analysis in project (John Schuyler) / 259 pages /

Project Management Institute
ISBN: 1880410281

Commentaire: Ce livre de référence pour la gestion du risque dans le

cadre du PMBOK est critiqué par pas mal de spécialiste en
modélisation du risque. Je pense qu'ils ont mal compris l'objectif de
l'auteur qui est de faire découvrir les concepts et non pas de la
maîtriser (et accessoirement de corriger une ancienne erreur du
PMBOK). Par ailleurs, le sujet est très complexe et nécessite une
maîtrise en mathématiques et un coaching présentiel d'où le fait que
donner des exemples pratiques est difficile si on veut tenter de
s'adresse au public le plus large possible. Cela reste donc une bonne
référence pour ceux qui confondent le domaine élémentaire qualitatif
de "l'identification du risque" avec le domaine quantitatif de haut
niveau qu'est la "modélisation du risque".

Six Sigma Statistics (Issa Bass) / 374 pages / Éditions McGraw Hill
ISBN: 0071496467

Commentaires: Excellent livre en anglais orienté pratique sur la

partie calculatoire de Six Sigma avec le non moins fameux logiciel
Minitab. Le livre est tellement bon en termes de pédagogie, de clarté
et d'exemple que je l'ai encore dans ma bibliothèque de nombreuses
années après l'achat.

Statistiques descriptives Exercices (Pierre Bailly, Christine Carrère) /

224 pages / Éditions Libres-Cours
ISBN: 9782706114120

Commentaires: Petit ouvrage pouvant être utile aux formateurs

internes d'entreprise dont les collaborateurs veulent absolument un
support papier. Les exercices sont pertinents.

Management de projet (Jean-Claude Corbel) / 169 pages / Éditions

d'organisation
ISBN: 2708128728

Commentaire: Bon support pour connaître quelques outils

intéressants et théoriques de la gestion de projets. Évidemment on
trouve mieux détaillé et gratuit sur le web mais pour ceux qui aiment
le papier et ne savent pas ce qu'il faut chercher sur Google (ou ne
savent tout simplement pas chercher…) cela reste un excellent début
pour connaître le nom de certaines techniques et procédures
empiriques.

Ingénierie de Gestion de projets 28/523

[Link]
 Vincent ISOZ

Data Analysis and Business Modeling (Wayne L. Winsont) / 598

pages / Éditions Microsoft Press
ISBN: 0-7356-2396-1

Commentaire: Comme MS Excel reste l'outil le plus courant soit pour

faire des statistiques, analyses ou prévisions ainsi que des plannings
pour de petits projets à moins de 20 millions de $ la maîtrise des
techniques avancées de cet outil est indispensable. Ce dernier
ouvrage couvre relativement bien les connaissances que l'ont fait en
MBA dans certaines écoles. Pour les scientifiques et ingénieurs en
gestion de projets le contenu fera plutôt office de rappel des cours de
licence.

Ultimate learning Guide to Microsoft Office Project 2007 (Dale A.

Howard; Gary L. Chefetz) / 920 pages / Éditions MSProjectExperts /
ISBN: 1934240001

Commentaire: Comme tout le reste des ouvrages de la même

collection que ce soit pour la version 2007 ou les versions
antérieures/ultérieures, cet ouvrage est un must pour apprendre ce
logiciel!

Ingénierie de la fiabilité (P. Lyonnet ) / 323 pages / Éditions

Lavoisier
ISBN: 2743008237

Commentaire: L'ouvrage ainsi que son contenu se font vieux… même

très vieux et nécessiterait une bonne réédition. On y trouve cependant
quelques informations de qualité, mais qu'il faut souvent compléter
par de la littérature se trouvant sur des sites Internet. J'ai en grande
partie récrit l'ouvrage dans mon propre livre de mathématiques
appliquées. Cependant, l'achat peut être intéressant sachant que c'est à
ma connaissance le seul livre papier en français à ce jour sur ce sujet.

Fundamentals of Forecasting Using Excel (Kenneth D. Lawrence,

Ronald K. Klimberg, Sheila M. Lawrence) /196 pages / Éditions IP
ISBN: 9780831133351

Commentaire: Excellent ouvrage pratique sur l'analyse prévisionnelle

pour la logistique, la gestion et la planification. Le plus c'est le CD-
ROM avec les fichiers MS Excel qu'il ne reste plus qu'à adapter à ses
besoins. Le moins, c'est le manque de rigueur mathématique et de
démonstrations mais il faut admettre que ce n'est pas l'objectif de
l'ouvrage. Le lecteur doit donc quand même faire attention à être
conseillé judicieusement par un spécialiste dans le cadre de ses
techniques utilisées dans de nombreuses multinationales.

Ingénierie de Gestion de projets 29/523

[Link]
 Vincent ISOZ

Méthodes de gestion de projets informatiques / Référentiel Suisse /

~500 pages cumulées / PDFs gratuits

Commentaire: Un peu trop théorique et idéaliste à mon goût. Reprend

de nombreux concepts d'ITIL et du PMI selon mon avis personnel.
L'intérêt principal est qu'il est effectivement vraiment orienté IT avec
le vocabulaire (pas toujours bien choisi…) et des processus adaptés
(seule raison pour laquelle je fais mention de cet ouvrage dans la
présente liste). Un problème cependant… c'est que l'on voit qu'il est
orienté principalement déploiements et migrations et peu (voir pas du
tout…) sur les développements avec les contraintes industrielles de
fiabilité et robustesse statistiques qui y sont liées. Une trop grosse
part fait appel à des approches qualitatives et on ne peut y trouver
aucune technique du niveau de ce dont a besoin l'ingénieur de projets.
Avantage cependant non négligeable: les documents sont tous
gratuits et disponibles ici: [Link]

Le métier de consultant: Principes, méthodes, outils (P. Stern, P.

Tutoy) / 286 pages / Éditions Eyrolles
ISBN: 9782708128996

Commentaire: Excellent ouvrage aussi bien pour le responsable de

projets qui souhaitent apprendre quelques subtilités avant de
mandater des consultants externes que pour ces derniers eux-mêmes.
Un bon ouvrage pour la culture générale à avoir lu au moins une fois!

Le cygne noir, la puissance de l'imprévisible (N. N. Taleb) /

496 pages / Éditions Les Belles Lettres
ISBN: 978-2-251-44348-5

Commentaire: Sympathique pour la culture générale mais attention à

prendre les opinions de l'auteur avec des pincettes, car vulgariser les
mathématiques amène l'auteur des exemples aberrants et qui peuvent
être considérés par le lecteur non spécialiste comme une preuve
d'opinion.

L'approche processus (H. Brandenburg, J.P. Wojtyna) / 191 pages /

Éditions d'Organisation
ISBN: 2708128884

Commentaire: Le meilleur ouvrage en français que j'ai eu entre les

mains à ce jour concernant ISO 9001.

Ingénierie de Gestion de projets 30/523

[Link]
 Vincent ISOZ

Management de la Qualité (Frédéric Canard) / 257 pages / Éditions

Gualino lextenso
ISBN: 9782297011112

Commentaire: Le meilleur ouvrage en français que j'ai eu entre les

mains à ce jour concernant le domaine de la qualité en général. Sans
être très technique, sans proposer des documents à télécharger sur
Internet, il permet d'acquérir une excellente culture générale sur le
sujet.

Gestion de production (Alain Courtois, Maurice Pillet, Chantal

Martin-Bonnefous) / 457 pages / Éditions d'Organisation (Eyrolles)
ISBN: 2708129864

Commentaire: Quelques pages intéressantes mais curieusement c'est

le seul ouvrage parmi ceux déjà cités qui aborde de façon non
exhaustive des techniques quantitatives fondamentales (différents
modèles mathématiques de gestion de stocks, organisation des flux,
prévisionnel). Cela est probablement dû à l'intervention de
Maurice Pillet en tant que co-auteur...

Guide commenté des normes et référentiels (Gilles Teneau, Jean-Guy

Ahanda) / 383 pages / Éditions d'Organisation (Eyrolles)
ISBN: 978-2-212-54388-9

Commentaire: Très bon petit ouvrage listant avec quelques descriptifs

et retour d'expérience des normes, référentiels, méthodes et modèles
majeures de l'industrie et de l'administration. Sympa à lire et on en
ressort moins ignorant.

Statistical Quality Control (Douglas C. Montgomery) / 754 pages /

6th Edition (Wiley)
ISBN: 978-0-470-16992-6

Commentaire: Montgomery a une renommée d'expert international

dans le domaine de la qualité et ce n'est pas pour rien. Son ouvrage
majeur en est la preuve et à part l'absence de démonstrations
mathématiques est irréprochable.

Ingénierie de Gestion de projets 31/523

[Link]
 Vincent ISOZ

Optimisez votre plate-forme logistique (Michel ROUX, Tong LIU) /

674 pages / 4ème Édition (Eyrolles)
ISBN: 978-2-212-54728-3

Commentaire: Superbe ouvrage très pédagogique et ludique sur la

gestion de la plate-forme logistique (supply chain). Par contre au
niveau mathématique passez votre chemin il n'y a aucune technique
de niveaux supérieur au BAC.

La gestion des opérations (William J. Stevenson, Claudio Benedettit)

/ 819 pages / 2ème Édition (Mc-Graw Hill)
ISBN: 2-7651-0406-9

Commentaire: Superbe ouvrage dans la même trempe que la

précédente c'est-à-dire très pédagogique et ludique sur la gestion des
opérations. Par contre au niveau mathématique le niveau est supérieur
à celui de dessus avec quelques démonstrations, de nombreux
exemple pratiques numériques. Une référence conseillée!

What every engineer should know about decision making under

uncertainty (John X. Wang) / 312 pages / Éditions Marcel Dekker
ISBN: 0-8247-0808-3

Commentaire: Suite à la demande d'un client qui voulait un livre

papier relié plutôt que mon livre PDF sur les techniques relatives aux
techniques décisionnelles pour ingénieurs j'ai du lire ce livre pour
voir le niveau de son contenu. Donc pour résumer: oui c'est le seul
livre papier et relié sur ce sujet à ma connaissance et au jour où j'écris
ces lignes mais les sujets traités ne décollent pas vraiment… À tous
les niveaux mon livre électronique est bien plus complet mais c'est
vrai qu'il est en français…

Ingénierie de Gestion de projets 32/523

[Link]
 Vincent ISOZ

2. Quelques chiffres
Attention!!! Je n'ai pas pu vérifier les données ci-dessous. De plus, certains termes étant
ambigus, les chiffres associés n'ont alors que peu de valeur. La taille des échantillons
statistiques n'étant pas donnée, il n'est aussi pas possible de déterminer l'intervalle de
confiance et donc la variabilité des chiffres. Bref, il faut prendre tous ces indicateurs avec des
pincettes puisque leurs auteurs n'ont pas eu la rigueur scientifique de bien faire leur travail…

Amélioration des résultats financiers induits par une politique d'entreprise orientée gestion de
projets selon enquête du Center for Business Practices ([Link]):

1. Retour sur investissement: ~88%

2. Retour sur capital: ~25%

3. Valeur économique ajoutée: ~76%

4. Augmentation des ventes: ~34%

5. Amélioration de la productivité: ~61%

6. Amélioration en matière de budget de fonctionnement: ~50%

7. Amélioration en matière de délais: ~50%

8. Amélioration de l'utilisation des ressources: ~50%

9. Amélioration en matière de délai de mise sur le marché: ~43%

10. Amélioration de la satisfaction des employés: ~36%

Journal "Le Temps", 15 septembre 2004, page 30, annexe "Le Temps Finance" à propos du
Taux de succès des projets informatiques bancaires:

1. 20% réussissent (concept de "réussir" non défini avec exactitude dans le journal)

2. 35% sont retardés

3. 45% échouent (concept de "échouer" non défini avec exactitude dans le journal)

The Economist, Special Report, 27. Nov. 2004

1. 30% des projets sont arrêtés

2. 50% dépassent le budget

3. 60% sont un échec

4. 90% dépassent les délais

Ingénierie de Gestion de projets 33/523

[Link]
 Vincent ISOZ

Dossier "Gestion de projets", LMI 28 mars 2005 (Source: Standish Group 2003)

1. 44% des projets sont conformes aux prévisions initiales

2. 15% d'échecs purs et simples dans les projets informatiques

3. 43% des projets dépassent les coûts prédéfinis

4. Les projets se terminent à 222% de la durée initialement prévue et à 189% des coûts
budgétés

5. 70% des projets ne remplissent pas les objectifs fonctionnels et qualités

6. 30% des projets sont abandonnés avant leur terme.

Étude en 2009 du Standish Group disponible dans leur rapport CHAOS:

1. 33% des projets sont finis à temps, dans le budget et avec les critères exigés

2. 24% des projets sont abandonnés où sont un échec total

3. 44% des projets sont soit en retard, soient hors budget, soit ne satisfont pas les critères
exigés

Les principales causes d'échec sont:

• Objectifs et spécifications non clairement définies

• Manque de ressources dès le début du projet

• Délais et budgets intenables mais acceptés par peur de dire non

• Politique, égoïsme, existence de "chasses gardées"

• Manque d'expérience en gestion de projets au niveau de la couche supérieure du

management

• Déficiences lors de la phase de planification du projet (non maîtrise des outils

contemporains)

• Mauvaises communication entre le projet et son environnement

• Utilisation de techniques de management de niveau seulement BAC, Licence ou

Master.

• ….

Ingénierie de Gestion de projets 34/523

[Link]
 Vincent ISOZ

Pour être couronnés de succès, on remarque très vite que les projets nécessitent l'existence ou
la mise en place de différentes conditions à leur déroulement. Parmi ces conditions, citons:

• Le soutien écrit absolu et non ambigu de la direction avec le pouvoir décisionnel du

responsable de projet clairement défini.

• Des rôles tenus par les spécialistes, les meilleurs et les plus expérimentés possible
(ayant si possible fait des cursus de plusieurs années en ingénierie de gestion de
projets ou ayant un doctorat dans le domaine). Car c'est effectivement par le manque
de compétences techniques en gestion de projets que ceux-ci sont le plus souvent
insatisfaisants.

• La même compréhension par le donneur d'ordre et la direction du projet, de la taille de

ce dernier et des principales caractéristiques déterminant sont type et sa catégorie.

• Une planification réaliste (probabiliste) des tâches pouvant être maîtrisées dans le
projet, compte tenu des limites fixées en matière de temps, d'argent, de quantité et de
qualité.

• Une grande clarté au niveau des ressources utilisables et des éventuelles restrictions
concernant leur disponibilité au cours du projet.

• Une réponse positive et sûre à la question de savoir si le concept de projet est vraiment
la forme d'exécution appropriée pour atteindre l'objectif visé.

• L'utilisation d'une méthode rationnelle, adéquate et concluante pour le traitement de

tous les résultats correspondant à l'bojectif du projet. C'est-à-dire une méthode telle
que celle proposée par le PMI, l'IPMA, Prince2, ISO 10006, Hermès, DMAIC (Six
Sigma), PDCA, etc.

Ingénierie de Gestion de projets 35/523

[Link]
 Vincent ISOZ

Ceux qui le peuvent font de la science, les autres... de la méthodologie...

J'ai reprise ici un article dont la source est:

[Link]

et qui permettra à des nombreux ingénieurs très compétents techniquement et créatifs de

comprendre pourquoi être un bon gestionnaire (donc métier qui qui à la base consiste à faire
du profit) n'est pas très compatible avec le fait d'être un bon ingénieur ou scientifique à la
base.

[...] Contrairement à l'idée qui a encore cours dans de nombreuses entreprises, le gestionnaire
ne doit pas être créatif. Evolv, une société californienne de big data qui travaille à
l'amélioration des performances des entreprises, a publié, 2013-12-01, son dernier rapport
trimestriel:

[Link]

où il apparaît que les gestionnaires les plus créatifs sont aussi ceux qui connaissent le turn-
over le plus important dans les rangs de leurs employés. Plus ces derniers sont notés par leurs
supérieurs sur une échelle d'innovation et de créativité, moins ils passent de temps dans
l'entreprise.

Effectivement, selon Idris Mootee, PDG du cabinet spécialisé dans l'innovation stratégique
Idea Couture, et auteur de Design Thinking for Strategic Innovation, interrogé par le
New York Times:

«le management, c'est avant tout s'assurer de l'exécution de tâches répétitives tout en
augmentant la productivité des machines et du travail».

Pas grand chose à voir, donc, avec de la créativité. Ni même avec de la polyvalence: un
manager capable d'assumer plusieurs casquettes garde ses employés moins longtemps qu'un
spécialiste.

Selon le rapport d'Evolv, les principales qualités d'un bon gestionnaire sont la pédagogie, le
leadership et l'adaptabilité: au lieu d'établir des stratégies et des plans pour les temps à venir,

Ingénierie de Gestion de projets 36/523

[Link]
 Vincent ISOZ

il est plus rentable, en terme de conservation des salariés, de s'adapter aux changements au
jour le jour. Toujours selon ce rapport, les managers les plus organisés, et donc leurs
subordonnés, ne sont pas aussi performants que les plus communicatifs. [...]

Ingénierie de Gestion de projets 37/523

[Link]
 Vincent ISOZ

3. Erreurs…
C'est impossible, dit la Fierté, C'est risqué, dit l'Expérience, C'est sans issue, dit la Raison Essayons, murmure le Cœur
William Arthur Ward

Après avoir lu plus d'une centaine de livres et de documents de tous types sur la gestion de
projets, la logistique, la finance, la qualité, les risques, le leadership… du niveau Bac au
niveau Bac+7 je constate qu'aucun auteur ne partage les erreurs vécues dans le cadre de ses
propres projets ou de ceux où il a accompagné des clients et ce de manière relativement
détaillée. Or, je pense que c'est surtout cela qui intéresserait les responsables de projets
débutants. Donc voici la liste des erreurs vécues en tant que responsable et consultant en
gestion de projets dans l'ordre des plus fréquents et qui peut être résumée naïvement par les
quatre fondamentaux structurels du Contribution Framework.

où simplement il est indiqué (trivial) que l'échec d'un projet est toujours dû à la présence de
confusion, d'indifférence, de carences et de négligences.

Voici quelques causes fréquentes d'erreurs (l'ordre est complétement aléatoire):

Cause du problème Effet

Aucun support de la direction Les méthodes de gestion, outils et directives
associées ne sont pas imposées à l'ensemble
des employés, ce qui génère un chaos quasi
total et une énorme perte de temps et
d'argent ainsi que des conflits.

Manque des ressources, absence de réserve Le cause est connue de tous donc pas besoin
financière de l'expliciter je pense…

Mauvais outils Les outils de gestion ne sont pas les bons

(gestion documentaire avec un disque
réseau, plannings faits dans un tableur,
communication par courriel, bref
catastrophe connue d'avance).

Formation et expérience insuffisante des La grande majorité des responsables de

intervenants projets ont un niveau intellectuel et de
rigueur insuffisants pour gérer et évaluer
correctement un projet. Donc, les coûts, la
qualité et les délais sont très mal évalués.

Comportement réactif des acteurs du projet La majorité des acteurs du projet travaillent
dans un mode réactif (ne rien faire jusqu'à ce

Ingénierie de Gestion de projets 38/523

[Link]
 Vincent ISOZ

Cause du problème Effet

qu'un facteur externe oblige à réagir) alors
qu'il faut avoir un comportement proactif
(tout le temps en recherche d'amélioration de
l'existant au-delà de ce qui est nécessaire).

Pas de légitimité La direction montre devant les ressources du

projet qu'elle ne fait pas confiance à son
responsable de projet et l'infantilise. Le
responsable est alors décrédibilisé et les
ressources ne prennent pas compte de ses
directives et le projet échoue à tenir ses
objectifs

Compétences Le mandataire n'a pas les compétences pour

exécuter le projet mais l'accepte quand
même ce qui produit souvent des explosions
de coûts et délais. À noter que parfois
l'inverse se produit: le mandataire et trop
compétent et donc demande trop de détails
aux clients ou est trop exigeant envers ce
dernier ce qui provoque des tensions.

Pas de procès-verbal des réunions, conflits Aucune traçabilité des promesses ou

ou autres objectifs ce qui génère encore plus de conflit
et de chaos dans le projet.

Terminologie non rigoureusement définie, Les requêtes et explications ne sont pas

discours vague. claires car ni le client, ni le manager n'ont un
discours rigoureux et ne définissent
correctement les mots qu'ils utilisent n'y ne
posent les hypothèse de fonctionnement.
Conséquences: mauvaises interprétations,
travail incorrect, problèmes de
communication.

Mauvaise implication des ressources Certains responsables de projets font croire à

leurs ressources qu'ils les impliquent dans un
projet en leur demandant leur avis pour finir
par imposer finalement toujours le leur en
faisant de la négociation par bout de
chandelle…

Réunions périodiques avec le client non Les projets n'ont souvent pas de cahier des
planifiées charges en interne et donc de nouvelles
attentes apparaissent lors de l'avancement du
projet que le mandataire (prestataire) n'avait
pas exprimé correctement au début. Des
réunions régulières où l'on présente
l'avancement du livrable permettraient d'y

Ingénierie de Gestion de projets 39/523

[Link]
 Vincent ISOZ

Cause du problème Effet

remédier.

Peur de demander au client un cahier des Des imprévus arrivent constamment pendant
charges détaillé la réalisation du projet car le client n'ayant
pas réfléchi avant il change ses exigences en
cours de route. Cela a pour effet d'exploser
les délais et les coûts du projet et d'énerver
les ressources ainsi que les responsables du
projet.

Pas de standard de management mis en Un peu plus de 99% des organisations

place utilisent la méthode La Rache pour gérer
leurs projets. Donc le livrable ainsi que
l'ambiance au sein de l'organisation sont à
l'image de cette méthode…

Pas de scénarios créés La quasi-totalité des responsables de projets

ne savent pas qu'il faut faire au moins 3
voire 4 scénarios d'un projet, voire au mieux
une simulation de Monte-Carlo ou par
Bootstrapping avec une probabilité cumulée
à 95% au moins. Dans le cas contraire, nous
nous retrouvons alors avec des objectifs qui
n'ont qu'une chance sur deux d'être respectés
et des réponses à appel d'offre (et les forfaits
associés) qui n'ont aucune rigueur.

Oubli des absences des ressources et du Le responsable de projet prend plusieurs

temps de travail effectif mois de retard dans son projet (et les coûts
qui vont avec) car il a oublié d'intégrer les
vacances, les jours de congé maladie, jours
de congé enterrement familial, jours de
congés maladie des enfants, le service
militaire, les congés maternité éventuels ou
encore l'impossibilité d'avoir un taux effectif
à 100% de ses ressources dans le projet…

Mauvais outils utilisés La grande majorité des organisations

utilisent un tableau pour gérer un projet ou
un planning. C'est bien évidemment une
grave erreur qui ne souffre d'aucune excuse
puisqu'il existe des logiciels de gestion de
projets gratuits. L'utilisation des tableurs
engendre des erreurs de calculs, des
problèmes de mise à jour et un suivi
impossible des ressources de manière
satisfaisant et ne respecte surtout aucun
standard.

Mauvaise communication et outils de Les différents médias de communications ne

Ingénierie de Gestion de projets 40/523

[Link]
 Vincent ISOZ

Cause du problème Effet

communication sont pas centralisés dans un pot commun.
Donc, chaque intervenant a des infos dont il
fait une rétention involontaire qui peut
amener à des graves anomalies avec le
mandant (soumissionnaire) et le mandataire
(prestataire).

Temps insuffisant réservé pour le suivi, la Erreurs multiples dans l'estimation des
préparation, les réunions, la gestion des durées, des coûts, des ressources, dans la
conflits, la documentation.... communication avec le client et la qualité.
Documentation, cahier des charges non
effectués donc aucun suivi possible à long
terme. Pas de réunions planifiables pour
faire le point sur les jalons (inexistants de
toute manière…). Donc le projet va au
fiasco!

Les commerciaux ont vendu une durée de Conflits internes dus au non-respect des
projet sans avoir demandé au responsable de processus et formation des commerciaux
projet et exécutant au préalable sur la insuffisante relativement à leur esprit
faisabilité. d'analyse et leur honnêteté vis-à-vis du
client.

Compétences des ressources non vérifiées Travail bâclé ou ne correspondant pas au

livrable attendu. Il peut arriver qu'il faille
toute refaire.

Pas de backup des ressources ou de Une ressource indispensable est absente et

maintenance préventive (AMDEC) bloque tout le projet. Une machine tombe en
panne et il n'y a rien de prévu pour la
remplacer ce qui engendre des coûts
considérables et une image qu'il sera très
difficile à relever.

Le client effectue des manipulations sur le Le client accuse à tort le fournisseur. Au

produit qui ne font pas partie du cahier des fait, il ne faut jamais oublier de former les
charges initial. utilisateurs au produit final quel qu'il soit!

Le responsable de projet a un Master alors Au fait ils sont aussi mauvais que les autres.
s'estime bon. Un responsable de projet de haut niveau doit
posséder un doctorat ou l'équivalent d'un
bac+7 dans un domaine des sciences exactes
avec au moins 10 années d'expérience dans
une organisation en tant qu'employé normal
avant de devenir responsable de projet.

Dans l'idéal, il faut faire passer un test de

logique, de capacité d'analyse et de
raisonnement à tout responsable de projet.

Ingénierie de Gestion de projets 41/523

[Link]
 Vincent ISOZ

Cause du problème Effet

Le niveau de délégation (pouvoir Cela peut amener le responsable de projet à
décisionnel) n'a pas été clairement défini. prendre des décisions qui seront par la suite
rejetées par la direction qui souhaitait au fait
implicitement une validation.

L'organisation interne s'autoproclame En réalité c'est souvent le chaos et les

comme satisfaisante voire excellente instances dirigeantes ne connaissent pas les
certifications ISO ou des méthodes
d'appréciation comme EFQM. Après en
avoir pris connaissance ils tombent de très
haut...

Pas de culture de gestion de projets au sein La gestion se fait à l'arrache et ils n'ont
d'une grande entreprise et pas d'employé(s) jamais lu d'ouvrage complet sur le sujet
dédié(s) uniquement à cette tâche (comme celui que vous êtes en train de lire
spécialisée. par exemple).
Tableau 1 Erreurs rencontrées

Ingénierie de Gestion de projets 42/523

[Link]
 Vincent ISOZ

4. N.R.M.M.
Les N.R.M.M. (Normes, Référentiels, Méthodes et Modèles) de gestion de projets existent
depuis environ le début des années 1950. Les normes sont des exigences alors que les
référentiels sont des recommandations. Les méthodes et les modèles sont des outils qui
servent aux référentiels ou aux normes dans le cadre du Système de Management de la
Qualité de la Sécurité et de l'Environnement (S.M.Q.S.E.).

Certaines mauvaises langues (qui n'ont pas vraiment tord sur le fond...) disent que les normes
sont des outils mis en place par de gros groupes industriels pour empêcher des petites PME
innovantes de pouvoir les concurrencer (sachant que le respect de certaines normes
nécessitent des investissements financiers considérables). De même d'autres disent aussi (et ils
n'ont pas vraiment tord non plus dans certains cas...) que les standards et les normes sont des
outils mis en place par les gouvernements pour créer artificiellement de l'emploi administratif
dans un monde surpeuplé...

Par exemple, la méthode P.D.C.A. est utilisée par des nombreuses normes et référentiels. Les
modèles sont quant à eux des outils simples tandis que les méthodes sont souvent plus
complexes. Certaines méthodes se suffisent à elles-mêmes, c'est le cas pour Six Sigma.

Il est cependant regrettable de constater que c'est malheureusement devenu principalement un

business très lucratif en termes de formations, de certifications et de débouchés commerciaux
(consulting sur mandats, produits dérivés, livres, etc.) vendus comme des solutions quasi
miraculeuses à tous les problèmes. Leur nombre est aussi devenu un problème comme en
atteste la cartographie ci-dessous pour les normes et référentiels:

Ingénierie de Gestion de projets 43/523

[Link]
 Vincent ISOZ

Figure 1 Cartographie normes et référentiels (source ISBN 978-2-212-54388-9)

et pour les méthodes et modèles:

Ingénierie de Gestion de projets 44/523

[Link]
 Vincent ISOZ

Figure 2 Cartographie méthodes et modèles (source ISBN 978-2-212-54388-9)

La quasi totalité des N.R.M.M. sont triviales à apprendre (niveau Bac et encore...) et ne
nécessitent pas obligatoirement de formations (un bon livre suffit). La difficulté réside dans
leur mise en place à cause de l'inertie de l'environnement dans lequel se trouve le responsable
de projets (souvent pas absence d'appui de la direction au plus haut niveau).

NRMM Définition Exemples

Norme Document de référence sur un sujet ou un ISO 9001:2000, ISO
domaine donné en accord avec la 14001:2004, ISO/IEC
réglementation nationale (norme suisse, 27001, SA 8000, ISO 31000,
européenne ou internationale). etc.
Certification de l'entreprise obligatoire
dans bien des cas mais audits
malheureusement pas indépendants.
Référentiel Standard ("best practice" du métier...) ITIL V2/V3, COBIT,
reconnu par des professionnels du domaine CMMi, IPMA; PMI,
et qui se réfère souvent à une norme. Zachmann, etc.
Certification des personnes dans bien des
cas.
Méthode Ensemble des démarches formalisées selon AMDEC, BSC, Kaizen,
des principes, dans le but d'acquérir un Six Sigma, etc.
savoir-faire conforme aux objectifs
attendus. Utilisation de la méthode à
travers l'entreprise ou une partie de

Ingénierie de Gestion de projets 45/523

[Link]
 Vincent ISOZ

l'entreprise.
Modèle Outil qui, grâce à ses caractéristiques, ses Ishikawa, Pareto, Chaîne de
qualités, son utilisation, peut servir de la valeur, 5S, 8S, 5P,
référence à l'imitation ou à la reproduction. SWOT, etc.
Application du modèle pour un domaine
ou une activité de l'entreprise
Tableau 2 NRMM

Le praticien professionnel ne doit lui jamais oublier que des "standards" sont bien
évidemment rarement adaptés totalement à leurs cas pratiques réels exceptés s'ils sont
imposés par des normes nationales ou internationales… (en France, en 2001, sur plus de
21'000 normes, seulement et malheureusement... 240 sont obligatoires).

Il faut voir les méthodologies et standards à la mode plutôt comme des best practices
(meilleures pratiques2/best practices) fonctionnant relativement bien et permettant d'éviter des
erreurs triviales qu'il faut démonter pour créer son propre standard adapté à ses besoins et aux
contraintes de son entreprise: avoir une bonne méthode de management standardisée et testée
constitue aussi la base d'une bonne gestion de projets (tout en évitant "l'obstruction
méthodologique")! C'est par ailleurs ainsi que de nombreuses méthodes connues
mondialement ont vu le jour!

2
Encore faudrait-il définir mathématiquement cette notion de "bonne pratique" ce qui est facilement possible
mais dépasse le contexte de cet ouvrage.

Ingénierie de Gestion de projets 46/523

[Link]
 Vincent ISOZ

Standardisation

Qualité

GESTION
EFFICACE DE PROJETS

Coûts Délais

Nous nous proposons ici de donner une liste non exhaustive (dans l'ordre qui semble à priori
des plus connus) avec une brève description des formations et méthodes que nous avons
rencontrées dans le cadre de nos expertises dans le management.

Nous pouvons dire que chacune de ces méthodes respecte une approche conforme aux 7S
mais en mettant l'accent plus sur certains points que d'autres:

 La stratégie (strategy)
 La structure (structure)
 Le système (système)
 Le style de management (style)
 Les ressources humaines (staff)
 Le savoir-faire (skills)
 Les valeurs partagées (shared values)

Enfin, rappelons que selon le BABOK, le business analyst et donc aussi un peu le
coordinateur de projets devraient choisir les méthodes et outils de gestion en fonction de la

Ingénierie de Gestion de projets 47/523

[Link]
 Vincent ISOZ

disponibilité des outils, de leurs limitations, des standards organisationnels, des contraintes
temporelles et du budget.

4.1 IREB

En ingénierie, et plus particulièrement dans les procédures d'appel d'offres, les exigences sont
l'expression d'un besoin documenté sur ce qu'un produit ou un service particulier devrait être
ou faire.

Dans l'approche classique de l'ingénierie, les exigences sont bien évidemment considérées
comme des prérequis pour les étapes de conception et de développement.

Le coût de correction des erreurs de spécification augmente bien évidemment avec le délai de
détection et les erreurs de spécification sont souvent découvertes très tard ou après la mise en
production.

L’ingénierie des exigences a un impact significatif sur la réussite du projet. Elle délimite
l’étendue du projet et établit une base de communication commune à toutes les parties
impliquées dans un projet. La maîtrise de la définition des exigences aboutit à des solutions
conformes aux besoins et permet ainsi une diminution des coûts et des risques d’échec.

L'IREB a établi un cadre professionnel de pratiques et de savoir-faire dans le domaine de

l'ingénierie des exigences qui assure:

 Une compréhension commune de l'ingénierie des exigences au sein d'une entreprise et

entre les parties prenantes aboutissant ainsi à une communication beaucoup plus
efficace; on sait de quoi on parle
 Une augmentation de la qualité des livrables des projets par la définition des exigences
basée sur un modèle éprouvé et compris
 Une réduction des coûts de développement et un respect des délais
 Une meilleure transparence sur les compétences des ingénieurs et les analystes
business exerçant dans le domaine de la définition des exigences. Le niveau de
certification donne une description précise des compétences requises par un poste de
travail et du degré de compétences d’une personne.

Formation: ~4 jours
Niveau: Bac
Source: [Link]

4.2 ISO 10006:2003

Ingénierie de Gestion de projets 48/523

[Link]
 Vincent ISOZ

L'ISO 10006:2003 donne des conseils sur l'application du management de la qualité aux
projets. Elle est applicable à des projets de complexité variable, qu'ils soient petits ou grands,
de courte ou longue durée, qui se situent dans des environnements différents, quel que soit le
type de produit ou de processus de projet. Il peut être bien évidemment nécessaire d'adapter
ces conseils à un projet précis.

Ce standard ne constitue cependant pas un guide pour le management de projet en lui-même,

mais se contente de donner des conseils sur la qualité dans le cadre des processus de
management de projet alors que l'ISO 9004 donne des conseils sur la qualité dans le cadre des
processus relatifs au produit du projet et sur l'approche processus.

Il convient de noter que le présent standard international est un recueil de conseils et qu'elle
n'est pas destinée à être utilisée pour des besoins de certification/enregistrement.

Formation: ~1 jour par code ISO

Niveau: Bac
Source: [Link]

Remarque: Personnellement, j'utilise le plus possible dans mes projets les standards suivants
(j'ai listé car on me le demande relativement souvent dans mes cours):

 ISO-8859-1: Pour les caractères utilisés dans les noms de fichiers et pour les dossiers
électroniques

 ISO 9660 (niveau Bac): Servant de base pour les règles de nommage des fichiers et
dossiers de projets qui nécessitent un travail multiplateforme et avec une comptabilité
sur tout système informatique (malheureusement peu respecté en toute rigueur!).
Ainsi, il est d'usage d'essayer de respecter au mieux les règles suivantes dans les
projets en ce début de 21ème siècle:

- Un seul "." séparant le nom de l'extension et aucun point dans les noms de dossiers

- Les dossiers sont en majuscules et ne comportent eux aucun point

- Les fichiers auront une majuscule pour la première lettre de chaque mot, le reste
étant en minuscule

- L'extension peut être sur 1 à 4 caractères et toujours en minuscules

- Maximum 106 caractères pour les noms de fichiers (y compris extension) ou dossiers

- Les noms ne doivent pas commencer par un chiffre

- Les espaces seront remplacés par des "underscores" (mais on peut les remplacer les
underscores la majorité du temps par l'obligation de commencer chaque terme dans le
nom des fichiers avec une majuscule, le reste étant en minuscule)

- Il ne devrait pas y avoir d'accents dans les noms de fichiers

- Les caractères suivants sont proscrits: ?!#+"%&/\()=][$€{}-;:*><,'~|@°£

Ingénierie de Gestion de projets 49/523

[Link]
 Vincent ISOZ

Remarque: Si nous rajoutons ISO 9001 aux noms de fichiers, ceux-ci peuvent dans
certains cas comporter dans le nom du fichier l'abréviation de la langue du contenu sur
deux lettres (FR, EN, DE, …), l'identifiant unique au début du nom de fichier (IDC1,
IDP1, IDR1,…) et juste avant le point séparant le nom de l'extension, le numéro de la
version majeure (V1, V2, V3,…) avec l'indication de la version mineure séparée par
un underscore (V1_3, V3_4) et enfin avec le numéro de révision (V1_3r14, V1_0r3).
Il y a donc au minimum déjà 12 caractères sur les 26 pris rien que pour avoir une règle
de nommage normalisée correcte. Enfin, pour les dossiers, il est déconseillé d'avoir
plus de 8 niveaux imbriqués.

 ISO 216 (niveau Bac): Pour les formats de papier (bon ça c'est facile mais j'ai déjà vu
des entreprises qui avaient des responsables de projets travaillent avec des formats de
papier exotique par manque de maîtrise des logiciels de traitement de texte)

 ISO 690 (niveau Bac): Pour les cartouches au début de chaque document important
(indiquant l'auteur, le responsable, la version, le référentiel, le niveau de
confidentialité, l'année, l'identificateur, etc.). Certains des documents électroniques
fournis pendant le cours ont une cartouche conforme ISO 690 pour être par la suite
référencés correctement. Plusieurs méthodes de gestion de projets recommandent
implicitement de suivre cette norme.

 ISO 639.2 (niveau Bac): Pour les métadonnées concernant l'identification des langues
de documents.

 ISO 4217 (niveau Bac): Pour respecter les symboles des formats monétaires dans mes
offres et dans les logiciels de simulation.

 ISO 5807 (niveau Bac à Bac+5): Pour schématiser et documenter des processus
(logigrammes). Parfois je dévie cependant sur du BPMN (Business Process
Management) ou de l'AdP (Arbre de défaillance Probabilistes) que je présenterai
sommairement plus loin dans le document.

Pour avoir plus de détails, il suffit d'acheter le PDF sur le site internet [Link] ou de
suivre mon cours sur le sujet (la première option étant plus simple et moins onéreuse).

 ISO 9001 (niveau Bac à Bac+1): Pour tout ce qui a trait à la qualité sous forme
généraliste (série de normes ISO 9000).

Pour avoir plus de détails, il suffit d'acheter le PDF sur le site internet [Link] ou de
suivre un cours sur le sujet (la première option étant plus simple, moins onéreuse et
plus rigoureuse). De toute façon même si vous suivez une formation ISO 9001 vous
devrez obligatoirement acheter et lire le PDF. Indiquons que la norme ISO 9001
regroupe les normes ISO 9001, 9002 et 9003 qui existaient en 1994.

 Norme AFNOR NF Z 12.001 (niveau Bac): Pour tout ce qui est relatif aux
organigrammes puisqu'il n'existe pas à ma connaissance (malheureusement!) de
standard ISO pour cela.

La documentation à ce sujet disponible sur Internet à ce jour est suffisante.

Ingénierie de Gestion de projets 50/523

[Link]
 Vincent ISOZ

 ISO 3951 (niveau Bac+3 à Bac+5): Pour tout ce qui est relatif aux contrôles de
réception de lots ou aux contrats incluant des clauses de qualité basées sur des plans
d'échantillonnages aux mesures. Cependant, je lui préfère son équivalent français
qu'est l'AFNOR X06-023.

Pour avoir plus de détails, il suffit d'acheter le PDF sur le site internet [Link] ou de
suivre un cours sur le sujet (la première option étant plus simple et moins onéreuse).
De toute façon même si vous suivez une formation sur le sujet, vous devrez
obligatoirement acheter et lire le PDF. Vous trouverez sur Internet aussi une large
documentation que j'ai écrite avec presque toutes les démonstrations mathématiques à
ce sujet.

 ISO 2859 (niveau Bac+3 à Bac+5): Pour tout ce qui est relatif aux contrôles de
réception de lots ou aux contrats incluant des clauses de qualité basées sur des plans
d'échantillonnages aux attributs. Cependant, je lui préfère son équivalent français
qu'est l'AFNOR X06-023.

Pour avoir plus de détails, il suffit d'acheter le PDF sur le site internet [Link] ou de
suivre un cours sur le sujet (la première option étant plus simple et moins). De toute
façon même si vous suivez une formation sur le sujet vous devrez obligatoirement
acheter et lire le PDF. Vous trouverez sur Internet aussi une large documentation que
j'ai écrite avec presque toutes les démonstrations mathématiques à ce sujet.

 ISO 8258 (niveau Bac+3 à Bac+5): Pour tout ce qui est relatif aux cartes de contrôles
les plus communes dans le domaine la maîtrise statistique des procédés et processus.

Pour avoir plus de détails, il suffit d'acheter le PDF sur le site internet [Link] ou de
suivre un cours sur le sujet (la première option étant plus simple, moins onéreuse et
plus rigoureuse). De toute façon même si vous suivez une formation sur le sujet vous
devrez obligatoirement acheter et lire le PDF. Vous trouverez sur Internet aussi une
large documentation que j'ai écrite avec presque toutes les démonstrations
mathématiques à ce sujet.

 ISO 9126 (niveau Bac): Qui bien qu'adressée au domaine du logiciel peut s'appliquer
à mon avis à beaucoup d'autres. Cette norme précise pour le produit fini certaines
caractéristiques précises et très pertinentes (mais qui peuvent aussi donc être utilisées
pour vérifier que la description du projet est suffisamment complète). Nous en
donnerons une description sommaire plus tard dans le présent document.

 ISO 31010 (niveau Bac à Bac+7): Je ne suis pas un fan de l'ISO 31000 pour la gestion
des risques bien que certains concepts (mais en très faible nombre) soient intéressants.
Je préfère me baser sur la norme ISO 31010 d'évaluation des risques que j'utilise assez
souvent pour analyser les erreurs de défaillances potentielles (Ishikawa, AdP Six
Sigma), la modélisation du risque (Monte-Carlo) et les arbres de décision (arbres de
Markov).

 ISO 80000 (niveau Bac à Bac+3): J'essaie d'utiliser cette série de normes lorsque je
fais de la mathématique appliquée à la gestion de projets (donc la majorité du temps au
fait...) puisqu'elle définit les notations standard pour les symboles mathématiques.
Dans la gestion de projets, il est particulièrement important d'utiliser les bonnes
notations dans les domaines de probabilités et statistiques (norme que j'avais par
Ingénierie de Gestion de projets 51/523
[Link]
 Vincent ISOZ

méconnaissance dans ma jeunesse pas suivie... mal m'en a pris!) et dans l'usage des
unités (certaines agences spatiales l'ont appris à leur dépend aussi...).

 ISO 10015 (niveau Bac): Donne un guide minimum pour la formation des ressources
afin d'adapter leurs compétences aux besoins du projet. Le problème de cette norme
cependant est qu'elle est un peu trop sommaire. Il manque des points importants, mais
moins cela peut servir de base au responsable de projet qui n'a jamais eu à gérer la
formation dans le cadre d'un projet.

 ISO 8601 (niveau Bac): Donne le format de date et heure international dans lequel une
date ou une heure devrait être écrit sur tout système ou support. Pas facile à respecter
tous les jours d'autant que la majorité des éditeurs de logiciels et fabricants d'appareils
ne jouent pas le jeu…

Cette norme ISO impose aussi la manière de compter les semaines dans une année:

- la semaine commence le lundi

- les jours de chaque semaine sont numérotés de 1 pour le lundi, à 7 pour le dimanche

- la semaine 1 est celle qui contient le premier jeudi de l'année

La semaine 1 est ainsi la première à contenir la majorité de ses jours (au moins 4
jours) dans l'année. Elle contient systématiquement le 4 janvier. Elle contient
systématiquement le premier jour ouvré de l'année en considérant que le 1er janvier,
les samedis et les dimanches sont chômés. C'est aussi celle dont le lundi est le plus
proche du jour de l'an. Elle commence au plus tôt le 29 décembre ou au plus tard le 4
janvier.

Ingénierie de Gestion de projets 52/523

[Link]
 Vincent ISOZ

 ISO 9241-11 (niveau Bac): Donne les règles de décision permettant de déterminer si
un système est utilisable. C'est-à-dire lorsqu'il permet à l'utilisateur de réaliser sa tâche
avec efficacité, efficience et satisfaction dans le contexte d'utilisation spécifié. Souvent
les employés dans les entreprises font l'acquisition d'un produit (logiciel) sans
s'informer sur ces points ce qui est assez grave pour des gens censés être des
professionnels d'autant plus que la majorité des mes clients sont des multinationales...

Bref en gros en 2014 les normes relatives à l'analyse statistique peuvent se résumer avec la
cartographie disponible sur le lien suivant:

[Link]

Et pour résumer les normes ISO à elles seules avec une touche d'humour (création personnelle
après une discussion difficile avec un client):

4.3 PMI

Le Project Management Institute, fondé en 1969, est une association professionnelle à but
non lucratif qui propose des méthodes de Gestion de projet. Son siège est à Philadelphie en
Pennsylvanie (États-Unis), elle compte plus de 200'000 membres répartis dans 125 pays. Elle
publie des standards relatifs à la gestion de projets et est en charge de la certification des
processus de gestion de projet.

Le PMI est aussi très connu pour sa formation et son ouvrage PMBOK: Project Management
Body Of Knowledge (pendant de la norme ISO 10006) qui s'essaie à définir les compétences
d'un responsable de projets et les processus relatifs à une bonne gestion de projets. C'est un

Ingénierie de Gestion de projets 53/523

[Link]
 Vincent ISOZ

excellent référentiel pour en très peu de temps éviter les grandes erreurs classiques et
également se rendre compte qu'il s'agit d'un métier (même si la majorité des entreprises et la
personne lambda en début de 21ème siècle ne l'ont visiblement pas encore compris3)!

À ce titre, le terme PMI est souvent utilisé pour définir la méthodologie de gestion de projet
défendue par le Project Management Institute dont les fondements reposent sur 9 domaines de
connaissance (intégration, contenu, délais, coûts, qualité, ressources humaines,
communication, risques, approvisionnements) et 44 processus y relatifs (le nombre de
processus évolue en fonction de la maturité du modèle et donc avec les années...).

Selon leur modèle le projet est découpé en 5 phases: l'initialisation, la planification,

l'exécution, la maîtrise (ou suivi) et enfin la clôture (avec le rapport de revue post-
implémentation) rassemblés dans un processus global dont voici un aperçu (certes ce n'est pas
très lisible mais vous pourrez l'étudier lors de l'achat du livre):

Il existe à notre connaissance deux niveaux de certifications reconnus et standardisés à

l'internationale: CAPM (Certified Associate Project Manager) et PMP (Project Management
Professional).

3
Voir la thèse en anglais de Paul Giammalvo disponible gratuitement au format électronique sur le web (PDF):
Is project management a profession? And if not, what is it?

Ingénierie de Gestion de projets 54/523

[Link]
 Vincent ISOZ

Formation: ~4 jours pour le PMBOK + ~5 jours pour le PMP

Niveau: Bac à Bac+2

Source: [Link]

Ingénierie de Gestion de projets 55/523

[Link]
 Vincent ISOZ

4.4 Six Sigma (ISO 13053-1:2011)

Six Sigma ou 6 Sigma (devenu entre-temps ISO 13053-1:2011) est une marque déposée de
Motorola4 et désignant une méthode structurée de management visant à une amélioration de
la qualité (éliminer les défauts et la variabilité en utilisant des outils statistiques avancés) et de
l'efficacité des processus (éliminer le gaspillage, l'inutile, automatiser et rationaliser le
répétitif, éviter la redondance, optimiser la production excessive de bien ou de documentation,
s'interroger sur la pertinence des tâches, les mouvements ou déplacements inutiles, etc.: lean).

La méthode Six Sigma a d'abord été appliquée à des procédés industriels avant d'être élargie
grâce au travail de chercheurs du MIT (une des meilleures écoles d'ingénierie du monde!) à
tous types de processus, notamment administratifs, logistiques, commerciaux et d'économie
d'énergie. Depuis le début des années 2000, elle connaît un grand essor en raison de la
complexité des organisations et de l'internalisation des processus qui imposent une vision
globale des problèmes.

La méthode Six Sigma (ISO 13053-1:2011) se base sur une démarche fondée à la fois sur la
voix du client (enquêtes, etc.) et sur des données mesurables (par indicateurs) et fiables (sous
contrôle statistique) le tout géré comme un vrai projet. C'est une méthode qui ne peut être

4
En 1981, Bob Galvin Président de MOTOROLA lance une démarche de maîtrise de la dispersion de la
production afin d'accroître les performances de l’entreprise. En 1985, un ingénieur de MOTOROLA, Bill Smith,
pose les bases de la démarche 6 sigma par l'usage des statistiques.

Ingénierie de Gestion de projets 56/523

[Link]
 Vincent ISOZ

appliquée que par des personnes ayant une formation universitaire pointue dans des
entreprises leader de leur marché car sa mise en pratique rigoureuse nécessite des
compétences logiques, mathématiques et techniques infiniment plus pointues que toutes les
autres méthodes citées dans le présent document.

Le principe de la méthode consiste à faire en sorte que tous éléments issus du processus
étudié, soient compris dans un intervalle s'éloignant au maximum de 6 Sigma par rapport à la
moyenne générale des éléments issus de ce processus. En réduisant la variabilité des produits
du processus, on réduit le risque de voir le produit (ou service) rejeté par son destinataire car
en dehors de ses attentes ou spécifications. Le principe vise donc à travailler sur le processus
afin que seuls des produits conformes aux exigences soient livrés: produire juste dès la
première fois en éliminant les coûts liés aux retouches, recyclage, mise au rebut et risque de
vente d'un produit non conforme.

surproduction
(les 5 pourquoi)

Déplacements-
Organisation Mouvements
(5S/Kaizen) (détrompeurs
Poka Yoke)

les 7 gaspillages

Défauts de qualité
(SPC: Statistical Stocks/Flux (Kanban)
Process Control)

Sur-traîtements Attente
(VSM: Value Stream (SMED: Single Minute
Mapping) Exchange of Die)

Remarque: Pour le SMED (Single Minute Exchange of Die) pensez par exemple au temps de
changement d'une roue entre une personne non entraînée à faire les bons gestes et à utiliser les
bons outils et une personne qui l'est!:

Ingénierie de Gestion de projets 57/523

[Link]
 Vincent ISOZ

La méthode se base sur 5 étapes qui se contractent dans l'acronyme DMAAC (ou DMAIC en
anglais) pour: Définir, Mesurer, Analyser, innover/Améliorer (Improve en anglais) et
Contrôler.

et utilise pour cela de nombreux outils (certains basiques comme les diagrammes d'Ishikawa
ou de Pareto et certains autres beaucoup plus complexes5).

Il existe 4 niveaux de reconnaissance de Six Sigma qui suite à des accords entre entreprises
commencent à être reconnus au niveau international depuis 2005 et qui sont: le Green Belt
dont on attend qu'il consacre partiellement son temps (souvent autour de 25%) à la conduite
de projets d'amélioration, le Black Belt qui est un responsable d'équipe se consacrant à plein
temps à l'amélioration et doit maîtriser la méthode dans son ensemble, le Master Black Belt
qui est mentor et formateur de Blacks Belts, garant du respect de la démarche et enfin le
Deployment Leader ou Champion, chargé d'élaborer la stratégie, le contenu de la formation,
les budgets, etc.

5
Voir mon livre sur le Génie Industriel et les Techniques de Gestion car le sujet est trop vaste pour être abordé
dans la présent ouvrage.

Ingénierie de Gestion de projets 58/523

[Link]
 Vincent ISOZ

4.4.1 Lean Six Sigma

Le lean Six Sigma peut se résumer grossièrement à une image:

Ceci n'est pas un processus "lean" car il y a beaucoup d'étapes non automatisées et le goût du
café dépendra de la personne qui le prépare (processus variable). Malheureusement je
n'insisterai jamais assez: le lean ne s'applique pas qu'aux ateliers de production/fabrication
mais devrait surtout s'appliquer aux départements administratifs où il y a selon mon
observation beaucoup trop d'activités faiblement bénéficiaires (afin que de trop nombreux
employés arrêtent de faire des fichiers Excel/Word/PowePoint à n'en plus finir et qui n'ont
aucune valeur rajoutée significative).

La solution dans ce cas serait de simplifier/automatiser le processus afin d'éviter toute

variabilité du processus (quantité de café, d'eau, température de l'eau, qualité du goût...):

et encore une fois (!!!) ceci peut très bien s'appliquer aux départements administratifs
(génération manuelle de documents répétitifs, qualité de rédaction des documents, nombre
d'erreurs par documents, niveau de qualité des documents...).

Ingénierie de Gestion de projets 59/523

[Link]
 Vincent ISOZ

L'application des méthodes lean peuvent se résumer aussi très bien dans les 5 points suivants:

 Vos coûts sont comparativement (benchmark) trop élevés

 Vous devez réduire le temps de cycle de vos processus
 Vous voulez optimiser l'utilisation de vos ressources
 Vous pensez que vos clients ne vont plus payer vos coûts cachés
 Vous devez gagner en réactivité et flexibilité (bref... en compétitivité)

Formation: ~4-18 jours selon le niveau (Green Belt, Master Black Belt…)
Niveau: Bac à Bac+7

Source: [Link]

4.5 CMMi

CMMi, sigle de Capability Maturity Model + Integration, est un modèle de référence, un

ensemble structuré de bonnes pratiques, destiné à appréhender, évaluer et améliorer les
activités des entreprises d'ingénierie.

Le modèle CMMI définit une échelle de mesure de la maturité à 5 niveaux: Initiation (gestion
en générale chaotique), Répétable (processus créés mais non appliqués), Mesures définies
(utilisation et application des processus), Géré (analyse et prévention des problèmes),
Optimisé (Automatisation):

Figure 3 CMM

ou une autre version courante beaucoup utilisée conjointement avec la série de normes
ISO 9000:

Ingénierie de Gestion de projets 60/523

[Link]
 Vincent ISOZ

Maturité Caractéristiques
0-Inexistant  Il n'y pas de processus
 Le processus n'est pas identifié (il n'apparaît pas dans la
cartographie)
 Le processus n'est pas décrit (pas de fiche processus)
1-Inefficace  Il y a des problèmes opérationnels majeurs
 Il y a beaucoup de réclamations clients
 Les objectifs ne sont pas atteints
 Il n'y a pas de boucles d'améliorations mises en oeuvre pour le
processus
 Le processus n'est pas ou peu documenté
2-Opérationnel  Il n'y a pas de problèmes opérationnels majeurs ou récurrents
 Le processus répond majoritairement aux attentes clients
 Certains objectifs sont atteints ou sur la voie de l'être
 Des boucles d'amélioration sont initiées
 Le processus fait l'objet d'une documentation adaptée
3-Efficace  Les processus ont atteint les objectifs en matière de qualité et de
délai
 Il n'y a plus de réclamation clients concernant le processus
 Les boucles d'amélioration du processus sont opérationnelles
4-Efficient  Le processus atteint tous ces objectifs, y compris ceux en matière
de coût ou de rentabilité
 Toutes les étapes du processus sont mesurées ou pour le moins
estimées quantitativement
 La majorité des clients expriment leur satisfaction
 Les boucles d'amélioration ont prouvé leur efficacité
5-Excellent  Les clients ne sont pas seulement satisfaits mais parfois même
surpris (le processus va au-delà de leurs attentes)
 L'entreprise est reconnue comme "best in class" (la référence)
pour ce processus dans des opérations de benchmarking (études
comparatives)
 Le processus est sous contrôle statistique (cartes de contrôle)
 Les salariés qui mettent en oeuvre le processus sont satisfaits de
leurs conditions de travail

Évidemment les entreprises au niveau 1 et 2 ne réalisent très souvent pas l'importance et le

pouvoir que leur donne une structure de gestion de projets professionnelle. Elles consacrent
peu de temps aux étapes préliminaires et perdent beaucoup d'énergie dans les étapes suivantes
de développement. Leur taux de réussite de projets n'est pas sous contrôle statistique. Pour les
autres niveaux, il est assez facile de deviner de quoi il en retourne.

Ce modèle a été réalisé par un ingénieur du département de la défense américain afin d'être en
mesure de donner des informations concrètes aux problèmes de la qualit suite à des pannes
logiciels.

Formation: ~3 à 5 jours
Niveau: Bac à Bac+3

Source: [Link]

Ingénierie de Gestion de projets 61/523

[Link]
 Vincent ISOZ

4.6 AFITEP

L'AFITEP est l'Association Francophone de Management de Projet dont des ingénieurs et

chercheurs très réputés dans le monde francophone sont membres et qui délivre des
certifications aux personnes physiques.

L'association délivre une Certification en Gestion de Projet (CGP) ainsi qu'une Certification
en Direction de Projet (CDP) délivrée aux directeurs et responsables de projets et reconnue
par l'International Project Management Association (IPMA).

Niveau: Bac à Bac+2

Source: [Link]

4.7 IPMA

L'International Project Management Association (IPMA) a pour principale tâche de

proposer une solution répondant aux besoins de compétences en management de projet. Avec
son système de certification à quatre niveaux, l'IPMA permet de déterminer quand un
spécialiste ou un cadre est qualifié pour diriger un projet. Le système de certification de D-A
dans l'ordre de difficulté s'appuie sur la définition exhaustive de la compétence en
management de projet.

- IPMA Niveau A: Désigne une personne qui est capable de diriger des portefeuilles ou des
programmes importants au moyen des ressources, méthodes et instruments correspondants.
C'est bien cela, l'objet de la certification Level A, et non pas le management de projets
individuels. Cette responsabilité exige une forte dose de connaissances et d'expérience (34
personnes certifiées au total Suisse en 2009 depuis l'implémentation de l'IPMA ; 278 dans le
monde).

- IPMA Niveau B: Désigne une personne capable de gérer un projet complexe. Celui-ci inclut
normalement des sous-projets, c'est-à-dire que le manager de projet gère le projet avec l'aide
de managers de sous-projets et se consacre moins à la conduite du groupe de projet (706
personnes certifiées au total Suisse en 2009 depuis l'implémentation de l'IPMA ; 6'154 dans le
monde).

- IPMA Niveau C: Désigne une personne qui est en mesure de gérer un projet d'une
complexité limitée. Cela signifie que le candidat dispose du savoir et de l'expérience du
management de projet nécessaires pour conduire efficacement un projet (855 personnes
certifiées au total Suisse en 2009 depuis l'implémentation de l'IPMA ; 27'861 dans le monde).

Ingénierie de Gestion de projets 62/523

[Link]
 Vincent ISOZ

- IPMA Niveau D: Désigne une personne qui est capable de mettre en pratique ses
connaissances en management de projet dans le cadre de sa participation à un projet, en
sachant que des connaissances spécifiques complètes et fondamentales sont nécessaires dans
le management de projet (2147 personnes certifiées au total Suisse en 2009 depuis
l'implémentation de l'IPMA ; 111'283 dans le monde).

Formation: ~15-20 au total pour les quatre niveaux

Niveau: Bac à Bac+2

Source: [Link]

4.8 ITIL

ITIL (Information Technology Infrastructure Library) est un ensemble d'ouvrages recensant

les bonnes pratiques pour la gestion des services informatiques, édictées par l'Office public
britannique du Commerce (OGC).

L'adoption des bonnes pratiques de l'ITIL par une entreprise permet d'assurer à ses clients
(internes comme externes) un service répondant à des normes de qualité préétablies au niveau
international. ITIL est à la base de la norme BS15000 (première norme de Gestion de Services
Informatiques formelle et internationale) un label de qualité proche des normes de l'ISO par
exemple (ISO/IEC 20000).

ITIL permet, grâce à une approche par processus clairement définie et contrôlée, d'améliorer
la qualité des SI et du support aux utilisateurs en créant notamment la fonction de Centre de
services qui centralise et administre l'ensemble de la gestion des systèmes d'informations.

Ingénierie de Gestion de projets 63/523

[Link]
 Vincent ISOZ

Les bénéfices pour l'entreprise sont une meilleure traçabilité de l'ensemble des actions du
département informatique. Ce suivi amélioré permet d'optimiser en permanence les processus
des services pour atteindre un niveau de qualité maximum de satisfaction des clients.

Pour les individus, il existe 3 niveaux de certifications pour ITIL à ce jour:

- Foundation Certificate: Certification de premier niveau accordée après un test sous forme de
questions à choix multiples, qui suit normalement un cours de 2 à 3 jours chez un formateur
accrédité. Ce certificat valide une connaissance générique des fondamentaux d'ITIL.

- Practitioners Certificates: Certifications accordées pour une discipline spécifique après un

cours de 2 à 3 jours chez un formateur accrédité et un test sous forme de questions à choix
multiples fondé sur un cas concret. Le Foundation Certificate est un prérequis.

- Managers Certificate: Certification accordée après deux tests de 3 heures qui suivent une
formation de 10 jours par un formateur accrédité. Le Foundation Certificate est un prérequis.

Formation: ~2 jours
Niveau: Bac à Bac+1

Source: [Link]

4.9 COBIT

COBIT (Control Objectives for Information and Related Technology) définit les meilleures
pratiques de gouvernance pour les responsables informatiques.

Ce standard propose une démarche pour gérer les services informatiques comme une
ressource qui permet d'apporter de la valeur et de mettre en œuvre une stratégie de gestion des
risques efficace.

COBIT propose un ensemble complet de processus, d'objectifs de contrôle, de métriques et

d'indicateurs pour un large éventail de processus informatiques en intégrant d'autres
référentiels, normes ou ressources, comme entre autres : la Val IT et le IT Risk de l'ISACA, le
référentiel ITIL et les normes connexes de l'ISO, TOGAF, PMBOK, Prince2, COSO, PCI
DSS, la loi Sarbanes-Oxley Act et Bâle III. C'est cette synérgie qui fait que selon moi COBIT
devrait être LE référentiel dans le domaine de l'IT.

Formation AMDEC: ~5 jours

Niveau: Bac à Bac+5

Ingénierie de Gestion de projets 64/523

[Link]
 Vincent ISOZ

4.10 AMDEC

AMDEC est la traduction de l'anglais FMECA (Failure Modes, Effects and Criticality
Analysis, littéralement "Analyse des Modes de Défaillance et de leur Criticité"). La version
non mathématique est nommée AMDE est donc simplement la traduction de FMEA. Il s'agit
d'une prolongation de l'analyse fonctionnelle. C'est encore une fois l'armée américaine qui est
à l'initiative du développement de l'AMDEC. La référence militaire MIL-P-1629 date de
novembre 1949.

L'AMDE est essentiellement une démarche inductive, aussi exhaustive que possible, qui
consiste à identifier au niveau d'un système ou d'un de ses sous-ensembles, les modes
potentiels de défaillance de ses éléments, leurs causes et leurs effets. De telles analyses
peuvent être adaptées à toute interrogation dans tout domaine et peuvent servir de base, entre
autres, aux analyses fiabilité, maintenabilité, disponibilité, qualité et testabilité. Évidemment
de nombreuses personnes (souvent des soft skill) considèrent que c'est inutile car de toute
façon on ne peut pas lister toutes les défaillances potentielles. Donc l'AMDE ou l'AMDEC ne
doit être vu comme un outil et certains mauvais esprits parleront même d'utopie ou
d'idéologie...

L'AMDE privilégie trois types d'actions principales qui sont (et que l'on retrouve aussi dans le
PMI/PMBOK V4):

1. La maintenance préventive qui est axée sur la correction des défauts des
applications, en vue de minimiser le risque d'une répétition des problèmes. Les
interventions de maintenance préventive comprennent la restructuration des codes
sources, la réorganisation des bases de données et la réécriture des programmes.

2. La maintenance corrective qui consiste à réparer les défauts qui empêchent une
application ou une machine de fonctionner correctement. Elle consiste donc à régler
des problèmes opérationnels ou à corriger des anomalies qui entravent l'exécution d'un
processus. La maintenance corrective exige un soutien 7 jours/24 heures, afin de
maintenir les applications à leur efficacité maximale.

3. La maintenance adaptative a pour but d'améliorer constamment les applications

selon l'évolution des besoins de l'entreprise. Les améliorations peuvent prendre
diverses formes: les mises à niveau logicielles, les modifications exigées par la
réglementation, l'intégration de systèmes, etc. La maintenance adaptative s'assure que
les applications progressent au rythme des changements constants qui surviennent, que
ceux-ci soient d'origine commerciale, technologique ou réglementaire.

Le but est de hiérarchiser les actions d'amélioration à conduire sur un processus, un produit,
un système en travaillant par ordre de criticité décroissant.

Formation AMDE: ~2 jours

Formation AMDEC: ~5 jours
Niveau: Bac à Bac+7

Source: [Link]

Ingénierie de Gestion de projets 65/523

[Link]
 Vincent ISOZ

4.11 PRINCE2

PRINCE2 (PRojects IN Controlled Environments) est une méthode de gestion et de

certification de projet structurée qui se focalise sur trois points: l'organisation, la gestion et le
contrôle du projet. PRINCE est divisé en huit processus définis par des clés d'entrée et de
sortie, des objectifs à atteindre et des activités à réaliser regroupées en 4 phases (au lieu de 5
pour le PMI et Six Sigma): Démarrage, Initialisation, Exécution, Clôture.

Il existe deux types de certification PRINCE2, reconnues dans le monde entier:

- PRINCE2 Fundamentals: Cet examen vérifie qu'un collaborateur dispose des connaissances
nécessaires pour participer à un projet géré selon la méthode PRINCE2™. La réussite de cet
examen et ainsi l'obtention du certificat passe par la maîtrise des principes et de la
terminologie de la méthode.

- PRINCE2 Praticien: Cet examen est la garantie d'une maîtrise parfaite de la méthode pour
gérer un projet et être capable d'appliquer et d'adapter les principes de la méthode
PRINCE2™ pour anticiper les attentes et éviter ou prévoir les problèmes d'un projet donné.

La méthode PRINCE est divisée en 8 processus. Chaque processus est désigné par une
abréviation: Élaborer un projet (EP), Initialiser un projet (IP), Diriger un projet (DP),
Contrôler une séquence (CS), Gérer la livraison de produits (LP), Gérer les limites de
séquences (LS), Clore un projet (CP), Planifier (PL).

Les huit processus sont regroupés de la manière suivante:

Figure 4 Modèle PRINCE2

Ingénierie de Gestion de projets 66/523

[Link]
 Vincent ISOZ

4.12 BPF

Les Bonnes Pratiques de Fabrication (BPF), en anglais Good Manufacturing Practices –

GMP, est une notion d'assurance de la qualité qui fait partie intégrante de la gestion de projets
d'entreprises industrielles mais qui peut très bien s'appliquer au administration sous la
dénomination de Bonnes Pratiques de Travail.

La production d'un bien de consommation (alimentaire, logiciel ou véhicule) doit souvent être
conforme à des spécifications définies dans l'autorisation de mise sur le marché et ne devant
pas exposer le consommateur à un risque remettant en cause la sécurité, la qualité ou à
l'efficacité du produit.

Dans cet esprit, les BPF s'attachent à limiter 5 catégories principales de risques:

1. Les risques de contamination croisée des produits (par un autre produit, ou un

contaminant interne et externe) dans le cas alimentaire ou médical.

2. Les risques de confusion notamment au niveau des étiquetages et de l'identification

des composants ainsi que de leur documentation.

3. La propreté (hygiène) de l'environnement de production et de fabrication qui doit

permettre d'éviter que des corpos étrangers s'immiscent dans le produit.

4. Le non respect des normes, étalons et standards à travers une organisation rigoureuse
de l'entreprise.

5. S'assurer que les intervenants sur le produit et les responsables aient les compétences
nécessaires pour éviter au maximum les risques.

Les 10 grandes lignes de la BPF sont (nous retrouvons au fait ces 10 points dans d'autres
domaines de la gestion de projets et pas que la fabrication!):

1. ÉCRIRE les modes opératoires et les instructions afin de fournir une "feuille de route"
nécessaire à la conformité aux BPF et à une production de qualité régulière.

2. SUIVRE scrupuleusement procédures et instructions pour prévenir toute contamination,

inversion ou erreur.

3. RENSEIGNER rapidement et précisément le travail en cours dans un but de conformité

aux procédures et de traçabilité.

4. PROUVER que nos systèmes font ce pour quoi ils sont conçus en effectuant des
démarches formelles de validation.

Ingénierie de Gestion de projets 67/523

[Link]
 Vincent ISOZ

5. INTÉGRER la productivité, la qualité du produit et la sécurité du personnel dans la

conception des bâtiments et des équipements.

6. EFFECTUER LA MAINTENANCE des bâtiments et équipements de manière régulière

et efficace.

7. DÉVELOPPER ET DÉMONTRER clairement les compétences au poste de travail.

8. PROTÉGER les produits contre toute contamination en adoptant des habitudes régulières
et systématiques de propreté et d'hygiène.

9. CONSTRUIRE LA QUALITÉ dans les produits par un contrôle des matières premières
et des processus tels que la fabrication, l'emballage, l'étiquetage…

10. PLANIFIER et EFFECTUER régulièrement des audits afin d'assurer conformité au BPF
et efficacité du système qualité

Ces principes sont souvent résumés autour des "5M":

 Matériel (identifié, entretenu, nettoyé, qualifié...)

 Méthodes (disponibles, détaillées, précises, vérifiées, validées, auditées...)
 Main-d'œuvre (formée et habilitée au poste de travail)
 Matières (identifiées, contrôlées...)
 Milieu (infrastructures de production qualifiées ...)

qui sont souvent identifiées et associées aux diagrammes d'Ishikawa (que nous verrons plus
tard) et à la méthode AMDEC.

Niveau: Bac à Bac+1

4.13 5S

La méthode des 5S, qui tire son origine de la première lettre de chacune des cinq opérations,
est une technique de management japonaise. Elle est tirée du Système de Production Toyota
(TPS) et repose sur cinq principes simples:

Seiri (整理, Débarras), Seiton (整頓 Rangement), Seiso (清掃, Nettoyage), Seiketsu (清潔,
Ordre), Shitsuke (躾, Rigueur)

Elle doit être organisée sur la base d'objectifs de rangement et de gains de temps afin de
faciliter le transfert de connaissances et l'automatisation facilitée des habitudes.

Formation: ~2 jours
Niveau: Bac à Bac+1

Ingénierie de Gestion de projets 68/523

[Link]
 Vincent ISOZ

Source: [Link]

4.14 SWOT

L'analyse SWOT (de l'anglais Strengths (forces), Weaknesses (faiblesses), Opportunities

(opportunités), Threats (menaces), est un outil de stratégie d'entreprise permettant de
déterminer les options stratégiques envisageables au niveau d'un domaine d'activité précis.

Niveau: Bac

Source: [Link]

4.15 IFCAM

L'Institut suisse pour la formation des chefs d'entreprise existe depuis 1966. C'est son
ancienneté et sa localisation dans les trois régions principales de la Suisse (suisse-romande,
suisse-allemande et suisse-italienne) qui fait sa réputation au niveau national. Outre le fait que
cet institut propose les certifications IPMA et PMP son importance réside dans le fait qu'il
propose un diplôme fédéral d'économiste d'entreprise en formation continue.

Niveau: Bac à Bac+3

Ingénierie de Gestion de projets 69/523

[Link]
 Vincent ISOZ

4.16 SPICE

Le standard ISO/IEC 15504 initialement connu sous le nom de SPICE (Software Process
Improvement and Capability dEtermination) permet l'évaluation des processus de
développement informatique et est aujourd'hui utilisé dans de nouveaux secteurs (dont la
gestion des services informatiques avec TIPA). Il s'agit grossièrement d'un mélange d'ITIL et
CMMi.

4.17 Hermes

HERMES est une méthode ouverte officielle de la Confédération Suisse pour la conduite et le
déroulement uniforme et structuré de projets dans le domaine des technologies de
l'information et de la communication (TIC). La méthode est obligatoire au sein de la
Confédération et doit être utilisée dans tous les projets TIC. HERMES. Elle est également
utilisée dans d'autres administrations publiques, des hautes écoles et des entreprises.

Pour structurer le déroulement d'un projet, HERMES divise l'ensemble de la démarche en six
phases: Initialisation, Analyse préliminaire, Conception, Réalisation, Introduction,
Finalisation. Contrairement à des méthodes orientées processus et pôles de compétence
(comme PMI/IPMA), HERMES est plus orienté phasing de projets.

Remarque: Cette méthodologie de gestions de projets n'a pas empêchée la confédération

d'avoir certains projets informatiques aberrants et certains dont les coûts ont largement
dépassé le budget initial (cf. projet du Système de Conduite et d'Information des Forces
Terrestres).

Il existe deux certifications reconnues au niveau fédéral:

- HERMES Swiss Project Team Professional HSPTP: Assure les compétences pour participer
en tant que collaborateur de projet à un projet conduit selon la méthode.

- HERMES Swiss Project Manager HSPM: Assure la capacité d'appliquer avec succès et
méthodiquement les connaissances et l'expérience de projet en situation.

Formation: ~2 à 6 jours selon le niveau souhaité

Niveau: Bac à Bac+1
(signalons que tous PDFs sont gratuits sur le site internet de la confédération!).

Source: [Link]

Ingénierie de Gestion de projets 70/523

[Link]
 Vincent ISOZ

4.18 MCTS

La certification Microsoft Office Project et Project Server est une certification

professionnelle conçue pour permettre aux professionnels du management de projet de
mesurer leur niveau de maîtrise de l'utilisation de Microsoft Office Project et Project Server
pour l'initiation, la planification, l'exécution, la surveillance, la maîtrise et la clôture des
projets, programmes et portefeuilles de projets.

Cette série de certifications apporte une plus-value à la fois pour les organisations et pour les
individus qui pratiquent le Management de Projet ou qui désirent améliorer leurs compétences
et leurs opportunités de carrière dans ce domaine. La validation d'un champ plus vaste de
compétences donne aux candidats, et à leur hiérarchie, un indicateur de performance fiable.
Cela correspond à une réelle demande des clients devant les besoins croissants en
compétences en Management de Projet, y compris dans la maîtrise des outils associés.

Trois niveaux de certifications sont reconnus à l'international:

- MCTS MS Project Pro: Assure la maîtrise de la version client de MS Project avec 3 jours de
formations.

- MCTS MS Project Server: Assure la maîtrise de la version client de MS Project avec 3 jours
de formations.

- MC IT Pro Project Server: Assure les compétences dans l'installation et la maintenance de

MS Project Server pour un informaticien.

Formation: ~3 à 9 jours selon le niveau de maîtrise souhaité

Niveau: Bac à Bac+2

Source: [Link]/france/msproject/

4.19 EFQM

L'European Foundation for Quality Management ou EFQM, (en français: Fondation

Européenne pour le Management par la Qualité) est une association européenne basée à
Bruxelles fondée en 1988 par 14 entreprises avec l'appui de la commission européenne.

L'EFQM compte aujourd'hui plus de 700 membres. L'objectif de cette organisation à but non
lucratif est de promouvoir un cadre méthodologique pour permettre à ses membres d'évaluer
leur niveau de qualité et de s'améliorer de façon durable.

Ingénierie de Gestion de projets 71/523

[Link]
 Vincent ISOZ

Son modèle d'autoévaluation est fondé sur 9 principes/processus (qui n'ont pas tous la même
pondération) de l'évaluation de la qualité d'une entreprise en termes de gestion.

Elle propose par la même occasion un modèle commun européen très intéressant de notation
des entreprises que tout à chacun peut mettre en pratique pour voir où son entreprise se situe à
l'aide d'un barème de points comprise entre [0,1000].

Les critères de ce modèle sont (voir schéma ci-dessous):

 En termes de facteurs: le leadership, le personnel, la politique et stratégie, les

partenariats et ressources et les processus.
 En termes de résultats: le personnel, les clients, les collectivités (société), les
performances clés.

Ingénierie de Gestion de projets 72/523

[Link]
 Vincent ISOZ

L'EFQM est ce que l'on appelle un "modèle d'excellence" visant à montrer par un concours et
un prix qu'une entreprise est la meilleure dans son domaine d'activité (parmi ceux appliquant
la méthode...). Il y a d'autres modèles d'excellent amenant aussi à des prix et classements
comme le modèle américain Malcolm Baldridge National Quality Award et le modèle
japonais du prix Deming.

Formation: ~3 jours
Niveau: Bac

Source: [Link]

4.20 Dimension 4

Dimension 4 est une méthodologie regroupant un ensemble de techniques et d'outils pour la

réalisation de bénéfices. Mises ensemble, elles réduisent l'incertitude concernant les résultats
d'un projet. Mais ces techniques peuvent aussi être utilisées séparément pour traiter des
difficultés liées au projet.

Cette méthodologie propose que chaque changement soit lié à un bénéfice financier, même
ceux qui sont obligatoires ou financiers.

Formation: 4 jours avec un test à la fin de chaque journée

Source: [Link]

Ingénierie de Gestion de projets 73/523

[Link]
 Vincent ISOZ

4.21 MBA

Le Master of Business Administration ou MBA, est un diplôme international d'études

supérieures dans le domaine de la conduite globale des affaires: stratégie, marketing, finances,
ressources humaines et management.

Dans le modèle traditionnel américain, les étudiants travaillent sur un large éventail de cours
la première année, puis entament une spécialisation lors de la seconde. Dans le reste du
monde le MBA dure en général moins longtemps: entre 9 et 16 mois en Europe, l'objectif
essentiel étant de réduire au maximum le temps passé par des cadres en dehors de l'entreprise.

Formation: ~ 65 jours
Niveau: Bac à Bac+3

4.22 ENS

L'ENS (École Normale Sup.) propose le cursus de formation en gestion de projets que je
considère comme le plus pointu et complet à ma connaissance et à ce jour. Il s'agit d'un
excellent minimum minimorum pour être ingénieur en gestion de projets avec un cursus
actuel de 7 ans (prérequis inclus).

Le programme est le suivant: Un cycle de formation de 350 heures environ (soit 2 ans à peu
près) d'enseignements techniques, théoriques et pratiques sous forme de modules spécialisés
(22 modules): finance d'entreprise, analyse et prévision financière, macro-économie
financière, finance empirique, évaluation des entreprises, fusions et acquisitions, techniques
financières internationales, gestion de portefeuille, gestion des risques bancaires, taux et
produits dérivés de taux, risque de crédit et produits dérivés de crédit, introduction aux
processus stochastiques en temps continu, méthodologie informatique, calcul stochastique
pour la finance, évaluation et couverture des produits dérivés, résolution numérique des EDP
pour la finance, économétrie des séries temporelles et modèles ARCH en finance, statistique
des processus en finance, méthodes neuronales et applications financières, microstructure et
organisation des marchés, gestion des risques de l'entreprise, finance d'entreprise approfondie,
simulation salle des marchés, développement informatiques, suivi des projets.

Cette solide formation appliquée est complétée par une thèse professionnelle validant un
projet de 4 à 6 mois en entreprise.

Le public visé est des ingénieurs diplômés, diplômés d'Écoles de gestion dont le titre est
reconnu par la Conférence des Grandes Écoles, ou titulaires d'un DEA ou d'un DESS dans les
disciplines suivantes: mathématiques, mathématiques appliquées, sciences physiques, gestion
et sciences économiques (options économétrie, économie mathématique, finance
quantitative...) ou titulaires d'un diplôme étranger de type Master of Science ou diplôme
équivalent.

Ingénierie de Gestion de projets 74/523

[Link]
 Vincent ISOZ

Formation: ~60 jours

Niveau: Bac+4 à Bac+7

Ingénierie de Gestion de projets 75/523

[Link]
 Vincent ISOZ

5. Logiciels
Pour travailler dans le domaine de la gestion de projets, de la qualité, de la finance et des
risques, les logiciels les plus connus et utilisés (ce qui ne veut pas forcément dire que ce sont
les meilleurs…) considérés souvent comme les outils minimum que doit posséder un
responsable de projet sont les suivants. Cependant, la connaissance de cette liste ne doit pas
amener le responsable de projet à se soustraire à la norme ISO 9241-11 qui permet de vérifier
"le degré selon lequel un produit peut être utilisé, par des utilisateurs identifiés, pour
atteindre des buts définis avec efficacité, efficience et satisfaction, dans un contexte
d'utilisation spécifié". Car entre les (soi-disant) responsables de projets dans les
multinationales qui utilisent un tableur pour faire des planning est de pseudo "bases de
données" et ceux qui ont des logiciels de gestion de projets qui buggent complétement car ils
n'ont pas attendu le service pack 2 ou 3 il y a un laxisme général à faire grimper les experts
aux rideaux...

Enfin, rappelons que selon le BABOK, le business analyst et donc aussi un peu le
coordinateur de projets devraient choisir les méthodes et outils de gestion en fonction de la
disponibilité des outils, de leurs limitations, des standards organisationnels, des contraintes
temporelles et du budget.

Inutile de revenir sur une description de Microsoft Office Project, car il s'agit du sujet
principal auquel prépare ce support (et voir mon livre de ~900 pages sur ce logiciel). Le
responsable de projet ne doit simplement pas oublier qu'il existe à ce jour trois versions
différentes de ce produit (Standard, Pro et Server) et qu'il faut au minimum 5 à 8 jours de
formations pour maîtriser les bases de l'outil (ce qui ne prend donc pas en compte la durée de
formation pour les bases en gestion de projets!).

OpenProj est un outil de planification de projet gratuit. Le logiciel permet la planification de

tâches avec association de dépendances, de ressources, et un état d'avancement ou une
catégorie. OpenProj est un clone de Microsoft Project, il permet de lire et modifier les fichiers
de ce dernir.

L'outil web par excellence pour une gestion professionnelle de la communication et de la

gestion des documents et workflows dans le cadre des projets ou de la qualité. C'est un outil
de toute manière obligatoire si l'on souhaite posséder Microsoft Project Server.

Ingénierie de Gestion de projets 76/523

[Link]
 Vincent ISOZ

Outil de référence mondiale en bureautique classique pour modéliser, formaliser et

dématérialiser les processus d'une entreprise en conformité avec ISO 5807:85 ou la B.P.M.N.
dans le cadre de ses projets ou de sa gestion de la qualité et des flux d'informations.

Connu par tout le monde mais bien évidemment indispensable pour rédiger des cahiers des
charges ou plans directeurs de projets correctement et conformément aux normes en vigueur
(je ne vais pas ici discuter de la comparaison avec LaTeX…).

Connu par tout le monde et utilisé même par des financiers et responsables de projet de très
très haut niveau malgré ses faiblesses en statistiques avancées. Comme de nombreux add-ins
payant s'y greffent de toute manière, il reste un outil de référence pour l'analyse des projets et
de la qualité, ainsi que la modélisation statistique et l'optimisation.

Connu aussi de tous ce logiciel de messagerie est indispensable depuis la fin de 20ème siècle
pour communiquer avec les clients. Il est surtout important dans le cadre de la gestion de
projets, car son agenda se connecte à MS Project Server pour les ressources et à SharePoint
pour prendre les documents en itinérance.

Microsoft Office OneNote est un logiciel collaboratif ou individuel de prise de note et de

gestion déstructurée de l'information extrêmement utile pour les cadres noyés sous
l'information et permettant outre une organisation rapide de l'info et de gérer les notes de
réunions rapidement de faire de la recherche OCR de texte dans les images et de synchroniser
la capture son ou vidéo des réunions avec les pris de notes textuelles.

Outil très utile pour simplifier l'analyse de données dans le domaine de la qualité, de la
gestion de projets et même de la R&D (mais ça c'est hors sujet dans ce support). On peut faire
(pour les usages courants) le même travail dans MS Excel, mais cela prend beaucoup plus de
temps et nécessite quasiment systématique le recours à la programmation VBA.

Ingénierie de Gestion de projets 77/523

[Link]
 Vincent ISOZ

Le meilleur (sans aucun doute!) outil du marché dans la modélisation statistique (Monte-
Carlo, Latin-Hypercube) de l'aide à la décision pour la durée, les coûts ou les risques de
projets. C'est un des logiciels de référence des top managers quantitatifs.

Le seul logiciel à ma connaissance qui permette de créer des modèles d'arbres de décisions et
de Markov pour l'aide à la décision. Il permet aussi d'intégrer des statistiques simples ou des
modèles de fonctions de probabilités.

Pour l'instant c'est à mon goût le logiciel le plus complet pour faire des arbres d'événements,
des arbres de décision, des arbres de défaillance probabilistes (associé à de l'AMDEC avec
Monte-Carlo).

Permet d'aider à appliquer la méthode de management Prince2 dans le cadre de la gestion de

projets avec MS Project comme la description et le suivi des produits, risques, requêtes et
clients dans MS Project et de pouvoir les gréer entre plusieurs fichiers.

Excellents logiciels pour l'analyse (statistique et graphique) et le suivi des risques selon de
nombreuses normes techniques, médicales, mécaniques, ISO, AMDEC.

Excellente solution intégrée à SAP pour faire de l'AMDEC, du FMEA et presque tout ce qui
est relatif à la gestion de la qualité. Un bijou à priori!

Ingénierie de Gestion de projets 78/523

[Link]
 Vincent ISOZ

La référence pour prendre des notes rapidement lors de réunions internes ou clientèles et
modéliser simplement des concepts ou idées dans des situations normales ou critiques.

Logiciel permettant de mettre en place la technique décisionnelle quantitative APH basée sur
les valeurs propres démontrée dans le cours théorique de mathématique décisionnelle.

Il est par ailleurs conseillé comme l'exige ISO 9001 que la liste des logiciels autorisés et
officiels soit documenté et que les employés soient bien informés de l'existence de cette liste.

Ingénierie de Gestion de projets 79/523

[Link]
 Vincent ISOZ

6. Documents (modèles)
Le responsable de projet a besoin d'une boîte à outils dans le cadre de son travail
(normalement mis à disposition et créés par les Business Analyst selon le BABOK). Nous
avons déjà certes au début de ce support présenté quelques logiciels et méthodologies… mais
il faut aussi si possible des modèles de documents qui vont avec et qui pourront
éventuellement lui faire gagner un peu de temps sur l'élaboration de ses propres modèles
"corporate". Posséder des modèles de documents (bref un fond documentaire solide!) est aussi
important car dans de nombreux domaines de l'économie la règle suivante s'applique:

Ce qui n'a pas été documenté n'a pas été fait!

Nous supposerons à ce titre que tout à chacun possède: MS Word, MS Excel, MS Project,
MS Visio puisqu'ils contiennent depuis 2010 (surtout les 2 derniers) des modèles très
intéressants et presque finalisés en ce qui concerne l'application de la BPMN, TQM et
Six Sigma.

Nous fournissons aux participants à la formation les modèles suivants, servant de base à une
première réflexion, que nous allons ouvrir et analyser en groupe tout au long de la lecture de
ce support:

 AccidentFRV1_0.dot (2 pages A4): un fichier MS Word permettant d'afficher les

accidents/anomalies ayant eu lieu dans le cadre d'un projet ou d'un centre de production
dans les couloirs de l'entreprise ou sur le mur d'un bureau pour tous.

 AMDECFRV2_0.xlt: un fichier MS Excel permettant de faire une analyse et un suivi

selon les méthodes qualitatives AMDE(C).

 AnomalieQualiteFRV1_0.dot (1 page A4): un fichier MS Word (à défaut d'une base de

données…) utilisable comme base de travail pour le suivi des anomalies qualité et donc de
non respects des processus.

 BuinessPlanFRV1_0.dot (24 pages A4): un fichier MS Word structuré contenant la

structure, la table des matières et les différents chapitres nécessaires à l'élaboration d'un
Business Plan digne de ce nom.

 CahierDesChargesFRV4_0.dot (34 pages A4): un fichier MS Word contenant la

structure, la table des matières et les différents chapitres nécessaires à l'élaboration d'un
cahier des charges (CdC) et d'un plan directeur de projet6 (PdP) professionnel très
complet 7(Project Management Plan). Ce type de fichier évolue tout le long du projet
jusqu'à sa clôture définitive (certains préfèrent faire évoluer uniquement le PdP).

 ConditionsGeneralesFRV1_0.dot (11 pages A4): un fichier MS Word contenant les

grandes lignes des conditions générales d'un contrat pour un projet, une vente de service
ou de produit.

6
Appelé aussi parfois "Note de cadrage"
7
De plus en plus d'entreprise intègre le dossier de spécification dans le CdD bien que cela ait tendance à alourdir
considérablement le document

Ingénierie de Gestion de projets 80/523

[Link]
 Vincent ISOZ

 AppelOffreFRV1_0.dot (6 pages A4): un fichier MS Word contenant les grandes lignes

d'un appel d'offre à candidatures typique ("request for bid" ou "request for proposal"8)

 ChangeRequestFRV1_0.dot (1 page A4): toute demande de changement de directive,

d'ajout de tâche ou de correction dans un projet qui changera la configuration du livrable
doit être faite par le client (interne ou externe) selon une procédure et une mise en forme
standardisée nécessitant un minimum de temps. C'est ce que propose ce document. Ce
document sera aussi utilisé pour les "service request" (demande qui n'implique pas de
changer la configuration du livrable).

 CodeDeConduiteReunionsFRV1_0.dot (1 page A4): contient les règles de conduite et

de préparation à mettre sur le mur de vos salles de réunions.

 ProcesVerbalReunionsFRV1_0.dot (1 page A4): contient les informations minimales

pour un process verbal correct.

 DashboardFRV1_0.xlt: un modèle MS Excel contenant un vieux et simple tableau de

bord avec des indicateurs de performance sous différents aspects.

 EFQMSelfAssessmentENV1_0.xlt: un modèle MS Excel permettant de faire un bilan

qualitatif de son entreprise suivant le standard EFQM. Je n'ai pas encore créé le modèle
permettant de faire le bilan selon la pondération quantitative de ce standard. Il faudra donc
patienter.

 GanttFRV1_0.mpt: un modèle MS Project de base pour les plannings (modélisation

déterministe de la durée et coût d'un projet) un peu amélioré par rapport à ce que propose
le logiciel par défaut. Ce fichier est amélioré (comme tous les autres) à chaque formation
selon les remarques des participants.

 GroupesFRV1_0.xlt: Tableau MS Excel aidant à définir des groupes et membres

d'équipes de projet avec leurs niveaux de délégation et rôles respectifs.

 ISO9001ManagementReviewENV1_0.mpt (56 tâches): un modèle MS Project avec le

planning et la charge des ressources nécessaires à la préparation d'un audit pour l'ISO
9001 tels qu'utilisé en Grande-Bretagne ou dans de nombreux payse de l'Union
Européenne.

 [Link] (27 primitives): un modèle de gabarit MS Visio que j'ai personnalisé et

complété afin d'être conforme au plus proche au standard ISO 5807:1985.

 ProcessusFRV5_0.vst: un modèle MS Visio avec les gabarits les plus courants déjà
ouverts ainsi qu'une mise en page conforme aux standards ISO et Six Sigma et des
propriétés de formes suffisamment complètes dans un schéma de propriétés enregistré à
même dans le document sous le nom Template Set + 71 processus déjà faits couvrant de
nombreux départements d'entreprise (150 pages A4).

8
La différence entre "request for bid" et "request for proposal" est que le premier va se baser sur un sélection
dont le seul critère sera le prix alors que le deuxième prendra en considération d'autres facteurs.

Ingénierie de Gestion de projets 81/523

[Link]
 Vincent ISOZ

 MatriceAnalyseHOQENV1_0.xlt: mise à disposition par une société américaine, ce

modèle MS Excel propose une House Of Quality Six Sigma assez élaborée et servira donc
de base à une analyse qualitative de la corrélation et des facteurs entre les contraintes
internes (VOP) et les exigences du client (VOC). Ce modèle peut également être utilisé
comme outil d'aide à la décision pour analyser les réponses à un appel d'offres.

 SixSigmaDMAICCycleENV1_0.mpt (36 tâches): un modèle MS Project avec le

planning et les phases correspondantes pour la mise en place d'un projet Six Sigma selon
l'approche DMAIC.

 OffreEmploiFRV1_0.dot (2 pages A4): un modèle MS Word pour publier une offre

d'emploi standardisée et complète afin d'engager des ressources pour un projet (et surtout
afin d'éviter l'amateurisme général actuel du niveau de détail des offres d'emploi visible
sur le marché)

 HERMESFRV1_0.mpt (461 tâches): un modèle MS Project avec le planning et les

phases correspondantes pour la mise en place d'un projet Hermès "avancé".

 PRINCE2ENV1_0.mpt (46 tâches): un modèle MS Project avec le planning et les phases

correspondantes pour la mise en place d'un projet selon PRINCE2.

 PMIENV1_0.mpt (49 tâches): un modèle MS Project avec le planning et les phases

correspondantes pour la mise en place d'un projet selon le PMBOK du PMI.

Et plutôt que de recréer la roue dans de nombreux domaines, le lecteur aura accès pour une
somme modeste à quantité de documents déjà existants (en français, anglais et allemand):

[Link]

plus des affiches (posters) imposés par la loi dans de nombreux pays sur le site suivant pour
une somme négligeable:

[Link]

Remarque: Rappelons que tout changement sur un document (modèle ou pas!) doit être
évalué (contrôlé), approuvé et mis en place et que les modifications/corrections doivent être
datées et signées et la raison de la modification noté. Par ailleurs on doit toujours avoir une
traçabilité des changements via un système de versions.

! Suivre les règles de BPD - Bonnes Pratiques de documentation!

Ingénierie de Gestion de projets 82/523

[Link]
 Vincent ISOZ

7. Processus et représentatives

Le responsable de projet est très souvent confronté à l'obligation (nécessité) de devoir

formaliser des synoptiques9 de méthodes de travail sous forme de procédures opérationnelles
standard (POS), des concepts d'organisation ou des idées. Effectivement, la majorité des
employés ont besoin d'un système de référence rigoureux pour la maîtrise collective de leurs
activités professionnelles et les entreprises dans le cadre concurrentiel du 21 ème siècle ont
besoin de processus pour:

 maîtriser les coûts

 proposer un produit irréprochable
 avoir un temps de réponse court et fiable
 atteindre un résultat de façon standardisée et fiable
 réduire le temps et les coûts de formation
 adapter ses produits aux besoins
 appliquer les bonnes pratiques de fabrication/travail (voir page 67)
 ne pas répéter les erreurs du passé et utiliser le retour sur expérience
 (obtenir des papiers de certifications qualité...)

et vont pour cela utiliser typiquement le processus série récursif d'implémentation qui consiste
à:

1. Audit de l'existant (par du "job shadowing10")

2. Identification des objectifs et besoins
3. Description des processus et procédures
4. Validation par tous les intervenants
5. Documenter le système qualité

9
Un synoptique désigne une présentation, en général graphique, qui permet de saisir d'un seul coup d'œil un
ensemble d'informations liées ou un système complexe.
10
Il s'agit d'observer les collaborateurs faire leur travail pendant qu'ils suivent les processus internes existants
tout en se mettant en retrait et en notant les points faibles de ces mêmes processus.

Ingénierie de Gestion de projets 83/523

[Link]
 Vincent ISOZ

6. Application des processus et procédure

7. Gestion des enregistrements
8. Piloter les changements et retours
9. Surveiller la capabilité
10. Revues

L'approche processus est donc une méthode (certains diront une idéologie voire même une
utopie ... ) d'analyse ou de modélisation (formalisation) qui consiste à décrire de façon
méthodique une organisation ou une activité dans le but d'agir efficacement dessus à
différents niveaux (cartographie/méta-processus et processus) et correspond à une
organisation de niveau de maturité au minimum 2 selon l'échelle du CMMi (voir page 60). Le
processus est donc essentiellement un outil d'optimisation de la performance (on devrait plutôt
parler de "rigueur" en réalité!). Souvent cette démarche si elle est faite sur le tard consiste à
reconstruire toute l'organisation de l'entreprise en partant quasiment de zéro. Cependant les
résultats sont généralement bons et ont prouvé l'intérêt de la démarche même si elle produit
quelques licenciements suite à l'identification de postes ou tâches inutiles.

Ainsi, le BABOK (Business Analysis Body of Knowledge) recommande particulièrement la

mise en place de processus lorsque qu'une grande structure fait appel à de nombreux
prestataires de services externes et ce afin d'homogénéiser et rationaliser les techniques de
gestion de leurs méthodes de travail et de communication.

Certains spécialistes disant que le rôle des processus et de leurs procédures (instructions)
associées n'est pas en plus de remplacer de pouvoir remplacer compétence si besoin est mais
de la compléter. Évidemment c'est un point de vue ... en ce qui me concerne quand je vois
avec mes dix années d'expérience de consultant en entreprise que moins de 2 à 3% des gens
utilisent vraiment leur cerveau je m'interroge ... (le reste des 97 à 98% ayant beaucoup de
peine à utiliser des raisonnements hypothético-déductifs qui sont du niveau du baccalauréat).

Remarque: La norme ISO 9001:2008 n'exige (malheureusement) pas de représenter vos

processus graphiquement et ce même en respectant leur propre norme (ISO 5807:85). Cette
norme n'impose jamais un moyen précis, mais décrit plutôt à un but à atteindre (d'où selon
moi le foutoir général dans la communication interentreprises et le fait que tout le monde ou
presque réinvente la roue). Elle précise uniquement qu'il faut identifier les processus
nécessaires au système de management et de la qualité [ .. et] déterminer la séquence et
l'interaction des processus.

Signalons que nombre de grands comptes qui n'avaient pas de processus (et leurs procédures
associées) s'en sont mordu les doigts de l'acquisition de solution ERP dans le but de
rationaliser la complexité administrative et de cohérence de la gestion de l'information!

Ingénierie de Gestion de projets 84/523

[Link]
 Vincent ISOZ

Définitions préalables selon ISO [Link]

Une procédure est définie comme une manière spécifiée d'effectuer une activité ou un
processus. La procédure est donc une manière de faire qui ne fait pas obligatoirement l'objet
d'une documentation. Lorsqu'une procédure fait l'objet de documents, les termes "procédure
écrite" ou "procédure documentée" sont fréquemment utilisés.

Un processus est un ensemble d'activités corrélées ou interactives qui transforme des

éléments d’entrée en éléments de sortie.

Ingénierie de Gestion de projets 85/523

[Link]
 Vincent ISOZ

7.1.1 Objectifs
Les raisons à ces besoins de formalisation sont relativement simples et peuvent se résumer
aux quelques points principaux (valeurs ajoutées) suivants:

1. Éviter le "management par exception" (contraire au Six Sigma)

2. Standardiser les actions et structurer l'information au sein d'un groupe de travail

3. Garantir une répétabilité à l'identique (mieux répondre aux besoins des clients)

4. Servir de base pour les formations aux méthodes de travail corporate (internes)

5. Faciliter la communication des méthodes standardisées et les attentes de résultats

6. Ne pas recréer la roue à chaque fois (et ainsi pouvoir se concentre sur l'innovation)

7. Formaliser le REX (Retour d'Expérience) afin d'éviter des erreurs passées

8. Minimiser les efforts et le temps en analysant les étapes inutiles (temps de passage)

9. Identifier, mesurer et anticiper les problèmes

10. Réagir de manière appropriée et standardisée lors d'imprévus

11. Assurer une traçabilité

12. Éviter les "je savais pas", "tu me l'avais pas dit donc c'est de ta faute"

13. Identifier les actions inutiles ou optimisables plus facilement

14. (obtenir des certifications qualité...)

De plus, la culture processus est davantage, par son formalisme, une culture de l'écrit qu'une
culture de l'oral. Ainsi, la communication orale n'est pas interdite... mais il vaut mieux fixer
des règles admises par écrit (et les améliorer) plutôt que de les discuter à chaque fois. L'écrit
(sous forme de processus et procédures) oblige à la réflexion, permet l'homogénéisation, la
mémorisation et la vérification de l'information, devient une référence pouvant être facilement
diffusée, autorise, le classement et l'archivage des informations (le bon document au bon
endroit).

Ingénierie de Gestion de projets 86/523

[Link]
 Vincent ISOZ

Description du système
qualité:

Niveau stratégique Charte qualité

POURQUOI, QUI est
responsable de
Référence système QUOI

Processus
qualité Savoir faire
organisationnel:
Niveau planification
Moyens d'application QUI fait QUOI,
QUAND?
Procédures qualité

Instructions de travail
Niveau opérationnel détaillées
Instructions de travail obligatoires
Instructions opératoires
(fiches techniques, modes opératoires) COMMENT faire avec
QUOI et QUI?

Documents créées et
Niveau individuel Documents personnels gérés par les
collaborateurs

Figure 5 Cinq niveaux de la hiérarchie des documents qualité (pyramide)

Le schéma suivant est parfois résumé sous la forme suivante:

Manager par les processus est aussi un préalable à toute forme de management. Cela consiste
à connaître toutes les activités nécessaires à la production des prestations satisfaisantes pour
les clients et à en harmoniser le fonctionnement. À cette fin, il faut identifier les processus,
définir les règles relationnelles, maîtriser les activités internes à chaque processus et améliorer
en permanence le mode de fonctionnement de l'ensemble.

Le logiciel le plus utilisé à travers le monde à ce jour et à notre connaissance (ce qui ne veut
pas dire que c'est le meilleur!) pour cela est Microsoft Office Visio qui permet non seulement

Ingénierie de Gestion de projets 87/523

[Link]
 Vincent ISOZ

de faire de nombreux types de synoptiques mais aussi de les analyser statistiquement avec des
rapports automatisés d'avancement envoyés vers Microsoft Office Excel, de connecter
certaines informations à une base de données centralisée, d'afficher des indicateurs de
performances et au final (point le plus apprécié) de publier le tout sous forme de pages web
afin de rendre les schémas interactifs (liens entre processus, vers des documents, moteur de
recherche,…). Il existe cependant nombre de logiciels plus performants (MEGA, Bizagi,
Bonitasoft, etc.).

Si vous souhaitez représenter graphiquement les processus de votre organisation, commencez

par remplir, sur la base de la hiérarchie des processus, la carte des processus au niveau le plus
élevé de votre architecture. Cette carte donne un aperçu de tous les processus d'affaires de
votre entreprise et en illustre les interdépendances. Vous pouvez vous inspirer de l’illustration
suivante:

Vous pouvez donc au deuxième niveau de votre architecture représenter les différents
processus d'affaires avec les processus de travail correspondants. L'exemple ci-dessous
illustre le processus d'affaires «Suivi de la clientèle»:

Ingénierie de Gestion de projets 88/523

[Link]
 Vincent ISOZ

Il y a malheureusement quelques difficultés et problèmes courants avec les schémas (et

particulièrement les processus) selon certains responsables de projets:

1. Leur documentation (très longue)

2. Leur communication (nécessite de former régulièrement les employés)

3. Leur mise à jour exigée par ISO 9001 (nécessite un responsable qualité à plein temps)

4. Leur application11 (nécessite des surveillants: le responsable qualité ou de faire

comprendre aux employés les possibles impacts de leurs discours/décisions/gestes
dans des environnements sensibles)

5. La mesure de leur performance (exigée par ISO 9001)

6. Les audits internes pour vérifier que les processus soient bien suivis

7. Les revues (réunions) qui prennent du temps

8. La tendance naturelle des employés à trouver un moyen légitime de contourner le

respect des processus.

Mais bon comme l'aurait dit William Edwards Deming (statisticien qui est une référence
mondiale dans la gestion de projets contemporaine et le créateur de la démarche qualité et qui
considère que le seul langage de la qualité doit être la statistique mathématique):

85% des raisons d'échecs en ce qui concerne la satisfaction des clients est liée au système et
aux processus… plutôt qu'à l'employé.

11
Un exemple assez "extrême" est une entreprise qui avait des collaborateurs qui ne savaient simplement pas lire
(et le responsable AQ n'était pas au courant).

Ingénierie de Gestion de projets 89/523

[Link]
 Vincent ISOZ

Raison pour laquelle nombreux sont ceux qui disent que sans objectifs clairs, sans formations
et sans systèmes de mesure: les résultats ne seront pas au rendez-vous ET il ne sera pas
possible de lancer des améliorations.

Si enfin nous rappelons le vieil adage qui dit que l'on ne peut améliorer que ce qui est
mesurable il n'est pas étonnant que le point fort de l'approche par processus est justement sa
capacité à mesurer les performances.

Certains cependant argumentent qu'il n'est plus possible au 21ème siècle de continuer à exercer
une approche analytique des organismes et qu'il faut prendre de la hauteur et préférer une
approche plus globale centrée sur la stratégie des résultats plutôt que sur le respect de règles
écrites qui se démodent aussi vite qu'elles sont formalisées. Il s'agit d'une critique à laquelle
j'ai toujours une réponse très simple: il suffit d'étudier un tout petit peu l'histoire des sciences
dures et exactes depuis Bacon pour voir avec quelle vitesse tout notre environnement a été
bouleversé depuis la mise en place de méthodes scientifiques rigoureuses et formalisées et... si
les entreprises veulent repartir dans le moyen-âge c'est leur problème... De plus si les
processus se démodent aussi vite qu'ils sont formalisées c'est simplement que la personne les
ayant formalisés n'est pas compétente!

Ingénierie de Gestion de projets 90/523

[Link]
 Vincent ISOZ

Cette petite citation est pertinente... mais encore faut-il se rappeler de ce qui est "nouveau" en
entreprise (car la très grande majorité des employés utilisent des méthodes et outils de travail
qui sont centenaires).

7.1.2 Types de représentatives

Tous les exemples de représentatives que nous allons donner ici ne sont pas faites
nécessairement avec Microsoft Office Visio mais il est cependant possible des toutes les créer
avec ce dernier logiciel.

Rappelons qu'au même titre que "une image vaut autant que mille mots", un "bon croquis vaut
mieux qu'un long discours" ;-)

[Link] Mind Mapping

Le Mind Mapping (appelé aussi parfois "Diagramme d'affinité") permet de rapidement
synthétiser des idées ou concepts discutés lors d'une réunion. Le meilleur logiciel pour faire
ce type de cartes à ce jour est très probablement MindManager. Si l'on souhaite pouvoir
communiquer des MindMap à tout un département dans lequel vous êtes le seul à posséder un
logiciel de Mind Mapping nous conseillons alors plutôt le logiciel FreeMind qui permet de
transformer toute carte en une page web interactive très pertinente.

Ingénierie de Gestion de projets 91/523

[Link]
 Vincent ISOZ

Ce type de diagramme (enfin les logiciels associés disons plutôt…) peuvent aussi très bien
être utilisés pour faire des "diagrammes bête à cornes" ou "diagramme pieuvre" (voir sur
Internet car c'est trivial).

[Link] Diagramme d'Ishikawa

Le diagramme d'Ishikawa (Diagramme de causes et effet) ou diagramme en arêtes de poisson
est le fruit des travaux de Kaoru Ishikawa pour la gestion de la qualité (en toute rigueur: en
"contrôle qualité").

Cet outil graphique issu d'un brainstorming, recense les causes aboutissant à un effet. Son
analyse permet une aide à la décision synoptique pour soit corriger un fait existant, soit la
mise en place d'un projet.

Les causes sont réparties traditionnellement dans cinq catégories appelées 5M:

1. Matière: Les matières premières, et plus généralement les inputs du processus.

2. Matériel: Concerne l'équipement, les machines, le matériel informatique…

3. Méthode: Le mode opératoire et la recherche et développement.

4. Main d'œuvre: Tout ce qui concerne les ressources humaines.

5. Milieu: L'environnement, le positionnement, le contexte.

Ingénierie de Gestion de projets 92/523

[Link]
 Vincent ISOZ

Chaque branche reçoit d'autres causes ou catégories hiérarchisées selon leur niveau
d'importance ou de détail. Le classement doit aussi mettre en évidence les causes les plus
directes. Ce sont celles les plus proches de l'arête de poisson.

La méthode 5M est souvent articulée autour des "bonnes méthodes de fabrication" (abrégée
BPF) qui s'articulent autour de 10 points et dont les 5M sont un résumé:

1. Écrire les modes opératoires et les instructions afin de fournir une "feuille de route"
nécessaire à la conformité aux bonnes pratiques et à un travail de qualité régulier.

2. Suivre scrupuleusement procédures et instructions pour prévenir toute erreur.

3. Renseigner rapidement et précisément le travail en cours dans un but de conformité

aux procédures et de traçabilité.

4. Prouver que nos systèmes font ce pour quoi ils sont conçus en effectuant des
démarches formelles de validation.

5. Intégrer la productivité, la qualité service et du personnel dans la conception de

l'environnement de travail.

6. Effectuer la maintenant des outils de manière régulière et efficace.

7. Développer et démontrer clairement les compétences au poste de travail.

8. Protéger les produits contre tout défaut en adoptant des habitudes régulières et
systématiques d'organisation et de suivi.

9. Construire la qualité dans les produits par un contrôle des processus…

Ingénierie de Gestion de projets 93/523

[Link]
 Vincent ISOZ

Planifier et Effectuer régulièrement des audits afin d'assurer conformité au système qualité.

La variante la plus intéressante du diagramme 5M est le diagramme 6M qui ajoute aux 5

domaines précédents celui de la Mesure: les causes correspondant à des biais ou erreurs liés
aux indicateurs utilisés pour chiffrer le phénomène à analyser.

Les entreprises de services utilisent une version étendue: c'est le diagramme 7M qui rajoute
les catégories Management (que l'on pourrait considérer comme redondante avec la catégorie
main-d'œuvre) et Moyens financiers.

Pour terminer signalons aussi les classiques 8P (Price, Promotion, People, Processes, Place,
Policies, Procedures et Product) et les 4S (Surroundings (environnement), Suppliers, Systems,
Skills).

[Link] Organigrammes (O.B.S./W.B.S./P.B.S./R.B.S.)

Le responsable de projets pour gérer l'information au mieux et dans les règles de l'art est
confronté à la nécessite de créer plusieurs organigrammes qui pour certains sont exigés pour
le bon fonctionnement de logiciels spécialisés en gestion de projets de quelques éditeurs.
Nous avons ainsi dans l'odre des plus utilisés au moins utilisés dans la pratique

 W.B.S. Work Breakdown Structure: Permettant de construire un organigramme

structurel des tâches avec un numéro d'identifiant (d'attribution) unique hiérarchisé et
non modifiable à travers tous les projets d'entreprises. Ce numéro permet de faciliter
la communication et également de mieux tracer (suivre) les modifications
structurelles effectuées sur le projet pendant l'exécution de ce dernier.

Il s'agit du seul organigramme de projet qui à ma connaissance est normalisée par

l'AFNOR sour dénomination S.F.T. pour Structure de Fractionnement de Travail.

 A.B.S. Activity Breakdwown Structure: Selon le PMI, le responsable de projet ne

devrait s'occuper au niveau du planning que de la A.B.S. qui représente
l'organigramme des programmes du projet, des phases et des livrables et en aucun cas
aller jusqu'au détail des tâches. Toujours selon le PMI, le détail des tâches pour que
la A.B.S. devienne une W.B.S. est la responsabilité des responsables d'équipes.

 R.B.S. Ressource Breakdown Structure: Il s'agit de l'organigramme des

compétences/métiers des ressources du projet. L'idée étant de pouvoir rapidement
trouver qui a des compétences dans le projet qui sont dans le même le même domaine
de spécialisation pour des éventuels remplacements ou pour compléter des équipes en
cas d'urgences (retards à atteneur). La R.B.S. des ressources est parfois aussi
confondue avec la Risk Breakdown Structure qui est l'organigramme structurel des
risques (mais je n'ai jamais vu ce dernier être utilisé dans la pratique) ou
l'organigramme des projets par niveau de risque tel que proposé depuis 2004 par le
P.M.I.

 O.B.S. Organizational Breakdown Structure: Il s'agit du plus souvent de

l'organigramme hiérarchique des ressources du projet et donc indirectements de la
structure hiérarchique des départements ou groupes de travail intervenant sur le
projet. L'O.B.S. permet de ne pas aller à la pêche à l'information quand un décideur
est absent (afin de rapidement savoir qui est le n+1 qui doit alors se substituer à la

Ingénierie de Gestion de projets 94/523

[Link]
 Vincent ISOZ

personne absente) et également de formaliser les responsabilités de tout à chacun et

ce par projet et enfin (et surtout!) de générer de statistiques une fois le projet terminé
par groupe de travail ou département.

 P.B.S. Product Breakdown Structure: Il s'agit de l'organigramme structurel

représentant l'ordre d'assemblage d'un produit. Dans la nomenclature la P.B.S. est
plus souvent connue sous la dénomination de "nomenclature produit" et permet donc
pour chaque tâche du projet d'identifier à quelle partie structuelle du produit final la
tâche appartient.

 C.B.S.: Communication Breakdown Structure: Permettant de définir le flux de

communication au sein du projet. Ainsi, un client n'a pas à s'adresser directement aux
exécutants du projet mais doit passer par un filtre de personne qui vont s'occuper de
distribuer l'information aux bonnes personnes, au bon moment en gérant les priorités
(ne pas respecter ce type de flux amène quasiment systématiquement à une gestion
catastrophique des priorités).

Voici un exemple de W.B.S. simplifié:

Figure 6 Exemple de W.B.S.

Le terme W.B.S. a une définition formelle dans la norme d'origine US MIL-HDBK-881A

(gratuitement disponible sur Internet et comportant 128 pages). Il est recommandé de
consulter la norme pour bien différencier rigoureusement la notion d'A.B.S. de celle de
W.B.S..

Ingénierie de Gestion de projets 95/523

[Link]
 Vincent ISOZ

Indiquons que le PMI recommande que tout responsable de projet doit refuser de reprendre ou
d'exécuter un projet s'il n'y a pas de W.B.S. de disponible (ou de W.B.S. sous forme de
planning de Gantt que nous allons voir de suite après) mais en même temps... ils
recommandant de ne pas obliger à travailler avec..... Le PMI n'étant pas à une contradiction
près...

[Link] Gantt
Le diagramme de Gantt est un outil utilisé (souvent en complément d'un réseau PERT) en
ordonnancement et gestion de projet et permettant de visualiser dans le temps les diverses
tâches liées composant un projet (il s'agit d'une représentation d'un graphe connexe, valué et
orienté). Il permet de représenter graphiquement l'avancement du projet sous la forme d'un
graphe connexe (toute tâche doit avoir une liaison entrante et sortante excepté le jalon de
début du projet et celui de fin du projet), valué (chaque tâche à une durée non nulle ou nulle)
et orienté (bon ça c'est simplement à cause de la flèche du temps).

Cet outil répond à deux objectifs: planifier de façon optimale et communiquer sur le planning
établi et les choix qu'il impose

L'exemple de diagramme de Gantt ci-dessus est très bon car comme vous pouvez le constater
les liaisons entre les tâches ne sont pas visibles. Il s'agit donc en toute rigueur d'un planning et
non d'un Gantt (car rien n'est connexe) et cela signifie aussi par extension que les dates ne se
mettront pas à jour en cascade automatiquement lors d'une modification du plan de projet et
que le calcul des marges totales et libres seront erronnées.

[Link] PERT
Le graphique PERT est une technique de gestion de projet qui permet de visualiser la
dépendance des tâches (réseau logique) et de procéder à leur ordonnancement en dehors du
ligne de temps et par un algorithme précis (que les responsables de projets appliquaient à la

Ingénierie de Gestion de projets 96/523

[Link]
 Vincent ISOZ

main jusqu'aux années 1980…) de déterminer le chemin critique du projet ainsi que les
marges totales et libres.

De nos jours, très rares sont les gens utilisant encore le PERT (appelé aussi "réseau de
tâches"). Les logiciels permettant de calculer les marges ainsi que le chemin critique
directements sur le Gantt cette représentative est abandonée petit à petit par les praticiens.

[Link] Time-Line
Une frise chronologique ou ligne du temps est une représentation linéaire qui associe des
événements à leurs positions dans le temps le long d'une échelle graduée, ce en quoi elle se
rapproche d'une chronologie.

Dans les entreprises, elle permet facilement lors de réunions de communiquer à un publique
de non spécialistes (qui n'arrivent pas à lire le Gantt) les jalons d'un projet.

Ingénierie de Gestion de projets 97/523

[Link]
 Vincent ISOZ

[Link] Diagramme de flux

En gestion et plus précisément selon le standard ISO 9001 pour la gestion de la qualité, un
diagramme de flux est un système organisé d'activités mesurables déclenché par un élément
prévu ou imprévu qui utilise des ressources (personnel, équipement, matériels et machines,
matière première et informations) pour transformer des éléments entrants en éléments de
sortie dont le résultat final attendu est un produit.

Voici quelques définitions officielles:

 Selon la norme AFNOR X 50 176: un processus est un système d'activité qui utilise
des ressources pour transformer des éléments entrants en éléments sortants.
 Selon la série de normes ISO 9000: un processus est un ensemble d'activités corrélées
ou interactives qui transforment des éléments d'entrée éléments de sortie.

Lors de la construction d'un diagramme de flux (processus) le responsable de projet peut

identifier des étapes inutiles ou manquantes dans un processus de travail et analyser la
conformité, la performance de celui-ci dans le temps afin de déterminer son efficacité en
utilisant la méthodologie Six Sigma (ISO 13053-1:2011). En utilisant la méthodologie Kaizen
il est aussi souvent possible d'optimiser le temps d'exécution d'un processus et sa fiabilité. Il
est aussi possible d'utiliser la méthodologie Six Sigma pour s'assurer de la stabilité statistique
d'un processus ou d'utiliser l'AMDEC pour le calcul de sa fiabilité.

Un processus est donc un outil très utile pour s'assurer de la stabilité, la conformité (qualité) et
le respect des règles de travail dans tout domaine d'activité quel qu'il soit et ceci avec tout le
retour d'expérience nécessaire afin d'éviter des erreurs déjà vécues.

Pour qu'un processus culture dans une organisation nous considérons souvent les chiffres
suivants:

 6 à 18 mois de définition
 2.5 ans de mise en vie, d'instrumentation
 1 à 2 ans d'optimisation des activités et organisations

Ingénierie de Gestion de projets 98/523

[Link]
 Vincent ISOZ

Les spécialistes en processus recommandent d'éviter la construction de flux à rétroaction afin

de garder le schéma le plus clair possible et de s'arranger afin que le processus et sa
documentation tiennent tous deux sur une seule et unique page A4.

Nous considérons également deux rôles majeurs dans le cas des processus:

1. Le Gestionnaire de processus: Les responsabilités du gestionnaire de processus

comprennent la planification et la coordination de toutes les activités nécessaires à son
fonctionnement, sa surveillance et l'établissement de tableaux de bords sur le
fonctionnement du processus. Le rôle du gestionnaire de processus est souvent
confondu avec celui de propriétaire du processus (voir Propriétaire de processus),
mais ces deux rôles peuvent être distincts dans les grandes organisations.

2. Le Propriétaire de processus: Les responsabilités du propriétaire de processus

comprennent la recherche de sponsors, la conception, la documentation, la gestion des
changements, l'amélioration continue, le contrôle du respect, la formation du processus
et de ses mesures. Ce rôle est souvent confondu avec celui de gestionnaire du
processus (voir Gestionnaire de processus), mais ces deux rôles peuvent être distincts
dans les grandes organisations.

Les formes à utiliser seront conformes à ISO 5807:1985.

Remarque: Un diagramme de flux comportant des bandes fonctionnelles est conformément au

BABOK devrait être appelé un "diagramme d'activité" et non un "diagramme de flux".

Il est possible dans MS Visio (par exemple...) d'ajouter des phases aux diagrammes de flux
fonctionnels comme celui ci-dessus. Dès lors, nous parlons de modèle MOSI pour "Méthode
d'Organisation et Stratégie d'Intervention".

Les informations (métadonnées) qu'il est typique de relier à chaque étape sont:

Ingénierie de Gestion de projets 99/523

[Link]
 Vincent ISOZ

 Créé par/Créé le (ISO)

 Identifiant étape processus (ISO)
 Responsable (ISO)/Back-Up
 Intervenants (ISO)
 Degré de délégation
 Niveau de confidentialité
 Coût médian d'exécution/Déviation de coût (Six Sigma)
 Temps moyen d'exécution /Déviation de temps (Six Sigma)
 Gravité défaillance (AMDEC)
 Effet potentiel de défaillance (AMDEC)
 Cause potentielle de défaillance (AMDEC)
 Délai moyen entre deux non conformités/MTBF (AMDEC)
 Quantifiable? (Six Sigma)
 Niveau de qualité en % (Six Sigma)
 Contact client

Enfin signalons au niveau global du processus les indicateurs suivants:

 Niveau de maturité CMM

 Rendement Global Combiné (voir page 119)
 Ratio d'efficacité du processus (rapport entre temps effectif de travail et temps total)

Ce dernier indicateur étant très simple donnons de suite sa définition:

temps de travail effectif

REP 
temps total y compris les temps d'attente

Comme on me le demande souvent voici la signification des formes standards de processus

(je fournirai un gabarit Microsoft Office Visio avec légendes et conformités à ISO 5807
pendant la formation):

Terminaison: Utilisez cette forme pour la première et dernière étape d'un processus.

Processus: Cette forme représente une étape dans votre processus.

Processus prédéfini: Utilisez cette forme pour un ensemble de sous-étapes d'un sous-
processus se trouvant défini ailleurs, souvent sur une autre page du même fichier.

Ingénierie de Gestion de projets 100/523

[Link]
 Vincent ISOZ

Décision: Cette forme indique une étape où la décision sortante dicte la prochaine étape à
faire. Il peut y avoir plusieurs sorties, mais souvent les deux les plus courantes sont Oui et
Non.

Document: Cette forme représente une étape qui résulte en la création d'un document.

Données: Cette forme indique que l'information arrive dans le processus depuis l'extérieur ou
quitte le processus. Cette forme peut aussi être utilisée pour représenter du matériel et est
parfois appelée "forme d'entrée/sortie".

Données stockées: Cette forme est utilisée pour représenter de l'information qui sera stockée.

Référence sur page: Cette forme indique simplement que la suite d'un processus se trouve
sur une autre page. Ceci est particulièrement utile pour les grands processus prenant plusieurs
pages.

Référence hors page: Forme utilisée pour créer un lien dynamique (interactif) permettant de
renvoyer automatiquement sur une autre page pour la suite d'un processus ou l'envoi à un
sous-processus.

Entrée manuelle: Étape utilisée pour représenter le fait qu'une personne apporte une
information au processus.

Ingénierie de Gestion de projets 101/523

[Link]
 Vincent ISOZ

Opération manuelle: Étape utilisée pour représenter le fait qu'une étape est effectuée par un
être humain.

Stockage interne: Cette forme représente une information saisie sur un ordinateur.

Donnée directe: Cette forme représente une information stockée comme un unique
enregistrement dans une base de données typiquement. Cette forme représente comme un
disque dur stock des données.

Donnée séquentielle: Quand une information est stockée de manière séquentielle, elle ne peut
être récupérée par hypothèse que manière séquentielle aussi. Par exemple, pour accéder à
l'enregistrement numéro 7, vous devrez d'abord passer par les enregistrements 1 à 6.

Enregistreur carte ou papier: Les anciens ordinateurs utilisaient des systèmes de cartes et
papier pour stocker et rapatrier des données et stocker pour exécuter des programmes.

Affichage: Cette forme représente une information qui sera affichée par une personne,
typiquement sur un écran d'ordinateur.

Ingénierie de Gestion de projets 102/523

[Link]
 Vincent ISOZ

Préparation: Cette forme indique où les variables d'un système mécanique ou informatique
doivent être réinitialisées pour une procédure.

Mode parallèle: Cette forme est utilisée pour indiquer où deux processus/actions/étapes
différents peuvent s'exécuter simultanément (en parallèle).

Limite de boucle: Cette forme représente le nombre de fois qu'une boucle d'un processus doit
s'exécuter avant de continuer à la prochaine étape.

Contrôle de transfert: Cette forme indique la manière particulière dont une transition entre
deux étapes doit se faire en indiquant avec une initiale le type de transition au milieu de la
forme (par exemple: P flux de type permanent, T flux temporaire, etc.)

[Link].1 Fiche processus

Il y a deux "écoles" en ce qui concerne les fiches processus:

1. Ceux qui font la fiche processus sur la même page et le même côté du processus mais
à droite (ce qui réduit malheureusement considérablement la place pour la
schématisation du processus mais qui a pour avantage que tout tient sur une seule page
A4). C'est une technique obsolète pour ceux qui travaillent sans papier en ce début de
21ème siècle.

2. Ceux qui font une fiche processus sur un page à part (ce qui malheureusement
nécessite de retourner la page/feuille mais a pour avantage de pouvoir mettre plus
d'information que la première méthode).

Personnellement, je préconise dans la majorité des cas la deuxième et voici un exemple type
de fiche processus:

Ingénierie de Gestion de projets 103/523

[Link]
 Vincent ISOZ

Figure 7 Exemple fiche processus

Ingénierie de Gestion de projets 104/523

[Link]
 Vincent ISOZ

[Link].2 Diagramme de flux SIPOC

SIPOC est l'acronyme de Supplier Input Process Output Customer, en français: Fournisseurs
Entrées Processus Sorties Clients.

Un diagramme SIPOC est un outil de visualisation pour identifier tous les éléments pertinents
associés à un processus P : son périmètre (frontières, début et fin), les sorties (O) les entrées
(I), les fournisseurs (S) et les clients (C). Il est recommandé d'employer le SIPOC dans la
phase initiale d'un projet d'amélioration d'un processus. Il fournit plus d'information qu'une
cartographique qui se concentre sur la description sommaire des étapes. Il oblige à définir qui
sont les fournisseurs et les clients.

Dans la méthodologie Six Sigma, le SIPOC est utilisé pendant la première étape du DMAIC,
Définir, afin de décrire le processus métier dont on veut améliorer la qualité. Comme ce
diagramme est propre à Six Sigma, il n'est pas soumis à la schématique ISO 5807.

Voici par exemple un exemple de diagramme SIPOC de Flux prépresse dans le cas d'un
workflow PDF/X (vous pouvez demander le PDF de qualité original à votre formateur si
besoin):

Ingénierie de Gestion de projets 105/523

[Link]
 Vincent ISOZ

Ingénierie de Gestion de projets 106/523

[Link]
 Vincent ISOZ

[Link] Analyse par arbres d'erreurs (A.A.E.)

L'analyse par arbres d'erreurs, appelée aussi "analyse par arbres de défaillances probabilistes"
(A.A.D.P.) ou encore "analyse par arbres de pannes" A.A.P.) sont utilisés dans les études
qualitatives ou quantitatives de fiabilité des systèmes et font partie intégrante de la norme
ISO 31010.

Basée sur une représentation graphique mettant en évidence les relations de cause à effet,
cette technique est complétée par un traitement mathématique qui permet la combinaison de
défaillances simples ainsi que leur probabilité d'apparition. Cet outil permet donc de
quantifier l'occurrence d'un Événement Redouté (E.R.) de bien mettre en évidence les causes
profondes probables d'un problème et les interactions avec d'autres causes.

Un arbre de défaillance est généralement construit de haut en bas avec la ligne la plus haute
ne comportant que l'évènement dont nous cherchons à décrire comment il peut se produire.
Cependant il est par la suite souvent lu de bas en haut.

Chaque ligne détaille la ligne supérieure en présentant la combinaison ou les combinaisons

susceptibles de produire l'évènement de la ligne supérieure auquel elles sont rattachées.

Ces relations sont représentées par des liens logiques OU, et ET (on emploie généralement le
terme de "porte" OU et de "porte" ET) comme le montre le schéma ci-dessou fait avec
MS Visio:

L'arbre ci-dessus est donc un exemple d'analyse par arbre de pannes qualitatif puisque aucune
probabilité n'est indiquée. Dans MS Visio il est très pénible d'associer des probabilités car il
faut construire toutes les formules à la main. Je conseille vivement l'utilisation du logiciel
Isograph pour faire des A.D.P. quantitatifs de haut niveau rapidement (ce dernier logiciel
présenté au début de ce support associe la méthode de Monte-Carlo avec les A.D.P.).

Par contre si des probabilités sont associées, rappelons les axiomes de Kolmogorov suivants:

0  P( A)  1

pour tout événement A et:

Ingénierie de Gestion de projets 107/523

[Link]
 Vincent ISOZ

P(U )  1

pour l'univers de tous les événements. Nous avons aussi si deux événements A et B sont
indépendants la probabilité que les deux événements se produisent en même temps (porte
ET):

P( A  B)  P( A)P(B)

et si les événements sont mutuellement exclusifs, nous avons la probabilité disjointe (porte
OU compatible) que soit A ait lieu soit B ait lieu (mais sans prendre donc en compte que les
deux aient lieu en même temps) suivante:

P( A  B)  P( A)  P(B)  P( A  B)

et si les événements sont non mutuellement exclusifs (porte OU incompatible), nous avons la
probabilité conjointe suivante:

P( A  B)  P( A)  P(B)

Enfin, si les événements sont totalement incompatibles (porte XOR) nous avons:

P( A  B)  P( A)  P(B)  2P( A)P(B)

Le lecteur intéressé trouver un autre exemple avec la légende/standardisation des formes dans
la norme ISO 31010:2009 ou CEI 61025 annexe B.14 (ou sur Wikipedia US).

[Link] Total Quality Management (TQM)

La qualité totale (Total Quality Management, TQM en anglais), dont la traduction japonaise
est le Kaizen, est une démarche quasi psychanalytique de gestion proactive de la qualité (de
toute façon tout doit être proactif dans la gestion...) dont l'objectif est l'obtention d'une très
large mobilisation et implication de toute l'entreprise (total) pour parvenir à une gestion
(management) par la qualité (quality) parfaite… en réduisant au maximum les gaspillages et
en améliorant en permanence les éléments de sortie (outputs) à très long terme. Selon le PMI
l'idée est que des améliorations continues infinitésimales sont préférables à des améliorations
brutales de la qualité (curieux que les gestionnaires de la majorité des organisations semblent
oublier systématique cette règle depuis presque 100 ans...).

Cette démarche repose sur ISO 9004, référentiel qui sert de document explicatif au standard
ISO 9001.

Cette méthodologie et sa représentative associé est étroitement liée à la TPM (Total

Productivity Management, TPM en anglais) dont le principe se résume grossièrement aux
trois points suivants:

 Maintenance: maintenir en bon état (réparer, nettoyer, graisser)

 Productive: assurer la maintenance tout en produisant
 Totale: considérer tous les aspects et y associer tout le monde (à tous les rangs!)

Ingénierie de Gestion de projets 108/523

[Link]
 Vincent ISOZ

Donc au même titre que la TQM (appliqué à la qualité en générale et pas seulement à la
production), la TPM consiste à chercher à maximiser le temps productif, réduire le temps non
productif dû aux arrêts et pannes, conserver les cadences optimales et réduire la non-qualité12.

Au-delà du simple maintien en bon état des machines ou de leur place de travail, la démarche
TQM/TPM pousse à modifier et à améliorer celles-ci. L'implication des employés est
l'occasion d'élever leur niveau de compétence et d'enrichir leurs tâches en leur confiant la
maintenance de premier niveau (avec leur accord et s'ils en sont motivés!). Par ailleurs, ils
connaissent leur outil de travail et l'environnement associé de manière intime. Sauf si les
employés sont temporaires et/ou d'un niveau trop faible, ou pas motivés pour des raisons
quelconques, ils ne se sentent pas concernés par ce qui se passe, ils subissent, c'est un
problème de motivation et de compétence.

L'indicateur utilisé, le taux de rendement synthétique (TRS) qui est le rapport entre temps
utile et temps employé, mérite son qualificatif car il restitue une vision simple et sévère, qui
englobe tous les paramètres affectant le rendement de la machine selon le triptyque
disponibilité, performance et qualité. L'analyse des composantes du TRS indique où les
efforts sont à porter.

Figure 8 Principe de découpage analyse TPM

La représentative type des schémas TQM et TPM ressemble énormément à ISO 5807:85.

12
La non-qualité ne se limite pas à celle qui est détectée par le client.

Ingénierie de Gestion de projets 109/523

[Link]
 Vincent ISOZ

Définitions:

D1. Manager par la qualité c'est appliquer au système (ensemble de processus)

d'organisation les principes qui permettent l'amélioration et le développement harmonieux et
durable du système.

D2. Manager de la Qualité c'est appliquer les principes qui permettent d'assurer la qualité du
résultat d'activités.

[Link] Business Process Management Notation

Business Process Modeling Notation a été développée par la Business Process Management
Initiative (BPMI), et est maintenant maintenue par l'Object Management Group (OMG)
depuis leur fusion en 2005. Le but principal de BPMN ([Link] pour la
documentation détaillée et gratuite) est de fournir une notation qui soit réellement
compréhensible par tous les utilisateurs de l'entreprise, depuis les analystes métier qui créent
les ébauches initiales des procédures, jusqu'aux développeurs responsables de mettre en place
la technologie qui va exécuter ces procédures, et finalement, jusqu'aux utilisateurs de
l'entreprise qui vont gérer et monitorer ces procédures. Ainsi, BPMN crée un pont standardisé
pour combler le vide entre la modélisation des procédures d'entreprise et la mise en place des
procédures.

Ingénierie de Gestion de projets 110/523

[Link]
 Vincent ISOZ

Le meilleur logiciel que je connaisse à ce jour pour faire de la BPMN de manière

professionnelle et rapide est BizAgi ([Link]

[Link] IDEF0
La SADT (en anglais Structured Analysis and Design Technique) - connue aussi sous le label
[Link].0 (en anglais Integration Definition for Function modeling) - est l'un des standards de
description graphique d'un système complexe par analyse fonctionnelle descendante, c'est-à-
dire que l'analyse chemine du général (dit "niveau A-0") vers le particulier et le détaillé (dits
"niveaux Aijk"). SADT est une démarche systémique de modélisation d'un système complexe
ou d'un processus opératoire.

Voici le principe du concept:

Ingénierie de Gestion de projets 111/523

[Link]
 Vincent ISOZ

et voilà ce que fait par exemple en réalité un logiciel comme Microsoft Office Visio:

Ingénierie de Gestion de projets 112/523

[Link]
 Vincent ISOZ

[Link] Arbres de décision

Un arbre de décision est un outil d'aide… à la décision et à l'exploration de données. Il permet
de modéliser simplement, graphiquement et rapidement un phénomène mesuré plus ou moins
complexe. Sa lisibilité, sa rapidité d'exécution et le peu d'hypothèses nécessaires a priori
expliquent sa popularité actuelle.

MS Office Visio n'est pas capable de faire ce genre de schémas avec les calculs associés de
manière simple. Il faudra typiquement se procurer soit TreeAge, soit Isograph (déjà
mentionnés lorsque nous avons présenté des logiciels au début du support), soit
Precision Tree de Palisade qui permettent non seulement de mettre de probabilités fixes mais
aussi d'associer à chaque branche une fonction de distribution. Avec TreeAge pour un cas à
probabilité fixe, cela donne:

Lorsque nous avons qu'une seule branche dans ce type d'arbore avec un seul gain attendu au
bout, nous parlons alors de "d'arbres de probabilités pondérés" (c'est certainement le cas le
plus courant).

[Link] Options réelles

Lors de l'utilisation d'arbres pour la décision dans l'investissement dans des projets (nous
parlons alors "d'analyse d'investissement par options réelles") il faut prendre en compte que
chaque série parallèle de branches représente une période du projet (mois, trimestre, semestre
ou année). Il ne faut donc pas oublier alors d'actualiser les valeurs aux taux de rendement sans
risque du marché correspondant à chaque période. De plus l'arbre permet aussi de calculer la
valeur d'option de l'investissement, ce qui est parfois demandé par la direction.

Effectivement, considérons la situation à une période suivante:

Ingénierie de Gestion de projets 113/523

[Link]
 Vincent ISOZ

Dans un logiciel cela donnera typiquement (malheureusement les coûts des options sont
toujours cachés dans le total de la branche dans les logiciels spécialisés, raison pour laquelle
je préfère dessiner mes propres arbres dans Microsoft Excel):

Alors nous avons bien évidemment:

E Pay-Off   12  0.75  (30  4  2)  0.25  (6  0.5  0.8)

 12  0.75  32  0.25  6.3  13.575

Car l'arbre se réduit à:

Ingénierie de Gestion de projets 114/523

[Link]
 Vincent ISOZ

Mais qu'en est-il de la valeur actuelle nette (VAN/N.P.V)? Eh bien ce type de logiciels nous
permettent facilement d'intégrer ce type de calcul avec ou sans simulation de Monte-Carlo.
Ainsi, si le taux sans risque du marché est à 10% sur un an, nous avons alors (voir le chapitre
concernant l'eVAN à la page 320 pour les explications techniques):

0.75  32  0.25  6.3

eVAN  12   11.25
(1  10%)1

Maintenant il peut être intéressant (même exigé par la direction!) de calculer le "prix de
l'option d'investir". Dans la configuration pessimiste notre arbre devient:

Nous avons alors pour cette configuration:

0.75  20  0.25  3.8

eVAN  12   3.95
(1  10%)1

Le prix de l'option réelle d'investissement (expected Option Value) est alors:

eOV  11.25  3.95  7.2M$

Nous donnerons d'autres exemples avec des détails bien plus tard.

Ingénierie de Gestion de projets 115/523

[Link]
 Vincent ISOZ

[Link] Tableau de bord (dashboard)

En gestion de projets ou de la qualité, un tableau de bord est un synoptique permettant en un
simple coup d'œil d'avoir un résumé graphique et colorié indiquant la performance et le
rendement de certains éléments dont l'analyse est souhaitée.

ou:

Ingénierie de Gestion de projets 116/523

[Link]
 Vincent ISOZ

Le lecteur intéressé à vouloir faire des tableaux de bord dans les normes pourra se reporter à
la très bonne base que constitue la norme NF FD X 50-171 (qui est utile mais d'un niveau très
peu élevé) que je ne peux pour des raisons évidentes de copyright par reproduire ici. Sinon, à
part entrer dans les mathématiques de la méthode Six Sigma (cartes de contrôles13) l'outil ne
consiste qu'à utiliser des outils du niveau de l'école obligatoire et un stagiaire ou un junior
peut alors très bien faire le travail.

En lisant la norme, le lecteur se rendra compte qu'il vaut mieux essayer de travailler aux
maximum avec des taux (pourcents) afin de pouvoir comparer sur des volumes / objectifs /
changements dont la base n'est initialement pas forcément la même (donc sans unités).

Pour information il y a même une époque quand je n'avais rien d'autre à faire je créais des
indicateurs (c'était amusant et enfantin). Voilà un exemple un peu tordu mais qui était
pratique (bien qu'incomplet).

Début de l'exemple:

Plutôt que d'avoir une bête flèche de couleur monochromatique nous pourrions déjà avoir une
flèche avec un dégradé. Ainsi:

13
Cartes X-S, X-R, -C, -P, -NP, -G, Leney, CUSUM, EWMA, ARIMA... se référer à mon livre sur les
mathématiques appliquées pour les détails sur ces cartes.

Ingénierie de Gestion de projets 117/523

[Link]
 Vincent ISOZ

qui indiquerait une valeur actuelle (valeur ponctuelle de 30'000 d'où le "k") haussière sachant
que la dernière valeur était baissière (couleur rouge). Le vert indiquant que pour la prochaine
période nous nous attendons à une hausse.

Nous pourrions ainsi avoir:

Indiquant que la valeur actuelle est haussière (valeur ponctuelle de 300 d'où le "d") mais que
la période précédente était baissière (d'où le rouge en bas) et la prochaine période sera aussi
probablement baissière.

Nous pourrions alors aussi avoir (nous arrêtons de mettre le nombre en coin car c'est toujours
le même principe):

Indiquant deux valeurs haussières successives (le vert étant la période précédente) et la
prochaine période est prévue comme étant baissière.

Maintenant introduisons de la volatilité (car c'est important!). Par exemple:

signifierait un indicateur à faible volatilité (avec valeur actuelle baissière, valeur précédente
haussière et la projection baissière). Et:

signifierait, indicateur à forte volatilité, avec valeur précédente baissière, valeur actuelle
baissière, valeur future projetée haussière.

Ingénierie de Gestion de projets 118/523

[Link]
 Vincent ISOZ

Lsa pointe de la flèche peut avoir encore un disque de couleur pour indiquer si l'objectif du
management est (ou "reste") atteint ou non (vert: ="ok", rouge: "pas ok") et des lignes peuvent
apparaître pour montrer les limites USL/LSL ou de la WECO du type (inspiration des cartes
de contrôle):

Fin de l'exemple... (quand on pense que la majorité des entreprises paient des cols blancs pour
faire des indicateurs avec des relativement hauts salaires salaires alors qu'un enfant pourrait
le faire aussi... j'ai toujours eu de la peine à comprendre le raisonnement des entreprises à ce
niveau là...?).

7.1.3 Optimisation des processus

Nous n'allons pas aborder ici l'optimisation des processus (business process reengineering)
dans le sens de leur clarté, leur standardisation conformément aux normes, à l'identification
des étapes inutiles ou manquantes qui sont tous trois accessible à toute personne possédant un
peu de bon sens et de temps.

Ce qui pose problème depuis le début du 20ème siècle et la mesure quantitative (dans le sens
scientifique du terme) de l'efficacité, on parle dans la statistique de "capabilité", d'un
processus et de l'analyse numérique de la variation de sa performance dans le temps et de sa
volatilité. C'est ce dont à quoi nous allons nous attarder ici.

Comme nous l'avons vu dans le cours de Statistiques, la loi Normale est une fonction en
forme de "cloche" donnée dans le cas général univarié par:

dont les écarts-types sont utilisées pour donner l'intervalle de probabilité cumulée de se situer
dans ces bornes centré sur la moyenne comme représenté ci-dessous:

Ingénierie de Gestion de projets 119/523

[Link]
 Vincent ISOZ

Ceci étant rappelé, nous avons également présenté dans le cours AMDEC les probabilités
conjointes dans le cadre de Six Sigma (ISO 13053-1:2011) pour une chaîne de processus P
connectés en série.

Au fait les processus mentionnés ne sont pas forcément des processus industriels mais
peuvent être assimilés sous des hypothèses identiques à des processus quelconques
(administratifs, procédures, workflows, etc.).

Nous avions vu que la probabilité conjointe (ou cumulée) est appelée dans Six Sigma "Rolled
Troughput Yield" (R.T.Y.) ou "Rendement Global Combiné" (R.G.C.) et est donnée par (voir
mon livre de Mathématiques Appliquées):

Par exemple l'application de la relation précédente donne pour un processus série en 4 étapes
dont la fiabilité est de 90% chaque (vous pouvez imaginer aussi qu'il s'agit de 4 tâches en
séquence d'un projet!):

Ingénierie de Gestion de projets 120/523

[Link]
 Vincent ISOZ

nous nous retrouvons au final avec une fiabilité de 65.6% soit une probabilité cumulée de
défaut pour l'ensemble du processus de 34.4%14.

Redonnons le tableau au pire selon Six Sigma, soit le tableau en procédé non centré avec une
déviation de la moyenne de 1.5 (donc à droite mais on pourrait prendre à gauche et les
résultats sont les mêmes) par rapport à la cible et d'écart-type unitaire avec USL et LSL
symétriques (ce qui restreint toujours le champ d'application):

Cp Cpk Défauts (PPM) Niveau de qualité Sigma Critère

0.5 0 501350 1.5 Mauvais

0.6 0.1 382572 1.8
0.7 0.2 27412 2.1
0.8 0.3 184108 2.4
0.9 0.4 115083 2.7
1 0.5 66810 3
1.1 0.6 35931 3.3
1.2 0.7 17865 3.6
1.3 0.8 8198 3.9 Limite
1.4 0.9 3467 4.2
1.5 1 1350 4.5
1.6 1.1 483 4.8
1.7 1.2 159 5.1
1.8 1.3 48 5.4
1.9 1.4 13 5.7
2 1.5 3.4 6 Excellent

où nous avons démontré dans le cours Six Sigma (ou voir mon ouvrage sur les mathématiques
appliquées pour la démonstration) que les valeurs PPM étaient données par:

14
Pour le cas général série/parallèle, le lecteur pourra sa référer à mon ouvrage sur les
mathématiques appliquées. On parle alors de "AMDEC processus".

Ingénierie de Gestion de projets 121/523

[Link]
 Vincent ISOZ

Ce qui donne pour un niveau de qualité de 3 Sigma en utilisant Maple:

>evalf((1-1/sqrt(2*Pi)*int(exp(-(x-1.5)^2/2),x=-
infinity..(1*3))))*1E6+evalf((1/sqrt(2*Pi)*int(exp(-(x-1.5)^2/2),x=-infinity..-
(3*(1+1)))))*1E6;

soit une valeur de 66'810 c'est-à-dire la valeur de la 6ème ligne. Ce qui correspond à ~6.68%
en termes de probabilité cumulée de non-qualité (66'810 divisé par 1 million et mis en
pourcents) et donc respectivement à une probabilité cumulée de ~93.32% de qualité.

Nous avons le tableau suivant qui peut résumer certaines valeurs importantes du tableau
précédent en utilisant la commande Maple:

Qualité% 93.32 99.38 99.98 99.9996

1 1.33 1.68 2
Jugement Mauvais Limite Bon Excellent

Une vision sympathique de la chose est (je n'ai jamais pu vérifier la véracité de ces
informations):

3.8 Sigma 6 Sigma

Défaut par million 10'000 (1% of total) 3.4 (0.00034% of total)
Eau potable 15 minutes d'eau non potable 1 minute non potable tous les
chaque jour 7 mois
Erreurs 5.000 erreurs médicales par semaine 1.7 opérations ratées par
semaine
Aéroport 1 atterrissage raté par jour 1 atterrissage raté tous les 5
ans
Électricité Pas d'électricité 3 heures par mois Une heure de coupure tous les
34 ans
La Poste 20'000 lettres perdues à l'heure 7 lettres perdues par heure

Sous l'hypothèse que chaque étape d'un processus série suit la même loi avec les mêmes
moments et les mêmes déviations par rapport à la cible nous avons alors:

Étapes/Qualité%

1 93.32 99.38 99.98 99.9996

7 61.63 95.73 99.84 99.9976
10 50.08 93.96 99.77 99.9966

Ingénierie de Gestion de projets 122/523

[Link]
 Vincent ISOZ

20 25.08 88.29 99.54 99.9932

40 6.29 77.94 99.07 99.9864
60 1.58 68.81 98.61 99.9796
80 0.40 60.75 98.16 99.9728
100 0.10 53.64 97.70 99.996
... ... ... ... ...

où chaque ligne représente le Rolled Troughput Yield donc calculé avec:

où i est donc le nombre d'étapes du processus (1,7,10,20,40) et où les probabilités sont

données par la première ligne (1). Ainsi, avec un niveau de qualité de 3 et une déviation à
la cible de 1.5 nous avons pour un processus de 20 étapes identiquement distribuées:

Ce qui est catastrophique! On comprend donc l'importance d'avoir un haut niveau de qualité
sur des processus complexes.

Ainsi, l'objectif du Lean Six Sigma dans une entreprise sera d'augmenter le niveau de qualité
avec d'avoir un RTY maximum pour un nombre donné d'étapes d'un processus.

Considérons comme exemple pratique le cas suivant:

Ingénierie de Gestion de projets 123/523

[Link]
 Vincent ISOZ

Nous avons alors une probabilité de réussite sur l'ensemble de:

ce qui correspond à un niveau de qualité d'environ 3 sigma!

Enfin, pour clore se sujet et pour le plaisir voici un logigramme (évidemment pas aux
normes...) assez représentatif parfois ce qui se passe dans la réalité:

Figure 9 Logique de traitement des incidents (source: ISBN 2708130226)

Ingénierie de Gestion de projets 124/523

[Link]
 Vincent ISOZ

8. Conduite et gestion de projets

Si votre responsable passe vous voir et vous demande de superviser un projet, c'est qu'il a
partiellement compris qu'une bonne gestion de projets peut faire gagner (si certaines
hypothèses sont respectées) du temps et de l'argent. Comme plusieurs millions de personnes à
travers le monde, il vous sera demandé d'utiliser votre grande expérience, votre habilité, votre
leadership et votre esprit analytique afin de permettre à l'entreprise de croître.

Si vous n'avez jusque-là jamais, ou pratiquement pas, suivi de formation officielle en gestion
de projet, ou ne n'êtes pas en possession d'une diplôme universitaire dans un domaine des
particulier sciences exactes, félicitations: vous voilà devenu gestionnaire de projets par
accident. On vous a sans doute confié cette fonction parce que vous êtes fiable (à moins qu'il
y a des attentions moins louables…) et que vous savez organiser votre travail, mais vous
n'avez qu'une vague idée de ce que vous êtes censé faire ou de ce qu'il faut faire pour réussir
ou obtenir une certaine légitimité de vos collègues hautement diplômés.

La gestion de projet inclut des techniques qui sont souvent considérées comme simple par de
nombreux spécialistes. Cependant il faut savoir que cela n'est pas une généralité. Plus les
projets sont gros, plus cela nécessite des compétences scientifiques analytiques pointues.
Raison pour lesquelles les gros projets sont souvent donnés à des personnes provenant du
monde financier et qui ont l'habitude de manipulation des équations. Mais dans le cadre de
petits projets (quelques millions de francs) cela reste simple et il n'est pas nécessaire de sortir
l'artillerie lourde.

Afin de tirer le maximum d'un projet, il est impératif pour le lecteur de bien saisir tous les
aspects minimum relatifs à la culture (très) générale de la gestion de projet. Nous discuterons
donc de celle-ci dans cette section, en élaborant les concepts reliés à la gestion informatisée
de projet. Nous examinerons aussi les facteurs clés de succès, de manière non exhaustive, que
l'on doit toujours considérer dans l'élaboration d'un projet.

L'ensemble des éléments acquis ici constitueront une partie du corps des connaissances de
base du gestionnaire de projet (Project Management Body Of Knowledge – PMBOK) qui
selon une définition internationale par le PMI (Project Management Institute) est donnée en
gros par:

«Le PMBOK inclus les connaissances prouvées et généralement acceptées, ainsi que les
pratiques traditionnelles qui sont largement appliquées, comme des méthodes innovatrices et
avancées de pratiques dans la gestion de projets ».

Cet ensemble de pratiques et de connaissances est accessible dans de nombreux ouvrages et

ne nécessitent aucunement une formation de haut niveau. Il convient cependant de préciser
que pour des projets considérés comme sensibles que des connaissances d'un tout autre niveau
sont nécessaires:

 Théorie de la décision (optimum de Pareto, équilibre de Nash, jeux coopératifs, jeux

non-coopératifs, critères de Laplace, etc.)

Ingénierie de Gestion de projets 125/523

[Link]
 Vincent ISOZ

 Mathématiques financières15 (escomptes, amortissements, spéculation, économétrie,

rentes, emprunts, retour sur investissement, taux internet de rentabilité et actuariel,
équilibre de Cournot, etc.)

 Statistiques descriptives15 (moyenne, médiane, mode, écart-type, variance, loi de

gauss, courbe de Pareto, loi de Poisson, loi Beta, SPC Six Sigma, etc.)

 Modélisation du choix (modèles de logit et probit)

 Techniques de gestion15 (loi de Wilson, droite d'Henry, PERT probabiliste,

estimateurs empiriques, loi de Weibull, etc.)

 Algorithmique (théorème du point fixe, méthode de Newton, théorème du simplexe,

recherche opérationnelle, méthode Monte-Carlo, théorie des graphes)

 Connaissances pratiques et théoriques à jour dans le domaine applicatif (veille

technologique et économique)

15
Voir cours "MS Excel Maths financières" avec votre formateur

Ingénierie de Gestion de projets 126/523

[Link]
 Vincent ISOZ

L'IPMA quant à elle définit (est c'est un excellent point de vue) les compétences d'un
responsable de projet dans trois domaines bien précis16 (le "Eye of Competence"):

1. Les compétences contextuelles (propres au contexte environnemental du projet)

2. Les compétences techniques

3. Les compétences comportementales

Figure 10 Oeil du IPMA

Avec les détails suivants qui constituent aussi un excellent référentiel!:

16
Dans une micro-conférence donnée une fois par l'agence de placement Adecco sur les critères de sélection d'un
bon responsable de projet, on retrouvait ses 3 points.

Ingénierie de Gestion de projets 127/523

[Link]
 Vincent ISOZ

Ainsi, les compétences représentées dans la figure ci-dessous peuvent être rangées dans une
de ces catégories:

Remarque: L'optimisation sous contrainte inclus également les contraintes organisationnelles

et consiste à jouer avec les 3 critères habituels: délais - coûts - qualité pour arriver aux

Ingénierie de Gestion de projets 128/523

[Link]
 Vincent ISOZ

objectifs. Par exemple, si la contrainte est de type "hiérarchique" (conflits organisationnels

internes) il faut essayer de responsabiliser les supérieurs pour résoudre le problème ou
proposer des choix à ceux-ci et de prendre la décision sous couverture d'un papier signé qui
valide l'acceptation du choix.

Depuis déjà plusieurs décennies, la gestion de projet a contribué de façon très significative à
la nouvelle pratique de la gestion. Grâce à cette approche, les organisations peuvent un peu
mieux planifier, coordonner, diriger et surtout contrôler leurs ressources et ce, de façon
structurée et optimale. En effet, la gestion informatisée de projet procure un outil très puissant
aux gestionnaires d'aujourd'hui par sa flexibilité et sa polyvalence. De plus, elle devrait
permettre de résoudre les problèmes les plus complexes.

La philosophie de la gestion de projets permet donc de faire face à des défis jadis
insurmontables pour les administrations traditionnelles. Il s'agit d'une méthodologie avant-
gardiste répondant à un monde de plus en plus complexe et dynamique. Elle répond à un
besoin pressant de faire travailler ensemble les ressources multidisciplinaires dans l'atteinte
d'un but commun. Elle génère la créativité, l'initiative et l'empowerment vis-à-vis des
membres de l'équipe de projet.

Plusieurs définitions de la gestion de projet existent un peu partout dans la littérature

académique. J.R. Meredith et S. Mantel, dans leur ouvrage «Project Management» la
définissent comme étant:

«la gestion des interfaces entre la performance, le temps et les coûts»

Ou selon l'AFNOR:

«La gestion de projet est l'ensemble des méthodes, outils d'évaluation, de planification et
d'organisation permettant d'atteindre ses objectifs en respectant les contraintes de
performance, de délais, et de coûts.»

Ou selon le PMBOK version 4.0:

«A project is a temporary endeavour that is progressively planned, controlled and executed by

people, working with some constraints on resources that results in a unique product service or
result that isn't possible for the organization to achieve through its normal operations.»

Ingénierie de Gestion de projets 129/523

[Link]
 Vincent ISOZ

En fait, la gestion de projet nous permet de livrer un bien et/ou un service de qualité à la
bonne place, au bon moment, à la bonne personne et au meilleur coût possible. C'est donc une
activité généralement isolée comportant des objectifs très bien définis.

Un projet est souvent l'effet d'une cause qui est:

- Une demande du marché

- Une demande d'un client (interne ou externe)
- Une opportunité stratégique
- Une évolution suite à un changement de l'environnement (légal, social, technologique)

8.1 Historique de la gestion de projets

La gestion de projets par progiciel fait appel à un certain nombre de techniques dont il est
intéressant de connaître un petit historique et les éléments principaux:

 En 1917, Henry L. Gantt, ingénieur américain assistant de Frederick Taylor (ingénieur

et économiste américain de l'organisation scientifique du travail O.S.T), doit organiser
la production d'un atelier. Dans ce but, il développe un système de représentation
graphique des activités sur une échelle de temps: le diagramme à barres. Aujourd'hui,
on parle de "Diagramme de Gantt" (Gantt Chart)

 En 1928 le mathématicien John Von Neumman reprend les travaux du 17ème siècle sur
la théorie des jeux sous un formalisme mathématique moderne. Une dizaine d'années
plus tard, cette théorie sera avec les améliorations de John Nash (Prix Nobel
d'Economie) à la base de toutes les décisions en entreprise ou en économie à l'échelle
mondiale.

 En 1940, les physiciens et les mathématiciens créent les bases des techniques
quantitatives statistiques de la gestion. La méthode de Monte Carlo, initialement
élaborée par les mathématiciens Nicholas Metropolis et Stanislaw Ulam en 1949, a été
utilisée à cette époque pour le projet Manhattan aux laboratoires de Los Alamos. Elle
est utilisée à outrance aujourd'hui dans la gestion des risques et la théorie du choix à
avenir incertain.

 Dans les années 1940 William Edwards Deming, Statisticien, mondialement connu
pour sa méthode PDCA (Plan Do Check Act) développe les techniques mathématiques
statistiques dans le domaine de la gestion de projets en se basant sur les travaux
mathématiques de Walter Shewhart développés dans les années 1920:

Ingénierie de Gestion de projets 130/523

[Link]
 Vincent ISOZ

Niveau de maturité
ACT PLAN

CHECK DO

Amélioration de
la qualité affective

Consolidation du niveau atteint

Base de référence = Reference Baseline

Échelle de temps

Le PDCA vise donc à l'amélioration continue comme objectif permanent et en stabilité

le niveau de consolidation atteint. Mais pour appliquer correctement cette méthode (au
même titre que ISO 9001), il faut définir le périmètre d'activités qui sera analysé et
amélioré, découper le périmètre en processus (cartographie des processus) et
formaliser chacun des processus (activités, intrants, extrants, rôles, compétences, etc.).

 Dans les années 1950, les sociétés Dupont de Nemours et Remington Rand cherchent
une technique qui permette de gérer au mieux un grand nombre de tâches liées entre
elles. En 56/57, Morgan Walker et James Kelley mettent au point un algorithme de
calcul par des mathématiciens, le CPM (Critical Path Method). Il permet de calculer la
durée totale d'un projet à partir de la durée de chaque tâche et des liaisons existant
entre les différentes activités du projet.

Parallèlement au CPM, la méthode PERT (Program Evaluation and Review Technic)

est créée par la marine américaine pour l'élaboration de ses missiles Polaris. Cette
technique met graphiquement en évidence les relations entre les tâches hors du temps.

 Dès 1958, le calcul mathématique du CPM, abrégé CP (Critical Path), est appliqué au
PERT. Par ce raisonnement, toute modification de la durée d'une tâche située sur ce
chemin entraîne une modification dans la date de fin du projet.

Adoptée par la marine américaine, cette dernière estime n'avoir passé que 5 ans sur le
projet Polaris au lieu des 7 prévues.

 En 1965, première utilisation de Monte-Carlo appliquée à la gestion de projets par le

statisticien R.M. Vanslyke.

 En 1970, le statisticien A.V. Feigenbaum et le chimiste K. Ishikawa élaborent ce qui

sera plus tard le "Total Quality Control".

 En 1995, le physicien E. M. Goldratt publie un article sur la fameuse Ctritical Chain et

Theory of Contraints (TOC).

 Depuis 2010 seulement, les techniques de modélisation et simulation stochastique du

risque sont enseignées dans certaines universités en Suisse...

Ingénierie de Gestion de projets 131/523

[Link]
 Vincent ISOZ

 Aujourd'hui on conjugue les trois techniques. Un Gantt affiche les relations entre les
tâches (ainsi que le réseau PERT mais hors du temps) et peut aussi afficher le chemin
critique (méthode CPM).

Nous pouvons donc constater que toutes les techniques et outils de pointe ont été créés par des
scientifiques de haut vol (et nous pourrions encore citer le physicien Eliyahu Moshe Goldratt,
le statisticien Pareto, le statisticien Joseph Juran, le mathématicien Gauss, etc.). In extenso,
nous pouvons nous demander s'il est judicieux de laisser des personnes qui n'ont pas de profil
scientifique s'occuper de projets complexes ou d'analyser la qualité dans les entreprises...
(sachant que le niveau des MBA et EMBA est misérablement bas relativement aux
mathématiques puisqu'il ne dépasse pas la deuxième année de licence).

8.2 Intervenants
Pour répondre aux questions posées et satisfaire la demande, de nombreux intervenants sont
consultés lors de la modélisation d'un projet ou de l'exécution de celui-ci (il faudrait vous
positionner parmi ceux-ci). Voici la liste de quelques-uns de ceux-ci:

Le Maître d'ouvrage:

Personne physique ou morale qui sera propriétaire de l'ouvrage réalisé. Plus

communément appelé le "client".

Le Maître d'œuvre:

Ingénierie de Gestion de projets 132/523

[Link]
 Vincent ISOZ

Personne physique ou morale qui réalise le travail pour le maître d'ouvrage.

Le Sponsor du projet/Project Champion:

Gestionnaire senior ayant un pouvoir décisionnel supérieur à celui de project ou

portfolio manager et étant en relation étroite avec la direction pour faire accepter le
projet qui est en phase d'études et faire comprendre à la direction l'intérêt de le gérer
selon des méthodes standardisées et éprouvées. Si le sponsor n'a pas le temps de gérer
le projet et n'est pas assez compétent pour motiver l'équipe de projet, il pourra
déléguer cette tâche à une autre personne qu'on désignera alors par le terme "project
champion".

Le Chargé d'affaires/Portfolio Manager:

L'affaire est une demande ou un besoin exprimé par un Client (ou un Prospect). Le
chargé d'affaires assure les contacts avec le maître d'ouvrage avant la conclusion du
contrat, pendant son déroulement et lors de son achèvement ainsi qu'après (contrat de
clôture équivalent à un bon de réception). Le chargé d'affaires gère plusieurs projets
qui n'ont strictement aucune relation entre eux (il s'agit de la définition d'un "portfolio"
de projets).

Le Responsable de programme/Program Manager

Personne qui supervise un projet qui a été découpé en plusieurs sous-projets dû à la

complexité de la tâche.

Le Coordinateur de projet/Project Manager:

L'[Link] (Association Française de Normalisation) nous donne la définition

(légère…) suivante: "personne physique chargée dans le cadre d'une mission définie,
d'assumer la maîtrise du projet, c'est-à-dire de veiller à sa bonne réalisation dans les
objectifs de technique, de coût et de délai".

Le Responsable planification/Scope & Time Manager:

Il identifie et organise les tâches, publie l'échéancier de chaque activité; ensuite, il met
à jour le planning et calcule la probabilité que les délais soient maintenus. Souvent, le
coordinateur de projet assume cette fonction.

Le Responsable de département/Team leader (Operation Manager):

C'est le garant d'un des savoir-faire de l'entreprise. Il est sollicité par le coordinateur de
projet à qui il doit fournir les moyens en rapport avec son métier et son expertise.
Attention à ne pas confondre les "Operation Managers" avec les "Functional
Managers", ces derniers étant un cas particulier du premier dans le domaine de
l'administration ou de l'immatériel (cols blancs VS cols bleus).

La Ressource/Resource:

Partie intégrante de "l'équipe de projet", elle est informée et animée par son
responsable de département. Son travail est géré et validé par son responsable
hiérarchique.

Ingénierie de Gestion de projets 133/523

[Link]
 Vincent ISOZ

Le Directeur Qualité/Quality Manager:

La gestion de projets s'inscrit dans une démarche qualité dont l'importance va en

augmentant (Risk Management). Les outils mathématiques sont à ce niveau
indispensables.

Le Contrôleur de Gestion/Cost Manager:

Le coût est l'un des trois piliers de la gestion de projet (Qualité – Coûts – Délais), d'où
l'importance de ce rôle. Les outils mathématiques sont aussi à ce niveau
indispensables.

Le Business Analyst (B.A.)

C'est la personne dédiée à analyser les contraintes, à identifier les

besoins/buts/objectifs, les exigences environnementales/interfaces/opérationnelles et
qualitatives, les moyens de communications, les outils centralisés et intègres de
gestion de projets, les risques, la volatilité, les bons intervenants et c'est aussi le
business analyst qui met en relation les différents intervenants du projet avant que
celui-ci commence et qui s'occupera de gérer le changement (change request) à l'aide
d'un "change request board". Le B.A. participera également à la validation du
prototype/pilote (version alpha ou beta) s'il y en a un (voir le BABOK pour plus
d'informations). En réalité, c'est le B.A. qui rédigera une bonne partie du cahier des
charges à lui seul.

Ingénierie de Gestion de projets 134/523

[Link]
 Vincent ISOZ

Le Responsable Juridique

C'est la personne de référence qui s'assurera que sur l'ensemble du projet il n'y ait pas
d'outils ou de contrats qui ne soient pas conformes à la législation en vigueur.

Le cas le plus typique et demandé en formation (mais ultra-basique...) c'est de savoir

quel système de jours de congé doit être pris lorsqu'un consultant part à long terme
dans un pays étranger. Normalement on fait un avenant juridique temporaire au contrat
de travail avec une clause d'adaptation aux jours non fériés du pays/région cible.

Le Project Management Office (PMO)

Il s'agit d'une organisation à l'intérieur d'une entreprise à laquelle des responsabilités

diverses reliées à la gestion de projets centralisée et à la coordination du management
sont assignées. Les fonctions type d'un PMO sont (selon le PMI/PMBOK V4) de gérer
les ressources entre les projets, de définir les standards, meilleurs pratiques et
méthodologies pour toute l'entreprise, de former les intervenants du projet et
responsables de projets, de développer les règles, procédures et modèles ou toute autre
documentation relative à la gestion de projets de projets et de coordonner la
communication.

Le Fournisseur

Il convient de distinguer le fournisseur de services qui est une organisation qui

fournit des services à un ou plusieurs clients internes ou externes du fournisseur
externe qui est une tierce partie, responsable de la fourniture d'éléments sous-traités
(biens ou services) nécessaires à la fourniture de bien.

Un petit schéma proposé par le référentiel ITIL bien pratique (mais logique…) pour
catégoriser les fournisseurs:

Au niveau du responsable de projet, voici un tableau empirique résumant les niveaux (d'après
mon expérience personnelle rencontrée dans les entreprises) uniquement en ce qui concerne
les responsables de projets:

Ingénierie de Gestion de projets 135/523

[Link]
 Vincent ISOZ

Titre Budget Nombre de ressources

Assistant de projets ou "white belt" 0-20'000$ 0-5
Condition minimale:
Certificat de fin d'études obligatoires
Particularités:
- Travaille seul pour gérer le micro-projet et
n'a pas de pouvoir décisionnel sur les
finances.
-Applique des méthodes minimalistes afin
que la gestion de projets pure ait un coût
minimal.
-N'a pas d'outil de gestion de projets
particuliers (utiliser un tableur et un agenda)
- Consacre ~10% de son temps total à la
gestion de projets.
Responsable projets junior ou "yellow 20'000$-100'000$ 5-10
belt"
Condition minimale:
Certification internationale en gestion de
projets avec au moins 5 ans d'expérience
Particularités:
- Travaille seul pour gérer le projet et peut
proposer à la hiérarchie un budget.
- Connaît les méthodes de gestion de projets
mais n'en applique qu'une partie, sans
respecter des processus éprouvés.
- N'a pas d'outil de gestion de projets
particuliers (utiliser un tableur et un agenda).
- Consacre ~50% de son temps total à la
gestion de projets.
Responsable projets ou "green belt" 100'000$ à 15M$ 10-200
Condition minimale:
Licence universitaire avec au moins 10 ans
d'expérience
Particularités:
- Travaille dans une équipe de 2 à 4
personnes dédiées uniquement à de la pure
gestion du projet.
- Connaît les méthodes de gestion de projets
et en applique une partie en respectant
quelques processus simples.
- A des outils de gestion de projets basiques
(planificateur, système électronique de
gestion de la documentation)
- Consacre 100% de son temps total à la
gestion de projets
Responsable de projet senior ou "blue 15M$ à 500M$ 200-1500
belt"
Condition minimale:
Licence universitaire avec certification
internationale en gestion de projets
Particularités:
- Travaille dans une équipe de 4 à 9
personnes dédiée à la gestion du projet
conformément aux pôles de compétences
décrits par le PMBOK.
- Connaît les méthodes de gestion de projets
et les applique en respectant des processus
éprouvés.
- A des outils de gestion de projets avancés

Ingénierie de Gestion de projets 136/523

[Link]
 Vincent ISOZ

Titre Budget Nombre de ressources

(planificateur centralisé, système
électronique de gestion de la documentation
avec workflows, système de gestion de la
qualité et des risques)
- Consacre 100% de son temps total à la
gestion de projets
Responsable expert de projets ou "red 500M$ à 5B$ 1500-10'000
belt"
Conditions minimale:
Maîtrise universitaire avec certification
internationale en gestion de projets et au
moins 15 ans d'expérience
Particularités:
- Travaille dans une équipe structurée en
PMO dédiée à la gestion de projets d'entre
10 et 50 personnes conformément à la
majorité des standards de gestion (PMBOK,
Six Sigma, BABOK).
- Connaît les méthodes de gestion de projets
et les applique en respectant des processus
éprouvés et optimisés.
- A des outils de gestion de projets avancés
(planificateur centralisé, système
électronique de gestion de la documentation
avec workflows, système de gestion de la
qualité et des risques) et d'aide à la décision
(modélisation du risque et arbres
décisionnels).
- Propose les instruments financiers pour se
protéger des variations (options, futures,
forex, etc.)
- Consacre 100% de son temps total à la
gestion de projets
Responsable maître de projets ou "black >5 milliard de $ (5B$) >10'000
belt"
Condition minimale:
Master/Doctorat universitaire ou équivalent
dans un domaine des sciences exactes et au
moins 20 ans d'expérience en gestion de
projets.
Particularité:
- Travaille dans une équipe structurée en
PMO dédiée à la gestion de projets de plus
de 50 personnes conformément à la majorité
des standards de gestion (PMBOK, Six
Sigma, BABOK).
- Connaît les méthodes de gestion de projets
et les applique en respectant des processus
éprouvés et optimisés.
- A des outils de gestion de projets avancés
(planificateur centralisé, système
électronique de gestion de la documentation
avec workflows, système de gestion de la
qualité et des risques) et d'aide à la décision
(modélisation du risque et arbres
décisionnels) le tout connecté en temps réel
à un ERP.
- Gère les instruments financiers pour se
protéger des variations (options, futures,

Ingénierie de Gestion de projets 137/523

[Link]
 Vincent ISOZ

Titre Budget Nombre de ressources

forex, etc.)
- Consacre 100% de son temps total à la
gestion de projets
Tableau 3 Niveaux de responsables de projets

Outre les intervenants, signalons également les domaines de connaissance de la gestion de

projets et quelques processus y relatifs par le diagramme synoptique de la page suivante pris
de l'excellent référentiel de base que constitue le PMBOK.

Remarque: MS Office Project ne peut pas englober l'ensemble des outils dont peuvent avoir
besoin ces différents corps de métier.

Figure 11 Métiers de la gestion de projets

ou selon la structure de MS Project Server nous la hiérarchie suivante:

Ingénierie de Gestion de projets 138/523

[Link]
 Vincent ISOZ

Remarque: La gestion de projets ne peut pas se satisfaire d'une structure de type "Lead
Management" ou chaque collaborateur est indépendant. La meilleure structure à ce jour reste
la hiérarchie traditionnelle.

Le coordinateur de projets (responsable de projet) ne doit surtout pas oublier avant que nous
allions plus loin les 3 points suivants concernant les ressources:

1. Très rarement disponibles réellement à 100%: par convention 80% en ce qui concerne
les personnes, pour les machines on utilise le taux de rendement synthétique (ou plus
simplement l'adéquation capacité/charge)

2. Ont un profil de travail de type Bêta en ce qui concerne les personnes

3. Ont des vacances et des jours de congé maladie dans une année… en ce qui concerne
les personnes et des temps de panne et de maintenance en ce qui concerne les
machines!

lorsqu'il planifie les détails d'un nouveau mandat!

8.3 Types de responsables de projets

Nous pouvons essayer de catégoriser par l'expérience vécue les responsables de projets dans
différentes catégories:

 Le responsable de planification (ne gère pas les coûts et la qualité)

 Le responsable de projets improvisé (apprend par l'erreur mais n'en est pas
responsable)

 Le responsable de projets autoproclamé (apprend par l'erreur et en est responsable)

Ingénierie de Gestion de projets 139/523

[Link]
 Vincent ISOZ

 Le responsable de projets certifié (a eu la bonne initiative d'éviter de découvrir les

erreurs classiques en suivant des formations adaptées)

 L'ingénieur en gestion de projets diplômé (a une formation de plusieurs années dans

l'ensemble du cercle vertueux de la gestion de projet en utilisant des outils et
techniques mathématiques élaborées)

 Le docteur en gestion de projets (a un doctorat dans le domaine et fait de la R&D

pour résoudre des problèmes complexes à l'aide de méthodes scientifiques)

Enfin nous pouvons aussi considérer 3 niveaux de compétences pour un responsable de

projets:

1. Le responsable de projet intuitif est capable de gérer un projet de petite envergure ou

simple très efficacement, avec une petite équipe. Il fait confiance à son propre bon
sens, essentiellement dû à une bonne pratique de la gestion de projets. Intuitivement, il
fait participer les parties intéressées, recherche des solutions, planifie, alloue le travail
et vérifie l'évolution. Beaucoup de responsable de projets improvisé ou autoproclamés
entrent dans cette catégorie.

2. Le responsable de projet méthodique est capable de gérer des projets de plus grande
envergure et plus complexes, qu'il ne peut suivre dans leur intégrité uniquement à
l'aide d'outils simples et de sa mémoire. Des méthodes, des protocoles et des pratiques
formels sont mis en place pour assurer que le projet est géré efficacement.

3. Le responsable de projet critique peut gérer des projets très complexes et souvent
difficiles. Il peut appliquer des méthodes de façon créative afin de construire une
méthode et un plan de projet qui soient à la fois souples et efficaces, tout en restant
fidèle à tous les principes d'une bonne gestion de projets.

Nous pouvons considérer que pour ce poste, la performance résulte de la combinaison de

quatre facteurs:

1. La connaissance comprend l'apprentissage d'un ensemble d'outils et de techniques liés

exclusivement à la gestion de projets.

2. Les compétences sont l'application de ces outils et techniques.

3. Les comportements correspondent à l'attitude et au style du responsable de projet

dans ses rapports avec les membres de son équipe, le sponsor, le conseil
d'administration et le client.

4. L'expérience mesure la profondeur avec laquelle les connaissances, les compétences

ou les comportements ont été appliqués.

Beaucoup d'ouvrages spécialisés recommandent nombre de critères pour choisir un bon

responsable de projet et basé essentiellement sur des compétences relationnelles et non
techniques. Je tiens à préciser cependant que la technique (science) a permis à toutes les
branches de la vie de se développer de manière fulgurant e avec rigueur et exactitude. Or la
majorité des responsables de projet au début de 21ème siècle (et avant…) ont des méthodes de
travail qui sont équivalentes aux décisions de saignées que faisaient les médecins il y a plus

Ingénierie de Gestion de projets 140/523

[Link]
 Vincent ISOZ

de 3 siècles pour résoudre un problème… jusqu'à ce que la méthode scientifique ait fait place
nette.

Par ailleurs la médiocrité de taux de réussite des projets montre bien que ce n'est pas la bonne
solution. Quand le domaine de la gestion de projets sera vraiment à maturité, les techniques
scientifiques seront mises en place comme cela l'a déjà été pour la gestion financière et la
gestion de la qualité dans le domaine de la gestion de projets de pointe aux Etats-Unis et en
Asie il y a plus de 50 ans… avec des responsables niveau Bac+7.

Bon ceci dit, ce n'est pas parce qu'un individu gère les hommes de façon exceptionnelle ou
qu'il est un expert technique talentueux qu'il l'envergure en termes de savoir, d'expérience,
d'habilité, de communication, de leadership pour diriger un projet. Le monde de l'entreprise et
des administrations est majoritairement rempli de gens promus au-delà de leur niveau de
compétences – et ce n'est pas de leur faute!

Remarque: Un responsable d'un niveau modeste dans l'échelle hiérarchique se doit de

maîtriser mieux que ses employés tous les aspects techniques de la profession! C'est donc
pour lui un point crucial s'il veut se faire respecter. D'autant que les subalternes n'ont aucune
peine à se faire une idée du niveau de compétence et peuvent dès lors adopter un
comportement dominant envers celui-ci. Du coup, ils résistent plus à l'influence de leur
supérieur, remettent en question ses ordres et critiquent plus ouvertement ses décisions.

Ce type de compétence n'est pas autant demandé de la part d'un top manager (personne
dirigeant une équipe de plusieurs milliers de personnes). On attend de lui de fortes
compétences interpersonnelles, c'est-à-dire une capacité à initier et maintenir des relations
avec les autres, de faire preuve d'empathie et d'une bonne aptitude à communiquer.

8.3.1 Le principe de Peter

Un grand classique repris tel quel de Wikipédia17 car permet souvent de se remettre en
questions (ou d'en remettre d'autres en question…):

Le Principe de Peter, également appelé de Laurence J. Peter et Raymond Hull (1969), est un
principe satirique relatif à l'organisation hiérarchique. Selon ce principe:

« Tout employé tend à s'élever à son niveau d'incompétence. »

17
"Principe de Peter." Wikipédia, l'encyclopédie libre. 28 fév 2011, 03:44 UTC. 3 mar 2011, 19:47
[Link]

Ingénierie de Gestion de projets 141/523

[Link]
 Vincent ISOZ

Il est suivi du corollaire de Peter:

« Avec le temps, tout poste sera occupé par un incompétent incapable d'en assumer la
responsabilité. »

Les principes de base sont les suivants:

 un employé compétent à un poste donné est promu à un niveau hiérarchique supérieur

 un incompétent à un poste donné n'est pas promu à un niveau supérieur

1er corollaire:

 un employé ne restera dans aucun des postes où il est compétent puisqu'il sera promu à
des niveaux hiérarchiques supérieurs.

 par suite des promotions, l'employé finira (peut-être) par atteindre un poste auquel il
sera incompétent.

 par son incompétence à ce poste, l'employé ne recevra plus de promotion, il restera

donc indéfiniment à un poste pour lequel il est incompétent.

2ème corollaires:

 à long terme, tous les postes finissent par être occupés par des employés incompétents
pour leur fonction.

 la majorité du travail est effectuée par des salariés n'ayant pas encore atteint leur
« seuil d'incompétence ».

De plus, si nous partons des principes que plus un poste est élevé dans la hiérarchie,

 plus il demande des compétences ;

Ingénierie de Gestion de projets 142/523

[Link]
 Vincent ISOZ

 plus son impact est grand sur le fonctionnement de l'organisation,

alors nous pouvons constater que l'impact de l'incompétence de l'employé aura été maximisé
par le niveau hiérarchique du poste auquel il aura été promu. Ces dernières hypothèses ne sont
qu'une interprétation non systématiquement retenue du principe de Peter.

Peter remarque que la compétence, chez les employés d'une organisation, se répartirait
(chiffres qui selon mon expérience ne doivent pas être trop éloignés de la réalité):

 10 % sont super incompétents

 20 % sont incompétents (30% cumulé jusqu'ici)

 40 % sont modérément compétents (70% cumulé jusqu'ici)

 20 % sont compétents (90% cumulé jusqu'ici)

 9% super compétents (99% cumulé jusqu'ici)

 1% sont exceptionnels (hauts potentiels)

Une version moderne du principe de Peter serait s'énoncerait selon certains: « Les gens les
moins compétents sont systématiquement affectés aux postes où ils risquent de causer le
moins de dégâts: ceux de managers. »

Je recommande fortement la lecture complète de l'article sur Wikipédia qui tient bien la route!

8.3.2 Sélectionner un bon responsable de projet

J'ai eu l'occasion une fois de suivre une micro-conférence d'Adecco en Suisse (avril 2010) sur
les critères de base de sélection d'un responsable de projet. Bien que l'exigence soit peu élevée
j'ai trouvé intéressant de faire un résumé dans le présent ouvrage et de les compléter avec des
remarques personnelles (en vert).

Pour résumer de manière extrêmement condensée avant d'aller dans les détails: On demande à
un responsable de projets de posséder un portefeuille de recettes ou outils et d'être capable
d'analyser un contexte, d'isoler des causalités essentielles dans un univers complexe, de
concevoir des scénarios. Il doit faire preuve d'une grande curiosité (ouverture intellectuelle)
et vivacité d'esprit et être doté d'une capacité analytique pointue pour émettre des jugements
sûrs (toute subjectivité est exclue). Au niveau humain, le responsable de projet doit avoir une

Ingénierie de Gestion de projets 143/523

[Link]
 Vincent ISOZ

grande maîtrise de soi, une empathie et un sens élevé de la diplomatie envers ses ressources
et supérieurs.

Il faut également considérer deux types de responsables de projets:

1. Les consultants externes experts qui doivent posséder une expérience très pointue et
dont il faut passer l'entreprise au crible via un audit ou des tests de connaissances très
difficiles. Faire une erreur dès le départ peut se révéler catastrophique.

2. Les responsables de projets internes. Cela à l'avantage d'être moins cher mais jaugez-
les aussi sévèrement que des consultants externes.

[Link] Compétences
Donc selon Adecco (Suisse) un responsable de projet devrait satisfaire de manière équilibrée
aux compétences suivantes (je pense - et j'espère… - que dans un souci de simplification par
rapport à l'auditoire ils n'ont pas voulu aller trop dans les détails):

1. Compétences comportementales

1.1. Dynamique, passionné, entreprenant

1.2. Orienté vers les résultats

(quantifiables avec des outils statistiques avancés)

1.3. Pouvant travailler indépendamment et respecter les délais

(en utilisant des techniques avancées de gestion du temps)

1.4. Bon sens de la négociation et de la communication

(doit maîtriser les sujets dont il parle au moins aussi bien que ses interlocuteurs)

1.5. Créatif, polyvalent et motivé pour trouver constamment de nouvelles solutions

(des solutions correspondantes aux techniques contemporaines et non d'il y a plus de
100 ans…)

Ingénierie de Gestion de projets 144/523

[Link]
 Vincent ISOZ

1.6. Apte à planifier, organiser, programmer et coordonner de multiples tâches afin

d'atteindre les objectifs planifiés
(avec les bons outils: c'est-à-dire sans tableau ni logiciel de traitement de texte pour
faire cela…)

1.7. Prêt à prendre des risques (calculés!), capacité de prendre des décisions (avec les
outils d'aide à la décision!)

1.8. Aptitude à développer ses propres capacités (faire passer un test de raisonnement et
de logique à tout futur responsable de projet…!), ainsi que celle des autres

2. Compétences techniques

2.1. Gestion des fournisseurs (connaître les techniques d'optimisation de

l'approvisionnement, les contrôles de réception et de l'optimisation des flux)

2.2. Connaissances des opérations d'outsourcing et d'offshoring (connaître ou être expert

dans l'utilisation des standards ISO et la législation utiles à ce type d'activité)

2.3. People management, capable de développer et de guider son équipe (capable de gérer
des ressources avec le même niveau de qualité et de rigueur qu'un projet lui-même)

2.4. Capable d'influencer (positivement et intelligemment) une équipe

3. Compétences en gestion de projets

3.1. Compréhension de méthodologies de gestion de projet comme PRINCE2 , Hermes,

Agile…
(avoir étudié de manière assez fouillée au moins 5 méthodologies de gestion de projet
reconnues au niveau international)

3.2. Bonne compréhension des échanges, en termes de temps passé sur le projet, les coûts,
la qualité, et le résultat
(être capable de mettre en place un glossaire et des techniques analytiques
automatisées et sophistiquées de réalisation d'un projet)

3.3. Capacité à créer et vérifier différents cas concrets

(capacité à déléguer les choix et estimations à ceux qui en ont les compétences)

3.4. Bonne gestion de projets

(avoir au moins une maîtrise universitaire - ou connaissances équivalentes - dans le
domaine de la gestion de projets ou dans un domaine directement connexe et la
maîtrise des outils informatiques ad hoc).

3.5. Profondes connaissances de la gestion des risques et questions liées au management

(connaissances statistiques pointures et formation de niveau universitaire selon les
mêmes critères que ceux donnés précédemment!)

4. Compétences IT

Ingénierie de Gestion de projets 145/523

[Link]
 Vincent ISOZ

4.1. Bonnes connaissances des méthodes et outils IT

(avoir une formation continue pointue sur chacun des outils utilisés et avoir passé un
test de niveau universitaire lors de l'embauche)

4.2. Compréhension des méthodes de test, des processus et des outils

(connaître les probabilités conditionnelles, l'AMDEC quantitative, ISO 5807:1985 et
les logiciels d'accompagnement aux calculs)

4.3. Connaissances des technologies

(savoir quels sont les bons outils par rapport à des besoins clairement identifiés)

4.4. Compréhension de l'analyse business et du processus de conception

(avoir une formation Six Sigma et la partie DOE qui y est incluse)

4.5. Capacité de développer des S.L.A. (Service Level Agreement)

(maîtriser les points précédents…)

[Link] L'interview
Toujours dans la cadre de la recherche du responsable de projet, la prochaine étape est
l'interview (doit durer au minimum 3 heures pour une bonne sélection!). Adecco propose un
modèle relativement bien ficelé qui consiste en plusieurs étapes à mettre sous forme de
tableau avec des notes et des pondérations en fonction des besoins18:

Première étape:

1. Analyser le CV en détails avant l'interview

2. Demander au candidat qu'elles sont selon lui les compétences d'un responsable de
projet (vérifier si réponse conforme au PMBOK)
3. Valider ses compétences en posant des questions techniques pointues
4. Demander au candidat de décrire ses activités au travail, ses réalisations et formations
dans le domaine
5. Comprendre pour quelle raison le candidat souhaite quitter son poste actuel (vérifier
en même temps qu'il respect la clause de confidentialité de son ancien employeur)
6. Demander au candidat pour il estime être la bonne personne pour ce poste?
7. Quelles sont les innovations managériales que le candidat a apporté à son précédent
poste et qu'elles ont été leurs impacts?
8. Quelles ont été selon lui ses responsabilités les plus importantes?
9. De quelles réussites est-il particulièrement fier?
10. Demander au candidat ses objectifs de carrière

Deuxième étape:

1. Comment le candidat prépare-t-il un projet (vérifier qu'il se base sur des processus
connus!)
2. Comment le candidat gérerait-il les personnes non-productives ou non motivées?

18
J'ai complété, corrigé (car il y avait des aberrations et fautes d'orthographe…) et réordonné un peu à ma
manière cependant… car les RH souvent évitent tout ce qui est technique dans un entretien car ils ne maîtrisent
pas les sujets et posent parfois des questions dont les pièges sont évidents ou anticipés dans le CV par les hauts
potentiels et n'apportent donc aucune plus-value.

Ingénierie de Gestion de projets 146/523

[Link]
 Vincent ISOZ

3. Comment le candidat gérerait-il les membres d'équipe qui viennent vous voir pour des
problèmes personnels?
4. Comment le candidat gérerait-il la situation où il y a plusieurs réponses à une
problématique proposées par l'équipe de projet.
5. Citer un exemple d'une situation Win Win que le candidat aurait négocié.
6. Qu'est-ce que le candidat aurait appris d'éventuels échecs dans le cadre de projets?
7. Est-ce que le candidat peut indiquer 5 signes annonceurs de l'échec probable d'un
projet?
8. Quelle est la décision la plus difficile que le candidat ait eu à prendre (toujours dans le
cadre de projets)
9. Quelle est la plus belle réussite et le plus grand fiasco du candidat?

Troisième étape:

1. Réaliser un jeu de rôle

2. Présenter une étude de cas où le projet doit être rapidement évalué en termes de coûts
et temps
3. Présenter une étude de cas où le projet est en train d'échouer et évaluer le candidat par
rapport à son approche à la résolution de cette problématique
4. Evaluer le candidat sur ses compétences, sa stratégie de planification et son
implication.
5. Evaluer le candidat sur ses techniques de communications orales et écrites

Ensuite, dans le cadre du processus de recrutement interne à l'entreprise j'insiste sur une chose
évidente… que les ressources intervenant sur les projets devront se souvenir aussi par
moment…:

On a que ce dont pour quoi on est prêt à payer…

Il ne faut effectivement pas attendre de miracles d'un responsable de projet dont le niveau de
compétence équivaut selon l'équation des salaires à environ (selon tarif Suisse en 2011) un
salaire brut de 10'000 CHF/mois (sur 12 mois). Effectivement, un salaire d'un haut potentiel
extrêmement compétent aura lui un salaire se situant entre 30'000 et 150'000 CHF/mois pour
travailler sur des projets de plusieurs dizaines de millions de CHF!!!

De plus il faut savoir que dans la réalité les départements de ressources humaines font presque
tous uniquement des tests de la personnalité pour les responsables de projets et top managers
qu'ils souhaitent engager et non des tests de compétences techniques d'ingénierie de la gestion
de projets. Donc très souvent on se retrouve avec des cadres qui ont un très bon profil
relationnel mais qui techniquement ne comprennent pas grand-chose au contenu de leurs
projets et qui ne connaissent souvent rien à l' de la gestion de projets.

8.3.3 Profil d'entreprise type

Le responsable de projet travaille très souvent (majoritairement) dans des entreprises où la
réalité est niée, l'imaginaire hypotrophié et la symbolique hypertrophié.

 Négation de la réalité: Si l'entreprise a des problèmes, subit des dysfonctionnements,

cela peut signifier qu'elle a vécu et vit peut-être toujours dans la négation de la réalité,

Ingénierie de Gestion de projets 147/523

[Link]
 Vincent ISOZ

qu'elle n'a pas mis en place le minimum de veille nécessaire, qu'elle n'accepte pas de
se voir comme elle est. Elle n'est pas capable de regarder la réalité en face.

 Hypotrophie de l'imaginaire: Les maîtres mots des entreprises sont souvent

réduction des coûts, plan social, rentabilité non réfléchie et autres classiques. De fait, il
est difficile de susciter l'imaginaire. L'imagination et la créativité sont alors proscrites
en dehors des départements de R&D et des groupements de hauts potentiels.

 Hypertrophie du symbolique: Des dirigeants d'entreprise ont parfois hypertrophié le

symbolique en ayant nié la réalité et n'ayant pas pu susciter l'imaginaire et permettre le
développement de l'imagination de de la créativité chez les salariés.

Ces dirigeants accordent une importance démesurée aux symboles comme le mobilier
design dans leur bureau, une voiture haut de gamme, une place de parking réservée…
Ces symboles sont représentatifs de leur fonction et renforcent leur puissance et leur
pouvoir face aux autres.

Le responsable de projet doit alors souvent trouver une équilibre entre ces trois principales
caractéristiques:

Réalité

Imaginaire Symbolique

Des propositions peuvent être apportées par le responsable de projet sur chaque point:

 Sur la réalité: Aider l'entreprise à regarder la réalité en face. Lui permettre d'accepter
les indicateurs de performance, de bien-être, les outils de comparaison, d'admettre les
veilles technologiques et concurrentielles comme une opportunité et non plus comme
une menace. L'opportunité est d'adapter sa stratégie, sa structure, son organisation en
trouvant un équilibre entre les réalités du marché et les attentes de ses employés.

 Sur l'imaginaire: Les recommandations à ce surjet peuvent être appliquées comme de

vrais projets qui non seulement peut faire mieux vivre l'entreprise pas son chiffre
d'affaires et sa marge, mais aussi permet le développement des personnels, privilégie
la prise d'initiatives, de risque, potentialise leurs compétences et met aussi les
méthodes de gestion de projet à l'épreuve en tant que laboratoire de test.

Ingénierie de Gestion de projets 148/523

[Link]
 Vincent ISOZ

 Sur la symbolique: Les répercussions de certaines symboliques sur l'ensemble des

employés doit être adapté afin d'éviter les ruptures sociales flagrantes entre les
différents niveaux hiérarchiques. Montrer que certains choix actuel engendrent des
coûts indirects est une voie possible.

L'équilibre est bien évidemment difficile à réaliser dans la majorité des cas que le responsable
de projets soit un expert ou non.

8.4 Formation de l'équipe de projet

Le travail d'équipe est essentiel. En cas d'erreur, ça permet d'accuser quelqu'un d'autre…

Remarque: Je recommande très fortement à toute personne intéressée à changer la mentalité

qui consiste à faire en sorte que les ressources courent après le temps au détriment du bien-
être du client et de la qualité du produit à se renseigner sur le "slow management".

Un aspect important du travail du coordinateur du projet est de gérer les ressources humaines
affectées à un projet et de contrôler les changements afin de minimiser tout impact nuisible à
l'accomplissement des objectifs du projet. Certains changements sont insignifiants alors que
d'autres sont d'importance capitale dans la vie du projet.

Dans certaines situations et dans le cadre de certains projets, il est possible et parfois même
conseillé de regrouper l'organisation du projet sur un site unique de sorte que les acteurs du
projet soient proches les uns des autres. Cette mesure améliore le travail en équipe et la
communication. Il se peut en revanche que certaines unités de l'organisation du projet soient
très éloignées géographiquement, voire se trouvent sur des continents très différents, ce qui
constitue un défi supplémentaire pour la gestion du projet.

Ingénierie de Gestion de projets 149/523

[Link]
 Vincent ISOZ

La performance d'une organisation de projet dépend de ses acteurs. La compétence des

personnes choisies doit être vérifiée et leur disponibilité convenue avec leur hiérarchie. Dans
l'idéal, le responsable de projet et les responsables hiérarchiques de l'unité d'organisation qui
fournit les ressources humaines examinent ensemble la qualification de chaque personne
retenue pour exercer une fonction donnée dans le cadre du projet. Cet examen commun porte
sur le savoir, les capacités et l'expérience de la personne. Le responsable de projet prend
également en compte la personnalité de l'individu et son potentiel d'intégration dans l'équipe.

Il convient que la définition des rôles et responsabilités en matière de gestion de projets (et
tous les spécialisations et métier de l'écosystème de la gestion) fasse partie des procédures
d'accueil des nouveaux arrivants (newcomer) à un poste ou une fonction. L'organisme doit
s'assurer que l'organisme s'assure que les personnes responsables sont en mesure de remplir ce
rôle en leur fournissant l'autorité, le temps, la formation, les ressources et les compétences
nécessaires pour assumer leurs responsabilités.

8.4.1 SCRUM
En 2001, 17 représentants des méthodes légères alternatives aux processus lourds
traditionnels se sont réunis pour trouver les points communs à leurs méthodes. De cette
réunion de quelques jours est né le Manifeste Agile: un texte bref énonçant des grands
concepts, simples, mais qui proposent une nouvelle façon de penser un projet. C'est une
méthode de gestion orientée quasiment que vers l'humain (relationnel) et fait abstraction des
processus, méthodes, normes et mesures (dans l'optique que trop de méthodes tu la
méthode...). C'est pour cette raison que nous l'incluons brièvement dans ce chapitre sur
l'équipe de projet. Par ailleurs je préconise fortement cette méthode pour les entités n'ayant
pas de P.M.O. (Project Management Office) ni de structure de gestion de projets (pas de
responsables de projets payés à plein temps pour faire que de la gestion de projets!) et ne
travaillant pas dans l'ingénierie de haut niveau.

Le manifeste agile résume sa philosophie en quatre oppositions entre les concepts

traditionnels (méthode la-rache19…) et les concepts proposés.

Individus et interactions contre processus et outils

Ce sont les individus qui font la valeur du travail accompli, ce sont donc eux que l'on doit
privilégier. Sans l'artisan, les meilleurs outils ne servent à rien. Les processus qui définissent
ce que doit faire chaque personne brident le potentiel caché derrière chacun: faire interagir les
gens au maximum est bien plus fructueux et permet d'améliorer grandement l'efficacité et la
qualité du travail fourni, en rassemblant des visions différentes d'un même problème.

Ceci dit, en tout objectivité l'approche est limitée dès qu'il s'agit de projets à plusieurs
centaines de millions de francs dans des domaines comme le nucléaire, l'électrotechnique,
l'aéronautique (bref tout domaine considéré comme "sensible").

19
Jeu de mot avec "à l'arrache"

Ingénierie de Gestion de projets 150/523

[Link]
 Vincent ISOZ

Source: [Link] ....

Logiciel qui fonctionne contre documentation exhaustive

Les processus lourds génèrent une documentation qui se veut exhaustive avec tous ses
inconvénients: ambiguïté du langage, coût de la rédaction, coût du maintien en accord avec la
réalité, etc. Ces documents ne sont qu'une illusion d'avancement du projet. Même une
conception technique initiale peut être complètement remise en cause en phase de codage (ou
après): comment peut-on alors déterminer l'avancement du projet? Une régression?

Dans les méthodes Agiles, un seul critère permet de mesurer l'avancement d'un projet: le
logiciel qui fonctionne. La documentation n'est qu'un support concret qui aide à produire le
logiciel.

Collaboration du client contre négociation de contrat

Dans tout projet, le but premier est de gagner de l'argent, autant pour le client (rentabilisation)
que pour le fournisseur (prestation). Si la négociation protège plus ou moins des risques
financiers, elle peut provoquer l'échec des projets (délais non respectés, budgets insuffisants)
et engendrer d'interminables procès où tout le monde y perd au bout du compte (le client n'a
pas son logiciel et le fournisseur ferme boutique).

Ingénierie de Gestion de projets 151/523

[Link]
 Vincent ISOZ

Il faut sortir de la guerre client/fournisseur et penser en équipe qui veut atteindre un but
commun: réussir le projet dans le cadre dans une optique Win-Win en oubliant pas de définir
la négociation sur les critères minimaux triviaux OCEAN (Objectif, Contexte, Enjeux,
Asymétrie de pouvoir, Négociateurs).

Réponse au changement contre suivi d'un plan prédéfini

Un plan prédéfini a tendance à nous rendre autistes aux événements qui surviennent pendant
le projet. Il est en plus à l'origine des conflits client/fournisseur classiques sur les délais de
livraison. Pour le client, pouvoir adapter les besoins en cours de projet est un atout
concurrentiel: il est réactif aux fluctuations des marchés et s'assure en plus que le logiciel
développé répond parfaitement à ses véritables besoins.

Les méthodes Agiles sont conçues pour s'adapter au changement, en assurant un plan
macroscopique précis et adaptatif.

8.4.2 Équipe de projet

Une équipe est un groupe de personnes qui travaille ensemble pour accomplir un objectif
commun. Chaque équipe évolue en passant par plusieurs étapes de développement. Les
coordinateurs du projet doivent prendre conscience des étapes à rencontrer pour développer
une équipe effective et cohésive:

Ingénierie de Gestion de projets 152/523

[Link]
 Vincent ISOZ

Figure 12 Procédure de mise en place de groupes de travail

Expliquons ces étapes (Formation, Confrontation, Normalisation, Production: FCNP) d'une

façon détaillée:

[Link] Forming
Formation du groupe (Forming): Pendant l'étape de formation de groupe (Forming), le
coordinateur de projet doit fournir des directions. En donnant des directions à l'équipe du
projet, le coordinateur de projet doit clairement communiquer les objectifs du projet et les
bienfaits qu'ils amèneront. Le coordinateur de projet doit aussi créer une vision de réussite à
l'égard du projet. Les contraintes concernant l'étendue du travail, le niveau de qualité, le
budget et l'horaire. Le coordinateur de projet doit aussi discuter du processus de formation
d'équipe; les raisons expliquant la sélection des membres de l'équipe, leurs niveaux de
compétences, leurs domaines de connaissances, et le rôle de chaque personne dans
l'accomplissement des objectifs (selon ISO 9001, les ressources humaines doivent avoir
documenté les formations initiales, formations continues, savoir-faire et expérience des
employés!). Établir des structures est une autre tâche que doit exécuter le coordinateur de
projet pendant cette phase. Ceci inclus la définition des procédures initiales pour le
fonctionnement de l'équipe et le traitement des réseaux de communication d'approbation et de
paperasse (workflow, business process). Ces procédés et procédures peuvent être améliorés
par les membres de l'équipe à mesure que le travail avance. Afin de réduire le stress, le
coordinateur de projet devrait discuter de son style de gestion et de ses attentes en ce qui
concerne le travail et le comportement des membres de l'équipe. Il importe aussi de faire
travailler l'équipe sur des tâches initiales. C'est ici que le coordinateur du de projet parvient à
faire participer l'équipe au développement des plans du projet avec un certain niveau de
délégation.

La figure ci-dessous montre la progression du degré de délégation (où certaines personnes

considèrent parfois que le degré de délégation peut être inversement proportionnel à la
criticité des tâches):

Ingénierie de Gestion de projets 153/523

[Link]
 Vincent ISOZ

Figure 13 Degrés de délégation

Ainsi, les responsables de la décision sont clairement désignés: la personne qui le veut, celle
qui le fait et celle qui la "paie". De plus cette technique est facile à définir dans une liste ou
une base de données informatique.

Insistons sur le fait que définir les délégations permet d'éviter: à ce que personne ne prenne de
décision, les conflits lors de prises de décision, que les décisions ne soient pas acceptées par
les bonnes personnes et que personne ne soit consulté.

Remarque: J'aime bien la citation de Stanislav Lee qui s'applique bien dans les organisations
n'ayant pas de DD: "Dans une avalanche, aucun flocon de neige ne se sent responsable". À
noter aussi que dans certains pays comme au Japon il est dans la nature des gens
(mentalité/éduction) d'exécuter sans réfléchir en respectant les procédures au pied de la lettre
même si parfois l'action est absurde. Donc il faut prendre garde bien évidemment aux pays
avec lesquels nous travaillons!

On peut aussi résumer les DD de la manière suivante (ce fichier fait partie des modèles qui
vous seront fournis pendant la formation):

Ingénierie de Gestion de projets 154/523

[Link]
 Vincent ISOZ

Sur les gros et longs projets une technique supplémentaire et sympathique est de faire des t-
shirts ou bandoulières de couleurs pour reconnaître les différents membres des groupes du
projet.

[Link] Storming
Mise en conflit du groupe (Storming): La deuxième étape du développement de l'équipe se
nomme Mise en conflit du groupe. Elle est généralement difficile pour tous les membres,
mais il faut absolument passer à travers. Il est impossible d'éviter cette étape de formation.
Les membres commencent à exercer leurs connaissances en accomplissant les tâches qui leurs
ont été désignées. C'est à ce moment que les attentes et la réalité se croisent dans le meilleur
des cas. Évidemment cela produit des sentiments de tensions et des conflits. Lorsque les
membres de l'équipe commencent à performer leurs rôles, ils résistent à l'autorité du
coordinateur du projet et les règles qui ont étés mises en place. Pendant l'étape de mise en
conflit, il y a beaucoup de frustration, d'hostilité et de tension donc c'est important de former
des méthodes pour résoudre les conflits. Le coordinateur du projet doit diriger mais moins
qu'en l'étape de formation. Il est important de donner des clarifications sur les tâches pour les
membres de l'équipe mais en même temps, leur donner des opportunités de partager le
pouvoir à faire les décisions.

Attention cependant à la dynamique de groupe, comme la supposition silencieuse, par

exemple. On a souvent tendance à s'imaginer que les autres pensent comme soi, qu'ils
disposent des mêmes informations, et que, s'ils ne s'expriment pas, c'est que l'on a tort de
s'inquiéter. En plus, la présence d'un leader lors du storming favorise la prise de risque
inconsciente car les discussions sont souvent moins vives et profondes – si ce n'est totalement
absente - que lors de l'absence d'un leader. Donc le fait que la majorité se tait pèse

Ingénierie de Gestion de projets 155/523

[Link]
 Vincent ISOZ

considérablement dans les mauvaises décisions. Des études auraient par ailleurs montré que
des groupes menés par un leader ont un tendance significative à prendre des risques non
évalués et que plus les groupes sont grands, plus les décisions prises sont risquées, parce que
la traille du groupe inhibe la parole.

Il paraît que l'armée française s'est rendu compte qu'en supprimant les protocoles
hiérarchiques dans certaines situations précises, on parvenait à des décisions plus réfléchies
puisque mises à l'épreuve de la critique démocratique (finalement ce n'est le résultat de la
théorie des Jeux qui date d'il y a presque un siècle...).

[Link] Norming
Dérivation des normes (Norming): Après avoir traversé l'étape de Mise en conflit du
groupe, l'équipe poursuit son chemin pour se rendre à l'étape de Dérivation des normes. Les
conflits interpersonnels devraient pour la plupart être résolus. En général, le niveau de conflits
devrait être inférieur à ce qu'il était dans l'étape de Mise en conflit du groupe car les attentes
personnelles s'alignent avec la réalité de la situation. Le contrôle et les décisions sont
transférés du coordinateur de projet à l'équipe. La cohésion commence alors à se développer.
Les contributions pour accomplir l'objectif du projet sont grandement appréciées de chaque
membre de l'équipe. Les informations, idées, et sentiments sont mieux partagés ce qui
augmente la coopération. Pendant l'étape Dérivation de normes le coordinateur de projet
réduit son rôle de directeur et adopte un rôle de soutien. La performance de travail s'active et
la productivité augmente.

[Link] Performing
Performance du groupe (Performing): A cette étape, dans un cadre théorique idéal, l'équipe
est dévouée et devient impatiente à atteindre l'objectif du projet. Le niveau de performance de
travail est élevé au cours de cette étape, ainsi que la confiance. Il y a un grand degré
d'interdépendance, les membres collaborent fréquemment et veulent s'entraider. L'équipe
possède beaucoup de pouvoir. Le sentiment de satisfaction grandit au fur et à mesure qu'il y a
du progrès et qu'il est reconnu. Pendant l'étape « performing », le coordinateur de projet
délègue entièrement les responsabilités et l'autorité. Il peut ainsi se concentrer sur la
performance du projet, son plan et sa portée. Son rôle est de faciliter et supporter le
développement et implanter les actions correctives si le progrès actuel prend du retard.

Remarques:

R1. Il faut parfois également planifier la réintégration d'une personne ayant participé à un
projet. Effectivement, il peut être difficile pour certaines personnes de revenir à leur poste ou
cahier des charges routinier!

R2. Dans le cas de la méthode agile (scrum) l'équipe ne comporte pas de rôles prédéfinis, elle
est autogérée. Il n'y a pas non plus de notion de hiérarchie interne: toutes les décisions sont
prises ensemble et personne ne donne d'ordre à l'équipe sur sa façon de procéder.

8.4.3 Hiérarchie/Organisation
L'organisation managériale la plus courante est appelée "organisation fonctionnelle": elle est
basée sur une hiérarchie par spécialisation/métier et non pas par responsabilité.

Ingénierie de Gestion de projets 156/523

[Link]
 Vincent ISOZ

L'organisation fonctionnelle est l'héritage du management scientifique de F. Taylor et H. Ford

où les individus étaient placés dans des domaines où ils excellaient pour être plus rapide, ne
pas réinventer la roue, être innovants ou créatifs. Le côté négatif de cette méthode est que les
employés sont rangés dans des cases et si il n'y a pas un bon suivi de l'évolution de carrière, le
travail peut assez vite devenir répétitif et ennuyeux (souvent déjà à partir de 4 à 5 ans à un
même poste).

Certaines personnes ayant remarqué que ce type d'organisation mettait en évidence les
incompétents trop facilement ont proposé une alternative appelée "organisation matricielle"
qu'ils justifient comme plus adaptée aux commerce moderne où la flexibilité est de mise.

En réalité, les scientifiques (les "vrais"!) remarquant alors que les entreprises actuelles sont
alors en grande majorité remplies d'employés principalement incompétents et ignorants aux
postes auxquels ils se trouvent et ces mêmes employés perdent 10 à 15 ans à recréer la roue
(sans se rendre compte puisqu'ils se complaisent dans l'ignorance) de ce qu'un spécialiste
aurait déjà appris en apprentissage, en école d'ingénieurs ou de commerce ou à l'université.

Comme je le dis toujours: est-ce qu'il vaut mieux un employé qui sait un peu tout faire, très
lentement et mal ou une employé qui peut faire qu'une ou deux choses mais rapidement et très
bien?

L'état actuel des organisations se comprend lorsque l'on est en contact direct avec les cadres
dirigeants des ressources humaines ou que l'on voit le niveau de rigueur de rédaction des
offres d'emplois (et ce même des multinationales renommées... du moins en dehors du cercle
des consultants indépendants).

Ingénierie de Gestion de projets 157/523

[Link]
 Vincent ISOZ

8.4.4 Profils
Le simple rassemblement d'individus (forming) n'est pas suffisant pour créer une véritable
équipe, même si on leur demande leur accord (storming) pour travailler ensemble.

La performance d'une équipe dépend de l'équilibre des rôles tenus par chacun de ses
membres. En effet, c'est dans la diversité des approches qu'elle est capable de fournir que
réside la véritable force d'une équipe.

En identifiant les rôles endossés par chacun, on peut augmenter l'efficacité de l'équipe en
jouant, à bon escient, sur sa composition ou sur son fonctionnement interne.

Les études menées à Cambridge par Meredith Belbin pendant plus de 20 ans ont montré qu'il
existe un nombre limité de rôles en équipe. Chaque rôle se structure sur des constantes de
comportement mises en œuvre dans le cadre professionnel par des types de personnalité
parfois tout à fait différents.

Les rôles selon ce modèle sont construits sur axes et représentés parfois sous la forme d'une
molécule:

© Belbin France ([Link])

Rôles de réflexion

PRISEUR - Modéré, stratégique. Il fait preuve de discernement et envisage

toutes les options. Evalue avec précision et de manière objective si les idées
sont réalistes et bénéfiques.

CONCEPTEUR - Créatif, imaginatif, peu orthodoxe et surtout

anticonformiste, il propose de nouvelles idées et des solutions créatives. Il
résout les problèmes complexes.

Ingénierie de Gestion de projets 158/523

[Link]
 Vincent ISOZ

EXPERT - Déterminé, autonome, concentré vers un seul objectif. Il

possède une source de connaissances et de compétences techniques peu
communes et utiles à l'équipe.

Rôles d'action

ORGANISATEUR - Discipliné, fiable, ordonné, méthodique et efficace. Il

transforme les idées en actions concrètes et pratiques que les membres de
l'équipe pourront réaliser.

PROPULSEUR - Dynamique et fonceur, il travaille bien sous pression. Il

a le courage et la capacité de surmonter les obstacles. Il pousse les autres à
l'action et aide l'équipe à recentrer son travail.

PERFECTIONNEUR - Il s'assure que le travail est bien fini.

Consciencieux, à la recherche des erreurs et omissions. Il a le souci de la
perfection. Il fait en sorte que le programme et les délais soient respectés.

Rôles de relation

PROMOTEUR - Extraverti, enthousiaste et communicatif. Il explore les

opportunités et développe les contacts. Il tire profit des idées et des
informations du monde extérieur.

COORDINATEUR - Mature, confiant. Attentif aux autres et diplomate. Il

clarifie les objectifs et fait progresser les prises de décision. Il s'assure que
les efforts et les qualités des coéquipiers sont utilisés au mieux.

SOUTIEN - Sociable, sensible et conciliant. Il est attentif aux autres et à

leurs besoins. Il est plein de tact. A l'écoute, il évite les frictions et
recherche les consensus. Il bâtit le relationnel dans l'équipe.

On se gardera bien avec ce type de modèle d'associer des points négatifs à chaque rôle
puisque chacun représente un rôle de compétences. Si on désire associer des rôles
d'incompétences à chacun des collaborateurs, il est aussi de nombreux modèles théoriques
pour cela équivalents à celui-ci.

Je propose un test simple pour vérifier le niveau de rigueur de travail d'une ressource: Donnez
à chaque membre de l'équipe de projet un document papier de 5 pages résumant le projet et à
la dernière page laissez un espace vide pour la date, l'heure et la signature comme quoi la

Ingénierie de Gestion de projets 159/523

[Link]
 Vincent ISOZ

ressource approuve ce qu'elle aura lu (mais n'en faites pas mention lorsque vous distribuez le
document)

Quand les documents vous reviendront vous aurez:

1. Ceux qui n'ont rempli ni la date, ni l'heure ni la signature…

2. Ceux qui auront rempli la date et la signature

3. Ceux qui auront tout rempli correctement

Après vous en tirez les conclusions que vous voulez…

Un autre exemple pour distinguer les employés/cadres expérientiels (qui se fient sur l'intuition
et des méthodes heuristiques) et les employés/cadres cognitifs (qui utilisent une réflexion
poussée dans chaque situation proche de la méthode scientifique) c'est de demander à chacun
comment ils feraient pour estimer la durée d'un projet... Vous risquez de tomber de haut la
majorité du temps en entendant les réponses...

8.4.5 Comportements
Je tiens à indiquer les types de comportements relatifs à divers domaines tels qu'indiqués dans
le très officiel Swiss National Competence Baseline Version 4.0 de 2007 (basé sur IPMA)
relatif au responsable de projet mais dont une grande partie implique aussi les ressources et la
direction.

La longue liste de catégories ci-dessous, dont une relecture périodique est fortement
conseillée, est très exhaustive mais la justesse de ce type de catégorisation est ouverte bien
évidemment à nombre de débats enflammés…:

Leadership

Comportements adéquats Comportements à améliorer

Sait déléguer des tâches, fait confiance aux Ne délègue pas, ne forme et ne développe
autres, encourage leur développement et leur pas les autres.
capacité à satisfaire les exigences.

A une vision, l'exprime clairement, la défend Est parfois égocentrique, tend à

et lui donne vie. l'inconstance, n'a pas de vision, ne défend pas
ses idées.

A de l'autorité naturelle, est écouté et inspire Doit se justifier en permanence, suscite le

confiance. doute.

Délègue des lots de travaux SMART N'applique pas les principes SMART et
(spécifiques, mesurables, atteignables, restreint la marge de manœuvre de ses
réalistes, définis dans le temps) et conformes subordonnées en leur imposant des
aux aptitudes de ses collaborateurs; les laisse obligations et des contrôles.
faire les choses à leur manière.

Ingénierie de Gestion de projets 160/523

[Link]
 Vincent ISOZ

Est un animateur habile. Ne sait pas animer un processus ou un

dialogue conflictuel.

Allie pouvoir et charisme. Semble faible et insignifiant.

Inspire les autres, les rend fiers de travailler Sa personnalité n'est pas attrayant pour
avec lui. autrui.

Sait récompenser et prend des mesures Récompense et prend des mesures corrective
correctives d'une manière compréhensible à mauvais escient et de manière inadéquate.
pour les membres de l'équipe.

Assume la responsabilité et les missions en Délègue directement toutes les

conséquence. responsabilités et tous les objectifs aux
membres de l'équipe.

Préserve les objectifs du projet et défend les Donne tort aux membres de l'équipe et laisse
membres de l'équipe dans la négociation de d'autres faire pression pour changer les
changements. objectifs, les missions ou la description du
projet.

Contrôle le comportement des membres de Ne sait pas vraiment que est l'effet d'un
l'équipe de projet sciemment de façon contrôle, prétend manque de temps, évite les
constructive, est discipliné et consacre du discussions.
temps à la communication.

Implique les membres de l'équipe dans les Prend toutes les décisions seul et ne les
décisions ou a de bonnes raisons de les communique pas aux membres de l'équipe de
prendre seul. projet.

Adapte son style de direction à la situation de Les autres considèrent que son
l'équipe et du travail et par d'autres parties comportement est inadéquat; il ne manifeste
intéressés. aucun comportement de direction envers
l'équipe et les autres parties intéressées.

Agit et parle avec calme, formule ses Parle trop vite, en phrases incomplètes et fait
réponses avec clarté et autorité. des gestes inappropriés ou utilise un langage
corporel inadéquat.

Reste calme même en cas de crise, évite la Panique et perd le contrôle de soi.
panique visible.
Tableau 4 Conduite (Leadership)

Engagement et motivation

Comportements adéquats Comportements à améliorer

Gère activement la prise en compte d'intérêts Limite son engagement à des intérêts
différents. personnels ou à ceux du projet; n'est pas
conscient des intérêts d'autrui.

Ingénierie de Gestion de projets 161/523

[Link]
 Vincent ISOZ

Apprécie les initiatives et l'engagement Limite ses collaborateurs à des tâches bien
d'autrui. définies, ne récompense pas l'initiative
personnelle, ne délègue pas, s'arroge tout le
mérite, rejette la faute sur les autres.

Est positif et enthousiaste, travaille avec Rend ses collaborateurs nerveux, se

bonne humeur, est axé sur les performances concentre surtout sur les risques et les
sans jamais perdre de vue les objectifs du problèmes ou, lorsqu'il s'enthousiasme, perd
projet. de vue les objectifs du projet.

Réserve un accueil positif à la critique, qu'il Ne sait pas gérer la critique et ne l'exploite
considère comme une forme d'engagement. pas pour le bien du projet.

Pratique une gestion active de la motivation. Ne se préoccupe pas des baisses de

motivation.

Fait des plans de projet l'affaire de toute Impose les plans de projet à l'équipe.
l'équipe.

Faire preuve d'un comportement positif et Rédige des rapports concernant des
réaliste, recherche des solutions en cas de problèmes sans proposer de solutions, attend
problème. que les auteurs prennent des décisions.

Donne de l'énergie à l'équipe et utilise Travaille essentiellement seul ou avec

l'énergie de tous les membres de l'équipe. quelques amis proches.

Sait où et comment faire participer les autres. Travaille seul.

Faire preuve de volonté pour le bien du Baisse facilement les bras et perd vite sa
projet. motivation.

Encourage le travail en équipe et la Empêche ou entrave le travail en équipe

collaboration interdisciplinaire. constructif, évite la collaboration
interdisciplinaire.
Tableau 5 Engagement et motivation

Maîtrise de soi

Comportements adéquats Comportements à améliorer

Contrôle ses émotions, est très résistant à la Paraît lunatique, irritable et irrationnel, perd
frustration. souvent son sang-froid.

A une attitude positive par rapport à la Se vexe ou se révolte face à la critique, réagit
critique constructive, réagit calmement aux de manière émotionnelle et incontrôlée, est
attaques personnelles, n'est pas rancunier. rancunier.

Est capable de discuter de problèmes au sein Ignore les conflits, ne sait pas ce qui se passe
de l'équipe; fait office de médiateur, discute. au niveau informel, provoque le refus.

Encourage une culture de discussion Néglige les conflits, utilise son pouvoir,

Ingénierie de Gestion de projets 162/523

[Link]
 Vincent ISOZ

constructive au sein de l'équipe, cherche démolit les adversaires, les humilie.

toujours le consensus.

Concilie vie professionnelle et privée. Est un drogué du travail, ne s'intéresse qu'au

travail, néglige sa vie privée.
Tableau 6 Maîtrise de soi

Relaxation et maîtrise du stress

Comportements adéquats Comportements à améliorer

Agit et réagit avec décontraction Est trop tendu pour maîtriser la situation

Pratique l'humour pour le bien du projet Ne pratique pas l'humour ou alors de manière
inadéquate

Est capable de neutraliser une situation Aggrave la situation en intervenant au

mauvais moment ou de manière inadéquate

Est constamment conscient des situations Ne s'aperçoit pas que quelque chose ne va
potentiellement difficiles, intervient de façon pas, n'est pas créatif dans ses interventions et
inattendue et peu conventionnelle pour utilise des méthodes exclusivement
obtenir des résultats optimaux conventionnelles

Remarque les tensions interpersonnelles et Refuse de reconnaître les tensions

est capable de les atténuer ou d'y remédier interpersonnelles et ne prend aucune mesure.

Parle ouvertement de son propre stress et de N'est pas capable d'avouer son propre stress
celui des autres. et ne prend pas ses symptômes au sérieux.

Tient compte des situations de stress et essaie Provoque inutilement du stress et ne

de les atténuer. recherche pas d'aide en situation de stress.

Est capable d'évaluer son propre bien-être et N'est capable ni d'évaluer son état ni de
applique des techniques de relaxation avant prendre les mesures nécessaires.
que le stress le submerge.

Budgétise et planifie les activités de Ne tient pas compte des activités

recherche de cohésion de l'équipe et des extraprofessionnelles.
événements sociaux et des loisirs extra-
professionnels.
Tableau 7 Relaxation et maîtrise du stress

Ouverture d'esprit

Comportements adéquats Comportements à améliorer

Est souple, s'adapte aisément aux Est rigide et refuse les changements, néglige
changements tout en tenant compte des les intérêts du projet.
intérêts du projet.

Est ouvert envers les différences dues à l'âge, Ignore les différences dues à l'âge, à

Ingénierie de Gestion de projets 163/523

[Link]
 Vincent ISOZ

à l'orientation sexuelle, à la religion, à la l'orientation sexuelle, à la religion, à la

culture et au handicap. culture et au handicap.

Gère la coopération, dirige l'équipe. Est axé sur son travail, gère l'équipe
mécaniquement et sans émotions.

Bénéficie d'une vase culture générale (non Est incapable de communiquer en tenant
limite au management de projet) et sait compte de la manière de penser d'autrui, n'est
adapter sa manière de communiquer à ses pas bien compris.
interlocuteurs de sorte à être compris.

Encourage l'ouverture d'esprit par une Décourage l'ouverture d'esprit en négligeant

ambiance au travail agréable, un habillement son habillement et son aspect et en
esthétique et un aspect soigné. détériorant l'ambiance de travail.

A une attitude ouverte et positive, est un Fait bande à part, ignore les autres, semble
optimiste réaliste. absent.

Suscite la confiance, est plein de bonnes Paraît méfiant.

volonté.

Aborde les autres activement et dans un Attend que les autres prennent l'initiative, est
esprit positif, est accessible. réservé et peu sûr de lui-même.

Gère activement les parties intéressées, Ne gère pas activement les parties
entretient des contacts formels et informels intéressées, évite le contact avec elles, ne
avec les parties intéressées. consacre pas de temps aux contacts
informels.

Accepte tous les membres de l'équipe, tolère Fait sentir son aversion aux autres, ne
et encourage les opinions différentes au sein fonctionne que selon des principes, croit tout
de l'équipe et stimule la participation active. savoir et ne cherche pas à connaître l'opinion
d'autrui.

Accepte et respecte les minorités, laisse les Est axé sur les structures de pouvoir en place.
autres avoir du succès.
Tableau 8 Ouverture d'esprit

Ouverture d'esprit

Comportements adéquats Comportements à améliorer

Est créatif, accepte les défis et est ouvert aux S'accroche aux solutions connues et
idées nouvelles. éprouvées et à peur de l'inconnu.

Est optimiste quant au fait que des idées Rejette les idées sans les avoir examinées en
nouvelles se traduiront par des solutions déclarant qu'elles sont impraticables.
applicables.

Aplanit les différends en définissant une N'est pas en mesure d'intégrer des idées
solution nouvelle qui peut être réalisée différentes. Fait un choix entre des opinions
moyennant le respect des opinions divergentes et crée des tensions au sein de

Ingénierie de Gestion de projets 164/523

[Link]
 Vincent ISOZ

différentes. l'équipe.

Trouve des solutions en appliquant des idées Ne peut pas acceptes les idées nouvelles ou
nouvelles, des outils et du bon sens dans de les outils nouveaux comme un moyen de
nouveaux domaines. résoudre des problèmes difficiles. N'utilise
pas le bon sens.

Incite les collaborateurs à exposer leurs Recherche toujours des solutions éprouvées,
idées, reconnaît les opportunités et organise ne sait pas gérer l'incertitude et n'est pas
un processus rationnel de recherche créative capable de diriger adéquatement un
de solutions. processus créatif de recherche de solutions.

Gère activement les descriptions de Refuse tout ce qui dépasse la définition

prestations et les changements. originale des prestations.

Est réceptif au langage corporel et aux N'accepte que ce qui est prévu, néglige les
sentiments, utilise son intuition pour résoudre intuitions et les sentiments. S'en tient à la
les problèmes et dans le cadre des relations logique et aux relations fonctionnelles.
humaines.

Écoute sa propre intuition et l'exploite, voit Refuse l'intuition.

en ses idées une source de créativité.

Utilise des approches non conventionnelles Accepte toujours le statu quo même si
pour le bien du projet. Prend des décisions l'avenir du projet est en jeu. A une aversion
créatives pour réduire les risques. au risque.
Tableau 9 Créativité

Orientation résultats

Comportements adéquats Comportements à améliorer

Se comporte en entrepreneur Se content de suivre les ordres

Est capable de régler des questions Ne règle pas définitivement les questions.

Recherche constamment des possibilités Accepte les choses telles qu'elles sont. Ne
d'amélioration et remet le statu quo en remet pas le statu quo en question.
question.

Recherche toujours des solutions qui ne N'est pas créatif dans la recherche de
nécessitent pas de modification des objectifs. solutions. Transforme chaque problème en
un changement.

Exploite les opportunités sans négliger les A une aversion au risque et ignore les
risques. opportunités.

Gère les modifications de manière adéquate; Promet de nouvelles fonctionnalités ou

informe dès que possible lorsqu'un plan ne prestations sans s'assurer qu'il pourra
peut être respecté, propose des alternatives. procéder aux changements sans ressources
La direction a l'impression de contrôler le supplémentaires. Tarde à informer la
direction de changements inattendus. La

Ingénierie de Gestion de projets 165/523

[Link]
 Vincent ISOZ

projet. direction n'a pas l'impression de contrôler le

projet.

Surveille les innovations et les opportunités Reste dans les limites convenues et laisse
nouvelles (p. ex. technologies, marchés, passer des innovations et des opportunités
concurrents nouveaux) susceptibles majeures qui influencent le projet.
d'influencer le projet et y réagit de manière
appropriée.

Gère activement les parties intéressées. Néglige les parties intéressées.

Parvient à gérer les attentes de manière Ne gère pas les attentes de manière
transparente et efficace; les satisfait ou les transparente ou suscite des attentes
dépasse. disproportionnées.

Est conscient des détails sans pour autant Ignore des détails importants et perd la
perdre la maîtrise de l'ensemble. maîtrise de l'ensemble.
Tableau 10 Orientation résultats

Efficience

Comportements adéquats Comportements à améliorer

Se prononce clairement sur la productivité et Ne se prononce pas clairement ou ne
l'efficience dans le projet et se comporte de communique pas sur la productivité et
façon correspondante. l'efficience, ne montre pas l'exemple.

Sait déléguer et fait confiance aux autres, Essaie de tout faire lui-même et a pour
pratique le management par exception. confiance en autrui.

Ouvre les réunions à l'heure convenue et les Arrive en retard aux réunions, les laisse se
termine le plus rapidement possible. prolonger inutilement.

Vise l'amélioration constante, incite ses Néglige les améliorations. Est facilement
collaborateurs à faire de même. satisfait de ses collaborateurs.

Possède l'énergie et l'opiniâtreté nécessaires à Semble lent, n'a pas de patience, abandonne
mener à bien ce qu'il entreprend. rapidement.

Encourage l'enthousiasme, demande des Est incapable de motiver, critique

contributions positives et est ouvert à la injustement et n'est pas ouvert à la critique.
critique.

Remarque l'utilisation inefficient de Ignore l'inactivité et ne réagit pas aux

ressources et prend les mesures nécessaires. avertissements des autres.

Sait tirer parti de l'efficience. Pratique l'efficience à mauvais escient, induit

ses collaborateurs en erreur.
Tableau 11 Efficience

Conflits et crises

Ingénierie de Gestion de projets 166/523

[Link]
 Vincent ISOZ

Comportements adéquats Comportements à améliorer

Est capable de discuter de situations avec son Ignore les conflits latents, en sait pas ce qui
équipe; intervient comme médiateur, discute se passe au niveau informel, provoque des
et est conscient des conflits latents. divergences.

Est accessible, prend toujours le temps S'occupe d'autre chose et s'isole en cas de
d'écouter en cas de crise ou de conflit, conflit ou de crise, ne s'entretient avec les
collabore avec l'équipe et avec d'autres autres qu'au niveau formel. N'a aucun lien
parties intéressées. informel ou social avec son équipe.

Considère l'incertitude comme un défi. Laisse les risques et les problèmes

s'accumuler.

Est ouvert aux intérêts contradictoires en cas Provoque activement au sein de l'équipe des
de cirse et de conflit. divergences d'opinion qui peuvent dégénérer
en conflit ou en crise.

A une attitude positive par rapport à la Se vexe ou se révolte face à la critique, réagit
critique constructive, réagit calmement aux de manière émotionnelle et incontrôlée, est
attaques personnelles, n'est pas rancunier. rancunier.

Est équitable, accepte les propositions des Impose ses propositions aux dépens des
autres sans rancune. autres, refuse les réactions constructives.

Fait la différence entre les problèmes de Confond relations personnelles et problèmes

relations humaines et les problèmes de travail de contenu.
et les résout dans l'ordre qui convient.

Est sûr de lui et positif, respecte la fonction Est arrogant, semble fragile, manipule les
la personnalité de chacun. autres membres de l'équipe.

Profite des conflits pour faire avancer le Néglige les conflits potentiels ou latents,
projet. n'est pas prêt à défendre le projet jusqu'au
bout.
Tableau 12 Conflits et crises

Conflits et crises

Comportements adéquats Comportements à améliorer

Est fiable, autrement dit fournit la prestation N'est pas faible, autrement dit fournit une
promise convenue au moment convenu, avec prestation inférieure à celle convenue, n'est
la qualité convenue et avec le budget pas ponctuel ou dépasse le budget, sacrifie la
convenu. qualité.

Lorsque la situation dépasse les tolérances Sa devise est "laisser aller, laisser faire".
admises du projet, fournit au mandant Tarde tellement à fournir un rapport au
(soumissionnaire) des rapports bien mandant (soumissionnaire) que celui-ci n'a
documentés en temps utile. plus la possibilité d'influencer le résultat.

Est digne de confiance, utilise avec Ne semble pas fiable, trahit la confiance des

Ingénierie de Gestion de projets 167/523

[Link]
 Vincent ISOZ

discrétion ce qu'on lui a dit en confidence. autres.

Se sent responsable du succès du projet au Rejette toujours la faute sur les autres.
nom de toutes les parties intéressées.

Assume la responsabilité de l'ensemble, Répercute directement tous les

définit correctement les sous-domaines de enseignements pris envers le mandant
compétence. (soumissionnaire) et tous les objectifs sur les
membres de son équipe.

Contrôle le comportement des membres de N'est pas conscient des conséquences de ses
l'équipe de projet d'une manière consciente et activités de contrôle, prétexte le manque de
constructive, est discipliné et consacre du te temps, ne communique pas de manière
temps à la communication. adéquate.

Transmet toutes les informations de manière A des difficultés à transmettre l'information.

adéquate.
Tableau 13 Fiabilité

8.4.6 Caractères
Voici une figure que j'ai prise de la présentation d'une entreprise Xtrem7 et que je trouve très
bien faite. Elle résume et différencie ce qu'est une bonne ressource, d'une…. moins bonne en
théorie dans un contexte idéal et selon les standards actuels de notre société.

En ce qui concerne la ressource idéalisée:

Figure 14 Ressource idéalisée

Ingénierie de Gestion de projets 168/523

[Link]
 Vincent ISOZ

Et la moins adaptée…:

Figure 15 Ressource inadaptée...

Enfin comme souvent voici deux petites citations qui peuvent amener réfléchir un peu:

Je préfère être détesté pour ce que je suis Que d'être aimé pour ce que je ne suis pas!
G. Simenon

et:

Vous pouvez tromper quelques personnes tout le temps. Vous pouvez tromper tout le
monde un certain temps. Mais vous ne pouvez tromper tout le monde tout le temps.
A. Lincoln

8.4.7 Théorie X et Y
Les théories X et Y sont des théories développées dans les années 1960 par Douglas McGregor
et utilisées en ressources humaines et en comportement de l'organisation (attention! il ne s'agit
pas d'une théorie dans le sens scientifique du terme mais d'une "observation"!). Les deux
théories s'opposent entre elles. La première suppose que l'homme n'aime pas travailler, la
seconde affirme le point de vue inverse. Ces deux théories sont issues d'observations
empiriques et sont formulées de manière à rendre compte des comportements observés dans
les organisations, selon les postulats des dirigeants.

On peut classifier majoritairement les employés en deux catégories dont la X représente la

majorité salariale:

 L'être humain moyen n'aime pas le travail et l'évitera s'il le peut.

Ingénierie de Gestion de projets 169/523

[Link]
 Vincent ISOZ

 Du fait de leur aversion à l'égard du travail, la plupart des gens doivent être contrôlés
 Les travailleurs ne fournissent l'effort dans les temps attendu que sous la contrainte
 L'humain moyen préfère être dirigé
 L'humain moyen n'aime pas ou évite les responsabilités
 L'humain moyen désire la sécurité par-dessus tout.
 L'humain moyen déploie vraiment son intelligence que pour contourner les règlements
 L'humain moyen ne va pas s'impliquer personnellement ni être innovant/créateur

Ensuite vient une deuxième catégorie dont Y représente la minorité salariale (moins de 5%
souvent) et dont les présupposés sont que les membres de cette catégorie:

 S'impliquent dans la vie de l'organisation comme dans sa propre vie privée

 Ne travaillent pas que pour le salaire mais pour le plaisir et pour se sentir utile
 Sont satisfaits et fiers de travailler pour leur employeur
 Apprennent seuls et deviennent en une dizaine d'années des experts dans leur domaine
 Cherchent à prendre des responsabilités
 Proposent des idées, des améliorations
 Préfèrent s'auto-organiser/s'auto-gérer

Il y a encore une troisième catégorie que sont les HP (hauts-potentiels) qui représentent
souvent au maximum 1% de la masse salariale.

8.4.8 Conflits
La gestion de conflit couvre un large éventail de sujets, qui va des conflits interpersonnels aux
conflits internes d'une organisation, en passant par les conflits qui concernent les domaines de
la gestion.

L'entreprise qui insiste à tirer une ligne de démarcation entre les exécutants et les penseurs
risque fort de se voir défendre par des idiots et dirigés par des lâches.

Quand vous faites face à un conflit, la première question à laquelle vous devez répondre est:
De quel type de conflit s'agit-il? et comme le recommande le PMI, la solution à un conflit
dans le cadre d'un projet devrait toujours aller vers une solution qui est favorable au client!

On peut diviser les conflits probablement en trois types principaux (donc ils sont non
exhaustifs!):

1. Conflits d'intérêts

2. Conflits de besoins

3. Conflits d'opinions

Il peut être parfois difficile de discerner le type de conflit auquel vous avez à faire.
Cependant, il est important que vous essayiez d'accéder au cœur du problème car cela vous
aidera à décider ce qu'il convient de faire au sujet de ce problème.

Obtenir un succès en gestion de conflit nécessite des choix éclairés. La liste ci-dessous peut
vous aider à décider le style de gestion de conflit à choisir pour une situation donnée. La liste

Ingénierie de Gestion de projets 170/523

[Link]
 Vincent ISOZ

indique aussi qu'il ne faut pas toujours se cantonner à un même style. Si vous gérez souvent
dans un style coopératif en face à face, vous gaspillerez beaucoup de temps et d'énergie s'il
s'agit de traiter de petits problèmes qui ne nécessitent pas ce style d'approche. Si vous utilisez
toujours des approches de non-confrontation et non-coopération, vous n'obtiendrez jamais ce
que vous et les bénéficiaires du projet veulent, et dont ils ont besoin (modèle de Hodgson -
1994):

 Collaboration (problem solving): un style de face à face coopératif.

Adapté quand les deux parties veulent trouver une solution et quand il faut qu'elles
soutiennent la solution. C'est un style proche de la situation gagne-gagne en
négociation.

 Contestation (forcing): un style de face à face non-coopératif.

Adapté quand des actions décisives rapides sont nécessaires (par exemple, cas urgents).

 Acceptation (smoothing): un style coopératif, sans face à face.

Adapté quand on s'aperçoit qu'on s'est trompé, ou que le problème a moins importance
pour vous, ou dans le cas où vous voulez augmenter votre crédit aux yeux des autres
parties et / ou des négociateurs.

 Évitement (withdrawal): un style de non-coopération, sans face à face.

Adapté dans le cas d'un problème sans importance: vous avez peu de pouvoir et vous ne
voyez aucune possibilité de changer les choses (par exemple, les problèmes de niveau
national, ou liés aux grandes organisations).

 Compromis: un style à mi-chemin de tous les autres et qui intègre des éléments de tous
les autres.

Adapté dans le cas de problèmes d'importance modérée.

Dans tous les cas, chaque discussion, chaque décision, chaque promesse doit être inscrite dans
un procès-verbal signée par chacune des parties.

La première étape en gestion de conflit est d'analyser le type de conflit. Comme indiqué plus
haut, c'est une information importante pour vous aider à maîtriser le conflit.

Pour analyser et gérer le conflit, vous pouvez utiliser la liste de contrôle suivante:

1. Quel(s) est (sont) le(s) vrai(s) problème(s)? Que se passe-t-il réellement? Quelles sont
les personnes réellement impliquées? A-t-on besoin d'information ou d'analyse
supplémentaires pour clarifier les problèmes? Est-ce que les parties ont la capacité de
comprendre des documents importants?

Ces questions vous aideront à éviter de parler des symptômes et au contraire à vous
concentrer sur le cœur du conflit – le(s) vrai(s) problème(s). Vous pouvez tenter
d'analyser le conflit tout seul ou avec les membres de votre équipe. Si vous discutez de
manière ouverte avec l'autre partie impliquée dans le conflit, vous pouvez aussi

Ingénierie de Gestion de projets 171/523

[Link]
 Vincent ISOZ

essayer d'inciter les parties à décrire leur vision de ce qui est au cœur du problème et
d'organiser une visite de site afin d'établir les faits sur place.

2. Que veulent réellement les personnes impliquées?

S'il vous est possible de définir un but commun pour les personnes impliquées, cela
facilitera le travail de recherche de solutions sur lesquelles les deux parties
s'accorderont. Même si cela n'est pas possible, il reste important que les buts des deux
parties soient définis pour une compréhension réciproque.

3. Le conflit est-il d'une taille gérable ou doit-il être découpé en plusieurs petits
problèmes? Si vous vous impliquez, avez-vous une chance raisonnable de mettre fin
au conflit?

Vous devez éviter de vous engager dans une gestion de conflit si vous percevez à
l'avance que vous n'obtiendrez pas de succès. Dès lors il convient d'adopter un
comportement démissionnaire ou de reproduire le même schéma à l'encontre de la
personne qui est la source du conflit.

4. Quel processus vous et l'autre partie choisirez pour résoudre le conflit? Les problèmes
doivent-ils être discutés dans un ordre précis? Quel est le programme? Il y a-t-il une
date butoir? Quelles sont les règles de négociation? Qui convoque et préside les
réunions? Est-ce qu'un accord final sera signé?

Vous devrez décider du type de processus de négociation – formel (avec un médiateur)

ou informel, par réunion publique, par évitement, par discussion (à l'aide d'un
facilitateur), etc.

5. Est-ce que les parties veulent négocier sur les problèmes? Est-ce que le médiateur doit
inventer des propositions spécifiques de compromis? Est-ce que les parties doivent
développer leurs propres propositions ou travailler ensemble sur un accord commun et
négocier ensuite section par section?

Cette étape doit se faire avec les deux parties en présence. Comme dans le cas de la
négociation, l'écoute de l'autre partie est le point important de cette phase. Il est
important que les parties comprennent leurs buts et leurs besoins réciproques afin de
pouvoir trouver une solution qui satisfasse tout le monde. Dans la plupart des cas de
gestion de conflit, c'est à ce stade que la négociation entre en scène. Cependant, ceci
peut se faire par des négociations formelles ou informelles suivant la situation et les
personnes impliquées. Lorsque l'on discute des solutions, il est primordial que les
besoins des parties et les solutions soient décrits de manière très concrète.

6. Comment s'assurer que les parties respectent l'accord? Est-ce que les parties et le
négociateur doivent encore se rencontrer automatiquement après une certaine durée de
mise en œuvre? Est-ce que l'accord doit être mis à jour plus tard si les conditions
changent?

Quand vous parvenez à un accord, il est important que les deux parties aient la même
vision des résultats. Une manière de le vérifier est de se mettre d'accord sur des actions
à suivre, sur qui va les réaliser et d'être très concret et spécifique avec un échéancier

Ingénierie de Gestion de projets 172/523

[Link]
 Vincent ISOZ

d'application et un suivi d'anomalies de non-respect ultérieur. Il peut aussi être

essentiel pour les parties de vendre l'accord à leurs parties prenantes.

Si vous négociez avec une partie avec laquelle vous avez été ou vous êtes présentement en
conflit, beaucoup d'ouvrages proposent de suivre les six étapes positives suivantes pour
faciliter l'accès à une solution acceptable (j'ai mis en italique mes remarques personnelles et
ma vision des choses relativement à mon expérience dans la gestion):

1. Adoptez une approche de résolution de problème (situation win-win).

Cette approche n'est applicable que lors de la première tentative de résolution d'un
problème donné. Au-delà du troisième, quatrième, etc… cela devient ingérable et il
n'existe plus de bonnes solutions.

2. Écoutez l'autre partie.

Encore une fois, cette approche n'est applicable que lors de la première tentative de
résolution d'un problème donné. Au-delà du troisième, quatrième, etc… nous ne nous
savons pas écouté et il ne reste plus que la manifestation orale violente.

3. Posez des questions pour connaître les arguments de l'autre partie, clarifier les
problèmes, et vérifier la compréhension.

Si le même conflit se répète plus tard, cette étape doit être sautée est la situation
clarifiée. La seule solution après signature du procès-verbal antérieur et
l'avertissement!

4. Restez ouvert.

Cela n'a de sens que si le conflit débute ou que les arguments diffèrent. Mais une fois
le procès-verbal signé lors de la première discussion, il convient de mettre les points
sur le i et de menacer le non-respect via un avertissement.

5. Rapprochez-vous des uns et des autres. Le mouvement est le seul moyen de

progresser.

Ceci peut être par contre dangereux lors de conflits répétitifs sur un même sujet. On
peut même en arriver aux mains ou pire…

6. Faites la distinction entre le problème et les personnes.

C'est une illusion… 70% du temps les conflits sont liés à la personnalité, au
comportement et au professionnalisme des personnes.

Lorsque qu'un premier conflit survient sur un sujet X, l'application des méthodes ci-dessus est
une première étape. Cependant, si elle n'aboutit à rien (aucune promesse tenue) alors qu'un
procès-verbal a été signé, il reste à répéter la même chose avec la hiérarchie supérieure
jusqu'au plus haut rang possible (cela peut donc durer). Si toujours aucun résultat n'est obtenu,
il ne reste plus que la violence verbale et les avertissements malheureusement…

Ingénierie de Gestion de projets 173/523

[Link]
 Vincent ISOZ

S'il vous est demandé d'être un médiateur dans un conflit, ou si vous le choisissez vous-même
parce que vous êtes le directeur du projet, votre travail (en tant que partie neutre) sera d'aider
les parties à résoudre leur conflit, et pas d'essayer de le résoudre pour elles. Vous pouvez
avoir à rétablir des moyens de communiquer entre les parties, si la communication n'existe
plus entre elles. Il est primordial que vous les aidiez à discuter du problème de manière
positive. Les accusations doivent être évitées. Faites-les toujours parler de leurs besoins, au
lieu de ce que l'autre partie fait mal.

Les tâches spécifiques du médiateur incluent souvent:

1. Établir l'agenda des réunions

2. Présider les réunions

3. Rédiger les minutes

4. Préparer les premières versions des accords

5. Rencontrer les parties individuellement

Il est de votre responsabilité que les parties s'écoutent. Il peut parfois être bon de leur
demander de résumer ce que l'autre partie a dit. Laissez du temps pour les silences pendant les
discussions. Ceci aidera les parties à s'écouter. Très souvent, on n'écoute pas parce qu'on est
occupé à préparer ce que l'on va dire quand l'autre partie aura terminé.

Enfin, si vous mettez en place des réunions quotidiennes ou hebdomadaires pour avoir un
feedback des tensions ou problèmes internes alors ceux qui ne parlent jamais pendant ces
réunions n'ont plus le droit de se plaindre en dehors!

Un aspect important du rôle de médiateur est de laisser les parties trouver leurs propres
solutions sans leur dire quoi faire. Si elles trouvent leurs propres solutions plutôt que vous ne
les imposiez, il est plus probable qu'elles s'accordent, et qu'elles pensent que la solution est
juste.

Enfin, je pense qu'il faut éviter de se prendre la tête pour des sujets qui n'ont souvent que peu
d'importance: le 99.999% des responsables et ressources intervenants dans les projets ne
laisseront aucune trace dans les livres d'histoire et personne ne se rappellera d'eux après 5 ou 6
générations. Il est en est de même pour le livrable lui-même qui a peu de chances de passer
plus de cinq siècles dans la mémoire collective ou même en tant qu'élément matériel visible. Il
vaut donc mieux prendre les projets et les conflits qui y sont associés avec le sourire et
légèreté en prenant si possible plaisir à rendre service à un mandant (soumissionnaire) et à
travailler en équipe afin de ne pas se pourrir le peu de temps que nous avons à profiter de
notre vie. Have and take fun!

Il vaut mieux s'entourer de dissidents constructifs prêts à dire la vérité ou à poser des
questions dérangeantes, que de béni-oui-oui qui se bornent à répéter ce que le
responsable veut entendre. R. Buttrick

Ingénierie de Gestion de projets 174/523

[Link]
 Vincent ISOZ

[Link] Syndrome de Calimero

Le "syndrome de Calimero" est un facteur important de détérioration des rapports de travail.
Non seulement il rend la vie au travail difficile mais il a des implications parfois dramatiques
dans les situations de burn-out.

Le syndrome de Calimero identifie une personne qui fait preuve d'une mentalité de victime
(certains disent à tort – selon moi – qu'elle est égocentrique), se répand sur ses problèmes et a
tendance à ne voir que ce qui va mal, critique facilement (ce qui peut cependant être très bon
si c'est constructif et proactif).

Il existe plusieurs sous-familles des syndromes de Calimero. Une sous-famille que je connais
bien est celle des individus qui ne sont jamais satisfaits de ce qu'ils accomplissent (ce soi-
disant peut être positif pour l'entreprise car ils ont alors des éléments motivés à faire mieux…
alors que beaucoup ne font rien de plus que ce qu'on leur demande…) car leur travail n'est pas
défini ni cadré de manière exacte, les intéressés se surmènent alors et peuvent s'investir
jusqu'au burn-out.

Pour éviter ce genre de situations dans le cadre d'un projet, il faut savoir définir en tant que
responsable de projets des objectifs très clairs, quantifiables et limités dans les temps à chaque
ressource et définir aussi clairement les objectifs de la direction et de l'équipe de gestion en
termes d'échéancier (réalisables… puisque ceux-ci ont souvent un écart de plus de 400% avec
la réalité…), de qualité et d'efforts. Évidemment, le problème est qu'un petit plus du 90% des
responsables de projets et dirigeants d'entreprise n'effectuent pas ce travail de normalisation et
dès lors l'ensemble de l'environnement est flou, chaotique, sans bornes et donc globalement
indéfini. Par ailleurs c'est ce dernier constat qui amène au burn-out certains employés dans de
nombreuses entreprises puisque la quasi-totalité des multinationales où je suis intervenu
utilisant la méthode "La Rache" dans leur travail quotidien…

Par ailleurs les consultants ou coach en ressources humaines, ne pouvant pas critiquer les
équipes dirigeantes qui les ont mandatées (ils n'osent pas faute de perdre leur contrat…) pour
résoudre les problèmes de ceux souffrants de syndrome de Calimero, mettent quasiment
systématiquement les torts sur l'employé alors que de mon expérience le problème vient d'un
manque de rigueur de méthode absolument abyssal des responsables de projets ou
d'entreprise.

Il faut aussi signaler le manque de reconnaissance des instances dirigeantes du travail

accompli qui génère une démotivation et alors une tendance à amener les collaborateurs à
souffrir du syndrome de Calimero. Si un employé s'investit dans son travail en apportant de
nouvelles idées qui amènent une plus-value à l'entreprise il faut le féliciter car vous avez alors
une perle rare entre les mains (99% des employés travaillent uniquement pour remplir la
marmite…). Inutile de donner une augmentation de salaire car ce n'est souvent pas ce
qu'attendent ce type d'éléments. Offrir des jours de congés payés leur fera largement plaisir en
contrepartie de l'effort fourni ou un petit article de presse sur l'Intranet leur donnera une
certaine reconnaissance.

Ce syndrome est particulièrement marqué parmi les cadres moyens. En diminuant les effectifs
(ou en les maintenant constants…), les dirigeants accroissent la charge de ces cadres sans
augmenter leur efficacité ni leur influence ce qui amène irrémédiablement à une surcharge de
travail, une frustration, une diminution de la qualité et de l'écoute.

Ingénierie de Gestion de projets 175/523

[Link]
 Vincent ISOZ

Des recherches (dont je n'ai pu obtenir les sources…) citées par plusieurs spécialistes en
ressources humaines auraient prouvé que les équipes et de travail et les collaborateurs les plus
heureux étaient ceux qui acceptaient l'idée de renoncer à atteindre un haut niveau de
performance, de créativité et de qualité.

Ma réaction par rapport à ce type de communication est la suivante: bridez vos employez afin
d'en faire des moutons qui viennent seulement pour faire ce que vous leur demandez et vous
verrez que l'innovation dans votre entreprise tombera à zéro (si l'on suite la référence des
spécialistes en ressources humaines…). Moi aussi je peux citer des études faites par trois
grandes universités américaines qui ont démontré que les employés à qui on en laisse pas libre
cours à leur imagination et à leur créativité perdaient tout esprit d'innovation et de
motivation… Il faut donc faire un choix et le mieux c'est d'en discuter ouvertement avec les
employés concernés régulièrement.

Une méthode de management consiste à classer les salariés selon un code couleurs:

 le vert correspondant aux alliés de la direction, favorables au changement

 l'orange, aux partenaires potentiels
 le rouge, aux récalcitrants
 le rouge, foncé aux rebelles

8.4.9 Souffrance au travail

Ne pas reconnaître sa propre valeur c'est faciliter la réussite des médiocres.

Par le manque de formation de haut niveau des responsables d'entreprise et des gestionnaires
de projets, la souffrance au travail (par "souffrance" il faut comprendre un "mal-être" ou un
stress envahissant dans le privé) ressentie par les employés ne cesse de croître à cause du
manque de rigueur général et de la demande de transversalité des compétences.

Ingénierie de Gestion de projets 176/523

[Link]
 Vincent ISOZ

Dans une société où l'économie n'est plus au service de l'homme, mais l'homme au service de
l'économie, les objectifs de productivité et les méthodes de management poussent les salariés
au bout et parfois au-delà de leurs limites.

Outre quelques cadres pervers sévissant ici et là (souvent des cadres qui se pensent
indispensables et irremplaçables), le fond du problème se situerait plus dans une idéologie
managériale propagée dans le monde de l'entreprise. Les salariés étant de plus en plus seuls et
assujettis à des objectifs qu'ils ne peuvent pas atteindre.

Une enquête pour le CNRS (Centre national de la recherche scientifique) relève que même si
on travaillait dans des conditions bien plus difficiles au 20ème siècle, la dégradation profonde
du «vivre ensemble» fait que les gens sont aujourd'hui très seuls face à l'arbitraire.

C'est aussi la perte de sens qui donne le goût de l'enfer au travail. Pour prévenir le burn-out, il
faut notamment que chacun retrouve son essentiel en se projetant dans l'avenir et en
s'interrogeant sur ce qui a constitué sa vie. Retrouver ce qui, dans une journée de travail,
donne sens à sa vie aide à retrouver du sens à son travail.

Un bon moyen de savoir où en sont les choses et les pourquoi du comment est de faire des
sondages anonymes par de société d'audit externes et que les spécialistes des ressources
humaines appellent des "180°" (le chef juge de façon normative ses ressources) ou "360°"
(tout le monde juge tout le monde).

Les 360° sont d'une redoutable efficacité si utilisés correctement!

Enfin indiquons le modèle empirique de Maslow dans le cadre du travail professionnel: la

motivation par la hiérarchie des besoins.

Nous avons alors typiquement de bas en haut un ensemble de besoins que le responsable de
projets et en particulier (normalement...) le responsable des ressources humaines peut utiliser
pour lors d'entrevues individuelles les ressources du projet lorsqu'il y a des conflits (car ses
besoins peuvent être une source possible de conflits):

Pyramide de Maslow
Besoins de Réalisation personnelle, Estime de soi
Fierté du travail accomplit; Sentiment de laisser "quelque chose";
Développement personnel
Besoin de reconnaissance
Titre; Statut; Compétences reconnues; Responsabilité et Autorité; Être
consulté ou considéré comme un expert
Besoin d'appartenance
Faire partie d'une entreprise, d'une communauté; Être complètement
intégré; Intégrer des groupes de travail, de réflexion; Être au courant de ce
qui se passe
Besoins de sécurité
Peu d'incertitude sur l'avenir au moins à moyen terme; Disposer d'une
certaine stabilité CDI/CDD; Ancienneté
Besoins primaires physiologique
Disposer d'un travail; Assurer sa subsistance à court terme; Manger, Boire-
Dormir
Tableau 14 Pyramide de Maslow

Ingénierie de Gestion de projets 177/523

[Link]
 Vincent ISOZ

et se rappeler qu'il existe de nombreuses entreprises connues de par le monde où les employés
se sont suicidés en laissant une lettre comme quoi ils avaient un mal être à cause d'un manque
de reconnaissance dans leur cadre professionnel...!

8.4.10 Suggestions du personnel

Le texte qui va suivre concernant ce petit chapitre est un copier/coller de quelques parties de
l'excellent livre Processus: les outils d'optimisation de la performance de Yvon Mougin
(ISBN 2708130226, Éditions d'Organisation) car simplement le sujet y est parfaitement traité
et il n'y a rien a rajouté (et je déteste recréer la roue quand celle-ci tourne parfaitement!).

L'implication du personnel dans les suggestions (principalement d'amélioration) est un des

tentatives d'amélioration les plus anciennes. Le principe est simple. Il est tentant de penser
que, si chaque collaborateur se mettait à donner des idées d’amélioration, même
modestement, le nombre produirait une quantité de suggestions intéressantes

Un exemple intéressant citée dans la livre susmentionné est le suivant:

Quelques chiffres officiels obtenus par l'Institut Qualité et Management qui datent de 1992
(donc près d'un siècle après l'initiative des USA) sont peu encourageants sauf pour le Japon
qui a, paraît-il, été longtemps leader en la matière. En 1992 donc, les Japonais obtenaient en
moyenne vingt-cinq suggestions par personne et par an alors qu'en France, on en était à une
moyenne de 0.4. Le pourcentage de mise en oeuvre des idées (c'est important aussi) était de
87 % au Japon et de 56 % en France. Les autres pays occidentaux avaient des performances
sensiblement égales aux françaises. Ces informations ne concernent que les entreprises qui ont
déclaré avoir mis en place des systèmes de suggestions du personnel. Ce qui est à noter dans
l'enquête est que les suggestions au Japon ne sont pas récompensées financièrement alors
qu'elles le sont dans la plupart des pays d’Europe et aux États-Unis. Il y a là matière à
réflexion car c'est une idée bien ancrée dans l'esprit des chefs d'entreprises qu'un système de
suggestions ne peut fonctionner sans une carotte financière.

D'après l'expérience de l'auteur du même livre, Quelques personnes malhonnêtes glissaient

des suggestions à l'oreille des ouvriers et se partageaient ensuite la prime. Des rumeurs ont
même couru sur des défauts mis volontairement dans les produits ou des modes opératoires
par les ingénieurs et techniciens des bureaux d’études et de méthodes pour pouvoir ensuite
proposer des solutions d'amélioration.

De plus avec les primes il y a toujours le problème de "Mon idée était meilleure que la tienne
(mes idées sont toujours meilleures que celles des autres) et ma prime est moins importante,
ce n’est pas juste, etc.".

La piste que je propose personnellement (donc rien à voir avec le livre qui sert de référence
pour ce petit chapitre!) plutôt que de donner des primes ou rien du tout est de prévoir par
contrat des pénalités financières sur salaire pour manquement de professionnalisme vis à vis
de l'activité quotidienne.

Enfin, rappelons une notion essentielle! Il convient de faire des suggestions d'amélioration en
forme de solutions et non en forme de question!

Ingénierie de Gestion de projets 178/523

[Link]
 Vincent ISOZ

8.4.11 Standardisation entre les ressources

Un point important dans un projet est que les ressources se mettent d'accord pour travailler,
organiser les données/outils/documents d'une manière identique. Nous rappelons encore une
fois à cet effet la proposition de la mise en œuvre la méthode 5S que nous avons déjà
mentionné à maintes reprises.

1 Diminuez avant
d'organiser.
Les piles doivent
l'avez terminée,
redébarassez-la.
vous doivent figurer dans
l'agenda et non sur des
bouts de papier, les
8 Accordez-vous du
calme.
Si l'environnement
disparaître. Ne pas trier ni numéros de téléphone sont n'est pas propice à une
empiler mais décider: notés dans un répertoire, bonne concentration ou si
jeter, déléguer, régler ou les notes non classables vous cherchez les calme,
classer.
4Aménager une piste
d'atterrissage. doivent être informatisées
Tout ce qui arrive sur au propre. Le savoir de
allez dans un bureau
monoplace et fermez-en la

2 Apprenez à trier
rapidement.
votre table doit atterrir à sa l'entreprise doit être écrit
place et pas ailleurs! en cas d'accident ou de
départ!
porte.

Ne prenez qu'une seule

fois en main et ne le
5
Créez des endroits 9 Faites de l'ordre.
Tous les jours sur votre
remettez pas sur la pile. privilégiés
Ce que vous utilisez 7 Réduisez la
décoration à
bureau. Et au moins
une fois par semaine dans
votre porte-documents, les
3 Débarrassez votre
table de travail.
N'y déposez que ce
tout le temps doit se trouve
à portée de main.
l'essentiel.
Sans être nu, votre bureau
ne doit pas faire
boîtes à cartes de visite,
documents électroniques,
dont vous avez besoin Mettez tout par écrit concurrence à un magasin e-mails, etc.
pour votre tâche
immédiate. Quand vous
6Mais pas n'importe
comment. Les rendez-
de souvenirs.

Ingénierie de Gestion de projets 179/523

[Link]
 Vincent ISOZ

Il en va de même pour la communication entre les ressources. Effectivement à l'époque du e-

mail le constat des spécialistes est que l'usage en est catastrophique en termes de
centralisation, de standardisation et de contrôle d'accès. Un très bon outil informatique pour
gérer tout ce qui est relatif à la communication dans un projet est Microsoft Office
SharePoint.

8.4.12 Matrice des responsabilités

Il faut savoir que la grande majorité des individus n'agissent que si:

 ils ont envie d'agir (motivation)

 ils savent comment agir (formation/compétence)
 ils ont la possibilité d'agir (responsabilité/délégation)

Les premier point est un problème qui doit être identifié à l'embauche (celles-ci étant souvent
bâclées en moins de deux heures et sans tests/examens d'entrée). Le point second pose
rarement problème puisque la majorité des entreprises et en particulier les multinationales ont
a des postes beaucoup de gens qui n'ont pas les compétences normalement pour en assumer la
responsabilité et dans le chaos général cela ne se remarque pas...

Le troisième point par contre est assez critique dans la gestion de projets et est parfois source
de conflits. Nous allons donc voir une technique empirique possible permettant d'y remédier
outre celle des 4 niveaux de délégation (4D) qui a l'avantage d'être simple à mettre en place.

La matrice RACI ou sa variante RASCI (aussi connu sous le nom de Responsability

Assignement Matrix (RAM)) permet de définir simplement les rôles et responsabilités dans
un service ou sur un projet. On trouve la définition de RACI dans le PMBok (Project
Management Body of Knowledge) du PMI (Project Management Institute).

L'acronyme RACI signifie:

• R: Responsible: Réalise: Réalise l'activité.

• A: Accountable: Autorité: A l'autorité pour approuver le travail de R.

• C: Consulted: Consulté: Est consulté par R.

• I: Informed: Informé: Est uniquement informé des travaux de R.

L'acronyme RASCI rajoute le rôle suivant au RACI:

• S: Supportive: En support: Apporte des ressources supplémentaires pour conduire le

travail de R.

La confusion peut venir des rôles R et A qui sont souvent inversés dans certaines traductions
françaises car le terme Responsible n'est pas équivalent de Responsable en français et le terme
Accountable est difficile à traduire. A ne doit pas être associé à Approbateur car le terme peut
donner lieu à des confusions.

Ingénierie de Gestion de projets 180/523

[Link]
 Vincent ISOZ

La matrice RACI ou RASCI présente des activités en ligne et des rôles en colonne comme
dans l'exemple ci-dessous. Dans chaque cellule du tableau, on indique la responsabilité du
rôle pour l'activité en utilisant les lettres du RACI ou du RASCI. Pour plus de pérennité, il est
conseillé d'utiliser des libellés génériques de fonction pour qualifier les rôles plutôt que des
noms de personnes:

Figure 16 Matrice RACI

Le RACI peut être utilisé pour établir les responsabilités dans un projet, une DSI, une
entreprise. Dans un modèle de document, il peut aussi indiquer qui doit rédiger ( R ) ou
valider ( C ) telle ou telle partie. Il n'y a qu'une seule personne qui valide l'ensemble du
document ( A ) par définition. Dans tous les cas, le RACI est l'outil idéal pour clarifier "qui
fait quoi".

*Mais si un responsable commet trop d'erreurs, c'est une erreur de l'avoir désigné à ce poste.

Ingénierie de Gestion de projets 181/523

[Link]
 Vincent ISOZ

8.4.13 Rencontres/Réunions
Le responsable du projet organise souvent les rencontres d'équipes, du CoP (Comité de
Projet), de l'AQ (Assurance Qualité) et autres groupes… pour stimuler les relations
interpersonnelles d'une équipe et pour renforcer les prévisions, les rôles et les obligations des
membres de l'équipe en considérant les objectifs du projet. Il est par ailleurs souvent accepté
comme normal que le responsable de projets passe 70% de son temps en réunion.

Des exemples de réunions types sont (ne pas oublier de les inclure dans la planification du
projet…!):

1. Définition du cahier des charges avec les mandants20

2. La formation de l'équipe (Forming, Storming, Norming,…)

3. Kick-Off ou Go/No Go

4. Validation de fin de chaque phase (avec les clients)

5. Résolution/anticipation de problèmes

6. Revues d'avancement

7. Fin de projet

8. et bien d'autres…

A ce titre, il est important d'inclure dans la planification du projet des réunions à l'avance,
régulièrement et facturées en tant que séances de conseils.

Ce serait un choix judicieux pour le déroulement des rencontres de suivre une routine
constante pour maximiser ses effets. Il est conseillé de considérer les facteurs suivants avant
que la rencontre prenne place21:

1. Déterminer si la rencontre est absolument nécessaire

2. Déterminer le but de la rencontre

3. Déterminer les participants de la rencontre

4. Définir le facilitateur de la rencontre (qui vérifie que tout le monde écoute, valide et
assure le consensus)

5. Distribuer un agenda de la rencontre au moins une semaine à l'avance

6. Préparer les média (les transparents, les prospectus, etc)

20
Lorsque celle-ci est sous forme accélérée et hyper simplifiée nous parlons alors en conformité avec le BABOK
de JRPS pour "Joint Requirements Planning Session".
21
Il est conseillé aux personnes qui ne sont pas habituées à gérer des projets, à suivre une formation en
techniques de présentations.

Ingénierie de Gestion de projets 182/523

[Link]
 Vincent ISOZ

7. Faire les arrangements pour la salle de rencontre

8. Faire en sorte que la rencontre soit périodique (chaque jeudi ou autre)

9. Qu'elle dure une demi-journée afin que les intervenants aient le temps de discuter et de
ne pas penser à autre chose qu'ils ont à faire tout de suite avant ou tout de suite après
la réunion.

10. Trouver un espace de réunion où chacun peut se mouvoir à son aise car dans un espace
restreint, la pensée est restreinte.

Pendant la rencontre il faut maintenir un format constant et essayer de suivre les suggestions
suivantes:

1. Commencer la rencontre à l'heure et la gérer comme un mini-projet (identifier les

sujets, planifier, réaliser, clore)

2. Nommer un membre de l'équipe pour prendre des notes de la rencontre

3. Inviter les membres de l'équipe à se présenter ou à se représenter

4. Revenir sur les points de la dernière rencontre (comparer au PV)

5. Réviser le programme et les objectifs de la rencontre

6. Faciliter la rencontre sans la dominer

7. Renvoyer les personnes qui ne sont plus concernées à partir d'un certain moment de la
réunion

8. Résumer les résultats de la rencontre avec un MindMap ou la suivre avec un MindMap

9. Essayer de terminer la rencontre à l'heure

10. Évaluer le déroulement de la rencontre

11. Publier les résultats de la rencontre dans les 24 heures qui suit la rencontre (PV:
procès-verbal). Le document sommaire devrait être concis et ne devrait pas dépasser
une page.

Il est aussi suggéré de fournir un code de conduite lors de la rencontre de l'équipe pour que
tout le monde comprenne les comportements acceptables. La figure ci-dessous montre un
exemple d'un code de conduite utilisée par les coordinateurs de projets.

Ingénierie de Gestion de projets 183/523

[Link]
 Vincent ISOZ

En ce qui concerne le modèle de PV, il doit être propre aux besoins et aux niveaux de détails
de l'entreprise. Il ne faut pas oublier que fréquemment les employés n'ont pas beaucoup de
temps pour lire de la documentation alors évitez de faire des PV avec trop de texte: soyez
brefs et concis.

Remarque: Dans le cas de la méthode agile (scrum), chaque journée de travail commence par
une réunion de 15 minutes maximum appelée mêlée quotidienne (Daily Scrum). Seuls
l'équipe, le directeur de produit et le Scrum Master peuvent parler, tous les autres peuvent
écouter mais pas intervenir (leur présence n'est pas obligatoire). A tour de rôle, chaque
membre répond à 3 questions: Qu'est-ce que j'ai fait hier? Qu'est-ce que je compte faire
aujourd'hui? Quelles sont les difficultés que je rencontre?

Enfin, la première réunion avec le mandant (soumissionnaire) est cruciale. Il faut être préparé
et montré qu'on à l'habitude de gérer des projets en ayant une liste de questions et des
processus établis à l'avance!

N'oubliez pas non plus! Plusieurs têtes valent souvent mieux qu'une (mais pas toujours!) donc
les réunions ne sont pas inutiles!

[Link] Types de participants

Dans une réunion il est relativement facile de profiler les participants car il y a certains
schémas assez classiques

Ingénierie de Gestion de projets 184/523

[Link]
 Vincent ISOZ

- Les participants imposants: Ils exercent une influence naturellement excessive dans un
groupe, souvent parce qu'ils sont de rang plus élevé dans l'entreprise (à juste titre ou pas…) ou
parce qu'ils ont des connaissances techniques très pointues. Le rôle de l'orateur est donc de
faire en sorte de trouver le juste milieu entre la présence d'experts utiles au groupe et la
possible domination exercée par ses derniers (leur rappeler parfois qu'il n'existe pas de
domaine sacré…). Le mieux est peut-être de les écouter et de leur proposer suite à un tour de
table avec les autres participantes de mettre en place des actions d'amélioration documentées
ou de formation pour l'équipe de projet tout en restant conforme aux processus de l'entreprise.

- Les participants dominateurs: Ils aiment bien s'entendre parler, et donnent rarement
l'opportunité aux autres de contribuer. Ils dominent la réunion par des interventions
prolongées avec des anecdotes hors sujet ou à un niveau intellectuel qui ne dépasse guère
l'école obligatoire et qui ne font que très rarement avancer les problèmes (souvent ce sont des
gens qui manquent de compétences pointues). Le mieux est peut-être de les demander
d'approfondir plus en détail le sujet afin qu'ils se rendent compte eux-mêmes soit qu'ils sont
hors contexte ou incompétents. Si vraiment ils ne sont pas possible à gérer, leur rappeler qu'il
y a un droit de parole équilibre entre chaque participant et qu'ils ont utilisé le leur.

- Les participants hésitants: Ils ont peur à chaque fois de dire une bêtise (ce qui peut
cependant être vrai). La seule manière de les faire participer c'est de leur poser des questions
ouvertes ou fermées et si jamais de tourner leurs propositions (qui peuvent donc vraiment être
parfois systématiquement mauvaises) en des suggestions constructives et pertinentes (l'orateur
de la réunion doit alors être très à l'aise et lui-même maîtriser de très larges sujets). Si jamais
le participant n'est pas récupérable, lui poser uniquement des questions fermées afin d'éviter
de lui faire développer les sujets.

- Les participants en désaccord: Il peut arriver qu'il y ait un très fort désaccord entre
l'orateur et les participants. Une stratégie qui fonctionnement relativement bien c'est que
l'orateur s'excuse (sous-entendu de son ignorance et de son incompétence que ce soit honnête
ou pas!) et demande une explication approfondie et argumentée des faits qui sont à l'origine
de l'opposition.

8.4.14 Congés Maladie

Voilà un sujet sensible pour lequel le responsable de projet doit avoir une culture générale
minimale en ce qui concerne au moins les lecteurs majoritaires du présent document: les
droits en ce qui concerne les congés maladie en Suisse tel que édictés en 2010. Pour les autres
pays il est recommandé que le responsable de projet s'adresse aux responsable RH de son
entreprise pour avoir au moins connaissance de ce points là pour avoir un minimum de
crédibilité en cas de discussion conflictuelles avec ses ressources.

Les textes ci-dessous ont été repris du magazine l'Illustré 42/10, page 96.

Paiement du salaire en cas de maladie de la ressource.

Il faut savoir que l'assurance perte de gain, au contraire de l'assurance maladie, n'est pas
obligatoire. C'est dire qu'une entreprise n'est pas obligée de contracter une assurance perte de
gain pour ses employés. Dans ce cas, l'employeur prend le risque maladie à sa charge, car le
Code des obligations prévoit tout de même dans l'article 324a que «si le travailleur est
empêché de travailler sans faute de sa part pour des causes inhérentes à sa personne (…)

Ingénierie de Gestion de projets 185/523

[Link]
 Vincent ISOZ

l'employeur lui verse le salaire pour un temps limité». La durée n'est pas précisée dans la loi,
mais la jurisprudence se base sur l'échelle dite de Berne pour définir le laps de temps pendant
lequel il est tenu de lui verser un salaire. Soit de trois semaines pendant la première année de
service, deux mois dès la troisième année, à dix mois dès la quarantième année (voir tableau
ci-contre). «Ce laps de temps est évidemment cumulatif, explique Célia Borlat, juriste au
syndicat Unia. Si vous êtes malade plusieurs fois dans la même année, le compte ne reprend
pas à zéro, mais les jours d'absence s'accumulent. L'employeur est tenu de vous les payer
jusqu'à concurrence du barème prévu dans l'échelle de Berne.»

Toutefois, une majorité d'entreprises ont conclu un contrat d'assurance perte de gain. Celui-ci
est régi selon deux lois, soit la loi sur l'assurance maladie (LAMaL), soit selon la loi sur les
contrats d'assurance (LCA). Selon la LAMal, vous avez droit, en cas de maladie, au maximum
à 720 jours payés à 80% sur 900 jours. Selon la LCA, le contrat peut être plus flexible.
Toutefois, la loi prévoit que la durée durant laquelle le salaire est dû doit être au moins
équivalente aux règles de l'échelle de Berne. La jurisprudence des tribunaux a ainsi estimé
que l'équivalence se situait à 720 jours à 80%. En général, la majorité des contrats selon la
LCA prévoient une durée de 730 jours payés à 80% par cas de maladie.

Absence sans certificat maladie

Légalement, rien n'est prévu. C'est dire que l'employeur pourrait vous demander un certificat
médical dès le premier jour d'absence. Il doit cependant le demander par écrit. Dans la
pratique, les délais sont divers. Cela dépend des employeurs. A la Confédération, par
exemple, il est plus long, puisque vous ne devez fournir un certificat médical qu'à partir du
sixième jour d'absence. En revanche, certaines conventions collectives, notamment dans le
domaine du bâtiment, sont moins larges et exigent un certificat dès le deuxième jour
d'absence. «En fait, cela dépend souvent du contrat d'assurance qu'a signé l'employeur. Si,
par exemple, l'assurance couvre le risque maladie dès le premier ou le deuxième jour
d'absence, celle-ci exigera généralement immédiatement un certificat», précise
Jean-Marc Rossier, responsable du personnel d'Unia Vaud et ancien secrétaire syndical. Reste
que la plupart des employeurs prennent généralement le risque maladie à leur charge durant
les trois, sept, voire trente premiers jours, et s'assurent essentiellement pour les cas de maladie
de longue durée.

Jour de congé pour s'occuper des enfants malade

Légalement e n'est pas un, mais jusqu'à trois jours qu'un employé peut prendre dans le cas de
la maladie de l'un de ses enfants. «L'employeur doit, sur présentation d'un certificat médical,
donner congé aux travailleuses et travailleurs ayant des responsabilités familiales pour le
temps nécessaire à la garde d'un enfant malade jusqu'à concurrence de trois jours», stipule
ainsi l'article 36 alinéa 3 de la Loi sur le travail. Toutefois, une règle de bonne foi est d'usage.
Le père ou la mère doit en effet reprendre le travail dès que la garde de l'enfant est organisée,
même si le délai de trois jours n'est pas complètement écoulé.

Licenciement pendant la maladie

En fait, vous ne pouvez pas licencier en cas de maladie pendant un temps de protection défini
par la loi. Soit trente jours durant la première année de service, nonante jours de la deuxième à
la cinquième année et 180 jours dès la sixième année. L'employeur ne peut, pendant ces laps
de temps, pas vous signifier votre congé. En revanche, il peut le faire dès la reprise de votre
activité ou vous donner votre congé à la fin de la période de protection, même si vous êtes

Ingénierie de Gestion de projets 186/523

[Link]
 Vincent ISOZ

encore malade. Le délai de résiliation de votre contrat court alors à partir de la date de la fin
de la période de protection.

Causes exactes de la maladie

Ni le responsable de projet, ni le responsable des ressources humaines, ni le directeur de

l'entreprise n'a le droit de demander à un de ses employés les causes exactes de votre maladie.

8.4.15 L'espace blanc

L'écart entre les ressources engagées et les ressources totales dont vous disposez est
fréquemment appelé "l'espace-blanc". C'est un élément essentiel pour la santé d'une entreprise
au quotidien. Si Vous vous n'en avez pas du tout entre le court et le moyen terme, vous êtes
paralysé: vous n'avez personne de disponible pour changer l'entreprise, répondre à de
nouvelles menaces ou exploiter de nouvelles opportunités avec qualité – à moins de retirer
certaines personnes d'un travail dans lequel elles se sont déjà engagées ou de leur faire ce
travail de manière souvent médiocre dans le cadre d'heures supplémentaires ce qui risquer de
faire perdre des contrats.

L'espace blanc donne donc les ressources pour effectuer le changement à venir (veille
technologique, anticipation, gestion des inattendus et autres).

De mon expérience personnelle, toute entreprise qui n'avait pas d'espace blanc avait soit un
turnover phénoménal, soit une perte de motivation conséquente de ses collaborateurs, soit
perdait quelques mandats sous l'effet du stress et du manque de qualité des démarches de ses
collaborateurs sous le coup de dizaines d'heures supplémentaires par semaine.

Évidemment, afin de contrôler ou mettre en place des espaces blancs, il faut mettre en place
un système de suivi du temps centralisé. Ceci principalement afin d'améliorer la gestion du
temps qui dans la majorité des entreprises (on ne doit pas être loin du 99%...) est
catastrophique soit pour éviter des conflits entre ce qui est pensé être fait et ce qui a été fait.

Ainsi, le concept des feuilles de temps (centralisée via un ERP par exemple) même mal perçu
par certains employés méfiants reste un bon outil dans le sens que c'est meilleure que rien.
Personnellement je recommande au lieu de cet outil que je trouve déplacé et inutile
statistiquement parlant de faire en sorte que toute l'entreprise travaille dans l'optique de la
gestion de projet (cela évite la double saisie de la feuille de temps). C'est-à-dire que chaque
tâche soit notée, assignée à un projet, à un initiateur avec un temps estimé et temps réel ainsi
qu'une date début demandé, une priorité et une échéance (bien évidemment dans un système
informatique centralité et non pas dans un tableur!).

Grâce à ce type d'outil j'arrive facilement à montrer au managers et employés les problèmes
d'estimation du temps (souvent sous-évalués par les responsables qui n'ont pas la
connaissance du concept de qualité faute de formation) et il est facile d'avoir une très bonne
estimation du travail exact de chaque employé par projet ou par département.

Un autre point très utile d'une optique "projet" de la gestion du temps (in extenso donc de
toutes les tâches) est que tout employé peut potentiellement (en fonction de ses autorisations)
savoir ce que chacun fait à tout moment de la journée en temps réel. Ce qui n'est
malheureusement pas le cas avec la vieille méthode des feuilles de temps remplies soit en fin
de mois, soit en fin de journée. De plus, cette vieille méthode ne permet de corriger des

Ingénierie de Gestion de projets 187/523

[Link]
 Vincent ISOZ

imprévus qu'avec des retards corresponds à la période de saisie choisie alors qu'avec le
système des tâches nous avons souvent un état de lieux de l'entreprise à la minute près et donc
de faibles écarts entre le prévisionnel et le réel!

Remarque: Utiliser un logiciel du type MS Office Outlook ou MS Project ou tout autre pour
gérer les tâches et le temps de façon détaillée est une très très mauvaise initiative. Il vaut
mieux s'orienter vers des outils web comme MS Office SharePoint Services (gratuit!) et ses
listes de gestion des tâches intégrées qui est un relativement bon outil pour commencer. Sinon
pour aller un cran au-dessus il faudra se reporter à MS Project Server qui reste l'outil de
référence mondiale à ma connaissance pour ce type d'objectif puisqu'il gère les conflits, les
approbations ainsi que les priorités.

Une solution élégante que m'a montré une fois un client pour avoir un suivi du travail précis
de ses collaborateurs sans avoir à leur demander de passer 10 à 15 minutes par jour (temps
estimé par le client) à faire de la saisie (ce qui emm… tout le monde il faut le dire
honnêtement et génère des coûts financiers indirects) est:

1. D'engager un opérateur/rice de saisie avec un numéro de téléphone fixe et un système

de messagerie vocal

2. Le numéro de téléphone de l'opérateur est communiqué à tous les employés et stockés

dans leur téléphone portable d'entreprise

3. Les employé sont tous munis d'une oreillette bluetooth et utilisent Siri pour lancer
l'appel sans avoir à prendre l'appareil dans les mains

4. Le contact établi, les employés communiquent à la messagerie vocale la tâche à saisir

dans le système

5. L'opérateur/opératrice saisi une tâche environ toutes les 10-20 secondes

Il a put être démontré que le coût salariale de l'opérateur/rice de saisie permettait des
économies considérable à l'échelle de l'entreprise (diminution d'environ 60% des coûts).

8.5 Communication
La communication dans les projets était très difficile avant l'internet et le téléphone mobile.
Aujourd'hui ce problème devrait être résolu avec les avancées technologiques existantes mais
un autre effet est venu annuler l'avantage: énormément d'entreprises considèrent que le
responsable de projet doit s'occuper de la planification, de la finance, des contrats, de la
logistique, des ressources, de la communication, etc. (problème de l'organisation matricielle
qui mettent des incompétents à toutes les fonctions par définition...0-

La grande majorité du temps j'observe que les responsables de projets (et pas que!) ont entre
15 et 20 activités dans leur cahier des charges au quotidien. Ce qui fait pour une journée de 10
heures type, un responsable de projet a à peine entre 30 et 40 minutes à consacrer à chaque
activité. On comprend alors tout de suite mieux le taux d'échecs des projets quand on sait
qu'un pilier fondamental d'une bonne gestion de projets est la communication! Par ailleurs,
des méthodes comme Agile (et implicitement Scrum et autres du même genre) donnent une
place importante à de nombreuses petites réunions.

Ingénierie de Gestion de projets 188/523

[Link]
 Vincent ISOZ

Si le responsable de projet est soutenu par un responsable de la communication du projet qui

s'occupe de récolter les informations et de les synthétiser alors il peut pour tout projet se poser
les 5 questions minimales suivantes:

1. Communiquer vers qui?

Utilisateurs finaux, équipe projet, direction du projet, clients. Attention à réduire le
nombre de cibles sinon quoi vous allez passer vos journées à faire de la
communication. Sinon déléguez cette tâche à un spécialiste de la communication de
projets (project community manager).

Comme le signale le PMBOK, et comme nous l'avons démontré dans le cours de

théorie des graphes, si nous considérons le réseau de communication comme un
graphe complet (toutes les arêtes possibles pouvant relier les sommets deux à deux
sont présentes) avec n sommets:

alors le nombre de canaux de communication possibles est donné par: n n 1 2

(donc proportionnel au carré du nombre d'intervenants). Si par exemple vous gérez un
projet avec 10 intervenants (correspondant à n), il y a donc 45 canaux de
communication (e-mail ou téléphone) possibles. D'où l'importance en gestion de projet
de définir des règles de communication claires (sous forme d'un graphe) si l'on ne veut
pas être noyé par les e-mails ou les téléphones inutilement.

2. Communiquer pourquoi?
Pour fédérer, mobiliser l'équipe projet, associer les utilisateurs finaux et informer les
mandants de l'avancement.

3. Communiquer quoi?
Les objectifs, les enjeux, les risques, les résultats intermédiaires, l'organisation, le
planning, l'avancement... Attention aux informations utlra confidientielles qui doivent
être cryptées ou ne pas passer par un format électronique quel qu'il soit.

Ingénierie de Gestion de projets 189/523

[Link]
 Vincent ISOZ

4. Communiquer quand?
Au lancement, aux échéances annoncées, lors de tout évènement (surtout à chaque
jalon par le maître d'œuvre au maître d'ouvrage!). Demander aux mandants et
ressources la fréquence avec laquelle ils souhaitent être informés et sur quoi ils
souhaitent être informés.

5. Communiquer comment?
Tous les moyens sont bons, mais outre le fait que le style doit être le plus simple et
standardisé possible l'implication du responsable de projet et de l'équipe est
primordiale... Ceci dit l'idée de faire un tableau de bord avec des indicateurs clés (KPI)
est très pertinente car en un coup d'oeil il est possible d'avoir une petite idée de
l'avancement du projet. Adaptez aussi le style et méthodes de communications à
l'environnement du projet!

et surtout d'éviter de disperser l'information (typiquement d'utiliser les e-mails) en utilisant

des plates-formes Internet pour centraliser toute la communication du projet de manière
standardisée!

Ci-dessous un schéma qui résume très bien ce qui se passe lorsque les tâches ne sont pas
centralisées et que les gens utilisent les vieilles techniques du téléphone ou de l'e-mail (et ce
schéma ne rend en plus pas compte du problème dit du "téléphone arabe"...):

Figure 17 Ingérence de la communication (source: ISBN 2708130226)

Ingénierie de Gestion de projets 190/523

[Link]
 Vincent ISOZ

Cependant les entreprises souffrent d'un grave problème depuis la fin des trente glorieuses.
Effectivement d'après une étude du PMI, les RH considèrent que les 5 compétences majeures
d'un bon responsable de projet sont (en % de la population totale par énumération):

Compétences de communication 84%

Compétences organisationnelles 75%
Esprit d'équipe 72%
Leadership 68%
Compétences techniques 48%

Or le problème que les RH des entreprises ont a priori oublié c'est que si on demandait cela
aux scientifiques, nous en serions encore à la machine à vapeur, à laver le linge sale dans les
rivières et à descendre de la neige des hauts massifs pour préserver nos aliments et la liste
serait encore longue. Ce qu'ils oublient donc… c'est que c'est l'innovation scientifique et la
méthode associée qui fait avancer le monde et sa condition et non les managers et les
commerciaux et que la rigueur scientifique a prouvé sa supériorité dans tous les domaines
d'activité de services ou industriels (c'est connu dans le monde des sciences pures que cet état
de fait énerve les personnes travaillent dans les sciences molles comme le sont les ressources
humaines... raisons pour lesquelles elles évitent de mettre des scientifiques aux postes clés22).

Nous devrions alors avoir plutôt la liste des compétences souhaitées suivante (dans l'ordre du
plus au moins demandé):

Éthique et responsabilité ?%
Esprit analytique et de synthèse ?%
Compétences techniques ?%
Esprit d'équipe ?%
Compétences organisationnelles ?%

8.5.1 Les quatre styles de communication

L'analyse des 4 styles de communication serait fondée sur les travaux du psychologue suisse
Carl Gustav Jung (1875-1961). Il est volontairement simplifié afin de le rendre utilisable par
chacun dans sa vie quotidienne. Je dois admettre que ce modèle de catégorisation marche très
bien!

Des travaux cités ci-dessus, il ressort que quatre styles de communication prédominent dans
les relations entre les personnes, notamment dans le cadre professionnel. Ces quatre styles
sont:

 Le rationnel
 L'affectif
 L'actif
 Le conceptuel

22
Par ailleurs un certain nombre de scientifiques s'accordent à dire que les premières fonctions qu'il faudrait
éradiquer dans les entreprises sont les RH car ils ont des méthodes de travail qui sont moyenâgeuses. Il y a même
un livre fort connu dans le cercle des initiés qui en donne indirectement une forme de preuve...

Ingénierie de Gestion de projets 191/523

[Link]
 Vincent ISOZ

Et on les retrouve à chaque fois dans les 6 modes de communication auxquels fait référence le
PMBOK:

1. Interne (propre au projet) et externe (clients, publique, projets connexes)

2. Formel (rapports, mémos, briefings) et informels (courriels, discussions diverses)
3. Vertical (entre les différents niveaux hiérarchiques des acteurs du projet) et horizontal
4. Officiel (newsletters, rapports annuels) et non officiel (communication non traçable)
5. Écrit et parlé
6. Verbal et non verbal (inflexion de voix et langage du corps)

Il est clair que chaque type de communication marque le mode de travail, de management,
etc.

Nous allons voir le portrait typique de chaque modèle, à quoi les reconnaître dans la vie
professionnelle, et comment communiquer avec eux ou avec elles.

Mais ce n'est pas tout à fait aussi simple qu'il y paraît ; sans entrer dans les détails, il faut
savoir qu'une personne sous stress (manque de temps, challenge important, émotion intense,
etc.) va certainement changer de style de communication, parfois brutalement. Nous en
parlerons à la fin de ce document.

Ces modes de communications ne rendent pas les personnes plus ou moins sympathiques,
cultivées, généreuses ou honnêtes ; il s'agit juste de la façon dont elles communiquent.

De même, si d'un pays à l'autre, d'une culture à l'autre, les attitudes fondamentales diffèrent, il
n'en reste pas moins qu'un rationnel méditerranéen, sera plus expansif que son homologue de
l'Europe du Nord. Le fait qu'un Américain vous appelle par votre prénom au bout de 2
minutes n'en fait pas automatiquement un affectif, parce que c'est la culture générale.

[Link] Le rationnel
Le rationnel est typiquement une personne qui aime se référer à des données quantifiées, à
une logique. Ces points vont conditionner son comportement à la fois dans son travail
personnel, son organisation et bien sûr sa communication ; qu'il écoute ou qu'il s'exprime, ce
sera la structure de son discours et de sa mémorisation.

C'est à ce comportement qu'on peut le reconnaître. Son bureau est assez rangé, les objets sont
alignés, et les outils rationnels (ordinateur, machine à calculer, agenda, etc.) sont en évidence
et accessibles. La décoration est sobre, régulière et … efficace.

Lorsque vous parlez avec lui, il va attendre des faits quantifiés (le mot « beaucoup » n'a pas
grand sens pour lui), des phrases courtes « to the point », pas d'exubérance, bref sa vision de
l'efficacité. La communication écrite est du même style. Il s'attachera plus à analyser le passé,
qu'à se projeter dans l'avenir ; s'il le fait ce sera conservateur et relativement peu créatif.

En réunion, il s'attend à ce que chacun respecte l'ordre du jour, qu'il y ait un compte-rendu des
décisions, et que l'horaire soit respecté.

Dans la vie professionnelle, les rationnels occupent souvent des fonctions comptables,
administratives, financières, parfois dans la production.

Ingénierie de Gestion de projets 192/523

[Link]
 Vincent ISOZ

Il n'aime pas être surpris, ce qui provoquera un stress important, et le fera changer de mode de
communication. Si vous connaissez cet autre mode, vous pouvez le prévoir, sinon ce sera la
surprise et donc un risque. Il est plus efficace de le laisser savoir à l'avance ce dont vous aller
parler, il pourra se préparer, et votre relation sera plus facile et efficace, à condition de
respecter le code verbal.

[Link] L'affectif
Comme le nom l'indique, l'affectif privilégie l'affectivité dans ses rapports avec les autres.
C'est-à-dire qu'il va évaluer votre relation en fonction de l'affection qu'il va sentir se
développer et des émotions qu'il ressent quant à vous, votre projet, etc.

L'affectif est généralement assez ouvert pour s'ouvrir aux autres styles de communication, ce
qui fait qu'il excelle dans la vente où le contact est essentiel. Il porte aux autres un intérêt
véritable et s'efforce de le lui faire comprendre par exemple en lui posant des questions
personnelles, en s'intéressant à sa famille. Il a besoin de visualiser le cadre de la relation, ou
simplement de la « réchauffer » pour bien nouer le dialogue. De même, il vous parlera
spontanément de lui, ou prendra des exemples personnels.

Selon les cultures, l'affectif aura plus ou moins tendance à « toucher » l'épaule, le bras de son
interlocuteur, pour avoir un contact plus étroit, mais il le fera plus que les autres modèles de
communication.

Son bureau parle pour lui ; il y a bien sûr sa famille, parfois ses amis, des images du passé,
des diplômes, bref ce qui a marqué sa vie et ce qui constitue ses points de repère.

En réunion, c'est malheureusement celui qui sera souvent le plus rapide à faire une digression,
mais aussi le plus efficace à trouver les terrains d'entente pour résorber les conflits.

Ce sont souvent des vendeurs, mais ensuite, ils évoluent dans la hiérarchie, et puisque la vente
mène à tout, nous les retrouvons dans pratiquement toutes les fonctions de management, sauf
peut-être en finance, et en industrie.

L'affectif est en principe toujours disponible (son emploi du temps est donc surchargé), mais
il ne faut pas le brusquer car il n'aurait pas le temps d'établir sa relation… Il lui faut donc du
temps pour commencer, et pour conclure. Entre deux, les choses peuvent aller vite car il vous
fera confiance, tant que vous resterez sur le mode affectif. Si vous ne respectez pas son mode
de communication, il se méfiera, deviendra stressé, et changera de mode de communication!

[Link] L'actif
C'est clair, il bouge et fait beaucoup bouger. Les questions se succèdent sans qu'il ait vraiment
le temps d'en écouter les réponses ; en fait ce sont plutôt des directives que des questions,
parce que, si vous êtes devant lui, c'est que vous faites déjà partie de ses projets ou que cela ne
va pas tarder.

Sa perception de la vie se résume aux actions qu'il conduit, ou auxquelles il participe. Son
emploi du temps est chargé, souvent fractionné, et laisse peu de temps à la réflexion. C'est
également l'image qu'il donne. Ce qui frappe, c'est l'énergie dont il fait preuve.

Ingénierie de Gestion de projets 193/523

[Link]
 Vincent ISOZ

Ne lui demandez pas de vous laisser le temps de la réflexion ; il ne le comprendrait pas, et

n'en a pas le temps ; au contraire entrez dans le jeu et dans l'action. C'est à ce prix qu'il
communiquera avec vous et gardera un bon souvenir de votre « conversation »…

La principale limite de l'actif est qu'il doit avoir la compétence de base pour être efficace,
sinon sa quête d'action se réalise en pure perte, car il ne connaît pas le territoire sur lequel il
dépense son énergie.

Son bureau vous éclairera, si tant est qu'il en ait un! En effet, le bureau typique de l'actif est
encombré, sans ordre apparent, mais il s'y retrouve, ou du moins il en donne l'impression.
Certains actifs ont franchi la limite et n'ont plus de bureau personnel, ils se posent à proximité
de leur secrétaire, ainsi qu'à côté de leurs collaborateurs. Pour eux ce qui compte c'est de
piloter et de construire. C'est ainsi qu'ils mesurent leurs résultats, et éventuellement les vôtres.
Ils travaillent dans les couloirs, dans la rue, au restaurant, partout où c'est le moment…

En réunion, l'actif ne respectera pas l'ordre du jour (sauf si c'est le sien…), mais sera le
premier à s'impatienter et à se plaindre de l'absence de résultat. Pour cadrer un sujet, il suffit
de lui donner la parole, mais de la lui retirer à temps avant que tout le monde ait fui.

Les actifs sont souvent dans la production, ou à la direction générale, jouant le rôle d'un
homme-orchestre. L'entreprise est fortement axée sur les résultats.

Il n'aime pas perdre son temps, et son aspect opportuniste cache une certaine fidélité. Il n'agit
pas sur un coup de tête, et sa confiance se mérite. En fait il est constamment sur le qui-vive et,
dans sa tête, les dossiers sont prêts. Pour travailler avec lui il faut préparer ses cartouches et
savoir les utiliser à bonne cadence. Il vaut mieux ajourner une réunion que de laisser des
temps morts s'installer.

Son esprit s'intéresse d'abord aux conséquences des actes et des décisions à prendre pour les
analyser et décider à court terme. Il est également l'intuitif.

Pour mener à bien son approche des choses et des gens, il a besoin de temps, et son rythme de
travail est relativement plus lent que celui de ses collègues. En fait quand il approfondit un
sujet, il va de plus en plus vite, car il capitalise sur ses analyses. C'est un des principaux
indicateurs pour l'identifier.

Quand vous échangez avec lui, vous remarquerez qu'il va spontanément prendre du recul, et
éventuellement vous proposer une approche plus globale, et plus long terme. Cette démarche
peut sembler pesante, mais elle est très puissante.

Son bureau, s'il n'est pas nécessairement zen, est serein, calme. L'ordre n'y règne pas en
maître, mais suffisamment pour pouvoir travailler. Il aime vous accueillir, et partager avec
vous ses visions. La décoration est assez facilement …conceptuelle, ou composée d'objets de
qualité, si possibles authentiques. C'est peut-être un fumeur de pipe.

En réunion, il ne s'intéressera qu'à un ou deux points de l'ordre du jour, et encore! En fait il

enrichira la réunion d'éléments clés qui permettront de mieux situer une problématique, ou de
réviser une allocation de ressources, etc.

Ingénierie de Gestion de projets 194/523

[Link]
 Vincent ISOZ

[Link] Le conceptuel
Les conceptuels se trouvent dans la recherche, le planning, la stratégie, et donc également à la
tête des organisations, qui invariablement intègrent le long terme dans leurs valeurs.

Il n'aime pas être confronté à une accumulation de détails et de décisions à court terme. C'est
le meilleur moyen de le stresser et de le faire changer de mode de communication, mais
souvent en pure perte, puisque, dès le calme revenu, il va prendre le temps de revoir ses
décisions par rapport au long terme. Éviter par exemple de l'associer étroitement à une cellule
de crise où il n'aurait pas sa place, mais lui soumettre les décisions pour prendre du recul.

8.5.2 Des mesures pour réduire le nombre d'e-mails

Alors que la culture digitale s'est très largement répandue dans l'entreprise, le mauvais usage
du mail s'accentue paradoxalement et impacte durablement la productivité. Comment
sensibiliser chacun à la nécessité de réduire le nombre de mails envoyés?

La perte de productivité liée aux mails inutiles est colossale. Et malheureusement il n'existe
pas de filtres antispam internes pour éliminer automatiquement les mails inutiles.

Considérons une entreprise de 5'000 employés et admettons que chacun gère une centaine de
mails par jour et que la plupart de ces mails sont internes à l'entreprise. Cela fait environ 100
millions de mails par an. Considérons enfin qu'il faille en moyenne une minute pour traiter un
mail. Il s'agit là d'un simple ordre de grandeur bien évidemment.

Si nous pouvions réduire de 10% le nombre de mails reçus (et donc envoyés), le gain de
productivité serait colossal. Dans cet exemple, il permettrait de gagner l'équivalent d'environ
100 postes à temps plein. Simplement en diminuant de 10 % le nombre de mails!!!

Personnellement je préconise deux solutions qui vont de la méthode douce à la méthode qui
touche au porte-monnaie. Il va sans dire que les deux doivent être strictement appuyées par la
direction de l'entreprise pour avoir un effet et par le département IT pour extraire les
statistiques nécessaires!:

 Méthode douce: Imaginez un concours ouvert à tous les employés, quel que soit leur
statut ou leur métier. Les participants sont aléatoirement répartis dans des groupes
d'une trentaine de personnes pour s'affranchir des disparités liées au métier de chacun.
Au début du concours, l'ensemble des e-mails envoyés par chaque groupe pendant
l'année écoulée est calculé et rendu public. Tous les mois, les efforts de réduction des
mails envoyés par ces participants sont également rendus publics afin de stimuler
l'esprit de compétition.

Au bout d'un an, si l'objectif de 10 % de réduction des mails est atteint pour l'ensemble
des participants, le groupe qui aura fait le plus bel effort se verra récompensé (par
exemple à hauteur d'un iPad par participant).

Le coût total de l'opération se chiffrerait alors pour l'entreprise à une somme bien
dérisoire par rapport au temps (ou aux postes d'emploi...) gagné de manière durable

Ingénierie de Gestion de projets 195/523

[Link]
 Vincent ISOZ

 Méthode forte: Cette méthode consiste simplement à facturer au prix du timbre de la

poste classique les e-mails échangés entre département et avec les partenaires
extérieurs... Cela calme tout de suite les esprits de certains et a un effet là aussi durable
puisque de nombreux centre de coûts traditionnels seront touchés...

Enfin, la pratique semble indiquer que de fournir un seul et unique point de contact et canal de
communication aux clients est grandement apprécié par ses derniers. Cela permet par ailleurs
quand bien appliqué de garder les clients satisfaits grâce à une prise en charge efficace et
professionnelle de toutes les demandes de service.

8.6 Cycle de vie d'un projet

Les projets sont des réalisations uniques qui impliquent nécessairement un certain degré
d'incertitude en ce qui a trait aux probabilités de succès. Les organisations qui exécutent des
projets divisent normalement ceux-ci en plusieurs phases afin d'en permettre une meilleure
gestion et un contrôle adéquat: identification, planification, réalisation et terminaison.

Collectivement, ces phases sont mieux connues (globalement ou individuellement) sous le

nom de cycle de vie de projet, chacune étant marquée par la réalisation d'un ou de plusieurs
biens livrables.

Remarque: Par définition, un bien livrable est un produit tangible, vérifiable.

Les figures ci-dessous illustrent quelques modèles particuliers23 des phases du cycle de vie
d'un projet (la première étant représentée empiriquement sous la forme d'une distribution
bêta):

23
Nous avons déjà mentionné qu'il existe des modèles de cycle pour la majorité des standards de la gestion de
projets. Celui du PMBOK étant relativement complet nous conseillons au lecteur d'y jeter un coup d'œil!

Ingénierie de Gestion de projets 196/523

[Link]
 Vincent ISOZ

Les phases du projet font partie d'une séquence logique ce qui permet d'assurer une définition
acceptable du produit obtenu. Pour la gestion informatisée de projet qui nous concerne, nous
vous proposons le modèle présenté à la figure ci-dessus comprenant cinq phases,
nommément: l'identification, la planification, la mise en place informatisée, le pilotage
informatisé et la terminaison.

Sinon voici un autre schéma un peu plus détaillé:

24

24
Il existe de nombreux types différents de "matrices d'analyse des tâches" (tableau à double entrée):
tâche/responsable, tâche/priorité, tâche/tâche avec corrélation, etc.

Ingénierie de Gestion de projets 197/523

[Link]
 Vincent ISOZ

ou encore un peu plus détaillé (ma version personnelle):

Ingénierie de Gestion de projets 198/523

 Vincent ISOZ

Légende:
 SWOT: Stregnths, Weaknesses, Opportunities, Threads
 AMDEC: Analyse des Modes de Défaillance et de leur Criticité
 SdF: Sûreté de fonctionnement
 AQ: Assurance Qualité
 QQOQCP(P): Qui Quoi Où Quand Combien Pourquoi, (Pour Quoi?)
 ATO: Au plus tôt
 ATA: Au plus tard
 W.B.S.: Work Breakdown Structure (structure des tâches du projet sous forme d'organigramme)
 P.B.S.: Product Breakdown Structure (structure du produit sous forme d'organigramme)
 O.B.S.: Organisational Breakdown Structure (structure qui permet de mettre en relation PBS avec WBS
pour identifier les responsabilités)
 L.B.S..: Localisation Breakdown Structure
 PERT: Program Evaluation Review Technic
 KPI: Key Performance Indicator (IPC: Indicateur de Performance Clé)

Pendant l'explication du modèle ci-dessus, le formateur vous demandera d'ouvrir MS Office

Project, MS Office Visio et MS Office Excel pour certains exemples pratiques (qui ont été
simplifiés pour commencer!).

L'idéal dans la réalité est cependant de faire une check-list adaptée à votre domaine d'activité
concernant le cycle de vie du Projet. Un bon exemple dont on peut s'inspirer est celui proposé
par la méthodologie Hermès dans son PDF gratuit intitulé Guide de poche, qui contient une
check-list d'une quarantaine de pages très bien faite.

Pour ceux qui ne trouveraient pas le PDF sur Internet, voici un copier/coller brut du modèle
de phases avec les critères d'évaluations de chacune.

Ingénierie de Gestion de projets 199/523

 Vincent ISOZ

Ingénierie de Gestion de projets 200/523

 Vincent ISOZ

Ingénierie de Gestion de projets 201/523

 Vincent ISOZ

Ingénierie de Gestion de projets 202/523

 Vincent ISOZ

Ingénierie de Gestion de projets 203/523

 Vincent ISOZ

Ingénierie de Gestion de projets 204/523

 Vincent ISOZ

Ingénierie de Gestion de projets 205/523

 Vincent ISOZ

Ingénierie de Gestion de projets 206/523

 Vincent ISOZ

Ingénierie de Gestion de projets 207/523

 Vincent ISOZ

Ingénierie de Gestion de projets 208/523

 Vincent ISOZ

Ingénierie de Gestion de projets 209/523

 Vincent ISOZ

8.6.1 Postulats et corollaires

Évidemment pour mettre en pratique ces outils, méthodes et techniques nous considérons
régulièrement les postulats suivants:

1. AVOIR LE TEMPS

2. AVOIR LES CONNAISSANCES

3. AVOIR LES COMPÉTENCES

4. AVOIR LES MOYENS (outils, finances, ressources, ressources compétentes…)

5. AVOIR LA LÉGITIMITÉ

6. AVOIR LE SOUTIENT DE LA DIRECTION

Ingénierie de Gestion de projets 210/523

 Vincent ISOZ

Ces 4 postulats satisfaits impliquent un corollaire:

L'OBLIGATION DE RÉSULTATS!!

Nous y associons souvent le rappel des limites évidentes suivantes:

1. L'environnement est toujours incertain

2. Le facteur chance fait partie des projets

3. Une ressource est rarement disponible à 100% (imprévus)

4. Aucun outil n'est 100% adapté

5. La gestion de projets n'est pas une science exacte

et le rappel des pièges suivants:

- Penser qu'on peut être accessoirement responsable de projet

- Ne pas chercher les raisons pour lesquelles on a été nommé responsable d'un projet

- Dire que "c'est facile"…

- Ne pas avoir les connaissances (communication, finance, logistique, outils, lois,

brevets…)

- Ne pas écouter les collègues qui ont de l'expérience métier

- Recréer la roue en termes de "méthodes" et "outils"

- Ne pas avoir formalisé ses méthodes et en faire un concept

- Forcer une méthode inadaptée à l'environnement de travail

- Ne pas se laisser le temps de réflexion

- Se rappeler que de petites variations ont un impact psychologique plus grand sur de
petits projets que sur des gros!

- Penser toujours au moins 3 coups à l'avance (pour chaque tâche ou chaque risque)

8.6.2 Identification
La première des cinq phases, soit celle de l'identification, est sans aucun doute l'une des plus
importantes. Elle permet de conceptualiser une idée par une démarche logique qui nous
amènera à bien la maîtriser tout en tenant compte de l'environnement. La phase
d'identification est aussi importante car elle impacte tout le déroulement du projet et il devient
alors très difficile de faire des changements par la suite sans impliquer des nuisances
financières ou temporelles.

Ingénierie de Gestion de projets 211/523

 Vincent ISOZ

L'identification est normalement le rôle du Business Analyst (selon le BABOK) mais dans la
majorité des entreprises le responsable de projet cumule malheureusement plus de rôles
(fonctions) et doit alors aussi s'improviser expert dans ce domaine.

Dans cette phase cruciale pour tout projet, il y a quelques outils et règles indispensables qui
nous aident à bien identifier le projet.

Avant d'aborder ce sujet je souhaite juste souligne l'importance (comme le souligne le

BABOK) d'avoir un outil ou une méthode de gestion de l'information et de la documentation
et ce afin d'éviter les erreurs suivantes (que l'on peut facilement contourner avec un outil
comme Microsoft SharePoint) que je retrouve dans presque toutes les organisations lorsque
j'interviens en tant que consultant:

 Centralisation des modèles de documents et fichiers de l'entreprise ainsi que des outils
informatiques afin d'éviter aux collaborateurs dans différentes départements de perdre
des centaines d'heures à recréer la roue en bricolant avec des macros ou du VBA pour
faire de la gestion de projets alors que des progiciels ont déjà été achetés ou qu'une
SSII a déjà développée la solution requise il y a plusieurs années de cela...

 Centralisation de la documentation dans un système centralisé unique par

métadonnées gérées avec assignation automatique et unique de tout fichier
électronique et ce afin d'éviter les copies de documents se promenant dans les boîtes e-
mail des collaborateurs et que ne l'on sache plus quelle est la dernière version où de ne
plus savoir où sont enregistrés les documents...

 Système d'approbation et de gestion des versions automatique de la documentation et

contrôle fin des accès aux informations afin d'avoir une traçabilité totale sur
l'évolution de la documentation et un système décisionnel plus efficace....

 Archivage des documents de projets terminés automatique ou semi-automatique

conformément aux standards internationaux et cryptage des données sensibles...

Parlons principalement de la Méthode d'Identification d'un Projet (MIP). Une fois bien
complétée, la MIP devient un puissant outil de communication, puisqu'elle incorpore sur
quelques pages l'idée, le concept et/ou le mandat du gérant de projet, tout cela articulé de
façon claire et concise suivant une logique éprouvée. La MIP permettra de bien saisir la
problématique qui génère le projet afin d'en déterminer le but et les objectifs. Elle permettra
aussi d'évaluer les risques, d'élaborer les extrants/livrables et les intrants du projet (voir
définitions plus loin), d'analyser les options potentielles, tout cela dans le but ultime d'obtenir
un mandat clair, sans équivoque et très cristallisé.

Un autre outil porte sur les dimensions de l'environnement, soit les facteurs externes et
internes pouvant affecter en tout ou en partie le projet. Il comprend les facteurs suivants:
physiques et environnementaux, technologiques, socioculturels, organisationnels, politico-
légaux, économiques et infrastructurels. C'est un ajout essentiel et complémentaire à la
méthode d'identification du projet.

Grâce à cette excellente source d'informations, les divers intervenants comprendront sans
distorsion le bien-fondé du projet ainsi que le but et les objectifs à atteindre. Finalement, le
tout aidera les instances décisionnelles à prendre une décision éclairée de Go/No Go pour la
suite ou le rejet du projet.

Ingénierie de Gestion de projets 212/523

 Vincent ISOZ

Le tableau ci-dessous présente les facteurs clés de succès que tout bon gestionnaire devrait
considérer avant d'entreprendre un projet.

[Link] Options
Souvent un client ou une entreprise ou un particulier face à un investissement ou à un projet
va comparer plusieurs alternatives ou solutions entre elles. Il est bien évidemment possible de
faire un choix au bolomètre (mais alors à quoi cela sert-il de faire un cursus universitaire si
c'est pour utiliser des méthodes d'enfants de 6 ans par la suite en entreprise… ou encore
d'utiliser le classique système des notes avec pondérations empiriques des critères qui
équivaut la méthode de travail de tout adolescent moyen.

Une méthode un peu plus élaborée que l'assignation de notes avec des poids empiriques
consiste à utiliser les Maison de la qualité Six Sigma que nous verrons un peu plus loin (voir
page 230) mais cela reste toutefois très enfantin et peu scientifique (donc pas rigoureux du
tout!).

Un méthode décisionnelle déterministe utilisée au plus haut niveau des gouvernements et

entreprises est l'APH qui est une technique d'analyse décisionnelle multicritère ("Multi
Criteria Decision Making" (MCDM) en anglais).

Nous savons que les systèmes de votes traditionnels ou de notes/rangs ne peuvent pas être
utilisés dans le cadre de décisions complexes multicritères et multi-niveaux car ces derniers ne
prennent trivialement pas en compte le poids d'importance associés aux composants. De plus,
même si un poids était affecté le problème résider dans le choix d'une valeur empirique de ce
dernier ce qui rend l'approche totalement non scientifique et ouvre la porte à des débats
interminables dans la pratique.

Pour présenter la technique de l'APH il nous semble pertinent de commencer avec un exemple
d'analyse naïve d'une somme de scores (notes):

Critère/Alternative Choix de X Choix de Y Choix de Z Plage

Facteur A 1 4 5 0-5
Facteur B 20 70 50 1-100
Facteur C -2 0 1 -2 à +2
Facteur D 0.4 0.75 0.4 0à1
Somme 19.4 74.75 56.4
Score normalisé 12.9% 49.7% 37.5%

Cependant, vous remarquerez que la plage de valeurs pour chaque facteur du produit/projet
n'est pas la même. Il est alors tout à fait injuste de résumer toutes les valeurs de plusieurs
critères et comparer le résultat. Il est clair que le facteur B est dominant parce que la gamme a
une valeur plus élevée. Pour être juste, nous pouvons proposer au moins deux solutions
triviales:

1. Au lieu d'utiliser des valeurs arbitraires pour chaque facteur, nous positionnons
juste le choix pour chaque facteur: la valeur de rang plus petit est plus
préférable que celle de rang supérieur (c'est psychologie par rapport à l'usage
quotidien de la majorité des humains).

Ingénierie de Gestion de projets 213/523

 Vincent ISOZ

2. Nous transformons la valeur du score de chaque facteur en fonction de la

valeur de plage de sorte que chaque facteur aura la même étendue
(normalisation des scores).

Essayons les deux solutions en commençant par la première:

Critère/Alternative Choix de X Choix de Y Choix de Z

Facteur A 3 2 1
Facteur B 3 1 2
Facteur C 3 2 1
Facteur D 2 1 2
Somme 11 6 6
Score normalisé 26.09% 36.96% 36.96%

où, puisque la plus petite valeur de rang est la meilleure, nous avons renormalisé les codes de
la façon logique suivante:

1. Comme la somme de tous les rangs est toujours égale, soustraire du total des rangs RT
la somme des rangs d'une colonne RCi a pour effet automatiquement de lui donner
l'importance inverse (effectivement si la somme totale des rangs vaut 23 comme ci-
dessus alors 23-6=17 alors que 23-11=12 donc nous avons bien l'effet recherché).
Nous avons alors la somme des rangs normalisée

SRNi  RT  RCi

2. Nous voulons un pourcentage, dès lors il est naturel d'écrire:

RT  RCi  1  RCi
%SR
Ni

RT RT

3. Le problème de ce dernier calcul c'est qu'il donne systématiquement sommé pour

toutes les colonnes 200%. Il faut alors le multiplier par 0.5 tel que au final:

%SR    RCi 
Ni 0.51


 RT 


Maintenant il est important de remarquer que le fait de travailler avec les rangs ne donne plus
le même résultat que dans le tableau antéprécédent. Effectivement, les choix Y et Z deviennent
indifférents et donc nous avons perdu de l'information!

Raison pour laquelle est il recommandé de travailler sur les scores plutôt que les rangs car non
seulement travailler sur les rangs peut amener à des égalités qui n'avaient pas lieu d'être mais
dans certains cas cela inverse même le range final de certains éléments d'un choix (nous
parlons alors "d'effet d'inversion de rang par les scores").

Ingénierie de Gestion de projets 214/523

 Vincent ISOZ

Maintenant voyons l'effet qu'aurait de normaliser les scores du premier tableau entre 0 et
100% en utilisant simplement une règle de trois (après décalage des scores), le tableau
suivant:

Critère/Alternative Choix de X Choix de Y Choix de Z Plage

Facteur A 1 4 5 0-5
Facteur B 20 70 50 1-100
Facteur C -2 0 1 -2 à +2
Facteur D 0.4 0.75 0.4 0à1
Somme 19.4 74.75 56.4
Score normalisé 12.9% 49.7% 37.5%

Devient alors:

Le calcul est clairement un peu plus compliqué qu'avec les rangs mais nous avon un résultat
meilleur dans le sens que la conclusion n'est pas changée.

Maintenant voyons une version naturellement plus évoluée inspirée des portefeuilles
financiers incluant des poids aux critères. Évidemment le résultat de l'exemple qui suit ne sera
plus comparable aux précédents.

Donc considérons le tableau de poids suivant:

Facteur A Facteur B Facteur C Facteur D Somme

Poids 6 2 2 1 11
Poids relatifs 54.5% 18.2% 18.2% 9.1% 100%

Notre tableau des scores normalisés devient alors:

Critère/Alternative Poids Choix de X Choix de Y Choix de Z

Facteur A 54.5% 0.109 0.436 0.545
Facteur B 18.2% 0.035 0.127 0.090
Facteur C 18.2% 0.000 0.091 0.136
Facteur D 9.1% 0.036 0.068 0.036
Somme 100% 0.180 0.722 0.808
Score normalisé 10.5% 42.2% 47.2%

Bon ce techniques élémentaires décisionnelles ayant été présentées passons maintenant à

l'APH à proprement parlé qui a une approche complément différente!

Remarque: Signalons que l'auteur de cette méthode (Thomas Saaty) a édité un logiciel qui
permet d'automatiser des procédures complexes de décision basées entre autres sur sa
méthode et qu'il est possible de retrouver à l'adresse suivante [Link]

L'approche de l'APH se veut déjà être très mathématique. Dès lors intuitivement nous
pouvons déjà nous dire que les scores normalisés sont en réalité les composantes d'un vecteur
de poids de préférence dont la somme vaut 100%:

Ingénierie de Gestion de projets 215/523