Conduite de projets informatiques

+ QUIZ
Développement, analyse et pilotage
Ingénieur ESIEA, Brice-Arnaud GUERIN
Ce livre sur la conduite de projets informatiques s’adresse à un public d’infor-

Conduite
est Directeur de programmes chez Kantar
maticiens, de chefs de projet, qu’ils soient professionnels ou étudiants. Il présente et auteur aux Editions ENI depuis 2003. Ses
la conduite de projets d’une façon concrète et abordable, en fournissant les élé- compétences en développement et son
ments clés d’un projet réussi : analyse, suivi, bilan. désir de partager ses connaissances l’ont na-
Toutes les étapes d’un projet sont présentées sous l’angle pratique, en reliant turellement conduit à l’écriture d’ouvrages

de projets
des règles implicites à des exemples réels. Les explications « toutes faites » et les para- consacrés à la conduite de projets et à la
réalisation d’applications (C++, .NET, PHP).
Téléchargement
digmes « prêts à l’emploi » sont analysés pour permettre aux chefs de projets d’ef-

Conduite de projets informatiques

[Link]
.fr
fectuer leurs propres choix, en toute connaissance de cause. Les informaticiens et
les professionnels impliqués dans des projets informatiques trouveront des réponses

informatiques
aux questions fréquemment posées et qui les concernent quotidiennement (gestion
d’aléas, moyens, chiffrage, planning, risques, aspects fonctionnels…). Le livre
traite des aspects financiers (budgets, business cases, contrôle de gestion) et de la sur [Link] :
b E­ xemples de chiffrages,
prise en compte du risque (analyse, plan de gestion) pour le pilotage du projet.
de budgets.
Le livre comporte des études de cas très détaillées, fruits de l’expérience de b E­ xtraits de spécifications,
l’auteur. Le premier projet décrit la mise en œuvre d’un CRM dans une société de plannings et d’indicateurs.
de conseil. Figure également le projet de développement d’une solution de
pilotage d’activité dans une entreprise de crowdfunding. Enfin, le livre présente le
lancement d’une entreprise startup et son projet de vente en ligne.
bD ­ ocuments relatifs aux études
de cas : budget, P&L, analyse Développement, 5e édition

analyse et pilotage
des risques, expression des
Les méthodes Scrum et Kanban sont naturellement étudiées dans le cadre des besoins, cas de test, planning,
projets agiles. Le lancement d’une application mobile développée en open source points d’avancement…
illustre concrètement la conduite d’un projet d’envergure en suivant une approche En téléchargement
itérative.
La nouvelle édition du livre étudie le pilotage d’un portfolio de projets, en com- exemples
mençant par la constitution du programme, son cadre contractuel, sa roadmap, ses Pour plus
d’informations :
Brice-Arnaud GUÉRIN
indicateurs de performance clés avant de poursuivre avec le suivi opérationnel, les fichiers complémentaires
aspects liés à la communication et la conduite du changement.
Les activités découlant du règlement sur la protection des données personnelles
(RGPD) incombant au chef de projet sont également expliquées. L’outillage de
conduite du projet est passé en revue pour permettre aux équipes, même réduites,
de communiquer et de suivre leurs projets avec efficacité.
Des éléments complémentaires sont en téléchargement sur le site [Link].

45 €
isbn : 978-2-409-03736-8
Table des matières 1

Les éléments à télécharger sont disponibles à l'adresse suivante :

[Link]
Saisissez la référence ENI de l'ouvrage DP5CPR dans la zone de recherche et
validez. Cliquez sur le titre du livre puis sur le bouton de téléchargement.

Avant-propos

Chapitre 1
Démarrer un projet informatique
1. Démarrer un projet informatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Identifier les enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Définir les objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Le périmètre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2. Élaborer son projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1 Dimensionner le projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Constituer une équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Déclencher le projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3. L’apport de la conduite de projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 Maximiser la valeur du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Fiabiliser l'emploi des ressources et le planning . . . . . . . . . . . . . 25
3.3 Développer son équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4. Quatre projets sous forme d’études de cas . . . . . . . . . . . . . . . . . . . . . 26
4.1 Mise en œuvre d'un CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.2 Besoin exprimé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.3 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.4 Les enjeux du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Développement d'une application de pilotage d'activité . . . . . . 29
4.2.1 Analyse de la situation et perspectives . . . . . . . . . . . . . . . 30
4.2.2 Résumé des exigences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.3 Dotation et contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2 Conduite de projets informatiques
Développement, analyse et pilotage

4.2.4 Les enjeux du chef de projet . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Création d'un site de vente en ligne . . . . . . . . . . . . . . . . . . . . . . 32
4.3.1 Des moyens conséquents au service d'un projet unique . 33
4.3.2 De la stratégie au plan projet. . . . . . . . . . . . . . . . . . . . . . . 33
4.3.3 Les enjeux d'une équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4 L'appli Sports' net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.1 Le défi d'une bande de passionnés . . . . . . . . . . . . . . . . . . . 35
4.4.2 Un projet à la mesure de sa communauté . . . . . . . . . . . . 35
4.4.3 Développer et grandir avec la technologie . . . . . . . . . . . . 35

Chapitre 2
Les aspects financiers et juridiques
1. Les aspects financiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.1 La structure de coût d'un projet . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.1.1 Les salaires et prestations de réalisation . . . . . . . . . . . . . . 38
1.1.2 Négocier les coûts journaliers en régie . . . . . . . . . . . . . . . 39
1.1.3 Négocier les prestations au forfait. . . . . . . . . . . . . . . . . . . 39
1.1.4 Le plan de charge financier. . . . . . . . . . . . . . . . . . . . . . . . . 40
1.2 Les prestations d’hébergement . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.3 Le plan de charge financier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1.4 Les prestations d’exploitation et de maintenance . . . . . . . . . . . 42
1.5 Les prestations de support aux utilisateurs . . . . . . . . . . . . . . . . 43
1.6 Les coûts refacturés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.7 Les coûts non liés à l’informatique . . . . . . . . . . . . . . . . . . . . . . . 44
2. Les budgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.1 Constitution des budgets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.2 Les indicateurs liés aux budgets. . . . . . . . . . . . . . . . . . . . . . . . . . 45
3. Le compte de résultats (Profit and Loss) . . . . . . . . . . . . . . . . . . . . . . . 46
3.1 Le modèle économique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.1.1 Licence et maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.1.2 L'abonnement (SaaS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.3 Le modèle transactionnel (Pay as you go). . . . . . . . . . . . . 47
Table des matières 3

3.2 La projection financière . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.2.1 Les flux de trésorerie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.2 L'analyse financière. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.3 Les indicateurs clés VAN, TRI, break even . . . . . . . . . . . . 51
4. Le business case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1 La proposition de valeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Le top line financier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3 L'executive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5. Le suivi financier des projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1 Les comptes rendus d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 La reconnaissance du chiffre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6. La réglementation concernant la protection
des données personnelles (data privacy) . . . . . . . . . . . . . . . . . . . . . . . 55
6.1 Que recouvre le terme de données personnelles ? . . . . . . . . . . . 57
6.2 Des données personnelles conservées
le temps d'effectuer des traitements . . . . . . . . . . . . . . . . . . . . . . 57
6.3 Le stockage des données personnelles et leur neutralisation . . . 58
6.4 Le registre des traitements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.5 La territorialisation des données dans le cadre
d'un projet de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.6 La responsabilité des données
au sein des organisations (alias le CDO). . . . . . . . . . . . . . . . . . . 60
7. Le cadre contractuel du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.1 Le vocabulaire des appels d'offres . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2 Différents types de contrat pour un projet informatique . . . . . 62
7.3 La définition contractuelle du projet ou Statement Of Work . . 63
7.4 Les annexes techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8. Étude financière du site de vente en ligne. . . . . . . . . . . . . . . . . . . . . . 64
8.1 Structure de coûts et budgets estimés. . . . . . . . . . . . . . . . . . . . . 65
8.1.1 Budget d'investissement CAPEX (Capital Expenditure) . . 66
8.1.2 Budget de fonctionnement OPEX
(Operational Expenditure) . . . . . . . . . . . . . . . . . . . . . . . . . 66
4 Conduite de projets informatiques
Développement, analyse et pilotage

8.2 Business case et P&L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

8.2.1 Résumé exécutif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.2.2 Proposition de valeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
8.2.3 Prévisions de ventes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
8.2.4 Analyse financière sur trois ans . . . . . . . . . . . . . . . . . . . . . 71
8.2.5 Résumé financier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.3 Scénarios de suivi financier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.3.1 Budget d'investissement CAPEX . . . . . . . . . . . . . . . . . . . . 72
8.3.2 Identification d'économies sur le budget
de fonctionnement OPEX . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.3.3 Révision du P&L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Chapitre 3
La prise en compte du risque
1. Les trois axes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2. Le modèle de développement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.1 Le modèle cascade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2.2 Le modèle en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
2.3 Le modèle itératif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
2.4 Le modèle RAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
2.5 Le modèle Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . 86
2.6 Le modèle RUP (Rational Unified Process) . . . . . . . . . . . . . . . . . 88
3. Le modèle d'analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.1 Le principe de modélisation en analyse. . . . . . . . . . . . . . . . . . . . 90
3.1.1 L'exemple du dictionnaire de termes . . . . . . . . . . . . . . . . . 92
3.1.2 L'exemple des figures géométriques . . . . . . . . . . . . . . . . . 95
3.2 Le modèle Merise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.3 Le modèle UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Table des matières 5

4. Le modèle de pilotage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

4.1 Les faits relatifs au projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.2 Les indicateurs clés de performance (KPI). . . . . . . . . . . . . . . . . 107
4.2.1 Indicateurs relatifs au planning . . . . . . . . . . . . . . . . . . . . 107
4.2.2 Indicateurs relatifs à la qualité. . . . . . . . . . . . . . . . . . . . . 107
4.2.3 Indicateurs relatifs à la roadmap . . . . . . . . . . . . . . . . . . . 108
4.2.4 Indicateurs financiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.2.5 Indicateurs relatifs à l'équipe . . . . . . . . . . . . . . . . . . . . . . 108
4.2.6 Indicateurs liés au risque . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.3 Le pilotage du projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.3.1 Décisions sur l'issue du projet . . . . . . . . . . . . . . . . . . . . . 109
4.3.2 Décisions sur le contrôle du projet . . . . . . . . . . . . . . . . . 109
4.3.3 Conduite de la communication . . . . . . . . . . . . . . . . . . . . 110
4.3.4 Constitution de la base de connaissances . . . . . . . . . . . . 110
5. Prendre en compte le risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.1 L'analyse des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.1.1 Les classes de risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.1.2 L'identification des risques. . . . . . . . . . . . . . . . . . . . . . . . 116
5.1.3 La caractérisation du risque . . . . . . . . . . . . . . . . . . . . . . . 117
5.2 Le plan de risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.2.1 Les stratégies de gestion du risque. . . . . . . . . . . . . . . . . . 119
5.2.2 Choisir le modèle de projet en fonction du risque . . . . . 121
6. Étude du risque pour le projet de CRM . . . . . . . . . . . . . . . . . . . . . . 123
6.1 Analyse des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
6.1.1 La faisabilité du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
6.1.2 La disponibilité des ressources . . . . . . . . . . . . . . . . . . . . . 125
6.1.3 La dimension personnelle. . . . . . . . . . . . . . . . . . . . . . . . . 125
6.1.4 Des aspects informatiques et techniques . . . . . . . . . . . . 126
6.1.5 Facteurs de réussite du projet . . . . . . . . . . . . . . . . . . . . . 127
6.2 Plan de gestion des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.2.1 L'évaluation des risques . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.2.2 La conduite du risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.3 Choix des modèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6 Conduite de projets informatiques
Développement, analyse et pilotage

Chapitre 4
L’approche classique du projet
1. Le modèle en cascade est une référence. . . . . . . . . . . . . . . . . . . . . . . 135
1.1 Estimer par anticipation pour planifier. . . . . . . . . . . . . . . . . . . 136
1.2 La contrainte de spécifications stables . . . . . . . . . . . . . . . . . . . 137
1.3 Gestion des risques et gouvernance dans un projet waterfall. . .138
2. Les phases du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
2.1 L’expression de besoins et le cahier des charges . . . . . . . . . . . . 139
2.1.1 Le contenu d'un cahier des charges . . . . . . . . . . . . . . . . . 140
2.2 Le cadrage et les spécifications générales . . . . . . . . . . . . . . . . . 145
2.3 La conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
2.4 La réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
2.4.1 Gestion du code source . . . . . . . . . . . . . . . . . . . . . . . . . . 146
2.4.2 Gestion de la documentation liée au codage. . . . . . . . . . 146
2.4.3 Les revues de code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
2.5 Les tests et les corrections, l'assurance qualité . . . . . . . . . . . . . 153
2.6 Les types de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
2.6.1 Tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
2.6.2 Tests d’intégration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
2.6.3 Tests fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
2.6.4 Le banc d'essai (benchmark) . . . . . . . . . . . . . . . . . . . . . . 157
2.6.5 Tests d'acceptation utilisateur (UAT). . . . . . . . . . . . . . . 158
2.6.6 Cycles de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
2.6.7 Plans de tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
2.6.8 Stratégie de tests descendants . . . . . . . . . . . . . . . . . . . . . 161
2.6.9 Stratégie de tests ascendants . . . . . . . . . . . . . . . . . . . . . . 162
2.6.10Tests de non-régression . . . . . . . . . . . . . . . . . . . . . . . . . . 163
2.6.11Suivi des anomalies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
2.7 Gestion des versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
2.7.1 Production d’une version . . . . . . . . . . . . . . . . . . . . . . . . . 167
2.7.2 Montée de version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
2.7.3 Livraison continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Table des matières 7

2.8 Le lancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

2.8.1 Industrialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
2.8.2 La mise en production . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
2.8.3 La mise en service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
3. Le développement du projet de pilotage d’activité. . . . . . . . . . . . . . 171
3.1 Organisation du développement . . . . . . . . . . . . . . . . . . . . . . . . 171
3.1.1 La gestion du code source et des éléments de travail . . . 171
3.1.2 La documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
3.1.3 Les revues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
3.1.4 La production des versions. . . . . . . . . . . . . . . . . . . . . . . . 173
3.1.5 La mesure de l'avancement du développement . . . . . . . 173
3.2 Organisation des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
3.2.1 La préparation des scénarios de test . . . . . . . . . . . . . . . . 174
3.2.2 Les tests automatisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
3.2.3 La non-régression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
3.2.4 Les jeux d'essais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
3.2.5 La planification des tests . . . . . . . . . . . . . . . . . . . . . . . . . 176
3.3 La gestion des anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
3.3.1 Les statistiques utiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
3.4 Le déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
3.4.1 La préparation des environnements . . . . . . . . . . . . . . . . 180
3.4.2 Les procédures de déploiement . . . . . . . . . . . . . . . . . . . . 181
3.4.3 Les mises à jour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Chapitre 5
Rendre les projets agiles
1. Les bases de l'agilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
1.1 La maîtrise du risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
1.1.1 Les limites des approches classiques . . . . . . . . . . . . . . . . 185
1.1.2 Le risque et l'aléa planning . . . . . . . . . . . . . . . . . . . . . . . . 186
1.1.3 Point de complexité VS charge . . . . . . . . . . . . . . . . . . . . 188
1.1.4 De la productivité à la vélocité . . . . . . . . . . . . . . . . . . . . 189
8 Conduite de projets informatiques
Développement, analyse et pilotage

1.1.5 Les critères d'achèvement. . . . . . . . . . . . . . . . . . . . . . . . . 191

1.2 Des préceptes agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
1.2.1 Stratégie des petits pas . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
1.2.2 Fail fast et quick win . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
1.2.3 Implication du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
1.3 Les nouveaux rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
1.3.1 Product manager et product owner. . . . . . . . . . . . . . . . . 194
1.3.2 De chef de projet à Scrum master . . . . . . . . . . . . . . . . . . 194
1.3.3 D'architecte à product designer . . . . . . . . . . . . . . . . . . . . 195
1.3.4 Delivery manager ou program manager . . . . . . . . . . . . . 195
2. Des approches agiles remarquables . . . . . . . . . . . . . . . . . . . . . . . . . . 196
2.1 La méthodologie Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
2.1.1 La définition du backlog. . . . . . . . . . . . . . . . . . . . . . . . . . 197
2.1.2 Les sprints ou itérations . . . . . . . . . . . . . . . . . . . . . . . . . . 198
2.1.3 L'avancement dans Scrum . . . . . . . . . . . . . . . . . . . . . . . . 199
2.1.4 Le rôle du Scrum master. . . . . . . . . . . . . . . . . . . . . . . . . . 199
2.2 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
2.2.1 Une cartographie visuelle suivie par tous . . . . . . . . . . . . 201
2.2.2 Flux continu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
2.2.3 Pas de rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
2.2.4 Lead time plutôt que vélocité . . . . . . . . . . . . . . . . . . . . . 203
2.2.5 Des changements à tout moment . . . . . . . . . . . . . . . . . . 203
3. Les outils adaptés à l'agile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
3.1 Structuration et planification . . . . . . . . . . . . . . . . . . . . . . . . . . 204
3.1.1 Les systèmes intégrés de gestion de projet . . . . . . . . . . . 204
3.1.2 Les outils de planification . . . . . . . . . . . . . . . . . . . . . . . . 205
3.2 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
3.3 Intégration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
4. Intégration des projets agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
4.1 La place de l'agile dans l'organisation R&D . . . . . . . . . . . . . . . 208
4.2 Le positionnement de l'agile vis-à-vis de l'externe . . . . . . . . . . 209
4.3 Contractualisation des projets agiles. . . . . . . . . . . . . . . . . . . . . 210
Table des matières 9

5. Le story telling de Sports' net. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

5.1 Composition de l'équipe et organisation du projet . . . . . . . . . 211
5.1.1 Au départ, pas de scope, pas (encore) de moyens. . . . . . 211
5.1.2 Être leader du projet sans en être responsable . . . . . . . . 212
5.1.3 Élargir la liste des contributeurs . . . . . . . . . . . . . . . . . . . 212
5.1.4 Des figures à l'affiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
5.2 La construction du backlog et le grooming. . . . . . . . . . . . . . . . 213
5.2.1 Une roadmap et des workshops publics . . . . . . . . . . . . . 213
5.2.2 Prioriser ce qui est impactant . . . . . . . . . . . . . . . . . . . . . 213
5.2.3 Laisser venir des idées simples . . . . . . . . . . . . . . . . . . . . . 213
5.2.4 Reverser des bénéfices à la communauté . . . . . . . . . . . . 214
5.3 La gestion des sources et les forks . . . . . . . . . . . . . . . . . . . . . . . 214
5.3.1 Publier le tronc sur une forge GIT . . . . . . . . . . . . . . . . . . 215
5.3.2 Encourager les forks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
5.3.3 Un écosystème à base de code source et non d'API . . . . 215
5.4 Le résumé du cas d'affaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
5.4.1 Des investissements réduits. . . . . . . . . . . . . . . . . . . . . . . 215
5.4.2 Des contrats préservant l'agilité . . . . . . . . . . . . . . . . . . . 216
5.4.3 Des actifs à forte valeur ajoutée
avec un faible niveau de risque . . . . . . . . . . . . . . . . . . . . 216
5.4.4 Le top line financier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Chapitre 6
Planification, chiffrage et suivi au quotidien
1. L'estimation des charges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
1.1 Les charges et les délais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
1.1.1 L'estimation par abaque . . . . . . . . . . . . . . . . . . . . . . . . . . 220
1.2 L'estimation analytique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
1.3 L'estimation imposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
1.4 L'estimation pour les méthodes agiles. . . . . . . . . . . . . . . . . . . . 225
10 Conduite de projets informatiques
Développement, analyse et pilotage

2. L'emploi du temps du chef de projet . . . . . . . . . . . . . . . . . . . . . . . . . 226

2.1 Les charges d'encadrement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
2.2 Les tâches d'organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
3. La gestion des ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
3.1 Le plan de charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
3.2 La montée en charge et la disponibilité. . . . . . . . . . . . . . . . . . . 232
3.3 La surcharge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
3.4 Gestion des ressources Cloud. . . . . . . . . . . . . . . . . . . . . . . . . . . 233
4. La planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
4.1 Les éléments d'un planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
4.1.1 Les unités d'œuvre et les tâches . . . . . . . . . . . . . . . . . . . . 235
4.1.2 Les jalons (points de phase) . . . . . . . . . . . . . . . . . . . . . . . 237
4.1.3 Les dépendances entre les tâches et les contraintes . . . . 237
4.1.4 Les ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
4.1.5 Le calendrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
4.2 Le recensement des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
4.2.1 Le recensement des ressources . . . . . . . . . . . . . . . . . . . . . 242
4.2.2 La définition de l'horizon temporel . . . . . . . . . . . . . . . . . 242
4.2.3 L'identification du plan de charge . . . . . . . . . . . . . . . . . . 243
4.2.4 La constitution du planning
à partir du plan de développement . . . . . . . . . . . . . . . . . 244
4.3 Le diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
4.4 Le diagramme PERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
4.5 Le chemin critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
4.6 Planifier en mode agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
4.7 Les outils de planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
4.7.1 Les logiciels spécialisés (MS Project, Gantt Project,
Sciforma). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
4.7.2 Les solutions généralistes (Smartsheet) . . . . . . . . . . . . . 249
Table des matières 11

5. Le suivi et le pilotage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

5.1 Le suivi de projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
5.1.1 Le compte rendu d’activité. . . . . . . . . . . . . . . . . . . . . . . . 250
5.1.2 L'avancement des tâches . . . . . . . . . . . . . . . . . . . . . . . . . 250
5.1.3 L'évolution du planning et les revues de planning . . . . . 252
5.1.4 Les réunions de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
5.1.5 Les réunions d'équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
5.1.6 Les sessions de spécification ou d'analyse . . . . . . . . . . . . 255
5.1.7 Les séances de briefing et de formation. . . . . . . . . . . . . . 255
5.1.8 Les coups d'envoi (kick-off) . . . . . . . . . . . . . . . . . . . . . . . 256
5.1.9 La centralisation de la documentation . . . . . . . . . . . . . . 256
5.2 La gestion des imprévus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
5.2.1 Les complications techniques . . . . . . . . . . . . . . . . . . . . . 257
5.2.2 Détection et diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . 258
5.2.3 Les causes possibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
5.2.4 Les solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
5.2.5 La base de connaissances . . . . . . . . . . . . . . . . . . . . . . . . . 260
5.3 Les conflits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
5.3.1 Les types de conflits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
5.3.2 Les techniques de résolution . . . . . . . . . . . . . . . . . . . . . . 261
5.3.3 Les aléas organisationnels . . . . . . . . . . . . . . . . . . . . . . . . 263
5.3.4 Retards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
5.3.5 Qualité médiocre des livraisons . . . . . . . . . . . . . . . . . . . . 264
5.3.6 Communication défaillante . . . . . . . . . . . . . . . . . . . . . . . 264
5.4 Le comité de pilotage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
5.4.1 Les règles de pilotage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
5.4.2 Les réunions de pilotage . . . . . . . . . . . . . . . . . . . . . . . . . . 266
5.4.3 Les modifications de planning . . . . . . . . . . . . . . . . . . . . . 267
5.4.4 L'allocation de ressources . . . . . . . . . . . . . . . . . . . . . . . . . 267
5.4.5 L'interruption ou l’arrêt d’un projet . . . . . . . . . . . . . . . . 268
12 Conduite de projets informatiques
Développement, analyse et pilotage

5.5 Terminer un projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

5.5.1 Les livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
5.5.2 Les modalités de livraison . . . . . . . . . . . . . . . . . . . . . . . . 269
5.5.3 La réception et la recette . . . . . . . . . . . . . . . . . . . . . . . . . 269
5.5.4 La gestion du changement . . . . . . . . . . . . . . . . . . . . . . . . 269
5.5.5 Le pilote. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
5.5.6 La formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
5.5.7 Le support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
5.5.8 La maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
6. La planification du projet de pilotage d’activité . . . . . . . . . . . . . . . . 272
6.1 Différentes estimations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
6.1.1 Estimation selon la méthode des points fonctionnels . . 272
6.1.2 Estimation par abaque . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
6.1.3 Estimation ad hoc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
6.2 Le planning du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
6.3 Analyse des périodes critiques . . . . . . . . . . . . . . . . . . . . . . . . . . 278
7. Suivi du projet de pilotage d’activité. . . . . . . . . . . . . . . . . . . . . . . . . 279
7.1 Organisation et suivi des réunions de projet . . . . . . . . . . . . . . 279
7.1.1 Les réunions daily standup meetings . . . . . . . . . . . . . . . 279
7.1.2 Les réunions d'avancement . . . . . . . . . . . . . . . . . . . . . . . 281
7.2 Quelques imprévus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
7.2.1 Les réunions de trente minutes qui s'éternisent . . . . . . . 283
7.2.2 Démarrage trop tardif de tâches sans alerte . . . . . . . . . . 284
7.2.3 La charge des testeurs en dent de scie . . . . . . . . . . . . . . . 285
7.3 Suivi du projet par le comité de pilotage. . . . . . . . . . . . . . . . . . 286
7.3.1 Quand le projet vire à l'orange. . . . . . . . . . . . . . . . . . . . . 286
7.3.2 La malédiction des données de production . . . . . . . . . . . 287
7.4 Le go live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
7.4.1 Le processus de lancement . . . . . . . . . . . . . . . . . . . . . . . . 288
7.4.2 L'adhésion au nouvel outil . . . . . . . . . . . . . . . . . . . . . . . . 289
7.4.3 Le bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Table des matières 13

Chapitre 7
Pilotage d’un portfolio de projets
1. Constitution d’un programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
1.1 Contrat et cadre contractuel . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
1.2 Définition de la feuille de route (roadmap) du programme. . . 293
1.3 Les indicateurs clés du programme & SLA . . . . . . . . . . . . . . . . 294
2. Pilotage d'un programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
2.1 Un tableau de bord consolidé. . . . . . . . . . . . . . . . . . . . . . . . . . . 297
2.2 Gestion et coordination des ressources . . . . . . . . . . . . . . . . . . . 298
2.3 Gestion financière et pilotage budgétaire . . . . . . . . . . . . . . . . . 299
2.3.1 Budget initial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
2.3.2 Suivi financier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
2.3.3 Prise en compte des demandes de changement . . . . . . . 299
2.3.4 Les révisions budgétaires ou reforcast . . . . . . . . . . . . . . . 300
2.3.5 Atterrissages financiers . . . . . . . . . . . . . . . . . . . . . . . . . . 300
3. Gestion de la communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
3.1 Gestion de la communication
auprès des équipes et des instances . . . . . . . . . . . . . . . . . . . . . . 300
3.1.1 Reporting opérationnel . . . . . . . . . . . . . . . . . . . . . . . . . . 301
3.1.2 Réunions de management et comités de pilotage . . . . . 301
3.1.3 Revues de business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
3.2 Conduite du changement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
3.2.1 Le kick-off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
3.2.2 Les réunions d'on-boarding . . . . . . . . . . . . . . . . . . . . . . . 303
3.2.3 Formations et documentations . . . . . . . . . . . . . . . . . . . . 303
3.2.4 Mesure et développement de l'usage . . . . . . . . . . . . . . . . 304
3.2.5 Animation sur les objectifs du programme. . . . . . . . . . . 304
4. Pilotage du programme d'expérience client On'Troc . . . . . . . . . . . . 304
4.1 Le kick-off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
4.2 Le comité de pilotage de fin d'exercice . . . . . . . . . . . . . . . . . . . 307
4.3 Booster l'usage ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
14 Conduite de projets informatiques
Développement, analyse et pilotage

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
 135

Chapitre 4
L’approche classique du projet

1. Le modèle en cascade est une référence

L’approche classique du projet

Le modèle en cascade est le standard incontournable de la gestion de projet.

Bien que souvent opposé aux méthodes agiles ou critiqué par leurs promo-
teurs, il continue à s'appliquer avec un taux de réussite certain.
Ce modèle qui repose sur une succession de phases est d'une logique
simplissime. Chaque phase débute à l'achèvement de la précédente de façon à
développer et enrichir un livrable en élaboration progressive. Ainsi, les spécifi-
cations sont la traduction de l'expression de besoins, le code source devient la
matérialisation des spécifications, les tests sont réalisés sur un programme
assemblé (on pourrait dire compilé), le logiciel est déployé et installé une fois
le programme qualifié à l'issue des tests, etc.
Ce modèle de développement est au moins aussi ancien que la programmation
informatique elle-même. Et ce constat amène deux remarques objectives.
Tout d'abord, un modèle de développement n'est pas une méthode de gestion
de projet. Un enchaînement de phases, d'activités et de tâches, aussi logique
soit-il, ne vaut pas suivi du planning, gestion des aléas ou prise de décision.
Deuxièmement, l'ancienneté de ce modèle et la persistance de son usage
témoignent certes de son adéquation à une certaine typologie de projet, mais
aussi par différence de ses limites.
136 Conduite de projets informatiques
Développement, analyse et pilotage

Ces deux remarques aident à positionner respectivement le modèle en cascade et

les méthodes agiles. Ces dernières ne s'inscrivent pas en opposition complète,
puisqu'elles intègrent en partie l'enchaînement des phases du modèle en cascade.
Il est donc utile de bien maîtriser la conduite d'un projet selon une approche
classique, d'abord pour l'appliquer à la typologie de projet idoine (cf. chapitre
La prise en compte du risque), mais aussi pour faire la part des choses dans le
recours aux méthodes agiles.

Remarque
Sans se hasarder à l'indication d'un pourcentage, un très grand nombre de
projets conduits en waterfall réussissent toujours. Les méthodes agiles ne sont
donc pas l'apanage de la modernité ni le seul moyen de mener un projet à
son terme.

1.1 Estimer par anticipation pour planifier

Commençons par expliquer le terme éponyme cascade (waterfall en anglais).

Imaginons un cours d'eau qui dévale la montagne, s'engage dans la vallée
alpine attenante, poursuit et serpente dans la plaine, s'étend dans l'embou-
chure maritime et finit dans la mer. À la source, on jette à l'eau un bouchon
en liège, celui-ci cheminera sans difficulté pour terminer sa course dans
l'immensité de l'océan. Le parcours inverse, en revanche, est beaucoup plus
coûteux, à l'image des saumons sauvages qui remontent les torrents et
finissent épuisés à l'endroit même de leur naissance.
En gestion de projet, on indique que le passage aller d'une phase à l'autre ne
coûte pas plus que la réalisation d'une phase, mais que le sens inverse multiplie
le coût par 10. Autrement dit, tout changement en cours de route se traduit
par un budget multiplié par 10, 100, 1000… et peut finalement remettre tota-

© Editions ENI - All rights reserved

lement en cause la faisabilité du projet si la modification est tardive.
On comprend donc que le changement est à éviter ou à anticiper autant que
possible. Le modèle en cascade fonctionne très bien sur des spécifications
stables et une plateforme technique éprouvée. Dans ces conditions, on est
tout à fait capable d'estimer la durée de chaque phase, d'en apprécier la charge
en jour-homme et de planifier le projet en enchaînant chaque tâche avec ce
qu'il faut de marge de sécurité.
 L’approche classique du projet 137
Chapitre 4

Il existe de nombreux abaques et quantité d'heuristiques pour planifier ce type

de projet (42 % de tests, 40 % d'industrialisation, 20 % de chef de projet…). Il
n'y a pas de recette universelle tant que les spécifications restent stables. Nous
étudierons les techniques d'estimation et de planification au chapitre Planifi-
cation, chiffrage et suivi au quotidien.

1.2 La contrainte de spécifications stables

Interrogeons-nous sur les conditions de spécifications stables. Il arrive

fréquemment que l'expression de besoins évolue pendant la phase de cadrage.
La maîtrise d'ouvrage (MOA), parfois guidée par un assistant à maîtrise
d'ouvrage (AMOA), va prioriser les besoins et éclaircir les fonctionnalités
attendues. Il est naturel et même souhaitable de conduire cette activité de
façon itérative car la mise au point d'un cahier des charges ne peut
raisonnablement pas réussir d'un seul trait.
Comme la rédaction de spécifications détaillées s'avère coûteuse, et puisqu'on
ne peut pas éviter quelques itérations dans le cadrage des besoins du projet, on
a l'habitude de réaliser des spécifications générales, une sorte d'intermédiaire
entre une expression de besoins forcément incomplète et des spécifications
détaillées nécessairement stables et cohérentes. Car dans le modèle en cas-
cade, le coût et le délai sont portés par la réalisation de ces spécifications
détaillées et, nous l'avons vu, tout changement s'avère dispendieux.
Comment dès lors garantir la stabilité des spécifications ? Tout d'abord, en
laissant suffisamment de temps à la MOA pour mûrir son cahier des charges.
Mais il faut aussi recueillir des validations formelles (sign-off) de chaque élé-
ment des spécifications. Voici les étapes habituelles pour y parvenir :
– Rédaction des spécifications.
– Revue dirigée (commentée).
– Révision et ajustement.
– Revue finale.
– Validation formelle (sign-off).
Au terme du sign-off, il est convenu que toute modification est exclue, les
demandes de changement devront attendre la fin du projet.
138 Conduite de projets informatiques
Développement, analyse et pilotage

1.3 Gestion des risques et gouvernance

dans un projet waterfall

Dire qu'un projet réalisé selon le modèle en cascade n'admet aucun aléa est
sans doute excessif, mais l'équipe projet doit rester vigilante face aux
demandes de changements apparemment mineurs et qui peuvent avoir de
grandes conséquences.
Pour éviter des tensions entre les parties prenantes du projet (aussi désignées
stakeholders) à l'initiative de modifications du besoin et les équipes en charge
de la réalisation, le chef de projet dispose de deux outils.
Tout d'abord, la gouvernance projet définit les règles de fonctionnement du
projet, précise les rôles et responsabilités de chacun, détaille les phases du
projet où les besoins sont acceptés, mais aussi documente les étapes indispen-
sables à la réalisation du livrable. La gouvernance établit les instances de suivi
et les instances de décision (on pourrait dire arbitrage).
Une bonne gouvernance évite les raccourcis « c'est pourtant une demande très
simple » et sécurise l'enchaînement des actions aboutissant à la formation du
livrable.
Le second outil est la gestion des risques ; elle permet d'objectiver tout au long
du projet la situation réelle du projet et les possibilités d'aboutir pour un péri-
mètre donné. En d'autres termes, la gestion des risques fournit les éléments
pour arbitrer des demandes de changements. Mais elle a une autre vertu ; les
demandes de changements « en cours de route » sont le fruit d'une décision
d'adresser des risques dûment qualifiés, ce qui relègue de fait au second plan
des demandes d'évolutions (le plus souvent fonctionnelles) effectuées au fil de
l'eau faute d'être parvenues à concentrer tous les besoins en phase de cadrage.
Ainsi, la gouvernance et la gestion des risques autorisent certains aménage-

© Editions ENI - All rights reserved

ments du plan projet en cours de route, ce qui est une bonne nouvelle pour le
chef de projet mais peut paraître étonnant pour les aficionados des méthodes
agiles.
 L’approche classique du projet 139
Chapitre 4

Les indicateurs clés Qualité, Coût et Délai seront en fin de compte les témoins
de la bonne exécution d'un projet. S'ils dévient franchement de leur valeur
nominale, le projet est peut-être en train de dériver à cause de demandes de
changements trop profondes ou trop impactantes. Dans pareille situation, le
chef de projet doit proposer au comité de pilotage de lotir les évolutions en
créant des paquets de demandes à traiter sur un cycle de projets en cascades.
L'autre possibilité est d'hybrider le projet en cascade avec un flux de travail en
mode agile. Cette approche est très intéressante dans le cas d'un projet dont le
périmètre évolue sensiblement en cours de route, ces modifications étant le
fruit de conditions extérieures et non d'un manque d'anticipation de la part de
l'équipe projet.

2. Les phases du projet

2.1 L’expression de besoins et le cahier des charges

Ces deux termes sont analogues, bien qu'en pratique une expression de
besoins soit le point de départ à l'élaboration d'un cahier des charges plus com-
plet.
Comme nous l'avons déjà évoqué, le cahier des charges est plus souvent décrié
qu'encensé. Et pourtant, il s'agit d'un document indispensable à la réalisation
d'un projet. Le principal problème lié à sa rédaction tient dans l'interprétation
réputée équivoque que l'on pourrait lui prêter, suivant que l'on est du côté de
la maîtrise d'ouvrage ou de la maîtrise d'œuvre. En effet, les clients
rencontrent parfois de réelles difficultés à exprimer clairement leurs besoins
(on entend même parfois que la meilleure expression correspond au logiciel
réalisé). Il arrive aussi que, rompus à l'exercice, les clients restent délibérément
flous dans leurs réponses, cherchant ainsi à maximiser leurs marges de
manœuvre et à différer leurs choix.
La société en charge de la réalisation poursuit précisément l'objectif opposé :
plus vite elle identifie le périmètre de la solution, meilleur sera le rendement
du projet, par le truchement de la capitalisation du savoir-faire.
140 Conduite de projets informatiques
Développement, analyse et pilotage

La situation paraît donc inextricable, et pourtant elle s'impose rapidement car

le cahier des charges reste la principale annexe technique d'un contrat de
développements informatiques.
Il apparaît clairement que les incompréhensions proviennent du caractère
« figé » prêté au cahier des charges. Il serait une fin en soi. Or il n'en est rien et
la solution tient dans une autre lecture de la remarque faite ci-dessus. Si la
meilleure expression d'un besoin client est supportée par un logiciel, elle n'est
qu'une dérivation d'un ensemble de spécifications qui découlent toutes du
cahier des charges.
Autrement dit, le cahier des charges n'est nullement un document figé mais
plutôt un canevas que le processus d'analyse va compléter et transformer
jusqu'à la production du logiciel.
Et tous les processus d'analyse commencent par donner une priorité aux élé-
ments du projet. Il n'y a donc pas de raison de presser le client pour bloquer
des éléments qui pourront être définis ultérieurement, sans remettre en cause
le déroulé des opérations.

2.1.1 Le contenu d'un cahier des charges

Dès lors, que trouve-t-on dans un « bon » cahier des charges ? Cela dépend
évidemment du niveau d'avancement de réflexion de son rédacteur, qu'il soit
représentant des utilisateurs (maître d'ouvrage) ou prestataire (maître
d'œuvre).

Contexte et objectifs stratégiques

Cette section reprend les grandes lignes du business case du demandeur ; la

situation existante, la cible. Il est habituel de ne pas dépasser quelques lignes
pour rappeler le contexte, la rédaction est souvent courte et synthétique.

© Editions ENI - All rights reserved

L’approche classique du projet 141
Chapitre 4

Objet

Est énumérée dans cette partie la portée du projet confié au maître d'œuvre.
Un lotissement peut être mis en place si les responsabilités et les domaines de
compétences sont trop vastes. La longueur de cette section varie considérable-
ment d'un projet à l'autre.

Domaine métier

Le domaine métier apporte des précisions sur les règles applicables au projet.
Ces règles sont décrites textuellement et font référence à des documents
annexes officiels.
Des modèles de base de données constituent également un bon moyen de
présenter les aspects métiers, surtout s'ils sont conceptuels (MCD).

Périmètre fonctionnel (généralement confondu

avec l'expression de besoins)

La description du périmètre fonctionnel s'appuie sur quantité de formalismes :

diagramme des cas d'utilisation, scénarios, diagrammes de flux de travail,
cartographies fonctionnelles…
Il n'est pas rare, au moment de l'élaboration du cahier des charges, d'avoir
suffisamment de matière pour développer cette partie du cahier des charges.
C'est une bonne démarche dans la mesure où elle clarifie souvent les
responsabilités ; cependant, une certaine souplesse doit être conservée quant
à son évolution au cours du projet. De plus, il ne faut pas trop anticiper les
phases d'analyse pour ne pas s'orienter vers une solution ne répondant pas au
besoin réel. Certaines parties peuvent donc être délibérément esquissées alors
que d'autres font l'objet d'une description beaucoup plus poussée.