COURS DE METHODES DE CONDUITE DES

PROJETS INFORMATIQUES

POYO RAMAZANI Tresor, Ir.

Ingénieur en Système d’information d’Entreprise.
Spécialité : Génie Logiciel

Cours dispensé à l’Institut Supérieur de commerce,

informatique et infirmerie en deuxième grade
informatique (ISI et ISRT)

© Ramazani Trésor, 2023

 2

BIBLIOGRAPHIE

▪ AFITEP(2000), « Dictionnaire de management de projet », 4e édition, Afnor.

▪ AFNOR (1998), « Management de projet », éd. AFNOR, 854p.

▪ BENNATAN E.M. (1995), « Management des projets informatiques», Afnor.

▪ CADLES James et YEATES Donald,(2001), « Project Management for
Information System », 3e édition, Prentice Hall.

▪ Christophe MIDLER(1994), « L’auto qui n’existait pas », éd. InterEditions.

▪ GOETHER Wolfhart B., BAILEY Elizabeth K., BUSBY Mary B., Software Effort
and Schedule Measurment,: A framework for counting Staff-hours and reporting Schedule
Information, CMU/SEI-92-TR-021, 1992,

▪ HP MADERS, ET GAUTHIER (1998), « Conduire un projet d’organisation »

éd. Editions d’Organisation, 301p.
▪ HUMPHREY Watts, A Discipline for Software Engineering, Addison-Wesley, 1995
▪ KEZSBOM D.S., SCHILLING D. Let EDWARD K. A(1989),« Dynamic
Project Management. A practical Guide for Managers and Engineers», John Wiley
& Sons.
▪ M. Gedin, H. Tardieu, A. Rochfeld et R. Coletti; « MCP, Méthode de conduite des
projets informatiques », éd. Organization, 1983

▪ MCCONNELL Steve, Rapid Development - Taming Wild Software Schedules,

Microsoft Press, 1996

▪ MORLEY Chantal(2004), «Management d’un projet système d’information », 4e

édition, Dunod.

▪ R. PARK, Software Size Measurement: A framework for counying source

statements, CMU/SEI-92-TR-020, 1992,

▪ SYMONS Charles, Software Sizing and Estimating: Mark II Function Point

Analysis, John Wiley, 1991

▪ Thierry PICQ(1999), « Manager une équipe projet », éd. DUNOD, 235p.

▪ VERMA V.K.(2003), « Guide du référentiel des connaissances en gestion de projet
(Guide PMBOK) », PMI.
 3

INTRODUCTION

Le monde du travail s'est vigoureusement réformé ces dernières années. Citons pour
faire court trois dispositions lourdes : d’abord, la propagation du fonctionnement en
mode projet (forme d'organisation dans laquelle chaque salarié devient un « entrepreneur
» qui se voit assigner un objectif et la responsabilité de l'atteinte de cet objectif) ;
ensuite, le lieu de l'exigence d'instantanéité (la réponse à une question du client ou du
supérieur hiérarchique qui ne peut être qu'immédiate) ; Enfin l'intrusion de l'informatique
et de l'internet qui, bien utilisés, permettent cette instantanéité.

Dans cette vie, Nous avons tous des projets : Qu’ils soient d’ordre privé ou
professionnel, ils donnent du sens à notre vie, et nous projettent vers un futur que nous
voulons meilleur … Un projet, au-delà de la part de rêve qu’il contient, appelle à la
réalisation, à la concrétisation de l’idée de départ. Mais comme le dit cet adage bien connu
« l’intention ne vaut pas l’action ». Il faut donc se donner les moyens de mener à bien une
démarche plus ou moins compliquée pour atteindre l’objectif du projet.

Les projets sont partout (la vie quotidienne, société, etc.) et nous sommes tous des
chefs des projets qui s’ignorent, cependant la conduite d’un projet exige plusieurs facteurs :

▪ Une bonne dose d’imagination et de créativité (osez) ;

▪ Une réelle ouverture d’esprit et beaucoup d’écoute.
▪ De l’audace et du réalisme (une prise de risque raisonnée) ;
▪ Une détermination sans faille (croyez en vous et en votre projet) ;
▪ Une patience à toute épreuve ;
▪ Du travail, encore du travail ;
▪ Un questionnement critique permanent ;
▪ Ce qu’il faut de méthode et d’organisation.
 4

DEFINITION DES CONCEPTS CLES

 Le maître d’ouvrage : est la personne physique ou morale qui est propriétaire de

l’ouvrage (Projet). Il fixe les objectifs, l’enveloppe budgétaire et les délais souhaités
pour le projet. C’est le bailleur de fonds.

 Le maître d’œuvre : est la personne physique ou morale qui reçoit la mission du maître
d’ouvrage pour assurer la conception et le contrôle de la réalisation d’un ouvrage
conformément au programme préétabli. C’est l’organisation ou l’entreprise qui
exécute le projet.

 Le Projet : ensemble d'activités regroupant les trois caractéristiques suivantes : Il est

entrepris pour satisfaire un besoin spécifique, sa durée et les moyens accordés
sont limités et enfin il aboutit à un résultat unique censé satisfaire le besoin.

 Un système est un ensemble d’éléments interagissant entre eux suivant un

certains nombres de principes et de règles dans le but de réaliser un objectif.

 Un modèle : est une représentation schématique de la réalité.

 Une base de Données: ensemble des données (de l'organisation) structurées et liées
entre elles : stocké sur support à accès direct (disque magnétique) ; géré par un
SGBD (Système de Gestion de Bases de Données), et accessible par un ensemble
d'applications.

 Une analyse : c’est un processus d'examen de l'existant

 Une Conception : est un processus de définition de la future application informatique.

 Un système d'Information : ensemble des moyens (humains et matériels) et des

méthodes se rapportant au traitement de l'information d'une organisation.
 5

OBJECTS DU COURS

Ce cours a pour objectif principal, d’acquérir et de renforcer la compétence dans

le domaine de la conception et de la conduite de projets des systèmes d’information afin
de fournir des savoir-faire opérationnels pour toutes les étapes allant de la conception à la
finalisation d’un projet informatique.

Et, D’une façon spécifique ce cours vise à :

▪ Comprendre et concevoir un projet informatique dans un environnement

économique et stratégique complexe ;

▪ Quantifier les ressources en temps, en matériels, en moyens humains et en

financements qui sont nécessaires à un projet informatique;

▪ Anticiper les évolutions technologiques et de gérer des difficultés techniques ou

managériales imprévues ainsi que la qualité et la sécurité dans un projet informatique
;

▪ Analyser la structure d'une organisation et le rôle de chaque acteurs du projet afin

de se positionner et de mettre en œuvre des dynamiques collaboratives complexes
(comprendre et être capable de mettre en place un système de confiance et de
coopération entre les différents acteurs d'un projet) ;

▪ Négocier et de conduire les processus de changement et d'innovation ;

▪ Analyser et de négocier la gestion des SI dans l'ensemble des stratégies de

l'entreprise.
 6

PREMIER CHAPITRE - GENERALITES SUR LES PROJETS INFORMATIQUES

I.1. DEFINITION ET CONTEXTE D’ETUDES

Du mot latin « projectum » de « projicere », en résumé, Ainsi, le mot «projet» voulait

initialement dire « quelque chose qui vient avant que le reste ne soit fait » ou
« jeter quelque chose vers l'avant » ; c’est ainsi, le projet peut être défini comme étant un
ensemble d'activités qui sont prises en charge, dans un délai donné et dans les limites de
ressources imparties, par des personnes qui y sont affectées dans le but d'atteindre des
objectifs définis. Cependant, le projet peut être appréhendé de plusieurs et selon différentes
organisations :

▪ Selon la norme ISO 10006 (version 2003) « un projet est un processus unique qui
consiste en un ensemble d'activités coordonnées et maîtrisées, comportant des dates
de début et de fin, entrepris dans le but d'atteindre un objectif conforme à des
exigences spécifiques, incluant des contraintes de délais, de coûts et de
ressources». La définition d’un projet comporte deux notions clés : le projet est
unique et le projet est temporaire.

▪ Selon Le PMBOK, référentiel du PMI, considère un projet comme une

« entreprise temporaire décidée pour obtenir un produit ou un service unique ».
L'unicité du produit entraîne l'unité des activités à mettre en œuvre.

▪ Selon L'AFITEP définit un projet comme un « ensemble d'actions à réaliser pour

satisfaire un objectif défini, dans le cadre d'une mission précise, et pour la réalisation
desquelles on a identifié non seulement un début, mais aussi une fin » ; et introduit
une distinction entre les projets d'ingénierie qui visent l'obtention d'un résultat pour
un client, et les projets produit débouchant sur un modèle qui fera ensuite l'objet d'une
fabrication répétitive.

L'unicité du processus projet doit être comprise de deux façons. D'une part, les
activités qui permettront d'atteindre l'objectif sont définies de façon à prendre en
compte les particularités de chaque projet, même si l'on réutilise des trames générales.
D'autre part, ces activités ne seront exécutées qu’une seule fois. Il y a donc unicité au niveau
du type et au niveau de l'instance. Ainsi, un projet peut être symbolisé par un triangle dit «
triangle projet » : on est en mode projet lorsque l’on doit atteindre un objectif avec des
moyens ad hoc et dans un délai donné :
 10

Objectif

Moyens Délai

L’AFNOR donne les deux définitions suivantes1 :

▪ « un projet est déterminé et mis en œuvre pour élaborer la réponse au besoin d’un
utilisateur, d’un client ou d’une clientèle et il implique un objectif et des actions à
entreprendre avec des ressources précises »

▪ « un projet est une démarche spécifique qui permet de structurer méthodiquement et

progressivement une réalité à venir »

A partir de celles-ci, nous voyons qu’un projet est :

➔ Composé d’un ensemble d’activités : Il s’agit donc d’un processus qui doit être géré
du point de vue de sa conduite, des moyens mis en œuvre et résultats attendus ;

➔ Mis en œuvre en vue d’atteindre un objectif précis : Celui-ci doit être clairement
exprimé par le (système) client. Cet objectif présente un caractère novateur et n’est
pas répétitif. Il est la plupart du temps matériel, mais il peut également porter sur
des éléments culturels, sur des valeurs à faire évoluer ou à introduire.

➔ Réalisé dans un délai donné : Il est limité dans le temps avec des dates de début
et de fin, « un projet n’a pas d’avenir, il a une fin » C. MIDLER ;

➔ Exécuté grâce à un ensemble de moyens : qui sont matériels et humains ; Pour

P. ZARIFIAN, l’organisation en projet réunit « une équipe multi-métiers autour d’un
projet d’innovation avec des objectifs précis et une durée de vie bien spécifiée
… Les gens travaillent ensemble sur un projet précis et pour une durée limitée
»2.

1AFNOR, « Management de projet : Qualité et efficience des organisations », éd AFNOR,

1995.
2P. ZARIFIAN, « Objectif compétence », éd. Liaison col. Entreprise et carrière, 1999
 11

Tout projet informatique digne de ce nom doit répondre à cinq (5) prérogatives
(atouts ou privilèges) principales :

▪ Fonctionnel : il doit répondre à un besoin défini par le client;

▪ Technique : il doit respecter des spécifications et des contraintes ;
▪ Organisationnel : il doit respecter un mode de fonctionnement (rôles, culture,
fonctions, résistance au changement) ;
▪ Délais : il doit respecter des échéances (planning) ;
▪ Coûts : il doit respecter le budget prévu pour le projet.

Le projet est constitué des actions ou des interventions que fait quelqu’un dans la
plupart de temps une personne morale pour atteindre des résultats utiles. Le projet implique
que ces personnes s’organisent pour le faire. L’organisation qu’elles mettent en place n’est
pas le projet mais cette organisation fait le projet. Le but du projet est de produire de
l’utilité de façon économe.
 12

I.2. OBJECTIFS DES PROJETS INFORMATIQUES

L’objectif visé par la réalisation d’un projet informatique est souvent appelé
« produit », même lorsqu’il ne présente pas un caractère matériel. On distingue ainsi le
contenu du produit (les spécifications) et le contenu du projet (le travail à réaliser pour
livrer le produit). Le premier détermine le second.

Le contenu du produit est en général précisé au cours de l’avancement du

projet. Il fait l’objet d’une première description, qui est ensuite traduite en « produits
livrables ». Le cahier des charges contient la liste des produits livrables. Le contenu du projet
dépend du contenu du produit. Il contient les tâches orientées produit, ainsi que les tâches de
gestion de projet. On opère en général un regroupement des tâches en sous-ensembles
aboutissant à la production des différents livrables. C’est ce qu’on appelle
l’organigramme des tâches (OT), qui décrit la totalité du travail à effectuer : les tâches ne
figurant pas sur l’organigramme des tâches se situent en dehors du contenu du projet. Les
outils et méthodes utilisés pour réaliser le produit varient selon le domaine
d’application, alors que ceux qui permettent la gestion du projet sont en grande partie
partagés par tous les projets.

Comprendre les objectifs du projet et faire émerger des réponses adéquates est de la
responsabilité du chef de projet. On rencontre souvent les grandes catégories suivantes,
qui auront des conséquences sur le management du projet. Nous allons les esquisser :

▪ Productivité administrative : la rentabilité du capital investi est recherchée dans la

diminution de main d’œuvre grâce à l’automatisation d’une partie des tâches. Le climat
social sera tendu et la gestion du changement difficile à mener. La participation des
utilisateurs peut conduire à un blocage du projet.

▪ Aide au management : l’objectif majeur du projet est l’amélioration des prises de

décision au moyen d’un observatoire au service du management. On va bâtir une
mémoire de l’organisation et de ce qui l’entoure, à partir de laquelle on pourra
construire des tableaux de bord, faire des analyses, assurer une veille concurrentielle.
La conception du système doit être très proche des gestionnaires, faute de quoi le
système ne sera guère utilisé.

▪ Efficacité opérationnelle : on attend un meilleur fonctionnement opérationnel par un

usage créatif des technologies de l’information et de la communication. L’analyse et la
reconstruction des processus sont déterminantes, mais la gestion du changement est un
enjeu essentiel.
 13

▪ Évolutivité : on cherche à obtenir un système flexible pouvant être modifié rapidement

en cas d’évolution des contraintes et/ou de la stratégie et sachant prendre en compte
des adaptations ou des personnalisations non encore identifiées au moment du projet. Cet
objectif s’inscrit dans une meilleure maîtrise des investissements informatiques. La
compréhension du domaine et de son évolution est importante.

▪ Utilisation d’une nouvelle technologie : le but principal du projet est d’expérimenter

une nouvelle technologie, pour voir ce que l’on peut en tirer ou pour obtenir un «
effet vitrine » vis-à-vis de l’extérieur. Un délai court est un élément essentiel de la
réussite du projet.

Le choix de démarrer un projet est fondé sur le gain que l'on en attend. Ce gain se
mesure à l'aide du ROI (Ret Our Investissement). Dans la langue de Shakespeare, on parle
de « Business Case », en terme plus simple, ce sont les objectifs économiques. Les objectifs
définissent le périmètre du projet. Les modifier revient à signer l'arrêt de mort du projet. Il
convient de ne pas confondre les objectifs et le cahier des charges qui découlent des
objectifs du projet. Ces objectifs sont :

▪ La définition des démarches d'amélioration fonctionnelle,

▪ la mise en route d'un nouveau produit,
▪ la croissance externe de l'entreprise,
▪ le nouveau besoin en termes d'organisation,
▪ la productivité attendue.

La vision entre le centre de coût ne permet toutefois pas bien d'appréhender tous
les avantages d'un projet informatique. La productivité issue de la mise en œuvre d'une
solution informatique est difficilement mesurable. C'est le paradoxe de Solow. Les objectifs
doivent intégrer deux contraintes : « celle du coût et celle du délai ». Il faut aussi prendre
en compte le risque dans la mesure où l'activité humaine s'appuie toujours sur un
environnement incertain. Les projets informatiques supposent à :

▪ l’adhésion libre et volontaire d’un ensemble des cadres du projet ;

▪ La définition et la compréhension explicite des objectifs du projet (chaque doit

comprendre l’intérêt qu’il a d’y participer afin que l’objectif global soit atteint);

▪ L’organisation responsable de la conduite du projet (l’ensemble des opérateurs et

bénéficiaires doivent s’assurer, en cours d’exécution, que le projet est
constamment géré en fonction de la poursuite des objectifs acceptés) ;
 14

▪ L’appréciation et la mesure des avantages d’un projet (la valeur du produit du projet
ne peut pas se mesurer par un prix sur un marché) ;

▪ Du fait que le projet représente un ensemble d’opérateurs investisseurs de leur

propre efforts, son analyse en terme de comparaison des avantages se fait de façon
double : du point de vue du projet dans son ensemble et du point de vue des
participants. Ce n’est que dans la mesure où la mesure où l’ensemble projet est lui-
même rentable qui sera intéressant de l’entreprendre du point de vue des participants,
surtout dans la mobilisation des ressources ;

▪ La technique de comparaison la plus usuelle entre les coûts et les avantages d’un
projet est celle du taux de rentabilité interne, financier ou économique (TRI) ;

▪ Tout projet informatique qu’il soit marchand ou non doit être rentable. C’est- à-dire
ce qu’il rapporte doit être supérieur à ce qu’il coûte.

L'objectif doit être précisé de façon claire, chiffrée et datée. Le résultat doit être
conforme à des normes de qualité et de performances prédéfinies, pour le moindre coût et dans
le meilleur délai possible :

Cadré (spécifique, précis, défini)

Approuvé, consensuel
Mesurable, critère de validation donné
Échéance précise dans le temps
Réaliste et faisable…
Ambitieux.

Le projet est un objectif «extraordinaire»(au sens littéral du mot) qui combine quatre
aspects :
 15

I.3. LES CARACTERISTIQUES DES PROJETS

INFORMATIQUES

Un projet se caractérise par un ensemble de déterminants. Ils sont de nature à

préciser :

1. La nature du projet3 : Un système d’information présente souvent un degré élevé de

complexité, dans la mesure où c'est un « ensemble organisé de ressources : matériel,
logiciel, personnel, données, procédures… permettant d’acquérir, de traiter, stocker,
communiquer des informations (sous formes données, textes, images, sons …) dans des
4
Organisations» . De plus, son caractère largement immatériel augmente la difficulté quand
on veut en obtenir une description a priori. Cela n'est pas sans conséquence sur les projets, qui
doivent prendre en compte ses diverses dimensions.

Le triplet (objectif, moyens, délai) présente ainsi, dans le domaine système

d'information, trois caractéristiques particulièrement marquées. D’abord, il y a interaction
entre l'objectif d'une part et les moyens/délais d'autre part. L’identification de l'objectif
conduit à évaluer la charge de travail. Cela permet de décider d’une échéance cible
théorique et des moyens à affecter. Si d’autres contraintes obligent à limiter le délai ou le
budget, on ajuste l'objectif, par exemple selon le principe du
« design-to-cost » (conception contrainte par le budget disponible) ou du « time- boxing »
(conception et développement contraints par l’enveloppe temps).

Ensuite, l'objectif du projet n'est parfaitement défini qu'à la fin. La plasticité des
technologies de l’information ouvre la porte à une multitude de choix, aussi bien pour le
logiciel que pour l’organisation qui l’accompagne. Une description exhaustive des fonctions
et des rôles est longue et coûteuse. Les modèles n'en donnent qu'une vue partielle, ce qui
explique qu’au fur et à mesure du projet, des options puissent être modifiées. Enfin, le
développement d'un système d’information se déroule en général dans une Organisation,
certains acteurs du projet étant directement concernés par le futur système d’information.
La répartition du pouvoir et des ressources, la division du travail, les modes de coordination,
les procédures opératoires, les statuts... peuvent être modifiés. Les acteurs ne forment pas
un groupe uni vers la réalisation d'un même objectif et certains peuvent développer des
stratégies individuelles ou de sous-groupes, pour soutenir ou contrer le projet. Ces
caractéristiques font que les projets de système d’information sont particulièrement risqués.

3La nature d’un projet fait appel à la complexité de plusieurs éléments de ce dernier :
(ressources, moyens et compétences)qui ne sont pas généralement placées sous la
responsabilité d’une même autorité et qu’il va falloir coordonner afin que les actions
concourent ensemble à l’atteinte d’un même objectif.
4R.Reix, « Systèmes d’information et management des organisations », 4e éd., Vuibert, 2002.
 16

2. La délimitation d’un projet : Tout projet doit forcément avoir un début et une fin, ce qui
est déterminé par l’expression du besoin normalement formalisée par un cahier des charges
et/ou un contrat.

3. Les risques d’un projet5 : Le risque est défini comme « la possibilité qu’un projet ne
s’exécute pas conformément aux prévisions de dates d’achèvement, de coût et de
spécifications, ces écarts par rapport aux prévisions étant considérés comme difficilement
acceptables voire inacceptables »6. La réalisation des risques peut porter sur les trois
sommets du triangle projet : objectif non atteint, délai non respecté, surconsommation
de moyens. On a longtemps cru que le respect de dispositions
méthodologiques a priori permettrait de mener les projets informatiques de gestion avec
succès.

C’était mal comprendre les particularités de ces projets. Les trois principales
sources d’échec sont la définition des besoins, l’estimation des charges et la possibilité de
nombreux aléas dans le déroulement du projet. En effet, les objectifs peuvent être imprécis
et le pilote du projet doit veiller à une clarification progressive. Par ailleurs, l'estimation
des charges n'est pas une science exacte : les écarts de productivité individuelle sont
parfois importants et de nombreux facteurs peuvent conduire à un dépassement de
charge. Divers imprévus peuvent également avoir une incidence sur le déroulement du
projet. Pour repérer et prévenir ces difficultés, deux approches d'analyse des risques ont
été proposées. L’une est générale à tous les projets, l’autre est spécifique des projets
système d’information. L’idée sous-jacente à l’approche généralisée est qu’en général le/la
chef de projet connaît bien les risques, mais qu’il/elle a besoin d’un cadre rigoureux pour
s’obliger à les gérer. La démarche proposée comprend cinq étapes :
▪ Identification des risques ;
▪ Évaluation d’impact sur les coûts et le délai ;
▪ Définition d’actions de réduction des risques inacceptables ;
▪ Suivi des actions ;
▪ Capitalisation d’expérience.
Des techniques classiques de stimulation et d’organisation des idées sont utilisées au
cours des trois premières étapes, telles que les remue-méninges, le diagramme causes-effets
dit d’Ishikawa, la matrice dite de Pareto permettant un classement en quatre catégories
depuis le risque « mineur » (probabilité faible, conséquences peu importantes pour le
projet) jusqu’au risque «inacceptable » (probabilité élevée, conséquences graves).

5Le risque d’un projet fait appel au non-conformisme(unicité) de ce dernier, c’est-à-dire

qu’il n’y aura jamais deux projets identiques, bien qu’ils peuvent se ressembler du point
de vue l’objectif à atteindre, tout comme l’objet et le résultat du projet, mais il y aura
toujours une différence plus ou moins importante du point de vue de l’environnement, des
bénéficiaires avec leur culture,…
6AFITEP, 2000.
 17

4. La gestion du changement7: La gestion du changement implique la planification et la

réalisation d'un ensemble d'activités, On identifie classiquement : « la communication, la
formation, la documentation, l'organisation des sites, la migration, l'expérimentation
».Le recours à de telles activités est en partie lié aux réticences anticipées. Le concept de
résistance au changement a parfois été présenté comme un facteur explicatif de l'échec de
certains systèmes d'information (projets informatiques), les utilisateurs préférant la stabilité
et refusant a priori toute évolution. Il est préférable de considérer la résistance comme un
symptôme, pouvant se manifester dès le début du projet jusque dans le fonctionnement
opérationnel du nouveau système, et de s'interroger sur ses origines, qui relèvent souvent de
plusieurs facteurs :

▪ La résistance peut être due au système : il s'agit d'une problématique de

« besoins ». Le système, en particulier le système informatique, apparaît insatisfaisant en
termes techniques (temps de réponses, bugs...), fonctionnels (fonctions inadéquates,
informations manquantes, erreurs, tâches lourdes...) ou ergonomiques (interfaces
inadaptées au contexte métier, apprentissage difficile...). Pour éviter ce type de
résistance, des actions sont mises en œuvre tout au long du projet pour s'assurer de
l'adéquation du futur système : participation des utilisateurs à l'analyse et à la conception,
expérimentation sur des sites pilotes, planification de la migration de l'ancien vers le
nouveau système.

▪ La résistance peut être liée aux acteurs eux-mêmes : il s'agit d'une problématique
d'attitude individuelle. Deux interprétations ont été données. La première considère que,
face au changement, il existe des comportements différents selon le profil
psychologique (innovateur ou conservateur). Il s'agit alors de rassurer et préparer ces
utilisateurs, par des actions de communication, de formation et d'accompagnement.
La seconde estime que les différences d'attitude sont contingentes à une situation donnée,
c'est-à-dire que la résistance ou l'engagement dépendent de la perception par l'individu
du changement proposé, notamment la facilité d’utilisation et l’utilité du futur
système. Il s'agit de faire évoluer les perceptions, par la formation et la documentation
pour agir sur la facilité perçue, et par la communication et la participation à la conception
pour développer la perception de l'utilité.

7La non répétitivité du projet. Ceci signifie qu’il est nécessaire de mettre en place une
organisation spécifique, éventuellement distincte de la structure de l’entreprise, spécialement
adaptée et temporaire, voire évolutive au cours du déroulement du projet. Cette
caractéristique fait référence au fait que le projet doit devenir autonome et non toujours
dépendant du donateur.
 18

▪ La résistance peut être liée à l'organisation: il s'agit d'une problématique impact

collectif. Le nouveau système modifie la division du travail, la coordination, la
collaboration ou coopération requise, les activités de contrôle... ce qui peut entraîner des
oppositions. Deux approches explicatives ont été proposées :

→ Selon la perspective dite « sociotechnique » : certains acteurs manifestent une

résistance parce qu'ils pensent que le nouveau système dégradera leurs conditions
de travail. Il s'agit, si l'on veut prévenir une telle résistance, de s'appuyer lors
l'analyse des processus sur des principes d'ergonomie (par exemple, appréciation du
stress causé par certaines tâches) et d'organisation des postes (par exemple, degré
de responsabilité et d'autonomie), et de favoriser une participation à l'analyse des
processus et à l'organisation des sites.

→ Selon la perspective dite « politique » : certains acteurs s'opposent parce qu'ils

pensent que le nouveau système leur enlèvera du pouvoir. L'opposition peut
provenir de différents niveaux hiérarchiques. Un cadre peut voir diminuer son
pouvoir de décision et d'action, ou la taille du groupe placé sous sa
responsabilité. Un opérationnel peut voir réduire sa « zone d'incertitude », liée à la
détention de son savoir-faire ou d'informations clés. Certains projets système
d'information conduisent, pour atteindre des objectifs d'efficacité, à remettre en
question des territoires. Cette situation doit être prise en compte, en particulier dans
l'analyse des risques et l'élaboration d'une stratégie adéquate. La construction d'une
vision d'un « bien commun », partagée par les acteurs en conflit, peut débloquer la
situation : un engagement de la direction de l'entreprise et/ou la référence à des
valeurs collectives sont des moyens d'y parvenir.
 19

DEUXIEME CHAPITRE - LA CONDUITE DU PROCESSUS DES PROJETS

INFORMATIQUES

L’administration d’un projet informatique en mutation requiert un ensemble

d’opérations impliquant des exécutions fortuites. C’est pourquoi l’IPMA précise que
« le conduite de projet consiste à planifier, organiser, suivre et maîtriser tous les
aspects d'un projet, ainsi que la motivation de tous ceux qui sont impliqués dans le projet,
de façon à atteindre les objectifs de façon sûre et dans les critères définis de coûts, délais
et performance».

II.1. LES ACTIVITÉS DE GESTION DE PROJET

Pour le PMBOK, la gestion de projet est « l’application de connaissances, de
compétences, d’outils et de méthodes aux activités d’un projet afin de répondre à ses
besoins ». Il convient toutefois de distinguer deux catégories d’activités dans un projet :

▪ les activités de production : sont celles qui sont nécessaires pour réaliser le
produit ou service visé par l’objectif du projet ;

▪ les activités de gestion de projet : sont celles qui consistent à planifier le travail,
l’organiser et suivre l’avancement des activités de production.

Le champ de la conduite de projets informatiques est calé sur les trois aspects
représentés par le triangle Projet. Ainsi :
 20

▪ Le délai donne lieu à une gestion du temps dont le rôle est de définir le parcours et de
le jalonner, d’établir des calendriers et de maîtriser la consommation de l’enveloppe
temps.

▪ Les moyens affectés constituent le budget du projet, qui est transformé en travail,
locaux, matériel, temps machine, déplacement... Cette transformation nécessite une
gestion des ressources portant sur les ressources humaines et les moyens matériels.

▪ L’objectif du projet doit à son terme être concrétisé par une ou plusieurs fournitures.
Cela implique une gestion de la production, qui a pour but de suivre et diriger
l'avancement vers l'objectif tout au long du projet. On parle parfois de « faire
converger le projet » : cela signifie qu’il faut sans cesse s’assurer que l’on se
rapproche du but et que l’on ne part pas dans des directions remettant en cause un
avancement consolidé.

On peut décomposer l'activité de la conduite des projets informatiques en trois

activités principales autour de la production proprement dite :

Analyser Organiser

Produire

Piloter

Les activités de gestion de projet

▪ Analyser : consiste à déterminer le chemin que l’on va emprunter pour avancer vers
l’objectif. Pour cela, on étudie les caractéristiques du projet, son contexte, les risques qui
le menacent et l’état de son avancement. Cela conduit à un découpage du projet en
actions à entreprendre et à une estimation de l'effort nécessaire. La maille de cette
analyse varie selon le moment du projet auquel on se place.
 21

▪ Organiser : signifie repérer les contraintes d'enchaînement entre les tâches afin de les
ordonnancer. Cela permet d’établir un calendrier. L’organisation recouvre aussi la
constitution d’une équipe, c'est-à-dire des personnes qui sont affectées et imputées au
projet, en déterminant les bons profils. Les relations avec tous les partenaires
nécessaires sont également prises en compte. Dès que la charge est importante, on
répartit le travail entre plusieurs personnes, voire plusieurs équipes, ce qui conduit à
mettre en place des moyens de partage d’informations pour éviter les incohérences.

▪ Produire : consiste à assurer les actions diverses (cultures, fabrications, etc.) qui
concourent à fournir sur le marché commercial certains biens ou services.

▪ Piloter : comprend le suivi de l'avancement du projet, en quantité et en qualité, ainsi

que l’analyse et le traitement des écarts avec ce qui était prévu, les orientations et les
décisions à prendre ou à faire prendre. Le pilotage inclut également le management de
l’équipe et la gestion des conflits.

Pour la norme ISO10006: 2003, les activités de gestion de projet sont

organisées en processus, et réparties en quatre familles :

→ La première famille ne comprend qu'un seul processus, appelé processus stratégique,

qui regroupe les activités relevant de la responsabilité de la direction de l'entreprise,
telle que la nomination des chefs de projet.

→ La deuxième famille comprend des processus qui touchent à la gestion des ressources,
en particulier le personnel.

→ La troisième famille structure les activités de gestion de projet orientées vers la

réalisation du produit, c'est-à-dire la production du bien ou service visé par l'objectif.
Elle comprend la coordination des activités, la maîtrise des tâches de production, la
maîtrise des délais et des coûts, la gestion de la communication, la maîtrise des risques
et celle des achats pour le projet.

→ La quatrième famille de processus réunit les activités de gestion de projet, qui visent
l'amélioration, c'est-à-dire le management des connaissances issues des projets achevés.
 22

II.2. PRINCIPAUX ACTEURS DANS UN PROJET

INFORMATIQUE

Un acteur est quelqu’un qui joue un rôle dans le déroulement du projet. La

notion de rôle est importante dans un univers projet. C’est une fonction temporaire,
déconnectée de la place qu’occupe la personne dans l’organigramme de l’entreprise ; on
attache au rôle des activités à effectuer et une responsabilité. Quand on organise un projet, on
commence par déterminer les rôles nécessaires. On distingue trois types d’acteurs
participant à un projet de développement de système d’information :

▪ le maître d’œuvre et
▪ le maître d’ouvrage ;
▪ l’équipe de projet ;
▪ les utilisateurs.

Les intervenants du projet informatique doivent être identifiés avec leurs rôles et les
fonctions qu’ils doivent remplir dans quel ordre et dans quelles conditions. Cette notion de
responsable à chaque niveau d’intervention est essentielle à la bonne marche du projet. La
première démarche consiste à définir les conditions d’intervention des différents partenaires
et la seconde à préciser les liens qui peuvent exister entre eux.

II.2.1. LE MAITRE D’OUVRAGE

Selon l’AFNOR, le maître d’ouvrage est « la personne physique ou, le plus
souvent, personne morale qui sera le propriétaire de l’ouvrage. Il fixe les objectifs,
l’enveloppe budgétaire et les délais souhaités pour le projet ». À ce titre, il « assure le
paiement des dépenses liées à la réalisation ».
 23

8
Les rôles de maître d’œuvre et maître d’ouvrage sont issus des grands projets
industriels. Ils sont liés par une relation contractuelle. Le maître d’ouvrage représente
« le client ». Partant d’une demande des futurs utilisateurs du système, il établit un cahier
des charges qui peut servir de base à un appel d’offres. Après discussions sur une ou
plusieurs propositions reçues, il passe contrat avec un fournisseur qui jouera le rôle de maître
d’œuvre. Celui-ci est responsable de la conduite du projet. Le maître d’ouvrage assure un
suivi de l’avancement du projet, selon des modalités contractuellement définies. À chaque
fourniture contractuelle par le maître d’œuvre, il procède à la recette et prononce
l’acceptation ou le refus. Il pilote la mise en œuvre du projet. Strictement parlant, l’ouvrage
est le résultat concret d’un projet : construction, matériel, progiciel. Bref, c’est le « bailleur
de fonds ».

II.2.2. LE MAITRE D’OEUVRE

Le maître d’œuvre est « la personne physique ou morale qui réalise l’ouvrage pour
le compte du maître d’ouvrage et qui assure la responsabilité globale de la qualité
technique, du délai et du coût ». L’œuvre est définie comme « le processus de réalisation de
l’ouvrage, c’est-à-dire la mise en place des moyens nécessaires à cette réalisation et à leur
conduite ». Par conséquent, elle « est constituée de l’ensemble des tâches, regroupées ou non
en lots de travaux ».

II.2.3. L’EQUIPE DU PROJET

L’équipe de projet rassemble différents acteurs, qui sont affectés au projet9.
D’après, l’AFNOR, c’est « l’ensemble des personnes placées sous l’autorité directe (et
quelquefois indirecte) du chef de projet ». Mais, on peut parfois considérer que l’équipe
de projet s’étend à toutes les personnes participant à la réalisation du projet. On distingue
ainsi trois différents types d’acteurs dans l’équipe de projet :

▪ Le chef de projet, est responsable devant le maître d’œuvre de l’avancement du projet.

▪ Le concepteur, qui peut être tenu par un informaticien, et qui joue le rôle d’un
organisateur ou un gestionnaire selon le stade d’avancement : sa responsabilité est de
concevoir le futur système aux étapes étude préalable et étude détaillée.
▪ Le développeur, qui est tenu par un informaticien : sa responsabilité est d’écrire les
programmes ou de réaliser un prototype. Pour certains développements réalisés en
langage de 4e génération, le rôle peut être tenu par un gestionnaire.

8 La transposition de ces deux rôles quand il s’agit de système d’information renvoie

davantage à la répartition des responsabilités qu’à la notion de propriété. En effet, même si
l’on parle parfois du « propriétaire d’une application informatique », il est difficile
d’étendre ce droit de propriété aux processus et aux acteurs.
9 Les autres différents acteurs, qui sont affectés au projet peuvent aussi être les
consultants, analystes,
développeurs …).
 24

La performance d’une équipe dépend de l’équilibre de ces positionnements,

appelés « rôles », parmi les membres. Au-delà de la répartition des activités, chacun
endosse en général un « rôle », et des rôles complémentaires favoriseront la synergie, alors
que des « rôles » non endossés manqueront dans la dynamique du groupe. C’est ainsi
Meredith Belbin10 a identifié neuf types de « rôles » regroupés en trois
catégories, selon l’orientation majeure : vers les personnes, vers l’action et vers la
production intellectuelle :

▪ Les rôles orientés vers les personnes sont les suivants :

▪ Le coordinateur a tendance à clarifier les buts et favoriser la prise de décision dans
le groupe ;
▪ Le coéquipier est attentif aux autres et les encourage ;
▪ Le pourvoyeur de ressources, dispose d’un carnet d’adresses qu’il est prêt à
ouvrir pour les membres du groupe.
▪ Les rôles orientés vers l’action sont les suivants :
▪ L’organisateur a tendance à traduire les idées en tâches concrètes ;
▪ L’entraîneur aide l’équipe à conserver le cap vers les objectifs et maintient la
pression ;
▪ Le contrôleur vérifie les détails, il a le souci du respect du calendrier et des
engagements.
▪ Les rôles orientés vers l’intellect sont les suivants :
▪ L’innovateur propose de nouvelles idées, mais il peut être irréaliste et peu
communicateur.
▪ L’évaluateur est au contraire réaliste et il aime analyser les problèmes
complexes.
▪ Le spécialiste possède des connaissances précises, utiles à l’équipe.

II.2.4. LES UTILISATEURS

Les utilisateurs ont pour rôle la mise en correspondance avec les fonctions
permanentes du développement du produit réalisé. Ces derniers peuvent représenter
différents niveaux : décideurs, gestionnaires ou utilisateurs finals. Quand on évoque
l'intervention d'utilisateurs dans un projet, on emploie souvent le terme générique de «
participation ». En réalité, la nature et les modalités de participation peuvent
présenter une grande variété et servir différents buts. Dans une perspective de pilotage
de projet, on considère que la participation peut avoir un effet sur la détermination des
besoins, sur le processus de décision ou sur une évolution organisationnelle.

10 Professeur à l’université de Cambridge.

 25

On peut alors distinguer 3 catégories des utilisateurs :

▪ L’utilisateur final est celui qui va utiliser les transactions et les éditions du futur
système dans son travail au quotidien. C’est, par exemple, l’employé de l’agence
bancaire qui se sert de son terminal pour effectuer les opérations avec la clientèle. La
responsabilité attachée à ce rôle est d’exprimer des besoins et des contraintes liées au
travail courant.

▪ L’utilisateur gestionnaire est un opérationnel qui a des responsabilités d’encadrement.

Il utilisera le futur système pour obtenir des informations permettant de prendre des
décisions de gestion. Par exemple, un responsable produit attendra des informations
permettant de suivre une vente promotionnelle. La responsabilité attachée à ce rôle est
d’exprimer des besoins en informations favorisant la gestion à moyen terme de l’activité.

▪ L’utilisateur décideur a le pouvoir de modifier les règles du système de gestion, pour

utiliser au mieux les possibilités technologiques. Sa responsabilité est de prendre des
décisions sur l’évolution des règles de gestion.

Ainsi la participation peut avoir pour objectif de transférer à l'équipe de projet une
connaissance sur un domaine, un système de gestion, une organisation existante. La
participation peut faciliter le processus de décision, en augmentant la visibilité des
décideurs sur les enjeux et conséquences des décisions. Si les utilisateurs sont multiples, la
prise de décisions passe par la construction d'un consensus. On peut citer à cet égard la
technique JRP11. Enfin, la participation peut rechercher des décisions
d'orientation et de poursuite du projet. Les utilisateurs visés sont des décideurs, et la
poursuite du projet pourra dépendre de leur appréciation et de leur engagement. Cette
participation se fait généralement à travers un comité de pilotage, mais elle peut être plus
informelle.

Prendre une décision, c’est souvent prendre un risque. Celui-ci est d’autant plus grand
que les conséquences du choix se font sentir à moyen ou long terme. C’est pourquoi on
observe parfois une réticence à s’engager. La participation permet de réduire cette crainte,
en donnant aux décideurs une meilleure connaissance du projet et en offrant des possibilités
d’échange et de discussion avec d’autres acteurs. La participation peut enfin faciliter
l'utilisation du futur système par l'utilisateur final.

11JRP (Joint Requirements Planning). Elle a pour objectif de donner un rôle actif à
l’utilisateur lors de l’étape d'expression des besoins, afin de réduire la durée de cette étape et
d’en augmenter la qualité. Les utilisateurs, qui sont également décideurs, jouent alors un rôle
central : ils effectuent la collecte des informations nécessaires à l’expression des besoins ;
ensuite, réunis en session avec les informaticiens, ils présentent leurs résultats qui sont
confrontés, amendés, acceptés, pendant une période de temps courte mais dense.
 26

II.3. NIVEAUX DE RESPONSABILITÉ DANS LE PROJET

INFORMATIQUE

En matière de gestion de projets informatiques, le niveau de responsabilités, c’est

un ensemble des étapes successives de l’analyse, hiérarchiquement subordonnées les unes aux
autres à partir d’une unité supérieure, c’est-à-dire c’est un échelon (degré) d’un ensemble
organisé des implications dans une hiérarchie quelconque. Comme dans la plupart des
organisations humaines, la distribution des responsabilités et des tâches se fait sur le mode
pyramidal du schéma ci-contre. Décrivons sommairement les quatre niveaux, en partant de la
base de la pyramide.

▪ Le niveau exécution : est celui des entreprises en charge des travaux et des contributeurs
internes, sollicités pour leur expertise métier. Le niveau exécution réalise les
différents livrables du projet. Il applique les directives établies par le niveau
opérationnel et lui rend compte des problèmes éventuels et de l'avancement. Le niveau
exécution n'a pas à connaître du projet plus que les informations strictement nécessaire à
la bonne réalisation des tâches qui lui sont confiées.

▪ Le niveau opérationnel : est celui du chef de projet et de son équipe. Il décline les
exigences du cahier des charges en solutions techniques et en tâches à accomplir. Il pilote
le projet au quotidien, détecte et corrige les écarts et rend compte au niveau stratégique.
 27

▪ Le niveau stratégique : détermine l'objectif, nomme le chef de projet, définit le cadre

général du projet et l'organisation, puis s'assure que la trajectoire du projet est conforme
aux prévisions. Bien entendu il intervient en cas d’écart grave, sur demande du chef
de projet ou de sa propre initiative.

▪ Le niveau décision : prend les grandes orientations, en principe sur proposition du niveau
stratégique. Les solutions de gestion de projet diffèrent entre elles, en premier lieu
par le service qu'elles rendent (ou pas) aux acteurs des différents niveaux. A
minima, elles permettent au chef de projet de piloter les travaux. Les solutions les plus
abouties fournissent aux acteurs de chaque niveau les informations qui leurs sont
utiles : un exécutant aura la vision des tâches qu'il doit accomplir, le chef de projet aura
accès à la totalité des données du projet. Quant aux acteurs du niveau stratégique, ils
disposeront d'un tableau de bord synthétique les renseignant principalement sur la
santé du projet. Bien entendu toute information saisie à un niveau est instantanément
répercutée par le système aux acteurs concernés, c'est bien le moins que l'on attende d'un
système informatique.

L’AFITEP appelle « management de projet », l’ensemble des activités de

gestion de projet et introduit une distinction entre deux rôles. Le chef de projet est
responsable de la « direction de projet » et s’appuie sur des assistants chefs de projet qui
accomplissent des tâches rassemblées sous le terme « gestion de projet ». Ces deux rôles
correspondent à deux niveaux de certification. La direction de projet, qui est toujours
exercée par le chef de projet, a pour mission essentielle de définir la stratégie de conduite du
projet, de coordonner l’ensemble des actions, de modifier le plan de marche si nécessaire,
et d’optimiser l’utilisation des ressources.

Pour accomplir la mission de direction de projet, le chef de projet a besoin

d'analyser les risques, d'estimer la charge, d'organiser le travail, de le planifier, de le suivre.
Pour cela, il doit effectuer, ou faire effectuer, un ensemble de tâches relevant de la gestion de
projet, notamment la préparation des différents plans et l’élaboration de tableaux de bord de
suivi. La distinction entre gestion et direction de projet n’est pas, à ce jour, reprise par les
autres acteurs de la normalisation.
 28

II.4. ROLES DE CHEF DE PROJET

Par définition, Le chef de projet est défini par l’AFNOR comme : « la personne
physique chargée par le maître d’œuvre, dans le cadre d’une mission définie, d’assurer 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 ». Cette définition est insuffisante pour les projets système
d’information. Heureusement, la définition est élargie : « Souvent le maître d’ouvrage
identifie, en son sein, un interlocuteur au chef de projet du maître
d’œuvre. Cet interlocuteur est aussi appelé chef de projet »12.

Le chef de projet doit faire en sorte que le projet réussisse. Pour cela, sa
responsabilité est multiple : il a la charge d’une bonne gestion du groupe et des
individus ; il pilote la production des livrables pour un achèvement en temps et en heure
; il participe à la gestion du changement, en particulier auprès des acteurs clés du projet ; il
lui revient enfin de veiller à ce que les processus de décision ne soient pas bloqués. Un chef de
projet doit au préalable développé les éléments suivants :

▪ les styles de management (conduite) d’équipe et leur adéquation ou

inadéquation à différentes situations pour atteindre les objectifs du projet;
▪ la motivation des membres de l’équipe ;
▪ la gestion des conflits à l’extérieur du groupe de projet.

▪ Il est responsable du groupe - D’un ensemble d’individus, il doit constituer une

équipe, l’animer et en maintenir la cohésion. L’équipe prend corps lorsque l’objectif
(le projet) devient collectif. Pour obtenir cette adhésion et cette synergie, il faut que
chacun soit responsable en propre d’une partie du travail ; il faut favoriser les
échanges latéraux grâce notamment à des points réguliers de coordination. L’esprit
de groupe se construit par des échanges directs d’individu à individu sur un but
commun. C’est pourquoi il est souhaitable que la taille de l’équipe reste limitée.
Au-delà de quinze à vingt personnes, le sentiment d’appartenance se dilue.

12 AFITEP, 2000
 29

▪ Le chef de projet est responsable des individus membres de l’équipe, qu’il doit
valoriser et soutenir. Ce domaine est l’un de ceux où, par chance, le travail est
souvent un moyen de se réaliser. Or, la satisfaction qu’un acteur retire de son
activité sur le projet est le plus puissant des moteurs. Chercher à ce que chacun se
sente gratifié par le travail accompli est une excellente approche managériale.

▪ Le chef de projet doit prendre en compte les souhaits des individus et

l’enrichissement apporté, lorsqu’il attribue les tâches. L’estimation de la charge
affectée doit être négociée avec celui qui va accomplir la tâche correspondante. S’il
y avait désaccord dès le départ, le risque serait grand de dépasser le délai.
L’avancement doit être suivi de près, pour ne pas laisser l’un ou l’autre piétiner. En
cas de difficulté, le dialogue est indispensable. Un retard sur une tâche peut être dû
à une cause exogène (panne de la machine de développement) ou
organisationnelle (demande de fonctionnalité supplémentaire), qui est du ressort du
chef de projet.

▪ Le chef de projet est également responsable de l’avancement des travaux et doit

convaincre l’équipe de la nécessité d’un suivi adéquat. Le système
d’information projet est indispensable à la réussite : il faut que les chiffres de base
soient le plus juste possible. Pour cela, le chef de projet doit utiliser avec
perspicacité les chiffres issus du bilan individuel. Les informations du compte rendu
d’avancement doivent être traitées immédiatement.

▪ Le chef de projet est un acteur du changement parmi les utilisateurs - Il doit pour
cela organiser une participation adaptée afin de créer un noyau qui portera le
changement. Si aucune dynamique n’a été déclenchée parmi les utilisateurs, la mise
en œuvre risque d’être difficile et le succès du projet compromis. Il appartient au
chef de projet de repérer et d’associer au projet certains utilisateurs convaincus de
son utilité et qui s’en feront les précurseurs.

▪ Le chef de projet est, à certains égards, le pilote des décisions touchant au

contenu du projet. Toute décision à prendre, si elle n’est pas prise immédiatement,
doit lui être signalée. Toutes celles qui sont en suspens doivent figurer sur son tableau
de bord, pour qu’il en suive le traitement. Il doit parfois aider à choisir en apportant
un éclairage aux décideurs ou en proposant des solutions flexibles si un choix
définitif ne peut être fait.
 30

II.5. L’ADMINISTRATION DU CYCLE DE PROJETS INFORMATIQUES

Du moment où le projet a un début et une fin, cette notion conduit à la notion de cycle
de projet. Ce cycle peut se résumer dans le schéma suivant :

1. La programmation : Le processus de programmation est l’issus d’un document global

stratégique pour un pays donné. Ce document détermine les différentes perceptions,
profils et diagnostic sur l’ensemble d’un pays et il doit être en accord avec la législation
de ce dernier pour l’exécution d’un projet informatique.

2. L’Identification : C’est une phase clé dans laquelle les analyses suivantes sont
faites pour garantir la pertinence et la faisabilité d’une idée de projet:

▪ Analyse du contexte politique et de programmation ;

▪ Analyse des parties prenantes, y compris l’analyse de la capacité
institutionnelle ;
▪ Analyse des problèmes, y compris la prise en compte des questions
transversales (genre, gouvernance, environnement,…) ;
▪ Appréciation d’autres initiatives similaires en cours et prévus, et des
enseignements tirés du passé ;
▪ Analyse préliminaires des objectifs et des stratégies;
▪ Une première appréciation des implications au niveau des moyens et des coûts;
▪ Une première analyse des dispositifs de mise en œuvre, coordination et
financement;
▪ Analyse préliminaire de la viabilité économique, financière, environnementale,
technique et sociale.
 31

3. La Faisabilité : cette phase, il est question de voir si le projet répond aux besoins
prioritaires (pertinence), le projet a été bien conçu et apporte des avantages tangibles et
durables aux groupes cibles, la formulation du projet est bien gérée (bonne gestion) …
Cette étape a deux objectifs principaux :

▪ Démontrer, à l’institution qui va mener le projet, que celui-ci est faisable,

viable et rentable;
▪ Servir de document de référence à toute requête de financement adressée à des
bailleurs de fonds externes.
En outre dans

4. Le Financement : Le financement a comme objectifs de permettre l’appréciation du

projet par l’organisme de financement et la négociation avec l’organisme de
financement avant la passation d’accord de financement, quel qu’en soit le statut:
subvention, prêts, apport en nature. Voici les étapes clés dans la phase de financement :

▪ Introduction de la demande de financement par le l’organisme promoteur du

projet s’appuyant sur l’étude de faisabilité ;
▪ Appréciation de la demande par le bailleur de fonds (comprenant souvent une
mission d’appréciation sur le terrain) ;
▪ Négociation technique portant sur le contenu technique du projet ;
▪ Négociation portant sur les aspects financiers du projet: montant de la
participation, termes et conditions (taux d’intérêts, durée de remboursement) et sur les
conditions de financement (procédure d’exécution, …) ;
▪ Signature de la convention de financement.

5. La mise en œuvre : La mise en œuvre a comme objectif de permettre au projet de

produire les résultats, atteindre les buts et contribuer efficacement aux objectifs
globaux du projet, gérer les ressources disponibles de façon efficiente, suivre le
déroulement et en faire les comptes-rendus. Les principales phases de mise en œuvre
du projet sont :

▪ Le démarrage : cette phase regroupe les éléments ci-après : les différentes

terminaisons des conventions, la mobilisation des ressources, la définition des
conditions et relations du travail, l’aménagement du démarrage, les auditions et
révisions du schéma du projet et l’établissement des systèmes d’évaluation et de
contrôle (M&E).
 32

▪ La mise en œuvre proprement dite : celle-ci regroupe fréquemment les éléments

suivants : la mise en place des ressources, la mise en œuvre des activités et
obtention des résultats, le suivi et le contrôle de l’état de l’avancement du
projet, la révision des plans opérationnels, et les rapports sur l’état de
l’avancement du projet.

▪ La phase finale : celle-ci regroupe autant graduellement les éléments suivants : les
différents transferts de toutes les responsabilités aux collaborateurs régionaux, la
vérification de la mise en place des plans d’entretien, la vérification du transfert
réel des compétences indispensables, la vérification de la couverture des dépenses
récurrentes.

6. L’évaluation : L’évaluation a pour but d’effectuer une appréciation, aussi

systématique et objective que possible, d’un projet, d’un programme ou d’une
politique, en cours ou achevé, de sa conception, de sa mise en œuvre et de ses
résultats. Elle se fixe à trois types de résultats :

▪ La réalisation physique du projet : voir si le projet est en train d’être exécuté

physiquement ;
▪ L’évaluation des effets : vise à estimer dans quelle mesure les actions du projet ont eu
les effets visés ;
▪ L’évaluation des impacts : mesure les améliorations des conditions de vie que les
effets du projet ont pu entraîner.

Une bonne évaluation dans un projet informatique requiert Les principes ci-après :

▪ L’Impartialité et indépendance, du processus d’évaluation par rapport aux

fonctions de programmation et de mise en œuvre ;

▪ La Crédibilité, de l’évaluation, grâce à l’intervention d’experts indépendants et

compétents et à la transparence du processus ;

▪ La Participation, des parties prenantes au processus d’évaluation, afin de

garantir que les différents aspects et points de vue soient pris en compte ;

▪ L’Utilité, des observations et recommandations de l’évaluation, grâce à la

fourniture en temps utile aux décideurs d’une information pertinente, claire et
concise.
 33

TROISIEME CHAPITRE - LE DECOUPAGE D’UN PROJET ET LES MODELES DE

CYCLE DE VIE

III.1. DEFINITION ET CONTEXTE D’ETUDES

Par définition, la dynamique du processus du développement de projets

informatiques peut être considérée comme étant une démarche de l’évolution a l’intérieur
d’une structure en développement.

Compte tenu de son unicité, tout projet est soumis à incertitude, car des événements
imprévisibles ou non prévus peuvent survenir et entraver son déroulement. C’est pourquoi les
méthodes et normes recommandent de découper le processus projet en « phases13 ». Les
phases sont ordonnées dans le temps, selon la logique de construction du produit. Ce
découpage introduit un jalonnement du projet, qui permet au commanditaire du projet de
valider progressivement les livrables et d’orienter le projet. Il favorise une maîtrise accrue
du projet. L’ensemble des phases du projet est
appelé « cycle de vie » du projet. Le cycle de vie est unique pour chaque projet, mais il existe
selon les domaines d’application des cycles de vie génériques qui guident le découpage
du projet en phases. En informatique, on les appelle souvent des modèles de
développement.

III.2. DECOUPAGE DE PROJETS INFORMATIQUES

L’AFNOR a proposé un découpage type classique des projets informatiques
(NF Z67-101, 1984) en cinq phases : Étude préalable, Conception détaillée, Etude technique,
Réalisation, Mise en œuvre et Évaluation.

13Une phase est un regroupement de tâches conduisant à un produit livrable principal et

d’éventuels produits livrables secondaires.
 34

▪ L’étude préalable - L’objectif d’une étude préalable est double. D’une part, il s’agit
de faire des choix structurants pour la future application : évaluer l’adéquation de la
solution aux objectifs, choisir éventuellement entre plusieurs solutions, évaluer
l’investissement (budget, temps), ajuster la solution à l’enveloppe si cela est nécessaire.
D’autre part, il s’agit de fournir une base de référence pour la suite du projet : le
rapport d’étude préalable peut donc être considéré comme un cahier des charges pour
l’étude détaillée. Une étude préalable comporte trois étapes : observation, conception-
organisation et appréciation :

➢ L’objectif de l’étape observation est de donner une représentation pertinente du

domaine étudié, suffisante pour porter un diagnostic et mettre en évidence des
besoins. Le résultat comprend :

→ une structuration du domaine en processus, qui va ensuite guider un éventuel

découpage structurel, pour établir un WBS par exemple ;
→ le choix d’un sous-ensemble représentatif (SER) : en effet, si le domaine est
important, on va se limiter à une partie du domaine, en utilisant la notion de
variante de procédure ;
→ une description du fonctionnement du SER ;
→ une description modélisée des données ;
→ un diagnostic.

➢ L’objectif de l’étape conception-organisation est de proposer une ou plusieurs

solutions, aux niveaux conceptuel et organisationnel, sur tout ou partie du
domaine. Le résultat comprend un modèle de données consolidé ou enrichi, ainsi
qu’une description d’au moins une variante de chaque processus, avec les traitements
et les règles de gestion.

➢ L’objectif de l’étape appréciation est d’une part de dresser un bilan des

avantages attendus et des coûts prévisibles (étude de rentabilité), d’autre part
d’élaborer un plan pour la poursuite du projet. On peut ainsi identifier différents
sous projets qu’il faut ordonnancer. Le découpage en sous-projets repose sur un
découpage structurel ; par exemple, on peut définir un sous- projet par processus.
L’ordonnancement se fait selon :

→ une éventuelle priorité stratégique de certains processus ;

→ la périodicité (traitements quotidiens, puis mensuels, puis annuels) ;
→ les contraintes logistiques (arrivée d’un matériel, mise en place d’un
réseau).
 35

▪ La conception détaillée - L’objectif d’une étude détaillée est de concevoir et décrire

de façon exhaustive la solution sur tout le champ de l’étude. Elle sera ensuite
complétée par l’étude technique. Les spécifications ainsi obtenues doivent faire l’objet
d’un consensus entre futurs utilisateurs et informaticiens. Elles représentent le cahier
des charges pour la réalisation. Le résultat comprend toute la vision externe du système :
l’interface homme-machine (maquettes d’écran, cinématique), la description des
traitements à une maille suffisamment fine pour qu’il n’y ait plus d’ambiguïté
fonctionnelle, ainsi que les sorties (maquettes d’état). On y ajoute souvent l’organisation à
mettre en place et le planning détaillé.

▪ Les études techniques - L’objectif de cette phase, qui ne concerne que les
informaticiens, est d’optimiser les structures physiques de données et de construire les
traitements (dossier programmes) en essayant de préparer la réutilisation du code. Le
résultat comprend des normes techniques, des dossiers de programme et la structure
physique des données. Il complète le cahier des charges de réalisation.

▪ La réalisation - Cette phase est parfois appelée « développement ». L’objectif est de

produire un logiciel testé. Elle comprend donc des tâches d’élaboration de jeu d’essai,
de programmation et de test. Elle se termine par une procédure d’acceptation
officielle est appelée recette : le client fournit un jeu d’essai et vérifie avec le fournisseur
la conformité du logiciel à ce qu’il avait demandé. Dans la pratique, la recette fait
souvent une étape séparée. On effectue parfois une recette provisoire après la réalisation
et une recette définitive après la mise en œuvre. Dans une relation contractuelle donnant
lieu à des flux financiers, la recette conditionne le paiement.

▪ La mise en œuvre - L’objectif est de préparer le démarrage effectif de la nouvelle

application. Cette phase comprend notamment le paramétrage, la reprise ou
l’alimentation des données, le développement d’interfaces, la formation des utilisateurs,
l’installation d’environnement d’exploitation. La gestion du changement décrite au
chapitre 5 relève de la mise en œuvre, qui souvent commence dès la fin de l’étude
détaillée.

▪ L’évaluation (qualification) - L’objectif est de réaliser des tests dans l’environnement

opérationnel et de tirer un bilan du système d’information installé, selon différents
critères qualité. Ces derniers sont présentés au chapitre 8 qui regroupe tous les
aspects de la qualité.
 36

III.3. LES MODELES DE DEVELOPPEMENT

Il s’avère de nos jours, que nous ne pouvons plus avoir une démarche unique dans
le développement de projets informatiques, mais qu’il faut construire le découpage
temporel en fonction des caractéristiques de l’entreprise et du projet. On s’appuie pour
cela sur des découpages temporels génériques, appelés modèles de développement
(process models) ou modèles de cycle de vie d’un projet informatique. Les principaux
modèles sont :
▪ le modèle du code-and-fix ;
▪ le modèle de la transformation automatique ;
▪ le modèle de la cascade ;
▪ le modèle en V ;
▪ le modèle en W ;
▪ le modèle de développement évolutif ;
▪ le modèle de la spirale.

III.3.1. LE MODELE DU CODE-AND-FIX

C’est un modèle qui repose sur la possibilité d’une détermination facile des
besoins : une première phase de Compréhension du problème est suivie d’une phase de
Programmation ; puis une phase de Mise au point, parfois en collaboration avec
l'utilisateur du futur système, est répétée jusqu’à l’atteinte du résultat visé.

Le modèle du code-and-fix.
 37

III.3.2. LE MODELE DE TRANSFORMATION AUTOMATIQUE

C’est un modèle basé sur la possibilité de transformer automatiquement des
spécifications en programmes. L’essentiel de l’effort va donc porter sur une description
exhaustive des spécifications qui devront être complètement validées. Une succession de
cycles Phase de Spécifications – Phase de Validation s’achève par la phase de
Transformation, où s’effectue la génération du code.

Le modèle de la transformation automatique

III.3.3. LE MODELE DE LA CASCADE

C’est un modèle qui a comme objectif majeur de jalonner (présenter sobrement)

rigoureusement le processus de développement et de définir de façon précise les rôles
respectifs du fournisseur qui produit un livrable et du client qui accepte ou refuse le
résultat. Le découpage temporel se présente comme une succession de phases affinant
celles du découpage classique : Étude de faisabilité, Définition des besoins, Conception
générale, Conception détaillée, Programmation, Intégration, Mise en œuvre. Chaque phase
donne lieu à une validation officielle. Si le résultat du contrôle n’est pas satisfaisant, on
modifie le livrable. En revanche, il n’y a pas de retour possible sur les options validées à
l’issue de phases antérieures.
 38

III.3.4. LE MODELE EN V
Le modèle en V est une amélioration du modèle de la cascade, qui vise à
réduire ce que l’on a appelé l’ « effet tunnel » : après la conception détaillée, le
commanditaire du projet n’a plus de visibilité sur le projet, car les phases suivantes
relèvent d’une validation technique. Ce n’est qu’au terme de la mise en œuvre que le projet
ressort du tunnel. Or, les livrables ne sont pas toujours ceux attendus, non pas qu’ils ne
soient pas conformes aux spécifications, mais parce celles-ci sont parfois impuissantes à
décrire les attentes et la seule validation de documents est insuffisante. Le modèle en V
propose de mettre en regard les phases de conception des phases de test. Dans chacune des
phases de la première branche du V, on explicite les critères d’appréciation et d’acceptation
du système aux étapes correspondantes de la deuxième branche du V. Ainsi, l’étude
détaillée produira un jeu d’essai qui sera utilisé pour effectuer la recette fonctionnelle.
L’installation sur un site pilote permettra de valider la définition fonctionnelle du besoin,
d’après les critères exprimés dans cette étape. Le bilan global du projet vérifiera que les
objectifs initiaux formulés dans l’étude d’opportunité ont bien été atteints.

Le modèle en V
 39

III.3.5. LE MODELE EN W

C’est un modèle qui enrichit le modèle en V dans le même esprit d’anticipation sur le
livrable final. La première partie du W vise à dégager avec les clients des orientations
pour la conception ou bien à explorer les possibilités d’une nouvelle technique. Le
développement de maquettes ou prototypes permet une validation plus concrète des besoins,
voire une expérimentation.

Le modèle en W

III.3.6. LE MODEL EVOLUTIF

Ce modèle est aussi appelé « modèle de développement itératif ». L’objectif de ce

modèle est de construire progressivement le système de façon participative. Il repose sur
l’idée que les besoins ne peuvent s’exprimer qu’après une expérimentation, même sur un
système rudimentaire ou incomplet. Dans ce modèle, chaque cycle est composé de trois
phases : « Détermination des besoins – Programmation - Expérimentation », aboutit à
une nouvelle version du système : le projet s’arrête lorsque le commanditaire juge le
système satisfaisant.
 40

Le modèle évolutif

III.3.6. LE MODEL EN SPIRALE

Ce modèle repose sur le même principe que le modèle évolutif, mais il s’inscrit dans
une relation contractuelle entre le client et le fournisseur. De ce fait les engagements et
validations présentent un caractère formalisé. Chaque cycle donne lieu à une
contractualisation préalable, s’appuyant sur les besoins exprimés lors du cycle précédent.
Un cycle comporte six phases :

▪ Analyse du risque ;
▪ Développement d'un prototype (modèle, archétype…) ;
▪ Simulation et essais du prototype ;
▪ Détermination des besoins à partir des résultats des essais ;
▪ Validation des besoins par un comité de pilotage ;
▪ Planification du cycle suivant.

Le modèle en spirale
Le dernier cycle permet de développer la version finale et d'implémenter le logiciel.
 41

III.4. LA GESTION D’UNE PHASE D’UN PROJET

INFORMATIQUE

D’après les normes (ISO10006, PMBOK), les activités de gestion de projet sont
organisées comme des processus (ensembles coordonnés d’activités aboutissant à un
résultat), classés en différents groupes, selon l’objectif : démarrage, planification,
réalisation, contrôle et clôture. Pour le PMI, chaque phase fait l’objet d’une gestion
complète qui met en œuvre les processus des cinq catégories à savoir :

Organisation de la gestion d’une phase

1. Les processus de démarrage : ils ont pour but de lancer officiellement le démarrage du
projet ou l’une de ses phases. Il s’agit de repérer certaines contraintes particulières
(financières, humaines, temporelles, techniques…) et d’arrêter une stratégie générale
de conduite de la phase. Lorsqu’il s’agit de la première phase du projet, le processus de
démarrage comprend la désignation officielle du chef de projet.
2. Les processus de planification : ils visent à définir et à planifier de façon précise le
travail à réaliser. Ils incluent une estimation des charges et une recherche de
ressources, et ils conduisent notamment à la production d’un calendrier de travail, avec
une répartition des tâches.
3. Les processus de réalisation : ils assurent la coordination du personnel et des autres
ressources dans la réalisation du travail planifié. Ils assurent un suivi du travail
réalisé et centralisent d’éventuelles demandes de changement par rapport à ce qui avait
été planifié.
4. Les processus de contrôle : ils sont mis en œuvre périodiquement. Ils comprennent la
mesure de l’avancement du projet par rapport à sa planification, la prise de mesures
correctives et le traitement des demandes de changement. Ils organisent également
l’acceptation officielle des livrables par le client. Une activité de contrôle peut ainsi
conduire à revoir la planification ou déboucher sur la clôture de la phase.
5. Les processus de clôture : ils ont pour but d’officialiser l’achèvement d’une
phase. Il est recommandé de formaliser l’expérience acquise sur la phase ou sur le projet.
 42

III.5. LA CAPITALISATION DE L’EXPERIENCE D’UN

PROJET INFORMATIQUE

L’expérience joue un rôle important dans la construction des connaissances sur la

gestion des projets informatiques. On observe un intérêt croissant pour leur gestion à un
niveau collectif. Un dispositif pour capitaliser les expériences autour des projets système
d'information relève à la fois d’une mémoire de projet et d’une mémoire d'entreprise14.
Les connaissances en jeu dans la gestion de projet ont trois sources :

1. L'explicitation : dans des ouvrages, dans des supports internes à l'entreprise, au

travers une formation, par des échanges entre individus d'un ensemble de savoirs
partageables par une communauté.
2. La capture des événements et activités lors du déroulement d'un projet.

3. L'engagement personnel d'un individu (en général le chef de projet) dans un projet
et sa perception du déroulement et contexte du projet.

Structuration des connaissances projet

14 Voir par exemple : DIENG-KUNTZ R., CORBY O., GANDON F., GIBOIN A.,
GOLEBIOWSKA J., MATTA N., RIBIERE M. (2001) Méthodes et outils pour la gestion des
connaissances. Une approche pluridisciplinaire du Knowledge Management, Dunod
 43

Cela conduit à distinguer trois grands ensembles de connaissances : des

connaissances de type référentiel, des connaissances de type trace et des connaissances de
type interprétation. Les premières ont un champ plus large que le projet, les deux autres
sont liées à un projet précis. Les trois ensembles de connaissances doivent être articulées.
Les connaissances de type trace servent en partie à alimenter ou faire évoluer les
connaissances de type référentiel, en général éclairées par les connaissances de type
interprétation. À l'inverse, des connaissances de type référentiel peuvent parfois être
illustrées par des connaissances de type trace, c’est-à- dire concrétisées dans des projets réels.

La capitalisation de l’expérience d’un projet informatique interprète 9 propriétés

de connaissance pour sa bonne gestion :

▪ Intégration : Développer la charte du projet, la formulation du périmètre et du Plan.

Diriger, Gérer, Suivre, Contrôler et Piloter les changements

▪ Contenu : Planification, Définition, Structure de Décomposition du Travail

(WBS), Création, Vérification et Contrôle.
▪ Délais : Définition, Ordonnancement, Estimation de la Durée des tâches et des
Ressources, Développement et Contrôle de la Planification.

▪ Coût : Planification des Ressources, Estimation des Coûts, Budgétisation et

Contrôle.

▪ Qualité : Planification de la Qualité, Assurance Qualité et Contrôle Qualité.

▪ Ressources Humaines : Planification des RH, Recrutement, Développement et
Gestion de l'équipe projet.

▪ Communications : Plan de Communications, Diffusion de l'information, Rapport

d'Activité et de Performance, Gestion des Partenaires.
▪ Risques : Prévision et identification des Risques, Analyse des Risques (méthodes
qualitative et quantitative), Prévision des Actions Correctrices Surveillance et
Contrôle des Risques.

▪ Approvisionnement : Plan d'Acquisition et de Contractualisation, Réponses et Choix

des Soumissionnaires, Administration et clôture des Pour chaque processus,
activité, ou pratique est réalisé une description des produits en entrée, des outils
et techniques ainsi que des produits.
 44

III.6. LES PRINCIPALES MODIFICATIONS DE CONDUITE DE PROJETS

INFORMATIQUES

Un projet se conduit en s’appuyant sur une démarche qui oscille (tergiverse ou

hésite) régulièrement entre une approche globale située dans le sens, les objectifs et une
approche analytique qui met l’accent sur la simplification afin de maîtriser tous les
paramètres. Cependant, comme le simplifié peut conduire à une représentation trop
réductrice du projet et donc à un résultat de mauvaise qualité, il faut absolument fonder
la démarche sur des méthodes éprouvées. Certains domaines utilisent des méthodes (ex.
: Merise pour l’informatique), des processus particuliers (ex. : la conduite d’opération pour
s’inscrire et respecter le cadre réglementaire, la programmation, les acteurs, les lots …).

Un projet se conduit en enchaînant des séquences, c’est un processus qui s’appuie sur
un découpage en étapes, chacune se concluant par une production, un résultat livrable
permettant au donneur d’ordre (DO) de : décider de poursuivre ou non
; et vérifier l’adéquation entre les prévisions et les investissements. Deux formes de
découpage sont particulièrement connues et utilisées : celle de l’AFNOR qui retient quatre
parties : Identification, Etude, Réalisation et Evaluation et celle dite des « 3C » : cadrage,
conduite, conclusion. C’est cette dernière que nous avons retenu pour sa simplicité
d’utilisation :

1. le cadrage : c’est l’étape qui permet de définir les objectifs du projet, sa pertinence par
rapport aux objectifs du service, ses composantes techniques, la qualité attendue, son
coût et les délais. Le cadrage comporte trois phases :

▪ la clarification de l’idée de départ et de l’intention : Il s’agit là, de s’assurer de son

intérêt, de son opportunité au regard des objectifs de service. A ce niveau le DO, après
avoir validé ce document, peut rédiger la lettre de mission au chef de projet.
 45

▪ L’étude de faisabilité : on fait d’abord l’Analyse fonctionnelle15 qui détermine la

démarche utile pour des projets de grande envergure, l’analyse fonctionnelle a pour
but de définir plus précisément l’usage du produit, son fonctionnement et la
motivation des utilisateurs. A cette fin, les éléments suivants seront déterminés,
analysés, hiérarchisés :

→ les fonctions de service. Elles expriment le besoin éprouvé par le demandeur.

Elles peuvent être décomposées en fonction d’un niveau inférieur en répondant
à la question comment ?
→ les contraintes (limites imposées au concepteur) ;
→ l’aptitude du produit à satisfaire le client. Elle est évaluée par des indicateurs
portant soit sur la fonction d’usage (nature objective) soit sur la fonction d’estime
(nature subjective).

Apres l’analyse fonctionnelle, c’est La recherche de plusieurs solutions (ou

scénarios) : Jusqu’ici, le produit ou service, objet du projet, a été considéré dans sa
globalité. Pour de gros projets, il peut devenir indispensable de réaliser un autre
découpage du projet en sous-projets plus opérationnels. Les critères de ce découpage
peuvent porter sur :

➢ les fonctionnalités du produit ;

➢ des sous-parties physiques ;
➢ des spécificités techniques ;
➢ les lieux de réalisation …

Un chef de projet est alors nommé pour chaque sous-projet et la démarche

reprend pour chacun au niveau de l’étude de faisabilité. La définition des scénarios doit
comporter pour chacun l’analyse de leurs avantages et de leurs inconvénients,
l’estimation des coûts et des délais. Dans un premier temps, la démarche s’appuie
essentiellement sur des méthodes de créativité sans se préoccuper des risques, des
contraintes : quelles sont toutes les pistes envisageables ?, Les contraintes sont prises en
compte ensuite :

➢ Le risque résulte-t-il du fait que le produit est nouveau, et/ou que le marché est
nouveau et/ou que la technologie est nouvelle ?
➢ Quel est le meilleur plan ?
➢ Existe-t-il une (des) solutions de repli ?
➢ Quels sont les individus concernés (poseur, porteur, verrou, décideur, acheteur,
payeur, ressource, voisin) ?

15 A ce niveau, on produira un Cahier des Charges Fonctionnel (CdCF) dont la partie

principale est
l’énoncé fonctionnel du besoin. Ce document permet de contractualiser une logique de résultat.
 46

16
Cette analyse permet au DO (Donneur d’ordre) de retenir la meilleure solution et
de s’assurer de la faisabilité du projet. La nature du projet, son importance notamment au
regard des objectifs du service permettront de définir des critères de choix qui seront alors
orientés vers l’efficience et/ou la pertinence et/ou la cohérence.

▪ L’étude détaillée17 : Cette phase vise à définir comment et par qui sera réalisé le
projet. Elle décrit :les solutions techniques ;les contraintes ;la planification ;les
moyens et les outils de suivi et de contrôle ;les rôles et les responsabilités des
différents acteurs. La communication à réaliser autour du projet doit être définie à ce
stade. Elle détaillera :

→ la finalité, les buts de l’action de communication : (partager les objectifs du

projet ; construire une représentation partagée ; arriver à un accord, un consensus sur
les différentes composantes du projet (méthodes, moyens, planning, rôles …).

→ une stratégie18 : (l’identification de chaque récepteur (ou cible19) et de ses attentes ;

l’adaptation du fond, de la forme des informations en fonction des cibles ; le choix du
média ; une planification adaptée aux phases du projet).

Enfin, deux autres axes sont étudiés ici :

→ la maintenance Elle peut mobiliser d’importantes ressources (hommes, matériel,

budget) ; et
→ le fonctionnement en terme de coût nécessite de prévoir la durée du produit.

2. La conduite : Le chef de projet constitue l’équipe projet. Jusqu’à cette étape, il a

avancé dans son projet soit en s’appuyant sur des groupes de travail spécifique, soit seul.
Les membres de cette équipe projet sont sollicités pour leurs compétences, leur
motivation, l’entente … Le chef de projet propose pour accord la liste des membres
de cette équipe au DO. La réussite de cette étape repose sur trois voies d’action :
▪ la gestion et l’organisation des ressources : L’objectif que vise la gestion d’un projet
est d’en suivre, d’en contrôler les coûts, les délais, et l’atteinte des objectifs partiels. Ces
critères sont détaillés dans le plan d’action grâce à un découpage du planning (cf. étude
détaillée) en tâches, à l’affectation des ressources, à la définition d’indicateurs et de
jalons.

16 Avant le Projet Sommaire, nous avons répondu à deux questions : Quel est le but de
ce projet ? Et Que réalise-t-on exactement ?
17 C’est la production du planning pour la conduite du projet
18 C’est la phase qui prépare le plan de la communication
19 Selon la cible, elle est opérationnelle, informative, promotionnelle.
 47

▪ La mise en œuvre du plan de communication : Le plan de communication est un

facteur clé de succès essentiel à la réussite du projet car il accompagne le changement
induit par tout projet ; et il permet à chacun de se situer au regard des actions, des délais.
La compréhension et l’adhésion au projet motivent et facilitent l’investissement en terme
d’énergie et le projet devient un catalyseur d’échanges entre emplois, entre services. La
diffusion de tableaux de bord, des CR, des plannings constituent un très bon vecteur
d’information.

▪ Le management de l’équipe : Le chef de projet veille à entretenir la motivation,

l’entente entre les membres de l’équipe ; et les compétences du collectif. Pour cela, il
doit veiller à ce que :

→ la direction s’engage et démontre cet engagement ;

→ l’organisation dégage les moyens de fonctionnement, permette des délégations
importantes ;
→ la culture puisse intégrer un mode de fonctionnement matriciel, une régulation
basée sur l’ajustement mutuel ;
→ son management soit cohérent avec le mode projet (donner des objectifs clairs et les
faire partager, les évaluations sont collectives, les responsabilités partagées, les
rôles et les procédures sont négociées …)

3. La conclusion : La livraison s’accompagne d’une évaluation qui porte sur la

qualité, les coûts, les délais. Les indicateurs de coût et de délais ont été utilisés pour
l’évaluation chemin faisant. En ce qui concerne les indicateurs de la qualité, ils ont été
déterminés soit, parce que l’analyse fonctionnelle a été réalisée, soit pendant la pendant
l’étude détaillée.

Le bilan final du projet doit être communiqué largement afin de porter à la

connaissance de tous les agents du service le succès de l’action, de montrer le travail
réalisé par les membres actifs du projet, de contribuer au changement culturel. Une
capitalisation de l’expérience peut s’avérer utile pour les futurs projets. En effet, d’une
part, elle met à la disposition des autres agents une source d’informations utiles et,
d’autre part, cet exercice impose à l’auteur de réaliser une analyse basée sur une
réflexion et une prise de recul. L’archivage du projet doit être effectué car il constitue
la mémoire de ce dossier, source qui peut s’avérer indispensable en cas de litige.
 48

III.7. LES OUTILS DE GESTION DE PROJETS INFORMATIQUES

Les outils de gestion de projets sont les éléments actifs (voies, moyens ou
instruments) qui permettent d’organiser, de piloter, de développer et de régir une
activité déterminée d’un projet. Dans le cadre de ce cours, il ne sera question que de deux
(2) grandes catégories d’outils de gestion de projets informatiques :

▪ Les méthodes de développement ;

▪ Les techniques de gestion.

1. LES METHODES DE DEVELOPPEMENT

Une méthode définit une démarche en vue de produire des résultats. Par exemple, les
cuisiniers utilisent des recettes de cuisine, les pilotes déroulent des check- lists avant de
décoller, les architectes font des plans avant de superviser des chantiers. Une méthode permet
d’assister une ou plusieurs étapes du cycle de vie du logiciel. Les méthodes d’analyse et de
conception fournissent des notations standards et des conseils pratiques qui permettent
d’aboutir à des conceptions « raisonnables », mais nous ferons toujours appel à la créativité
du concepteur. Il existe différentes manières pour classer ces méthodes, dont :

▪ La distinction compositionnelle / décompositionnelle : met en opposition d’une part

les méthodes ascendantes qui consistent à construire un logiciel par composition à
partir de modules existants et, d’autre part, les méthodes descendantes qui
décomposent récursivement le système jusqu’à arriver à des modules programmables
« simplement ».

▪ la distinction fonctionnel / orientée objet : Dans la stratégie fonctionnelle un

système est vu comme un ensemble d’unités en interaction, ayant chacune une
fonction clairement définie. Les fonctions disposent d’un état local, mais le système a
un état partagé, qui est centralisé et accessible par l’ensemble des fonctions. Les
stratégies orientées objet considèrent qu’un système est un ensemble d’objets
interagissant. Chaque objet dispose d’un ensemble d’attributs décrivant son état et
l’état du système est décrit (de façon décentralisé) par l’état de l’ensemble. La
décomposition fonctionnelle du haut vers le bas a été largement utilisée aussi bien
dans de petits projets que dans de très grands, et dans divers domaines d’application.
La méthode orientée objet a eu un développement plus récent. Elle encourage la
production de systèmes divisés en composants indépendants, en interaction.
 49

Dans le cadre de cours, nous distinguerons alors quatre (4) types des méthodes à
savoir :

▪ les méthodes fonctionnelles, basées sur les fonctionnalités du logiciel ;

▪ les méthodes objet, basées sur différents modèles (statiques, dynamiques et
fonctionnels) de développement logiciel.
▪ Les méthodes adaptatives ou Agiles, basées sur le changement des besoins ;
▪ Les méthodes spécifiques, basées sur les découpages temporels particuliers.

1.1. LES METHODES FONCTIONNELLES

Les méthodes fonctionnelles ont pour origine la programmation structurée. Cette

approche consiste à décomposer une fonctionnalité (ou fonction) du logiciel en plusieurs
sous fonctions plus simples. Il s’agit d’une conception « top-down », basée sur le principe «
diviser pour mieux régner». L’architecture du système est le reflet de cette décomposition
fonctionnelle. La programmation peut ensuite être réalisée soit à partir des fonctions de
haut niveau (développement « top-down »), soit à partir des fonctions de bas niveau
(développement « bottom-up »).

Schéma de la décomposition fonctionnelle

 50

Cette méthode présente comme les inconvénients suivants :

▪ L’architecture étant basée sur la décomposition fonctionnelle, une évolution

fonctionnelle peut remettre en cause l’architecture. Cette méthode supporte donc
mal l’évolution des besoins.

▪ Cette méthode ne favorise pas la réutilisation de composants, car les composants

de bas niveau sont souvent ad hoc et donc peu réutilisables.

1.2. LES METHODES OBJET

Les approches objet sont basées sur une modélisation du domaine d’application. Les «
objets »sont une abstraction des entités du monde réel. De façon générale, la modélisation
permet de réduire la complexité et de communiquer avec les utilisateurs. Plus précisément un
modèle :

▪ Aide à visualiser un système tel qu’il est ou tel qu’on le souhaite ;

▪ Permet de spécifier la structure ou le comportement d’un système ;
▪ Fournit un guide pour la construction du système ;
▪ Documente les décisions prises lors de la construction du système.

Ces modèles peuvent être comparés avec les plans d’un architecte : suivant la
complexité du système on a besoin de plans plus ou moins précis. Pour construire une niche,
on n’a pas besoin de plans, pour construire un chalet il faut un plan, pour construire un
immeuble, on a besoin d’un ensemble de vues (plans au sol, perspectives, maquettes).
Dans les méthodes objet, on distingue trois aspects :

▪ Un aspect statique : Dans lequel, on identifie les objets, leurs propriétés et leurs
relations ;
▪ Un aspect dynamique : Dans lequel, on décrit les comportements des objets, en
particuliers leurs états possibles et les évènements qui déclenchent les
changements d’état ;

▪ Un aspect fonctionnel : qui, à haut niveau, décrit les fonctionnalités du logiciel, ou,
a plus bas niveau, décrit les fonctions réalisées par les objets par l’intermédiaire des
méthodes.
 51

Les intérêts des approches objet sont les suivants :

▪ Les approches objet sont souvent qualifiées de « naturelles » car elles sont
basées sur le domaine d’application. Cela facilite en particulier la communication
avec les utilisateurs.

▪ Ces approches supportent mieux l’évolution des besoins que les approches
fonctionnelles car la modélisation est plus stable, et les évolutions fonctionnelles ne
remettent par l’architecture du système en cause.

▪ Les approches objet facilitent la réutilisation des composants (qui sont moins
spécifiques que lorsqu’on réalise une décomposition fonctionnelle).

1.2.1. LES METHODES ADAPTATIVES

Les méthodes dites « adaptatives » sont subdivisées en 2 parties notamment :

les méthodes prédictives et les méthodes agiles (adaptatives).

1.2.1.1. LES METHODES PREDICTIVES

Ce sont des méthodes qui correspondent à un cycle de vie du logiciel en

cascade ou en V, sont basées sur une planification très précise et très détaillée, qui a pour
but de réduire les incertitudes liées au développement du logiciel. Cette planification
rigoureuse ne permet pas d’évolutions dans les besoins des utilisateurs, qui doivent donc
être figes dès l’étape de définition des besoins.

1.2.1.2. LES METHODES AGILES

Ce sont des méthodes qui correspondent à un cycle de vie itératif, qui considèrent que
les changements (des besoins des utilisateurs, mais également de l’architecture, de la
conception, de la technologie) sont inévitables et doivent être pris en compte par les modèles
de développement. Ces méthodes privilégient la livraison de fonctionnalités utiles au client
à la production de documentation intermédiaire sans intérêt pour le client.

Ainsi, Toutes les méthodes agiles prennent en compte dans leur modèle de cycle
de vie trois exigences :

▪ Une forte participation entre développeurs et utilisateurs,

▪ Des livraisons fréquentes de logiciel et ;
▪ une prise en compte de possibles changements dans les besoins des utilisateurs au
cours du projet.
 52

C’est pourquoi toutes font appel, d’une façon ou d’une autre, à un modèle
itératif et incrémental. De plus, elles préconisent en général des durées de cycle de vie des
projets ne dépassant pas un an. Parmi les méthodes agiles, les plus usuelles ; on peut citer :

▪ La méthode RAD (Rapid Application Development) ;

▪ La méthode DSDM (Dynamic Systems Development Method);
▪ La méthode XP (Programmation eXtrême);
▪ La méthode SCRUM.

1.2.1.2.1. LA METHODE RAD

La méthode RAD, est un modèle linéaire (présentoir), structuré en cinq phases, et

dont le modèle itératif intervient à la phase Construction du logiciel en vu de la
séquencer en plusieurs modules Successivement livrés.

La participation des utilisateurs est placée au cœur du cycle. En effet, le

déroulement d’une phase comprend une ou plusieurs sous-phases, et chaque sous- phase
présente une structure à trois temps, dans laquelle la tenue d’une session participative joue un
rôle central. Des travaux préparatoires rassemblent et construisent le matériau (modèle ou
prototype) qui sera ensuite discuté par les différents acteurs et ajusté.
 53

1.2.1.2.2. LA METHODE DSDM

La méthode DSDM a évolué au cours des années. L’actuelle version distingue le

cycle de vie du système et le cycle de vie du projet. Le premier comprend, outre les phases
du projet lui-même, une phase de pré-projet qui doit conduire au lancement du projet et une
phase post-projet qui recouvre l’exploitation et la maintenance de l’application.

Le cycle de vie du projet comprend cinq phases, dont deux sont cycliques. Les
flèches pleines indiquent un déroulement normal. Les flèches en pointillé montrent des retours
possibles à une phase antérieure, soit après la phase Conception et construction, soit
après celle de Mise en œuvre.

Après une Étude de faisabilité, la phase Étude du métier permet, à travers des
ateliers (workshops) entre équipe de projet et manageurs, de définir le périmètre du projet,
avec une liste d’exigences prioritaires et une architecture fonctionnelle et technique du futur
système.

La phase Modélisation fonctionnelle est une suite de cycles. Chacun permet de

définir précisément les fonctionnalités souhaitées et leur priorité. L’acceptation par toutes
les parties prenantes d’un prototype fonctionnel, sur tout ou partie du périmètre, permet de
passer à la phase Conception et construction. L’objectif de cette phase est de développer un
logiciel testé, par des cycles successifs de développement/acceptation par les utilisateurs.
 54

1.2.1.2.3. LE MODELE XP

La méthode XP, focalisée sur la partie programmation du projet, propose un

modèle itératif avec une structure à deux niveaux : d’abord des itérations de livraison
(release), puis des itérations de développement. Les premières conduisent à livrer des
fonctionnalités complètes pour le client, les secondes portent sur des éléments plus fins
appelés scénarios qui contribuent à la définition d’une fonctionnalité.

Après une phase initiale d’Exploration des besoins, un plan de livraison est défini
avec le client. Chaque livraison, d’une durée de quelques mois, se termine par la fourniture
d’une version opérationnelle du logiciel. Une itération de livraison est découpée en
plusieurs itérations de développement de courte durée (deux semaines à un mois), chacune
donnant lieu à la livraison d’une ou plusieurs fonctionnalités pouvant être testées, voire
intégrées dans une version en cours.

De façon plus détaillée, chaque itération de développement commence par

l’écriture de cas d’utilisation ou scénarios (user stories), c’est-à-dire des fonctions
simples, concrètement décrites, avec les exigences associées, qui participent à la
définition d’une fonctionnalité plus globale. Utilisateurs et développeurs déterminent
ensemble ce qui doit être développé dans la prochaine itération. Une fonctionnalité est ainsi
découpée en plusieurs tâches. Les plans de test sont écrits, les développeurs sont répartis en
binôme ; ils codent les tâches qui leur sont affectées, puis effectuent avec les utilisateurs
des tests d’acceptation. En cas d’échec, on revoit les scénarios et on reprend la boucle.
Sinon, on continue jusqu’à avoir développé tous les scénarios retenus. Une version
livrable est alors arrêtée et mise à disposition, ainsi que la documentation.
 55

1.2.1.2.4. LA METHODE SCRUM

La méthode SCRUM emprunte au vocabulaire du jeu le qualificatif des trois

phases du cycle préconisé.

▪ La phase d’Avant-jeu (pre-game), Conception et architecture du système, se déroule de

façon structurée, en général linéaire, et permet de déterminer le périmètre, la base du
contenu du produit à développer et une analyse de haut niveau.

▪ La phase de Jeu (game) est itérative et qualifiée d’empirique, dans la mesure où le travail
effectué ne fait pas l’objet d’une planification. Une itération, dont la durée oscille entre
une et quatre semaines, est appelée un Sprint, en référence à ces poussées rapides et
fortes que les joueurs de rugby peuvent effectuer sur le terrain. Un Sprint est découpé en
trois sous-phases :

→ Développement (develop) : il s’agit de déterminer l’objectif visé au terme de

l’itération, de le répartir en « paquets » de fonctions élémentaires, de développer
et tester chaque paquet.

→ Emballage (wrap) : on referme les « paquets » et on les assemble pour faire une
version exécutable. • Revue (review) : une revue élargie permet de faire le point
sur les problèmes et l’avancement.

→ Ajustement (adjust) : ajusté le travail restant.

▪ La phase d’Après-Jeu (postgame), Clôture, vise à livrer un produit complet et

documenté. Comme dans la première phase, on peut en planifier les tâches et les
dérouler de façon linéaire.
 56

1.2.2. LES METHODES SPECIFIQUES

Certains découpages temporels sont liés soit à une méthode, soit à un type de projet
bien particulier. Nous en proposons deux exemples : le découpage préconisé pour mettre
en place un progiciel intégré et le modèle RUP proposé par la société Rational Software.
A ce stade, nous citerons les méthodes telles que :

▪ La méthode ERP ;
▪ La méthode RUP ;

1.2.2.1. LE CYCLE ERP

La mise en place d’un progiciel de gestion intégré, souvent appelé du terme

anglo-saxon ERP (Enterprise Resource Planning) s’appuie sur un découpage spécifique.

En effet, il s’agit de construire, en tirant le meilleur parti du progiciel, un

système améliorant la performance de l’entreprise. Deux étapes doivent donc être
menées en parallèle : Description des processus et Formation au progiciel. Ensuite, il y a
autant de cycles d’analyse — paramétrage — prototypage qu’il y a de processus. La
validation par le Comité de pilotage permet une simulation en grandeur réelle. Il faut alors
prendre en compte ce qui est resté en dehors du champ couvert par le progiciel.
 57

1.2.2.2. LE MODELE RUP

Le modèle RUP (Rational Unified Process) est représentatif d’une approche

combinant plusieurs modèles. Sa structure fait l’objet d’un assez large accord, notamment
parmi les praticiens (figure 2.17). Il peut être lu de la façon suivante :

1. Le cycle est constitué de quatre phases principales, que l’on retrouve globalement
dans toutes les approches descendantes : étude préalable (opportunité), conception de
la solution détaillée (élaboration), développement de la solution (construction) et mise
en œuvre (transition).

2. Il existe six types de tâches qui, au lieu d’être affectées exclusivement à une
phase, se retrouvent à des degrés divers dans chacune des phases. Par exemple,
l’étude des besoins peut apparaître jusqu’à la fin du projet, mais la plus grande partie
est effectuée dans les deux premières phases. L’implémentation (développement)
a principalement lieu dans la phase de construction, mais on peut réaliser un
prototype dès la première phase. Certaines tâches, comme la direction de projet,
s’effectuent sur toute la durée du projet.

3. Certaines phases peuvent être menées de façon cyclique. Ainsi, l’élaboration se fait en
deux cycles, conduisant par exemple à la production de spécifications externes
(vision utilisateur) et spécifications techniques (vision développeur). La
construction est itérative et incrémentale. De plus, l’ensemble du modèle
représente un tour de spirale, dans le cas d’une approche globale en spirale.
 58

1.3. TOP-DOWN NETWORK DESIGN

Top-Down Network Design, est un guide pratique et complet pour la conception de

réseaux d'entreprises qui sont fiables, sécurisés et gérables. L’utilisation des
illustrations et des exemples du monde réel enseigne une méthode systématique
pour la conception de réseaux qui peuvent être appliquées aux réseaux locaux, de
campus, d’accès à distance, des liens WAN, et inter-réseaux. Que vous soyez un
concepteur de réseau débutant ou un architecte réseau expérimenté, vous avez
probablement les préoccupations sur la façon de concevoir un réseau qui peut
suivre le rythme de l'accélération des changements dans l'industrie de réseaux.

Partie I : Identification des besoins et objectifs du client

Cette partie couvre les phases de l'analyse des besoins. Cette phase commence par
l'identification des objectifs d'affaires et des exigences techniques. La tâche de
caractériser le réseau existant, y compris l'architecture et les performances des
segments de réseau et les dispositifs principaux, suivent après. La dernière étape de
cette phase consiste à analyser le trafic réseau, y compris le trafic de flux et la
charge, le comportement du protocole, et la qualité de service (QoS).

Partie II : Logical Network Design : Conception logique du réseau

Au cours de la phase de conception logique du réseau, le concepteur du réseau

développe une topologie de réseau. Selon la taille du réseau et des
caractéristiques de trafic, la topologie peut varier de plus simple au plus complexe,
en nécessitant la hiérarchie et la modularité. Au cours de cette phase, le concepteur
de réseau élabore également un modèle d'adressage de la couche réseau, et il
choisit les protocoles de commutation et de routage. La conception logique
comprend également la planification de la sécurité, la conception de la gestion du
réseau, et l'enquête initiale dans laquelle les fournisseurs de services peuvent
répondre à la zone de mise en réseau étendu (WAN) et les exigences d’accès à
distance.

Partie III : Conception physique du réseau

Au cours de la phase de conception physique, les technologies et produits spécifiques

pour réaliser la conception logique sont sélectionnés. La conception physique du
réseau commence par la sélection des technologies et des dispositifs pour les
réseaux, y compris le câblage, les commutateurs Ethernet, les points d'accès sans
fil, les ponts sans fil et routeurs. La sélection des technologies et dispositifs pour
l'accès à distance et des besoins WAN s’en suit. En outre, l'enquête sur les
fournisseurs de services, qui a débuté au cours de la phase de conception logique,
doit être complétée au cours de cette phase.

Partie IV : Tester, optimiser, et documenter votre Architecture

réseau
 59
Les dernières étapes de conception de réseaux consistent à écrire et mettre en
œuvre un plan de test, de construire un prototype ou pilote, d'optimiser la
conception du réseau, et de documenter votre travail avec une proposition de
conception de réseau. Si vos résultats indiquent des problèmes de performance,
alors au cours de cette phase, vous devez mettre à jour votre conception pour
inclure les fonctionnalités d'optimisation telles que le lissage dutrafic de pointe et
des longues files d'attente de routeur et des mécanismes de commutation.
 60

CHAPITRE III : L’ESTIMATION DES CHARGES ET LES TECHNIQUES DE

PLANIFICATION DE DELAI

III.1.L’estimation des charges

1 la charge et la durée
Avant de présenter les méthodes permettant d’estimer la charge d’un projet, nous
allons préciser certaines notions, puis nous situerons les différents niveaux d’estimation,
auxquels sont attachés des objectifs spécifiques. Il convient de bien distinguer charge et durée.
La charge représente une quantité de travail nécessaire, indépendamment du nombre
de personnes qui vont réaliser ce travail ; elle permet notamment d’obtenir un coût prévisionnel.
Elle s’exprime en jour-personne, mois-personne ou année-personne. Un mois-personne
représente l’équivalent du travail d’une personne pendant un mois, en général 20 jours.
Ainsi, un projet de 60 mois-personne représente l’équivalent du travail d’une personne pendant
60 mois.
On mesure la taille des projets à leur charge. Les ordres de grandeur généralement
retenus sont les suivants :
• si la charge est inférieure à 6 mois-personne, c’est un très petit projet ;
• si la charge est comprise entre 6 et 12 mois-personne, c’est un petit projet ;
• si la charge est comprise entre 12 et 30 mois-personne, c’est un projet moyen ;
• si la charge est comprise entre 30 et 100 mois-personne, c’est un grand projet ;
• si la charge est supérieure à 100 mois-personne, c’est un très grand projet,
souvent mesuré en années-personne.
La durée dépend du nombre de personnes. Soixante mois-personne, ce peut être
aussi bien une personne pendant cinq ans, cinq personnes pendant un an, dix personnes pendant
six mois ou soixante personnes pendant un mois. Cependant, intuitivement on sent bien que l’on
ne peut pas faire n’importe quoi.
Certaines méthodes d’estimation proposent de respecter un rapport charge/durée.

IV.2.2 LES DIFFÉRENTES MÉTHODES D’ESTIMATION

Il existe cinq familles de méthodes d’estimation, qui ne sont pas forcément
concurrentes, mais peuvent être utilisées simultanément, ou à des moments différents du cycle
de vie du projet : le jugement d’expert, l’estimation par analogie, l’estimation ascendante,
l’estimation paramétrique et l’estimation probabiliste.

1) LE JUGEMENT D’EXPERT : LA MÉTHODE DELPHI

Les méthodes basées sur le jugement d’expert peuvent être utilisées à différents
moments et à différents niveaux (pour un projet entier ou pour une activité). On y recourt
généralement lorsque l’on dispose de peu d’éléments. Par exemple lors d’une étude de faisabilité
ou d’opportunité, le jugement d’expert peut apporter une aide à la décision de poursuivre ou non
 61
le projet. La méthode Delphi fut élaborée en 1948 par la Rand Corporation1, pour améliorer les
prévisions économiques. C’est un domaine où l’avenir est généralement incertain ; les avis des
experts, bien que parfois divergents, apportent des éclairages précieux. Le nom Delphi fait
référence à la pythie de Delphes, à qui l’on posait des questions et qui, en rendant son oracle, se
faisait l’interprète de la réponse des dieux. Sa parole était donc comme celle des experts
empreinte d’une grande autorité. Cette méthode propose une démarche pour mettre en commun
des jugements d’experts. Elle est utilisée dans différents domaines, dont l’estimation des charges
d’un projet système d’information. La démarche est la suivante :
➢ Dans un premier temps, chaque expert propose une estimation en utilisant sa propre
expérience.
➢ Dans un second temps, tous les jugements sont rendus publics, mais restent anonymes.
Chaque expert peut alors modifier sa propre estimation ou la confirmer. Chacun doit bien
sûr considérer que tous les autres sont également des experts, ce qui le conduit à se poser
des questions si ses propres estimations sont très éloignées de celles des autres.
➢ Dans un troisième temps, les nouvelles estimations sont dévoilées et chacun peut
justifier son propre jugement.
➢ Dans un dernier temps, chacun propose une révision de son estimation.
Normalement, sans que l’on arrive toujours à un consensus, les résultats
Cette méthode, utilisée notamment dans les sociétés de services, peut comporter
différentes variantes, selon le mode de communication entre experts (oral, écrit, rapproché ou à
distance…), le nombre de cycles de prévision et la conduite de la discussion (avec ou sans
animateur extérieur…). Bien que fortement dépendante de l’expérience des experts, elle permet
de dépasser la dimension strictement individuelle en organisant la confrontation collective des
estimations. On considère, par ailleurs, qu’elle évite que certains exercent une trop grande
influence sur les autres, ce qui biaiserait le résultat.

2. L’ESTIMATION PAR ANALOGIE

a) 1 La méthode de répartition proportionnelle

La méthode de répartition proportionnelle est utilisée au niveau du projet ou d’un

ensemble de phases. Elle est basée sur des observations de projets antérieurs : la charge de
chaque phase d’un projet devrait correspondre, avec un certain intervalle de tolérance, à un
pourcentage de la charge globale. Il existe plusieurs versions qui donnent des pourcentages
indicatifs, chacune s’appuie sur un cycle de vie de référence. Cette méthode est utilisée de trois
façons :
➢ On a fait une estimation de la charge globale du projet, que l’on cherche à répartir dans
le temps.
 62
➢ On a évalué l’une des phases, au moyen d’une autre méthode, et l’on veut en déduire la
charge des autres étapes.
➢ On est en cours de déroulement du projet, on a observé le temps déjà consommé et on
veut estimer celui des phases à venir.
L’exemple de répartition donné fait référence au cycle RUP et distingue la
répartition en charge et la répartition en durée. Notons qu’il est toutefois rare d’évaluer la charge
de la phase de mise en oeuvre au moyen d’un ratio. En effet, celle-ci comprend des activités
diverses dont une partie est décrite au paragraphe traitant de la gestion du changement. Il faut
donc comprendre ici la transition comme réduite à son aspect informatique de préparation de
l’exploitation.

Une autre répartition classique est donnée à la figure 3.4. Ces ratios sont issus
d’expériences positives et négatives de projet. Ils doivent être considérés en partie comme des
recommandations et en partie comme des règles. Ainsi, une étude préalable ne doit pas
consommer plus de 10 % des ressources d’un projet ; ou bien on doit s’attendre à consommer
deux fois plus en réalisation qu’en étude détaillée.

Il s’agit donc moins de les appliquer de façon aveugle que de les prendre comme base, en
comprenant les relations qui unissent les différentes phases.

La méthode des ratios

 63
La méthode des ratios est également une forme d’estimation par analogie, c’est une
variante de la répartition proportionnelle qui vise la relation entre deux activités. Elle est souvent
utilisée pour estimer des charges complémentaires au développement de l’application (figure
3.6). Il s’agit par exemple de l’encadrement du projet, de la recette et de l’élaboration de la
documentation utilisateur.

Pour ce qui est de la charge d’encadrement, le ratio est plus élevé à la phase de
réalisation. En effet, classiquement, l’équipe de projet est la plus nombreuse à ce stade. La
coordination assurée par le responsable augmente de façon significative.
La charge de recette dépend de la taille du logiciel. En effet, la recette est la
procédure par laquelle le client maître d’ouvrage et le fournisseur maître d’œuvre constatent
ensemble que le produit (logiciel) livré correspond aux spécifications

La charge d’élaboration de la documentation utilisateur est proportionnelle à la

taille du logiciel. La plupart des logiciels développés ont des aides utilisateurs intégrées pour la
partie transactionnelle. Il faut néanmoins généralement livrer un guide sur papier pour
l’utilisateur de l’application. La charge de la phase de mise en œuvre ne relève pas d’une
estimation standard. La mise en œuvre est le passage de l’ancien système au nouveau. L’effort
est souvent proportionnel au nombre et à la complexité des programmes écrits, mais les
évolutions organisationnelles (rôles, responsabilités, apprentissages…) sont déterminantes pour
évaluer la charge. Si le futur système est implanté sur plusieurs sites, il faut prévoir une charge
additionnelle variant avec le nombre de sites. On applique parfois un ratio de 40 % sur la charge
de réalisation, ce qui indique une relation de proportionnalité avec la taille du logiciel. Mais
cette estimation est en général affinée en fonction du nombre de sites et de leurs caractéristiques
techniques, organisationnelles et humaines.

L’ESTIMATION PARAMÉTRIQUE : LE MODÈLE COCOMO

Le modèle Cocomo (Constructive Cost Model, modèle de construction des coûts) a

été proposé en 1981 par B.W. Boehm [Boehm, 1984]. Ce modèle repose sur deux hypothèses :
 64
➢ d’une part, un informaticien chevronné sait plus facilement donner une évaluation de la
taille du logiciel à développer que faire une estimation du travail nécessaire ;
➢ d’autre part, il faut toujours le même effort pour écrire un nombre donné de lignes de
programme, quel que soit le langage de troisième génération employé.
Ces deux hypothèses ont conduit B.W. Boehm à calculer des coefficients de
corrélation entre la taille du logiciel et la charge consommée à partir d’observations sur une
centaine de projets déjà réalisés. Le paramètre utilisé par ce modèle est l’instruction source. Il
faut donc disposer du nombre présumé de lignes de programme en langage source, en dehors
d’éventuels commentaires.
Le modèle permet d’obtenir la charge de la réalisation en mois-personne, ainsi que
le délai « normal », recommandé si on ne veut pas prendre de risques supplémentaires. Cela
nous indique la taille moyenne de l’équipe qui est égale à charge/délai. Les formules de calcul
de la charge et du délai sont les suivantes :
Charge en mois-personne = a (kisl)b
Délai normal en mois = c (charge en mois-personne)d
avec kisl = nombre de milliers d’instructions sources livrées, c’est-à-dire le nombre de milliers
de lignes de programme source testées. Les paramètres a, b, c et d prennent des valeurs
différentes selon la catégorie de projet. En effet, l’analyse statistique a conduit à distinguer trois
types de projet : simple, moyen et complexe.
➢ Un projet est simple si le logiciel comporte moins de 50 000 instructions, si les
spécifications sont stables et le développement effectué par une petite équipe.
➢ Un projet est moyen si le logiciel comporte entre 50 000 et 300 000 instructions.
➢ Un projet est complexe si le logiciel comporte plus de 300 000 instructions et si l’on
prévoit une équipe nombreuse ; il s’applique souvent à un domaine nouveau.

Soit par exemple un projet simple visant à développer un logiciel estimé à 40 000 instructions
sources :
Charge = 2,4 * (40)1,05 = 116 mois-personne (arrondi)
Délai normal = 2,5 * (116)0,38 = 12 mois (arrondi)
Taille moyenne de l’équipe = 116 / 12 = 9 personnes.
La méthode Cocomo prend en compte des caractéristiques propres au projet pouvant
modifier l’estimation de la charge. Ces caractéristiques se traduisent par un coefficient de
 65
pondération appelé « facteur correcteur ». Les valeurs des coefficients données par B.W. Boehm
et obtenues de façon statistique sur un échantillon limité et biaisé (les projets de sa propre
société TRW) sont de moindre intérêt que la démarche de correction. Celle-ci répartit les
facteurs selon quatre sources de risques (figure 3.10) : les exigences attendues du logiciel, les
caractéristiques de l’environnement technique (matériel), les caractéristiques de l’équipe projet
et l’environnement du projet lui-même.
Ainsi, si on gère 100 kilo-octets pour 1 000 lignes de programme, le ratio sera 100.
La méthode considère que l’influence du facteur est faible si le ratio est inférieur à 10, moyenne
entre 10 et 100, forte entre 100 et 1 000 et très forte si le ratio est supérieur à 1 000. La
complexité est celle des algorithmes à développer. Le temps d’exécution peut être crucial pour
certains systèmes temps réel, comme le contrôle du trafic aérien ou le système de cotation des
valeurs mobilières. Le facteur taille mémoire signifie qu’il y aura besoin d’optimiser l’utilisation
de la mémoire.

La stabilité de l’environnement est celle du logiciel de base. La contrainte de délai

se mesure par rapport au délai « normal ». Chaque facteur peut prendre ses valeurs dans un
intervalle spécifique, dont les valeurs résultent de l’analyse statistique des projets de référence.
Ils modifient la charge brute de façon multiplicative :
Charge nette = Produit(valeurs des facteurs correcteurs) * Charge brute
La méthode Cocomo propose donc une démarche en cinq temps :
➢ estimation du nombre d’instructions sources c’est-à-dire en langage de programmation ;
➢ calcul de la charge dite « brute » ;
➢ sélection des facteurs correcteurs ;
➢ application des facteurs correcteurs à la charge brute pour obtenir la charge dite « nette »
;
➢ évaluation du délai normal.

III.2. TECHNIQUES DE PLANIFICATION DES DELAIS

1. L’UTILISATION DE LA PLANIFICATION

La planification des délais d’un projet comporte deux aspects, l’ordonnancement

des activités et l’élaboration de l’échéancier, marqués par l’utilisation de deux techniques
complémentaires : la technique des graphes et la technique Gantt.
En premier lieu, indépendamment de toute affectation du travail, on prend en compte
les caractéristiques de chacun des éléments résultant d’un découpage de type en général affiné.
On part donc d’une liste d’activités avec la durée estimée de chacune d’elles. On commence la
planification par une réflexion sur les contraintes d’ordonnancement de ces activités et sur les
possibilités de parallélisme. La technique des graphes d’ordonnancement permet de calculer la
durée minimum du projet, ainsi que les temps d’attente éventuels entre deux activités. Après une
 66
première planification, il est possible d’ajuster le découpage ou de chercher à assouplir certaines
contraintes. En effet, un parallélisme faible offre peu de marge de manoeuvre dans la répartition
du travail. On peut également utiliser des graphes d’ordonnancement pour traduire plusieurs
hypothèses de fin de projet souhaitée Dans un second temps, il s’agit d’établir un calendrier de
travail. La durée minimum obtenue précédemment est à rapprocher du délai « normal » ou «
raisonnable » proposé par certaines méthodes d’estimation des charges. On utilise ici le
diagramme de Gantt. Pour cela, il faut faire une hypothèse sur les ressources dont on disposera
et, parfois, prendre en compte les contraintes de disponibilité attachées à ces ressources. On peut
établir plusieurs scénarios qui correspondent à différentes hypothèses : les diagrammes aident à
décider quel est le scénario souhaitable .

2. LES GRAPHES D’ORDONNANCEMENT

Il existe deux formalismes de représentation de l’ordonnancement des activités : la méthode des

antécédents et la méthode du diagramme fléché. Dans le graphe de la méthode des antécédents
(figure 4.2), les activités figurent sur les rectangles, les flèches ne représentant que les liens. Les
ronds représentent
des jalons, c’est-à-dire des activités de durée nulle.

Dans le graphe de la méthode du diagramme fléché ,les activités figurent sur les flèches, les
ronds représentent des événements appelés jalons. Ceux-ci n’ont pas de durée. Pour traduire de
façon correcte les contraintes d’enchaînement, on est parfois amené à introduire des activités
fictives, représentées par des flèches en pointillés. Ces deux notations sont équivalentes. Dans ce
chapitre, nous utilisons le formalisme du graphe des antécédents, qui est plus simple et qui est
retenu par la majorité des progiciels de planification. Ce type de réseau peut être utilisé à

différentes mailles de décomposition du projet. Dans la suite, nous employons le terme « tâche »
de façon générique, celle-ci pouvant aussi bien être une tâche élémentaire, qu’une activité ou
 67
même une phase.
Soulignons qu’il y a eu ces dernières années un changement de vocabulaire : ce
graphe a longtemps été appelé réseau PERT . Aujourd’hui, lorsque l’on emploie le terme PERT,
c’est souvent pour faire référence au PERT probabiliste exposé en fin de ce chapitre. De son
côté, l’IPMA ainsi que le logiciel MS Project, dans sa version 2003, utilisent le terme
organigramme des tâches, OT, pour désigner le graphe des antécédents.

3. LES TYPES DE LIENS

Les liens entre les tâches représentent des contraintes provenant de la nature des tâches elles-
mêmes. Il existe quatre types de liens : le lien fin-début, le lien finfin, le lien début-début, le lien
début-fin.

Le lien fin-début est le plus courant : la tâche A doit être terminée pour que la tâche B puisse
commencer. La tâche A est le prédécesseur de la tâche B. La tâche B est le successeur de la
tâche A. On dit parfois que A est antécédente et B subséquente.

Par exemple , la tâche de Programmation doit être terminée pour que la tâche de Test puisse
commencer.

Le lien peut être caractérisé par un délai, exprimé en jours. Si le délai est négatif (– n jours), on
parle d’une avance1. L’avance peut être exprimée en pourcentage de la charge restante (– x %).

4. LE DIAGRAMME DE GANTT
Le graphe des antécédents permet de faire apparaître les possibilités de parallélisme dans
l’exécution des tâches et donne les dates de fin du projet possibles en dehors des contraintes de
ressources. Pour passer à un planning (calendrier du projet), il faut faire des hypothèses de
ressources et affecter les tâches à des personnes ou à des profils de personnes. On pourra faire
plusieurs simulations selon la taille de l’équipe envisagée. On prend également en compte les
 68
contraintes de calendrier (jours non ouvrables, jours fériés…). On utilise, pour représenter le
planning, le diagramme de Gantt, qui se construit de la façon suivante :
➢ en abscisse, on a l’axe du temps ;
➢ en ordonnée, on peut avoir soit les tâches, soit les personnes affectées aux tâches.
Selon que l’on utilise ou non les marges pour effectuer la planification, on parlera de
planification au plus tôt ou de planification au plus tard. Le diagramme de Gantt, qui porte le
nom de son concepteur, a été élaboré au début du XXe siècle pour représenter de façon
graphique la répartition du travail en atelier. C’est probablement la technique de gestion de
projet la plus largement utilisée.Le diagramme de Gantt, qui porte le nom de son concepteur,
a été élaboré au début du XXe siècle pour représenter de façon graphique la répartition du
travail en atelier. C’est probablement la technique de gestion de projet la plus largement
utilisée.

Voici des exemples de planning à partir du réseau ci-dessus (figure 4.20).

➢ Planification au plus tôt : on planifie les tâches en s’appuyant sur les dates au plus tôt
(figure 4.21). On utilise deux personnes : ressource 1 (R1) et ressource 2 (R2). R2 doit
attendre pendant 9 périodes, car la tâche C ne peut démarrer avant la fin de la tâche B.
Les parties grisées représentent la marge
69
 70

CONCLUSION

En guise de conclusion, le pilotage et/ou la gestion de projets informatiques est un

ensemble de techniques qui permettent d’identifier, de planifier et de piloter le
développement d’un produit logiciel. Toutefois l’évolution actuelle à fait susciter
l’aspect managériale afin d’avoir une plus grande valeur ajoutée qui permet la conduite du
projet vers la réussite. Ces techniques et outils ne peuvent fonctionner pleinement que dans
le cadre d’une gestion dimensionnée par projet.

En effet, nous avons voulu montrer, dans les différents chapitres de ce cours, qu’il
existe des techniques permettant de maîtriser le management hors hiérarchie qu’implique
une organisation par projet répondant aux nécessités du troisième millénaire. Le tout étant
d’accepter d’y consacrer les moyens voulus en fonction de l’ambition du projet. Parce
qu’il ne reproduit pas de modèle mais crée des modèles nouveaux, la conduite par projet
est l’outil du passage à une nouvelle forme de progrès: développer à la fois le potentiel
des hommes et celui des métiers de l’entreprise.

Plus qu’une méthode d’organisation, la conduite de projets informatiques représente

une nouvelle approche culturelle pour les entreprises informatiques ; une approche fondée
sur la culture de la transversalité. En ce sens, la conduite de projets va donc bien plus loin
que le fait de faire travailler ensemble des gents venants de différents métiers sur un
objectif commun. C’est à la fois un outil stratégique de l’entreprise pour répondre aux
changements rapides des marchés et un formidable outil de motivation pour ceux qui y
participent comme pour les métiers, si tous les apprentissages réalisés sont mémorisés. Le
tout est d’avoir envie et de savoir-faire vivre cette transversalité entre les objectifs à court
terme des projets et les objectifs à long terme de l’entreprise. Faire vivre un projet est
 71
une question de méthodes et d’hommes. C’est aussi, pour les entreprises, une question de
volonté.