CSI 1205 - FR La Gestion de Projets Informatiques

INFORMATIQUE APPLIQUÉE: CSI 1205
LA GESTION DE PROJETS
INFORMATIQUES
Ahmed Salem Cheik
La Gestion de Projets informatiques
Avant-propos
L’Université Virtuelle Africaine (UVA) est fière de participer à accès à l’éducation dans les pays
africains en produisant du matériel d’apprentissage de qualité. Nous sommes également fiers
de contribuer à la connaissance globale, pour nos ressources éducatives sont principalement
accessibles de l’extérieur du continent africain.
Ce module a été développé dans le cadre d’un programme de diplôme et diplôme en

informatique appliquée, en collaboration avec 18 institutions partenaires dans 16 pays africains.
Un total de 156 modules ont été développés ou traduits pour assurer la disponibilité en
anglais, français et portugais. Ces modules sont également disponibles en tant que ressources
éducatives ouvertes (OER) à oer.avu.org.
Au nom de l’Université Virtuelle Africaine et notre patron, nos institutions partenaires,

la Banque africaine de développement, je vous invite à utiliser ce module dans votre
établissement, pour leur propre éducation, partager aussi largement que possible et
participeractivement aux communautés AVU de pratique d’intérêt. Nous nous engageons à
être à l’avant-garde du développement et de partage ouvert de ressources pédagogiques.
L’Université Virtuelle Africaine (UVA) est une organisation intergouvernementale

panafricaine mis en place par lettre recommandée avec un mandat d’augmenter l’accès
à l’enseignement supérieur et de formation de qualité grâce à l’utilisation novatrice des
technologies de communication de l’information. Une charte instituant la UVA Organisation
intergouvernementale, signée à ce jour par dix-neuf (19) Les gouvernements africains - Kenya,
Sénégal, Mauritanie, Mali, Côte d’Ivoire, Tanzanie, Mozambique, République démocratique du
Congo, Bénin, Ghana, République de Guinée, le Burkina Faso, le Niger, le Soudan du Sud, le
Soudan, la Gambie, la Guinée-Bissau, l’Ethiopie et le Cap-Vert.
Les institutions suivantes ont participé au programme informatique appliquée: (1) Université
d’Abomey Calavi au Bénin; (2) University of Ougagadougou au Burkina Faso; (3) Université
Lumière Bujumbura Burundi; (4) Université de Douala au Cameroun; (5) Université de
Nouakchott en Mauritanie; (6) Université Gaston Berger Sénégal; (7) Université des Sciences,
Techniques et Technologies de Bamako au Mali (8) Institut de la gestion et de l’administration
publique du Ghana; (9) Université des sciences et de la technologie Kwame Nkrumah au
Ghana; (10) Université Kenyatta au Kenya; (11) Université Egerton au Kenya; (12) Université
d’Addis-Abeba en Ethiopie (13) Université du Rwanda; (14) University of Salaam en Tanzanie
Dar; (15) Université Abdou Moumouni Niamey Niger; (16) Université Cheikh Anta Diop au
Sénégal; (17) Université pédagogique au Mozambique; E (18) L’Université de la Gambie en
Gambie.
Bakary Diallo
le Recteur
Université Virtuelle Africaine
2
Crédits de production
Auteur
Ahmed Salem Cheik
Pair Réviseur
Cherif Diallo
UVA – Coordination Académique
Dr. Marilena Cabral
Coordinateur global Sciences Informatiques Apliquées
Prof Tim Mwololo Waema
Coordinateur du module
Robert Oboko
Concepteurs pédagogiques
Elizabeth Mbasu
Benta Ochola
Diana Tuel
Equipe Média
Sidney McGregor Michal Abigael Koyier
Barry Savala Mercy Tabi Ojwang
Edwin Kiprono Josiah Mutsogu
Kelvin Muriithi Kefa Murimi
Victor Oluoch Otieno Gerisson Mulongo
3
Droits d’auteur
Ce document est publié dans les conditions de la Creative Commons
Http://fr.wikipedia.org/wiki/Creative_Commons
Attribution http://creativecommons.org/licenses/by/2.5/
Le gabarit est copyright African Virtual University sous licence Creative Commons Attribution-
ShareAlike 4.0 International License. CC-BY, SA
Supporté par
Projet Multinational II de l’UVA financé par la Banque africaine de développement.
4
Table des matières
Avant-propos 2
Crédits de production 3
Droits d’auteur 4
Supporté par 4
La Gestion de Projets informatiques 7
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
I.1. Définitions: 7
I.1.1Qu’est-ce qu’un projet 7
I.1.2 Projet informatique : Une définition 7
I.1.3 La gestion de projet 7
I.2. Acteurs du projet 8
I.2.1 Maître d’Ouvrage (MOA) 8
Différentes fonctions MOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
I.2.2 Maîtrise d’Œuvre (MOE) 10
II. Le cycle de vie d’un projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
II.1 Les activités d’un cycle de vie d’un projet informatique 12
II.1.1. Etude d’opportunité et de faisabilité (Définition des Objectifs) 12
II.1.2. Analyse du système (Définition des Besoins) 12
II.1.3. Spécification et conception (Définition du Produit) 12
II.1.4 Planification et gestion de projet 12
II.1.5. Implémentation du système 13
II.1.6. Maintenance du système 13
II.2 Typologie des cycles de vie 13
II.2.1 Le modèle traductionnel 13
II.2.2 Le Modèle flexible ou expérimental 13
II.2.3 Modèle intermédiaire 14
II.3 Modèles de cycle de vie. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
II.3.1 Modèle en cascade 14
5
II.3.2 Le cycle en V 15
II.3.3 Le Cycle de vie évolutif 16
II.3.4 RAD (Développement rapide d’applications) 17
II.3.5 Cycle en spirale 19
III. Outils Pour La Gestion De Projet. . . . . . . . . . . . . . . . . . . . . . . . 20
III.1 Outils de conception de formalisation 20
III.1.1 La méthode MERISE 20
III.1.1.2 Le langage de modélisation UML 21
III.2 Outils de planification et de suivi 21
III.2.1 Le diagramme de Gantt 22
III.2.2 Le diagramme PERT : exploration des réseaux de tâches 23
III.2.3 La courbe en S 24
III.2.4 Tableau de bord 24
III.3 Les outils informatiques 24
IV. La Documentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 25
V. gestion du changement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
V.1. Les objectifs de la gestion du changement 26
V.2 Méthodologies de la gestion du changement 27
Liens & Références. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6
Introduction
I.1. Définitions:
I.1.1Qu’est-ce qu’un projet

Un projet est un ensemble d’actions mis en place pour la réalisation d’objectifs définis
et précis dans un délai fixé (il a un début et une fin) et pour un bénéficiaire donnée. Ainsi
un projet étant une action temporaire avec un début et une fin, mobilisant des ressources
identifiées (humaines et matérielles) durant sa réalisation, celui-ci possède également un coût
et fait donc l’objet d’une budgétisation de moyens et d’un bilan indépendant de celui de
l’entreprise.
I.1.2 Projet informatique : Une définition

Un projet informatique est un projet dont les réalisations (livrables) se constituent d’outils de
méthodes ou de services informatiques.
Les projets informatiques sont généralement, par nature, complexes. Cette complexité
s’explique notamment par la grande diversité des acteurs qu’ils font intervenir : techniciens,
responsables métier, marketeurs, gestionnaires...
I.1.3 La gestion de projet

La gestion de projet est l’utilisation d’un savoir, d’habiletés, d’outils et de techniques dans
le cadre des activités d’un projet, en vue de satisfaire ou de dépasser les exigences et les
attentes des parties prenantes à l’égard d’un projet. Le gestionnaire de projet, parfois appelé
coordonnateur ou chef de projet, en administre les détails, au jour le jour. Il s’agit là d’un défi
constant qui demande une compréhension du contexte plus général du projet et la capacité
de concilier des exigences contradictoires telles que :
• les ressources disponibles et les attentes;

• les priorités des parties prenantes;
• les besoins définis et à la portée du projet;
• la qualité et la quantité.
7
Une approche mécaniste de la gestion de projet prend en compte quatre critères : le coût, la
qualité, les délais et la satisfaction du client. En effet, un chef de projet doit réaliser son projet
en coûts, délais et qualité fixé initialement. Aussi est nécessaire de s’assurer tout au long du
projet, que le produit en cours de réalisation correspond clairement aux attentes du client.
Le projet est avant tout une aventure humaine, qui mobilise un ensemble d’acteurs pour
atteindre un but. Chaque acteur assume, dans le projet, une responsabilité propre : planifier,
concevoir, développer, valider, tester...
Le projet est avant tout une aventure humaine, qui mobilise un ensemble d’acteurs pour
atteindre un but. Chaque acteur assume, dans le projet, une responsabilité propre : planifier,
concevoir, développer, valider, tester...
Parmi cette somme d’acteurs, on peut identifier deux entités essentielles de l’organisation :
• la MOA, maîtrise d’ouvrage : le client du projet (mais pas forcément l’utilisateur) ;

• la MOE, maîtrise d’oeuvre : l’organe réalisateur du projet, représenté par le chef
de projet.
I.2. Acteurs du projet

Un acteur est une personne qui jour un rôle dans le déroulement d’un projet. Le rôle
consiste en une fonction temporaire, indépendamment de la position de la personne dans
l’organigramme de l’entreprise.
Dans le cas de petits projets, il y a peu souvent d’acteurs qui sont concernés, et on peut se
limiter à une relation client - fournisseur. Le client (ou maître d’ouvrage (MOA)) est la personne
(physique ou morale) qui exprime un besoin. Le fournisseur (ou maître d’œuvre (MOE) est la
personne (physique ou morale) qui satisfait le besoin.
Le projet est porté en général par un seul fournisseur qui fait appel éventuellement à des
partenaires ou des intervenants externes, qui seront fournisseurs de parties de projets.
L’ensemble des acteurs impliqués dans un projet s’appelle les parties prenantes
I.2.1 Maître d’Ouvrage (MOA)

Le MOA est la personne qui commande et paie un système (un ouvrage) qui répond à des
besoins. Il est l’entité qui représente les utilisateurs finaux dont le système est destiné.
Partant des besoins des utilisateurs du système, le MOA rédige un Cahier des Charges qui
peut servir de base à un appel d’offres. Après la sélection d’un fournisseur, elle passe un
contrat avec ce dernier, qui jouera le rôle de maîtrise d’œuvre.
8
Différentes fonctions MOA

On distingue dans la Maîtrise d’ouvrage (MOA) plusieurs rôles ou fonctions. En voici une liste
non-exhaustive :
a. Maître d’ouvrage délégué (MOAD)
Le maître d’ouvrage délégué aide le maître d’ouvrage lorsqu’il n’a pas les compétences
nécessaires. Elle est chargée de faire l’interface entre le maître d’œuvre et le maître d’ouvrage,
notamment en apportant une aide et un soutien à la MOA pour la définition des cahiers des
charges, la validation de certains livrables. Elle justifie généralement d’une double compétence
(informatique et métier) qui apporte à la maîtrise d’ouvrage une aide technique pour jouer au
mieux son rôle.
b. La maîtrise d’ouvrage stratégique (MOAS)
C’est lui qui prend les décisions importantes concernant la MOA, qui arbitre les différends
entre ses collaborateurs, qui signe le contrat avec la Maîtrise d’œuvre (MOE), qui participe
au Comité de pilotage ou le comité directeur du projet. Comme le système d’information (SI)
est, dans la plupart des entreprises, à la fois la concrétisation de la stratégie et la condition
de sa mise en œuvre, les décisions essentielles sont prises par le MOAS (notamment pour le
lancement des grands projets et des programmes d’entreprise).
Le rôle du MOAS est de s’assurer de la bonne adéquation entre:
• d’une part la stratégie « métier » de l’entreprise ou de l’organisation : les objectifs,

les enjeux, inscrits dans leur contexte, les opportunités et menaces, ainsi que les
forces et faiblesses (vulnérabilités) (voir risque et SWOT).
• et d’autre part le système d’information qui doit se mettre au service de cette
stratégie.
c. Le sponsor ou commanditaire
Lorsque la fonction de maîtrise d’ouvrage est moins impliquée dans le projet, on parle parfois
de « sponsor » .On retrouve dans cette appellation les origines du vocabulaire de maîtrise
d’ouvrage : le sponsor est celui qui « paie ».
Lorsque le projet est de grande envergure et qu’il met en jeu de nombreuses directions
métiers au sein de l’entreprise ou de l’organisation, le maître d’ouvrage délégué est mandaté
par la direction principale de l’entreprise (la direction générale, ...) - dans ce cas, le MOAD
peut s’appuyer sur des relais au sein des différentes directions métier de l’entreprise : ce sont
des « sponsors ».
9
d. Le maître d’ouvrage opérationnel (MOAO)
Le « maître d’ouvrage opérationnel » (MOAO) est, dans l’entité, un expert qui connaît
parfaitement l’un des grands processus du métier. Lorsque le SI est organisé en applications,
le MOAO est celui qui connaît parfaitement l’application. Il sait, quand on veut faire des
choses nouvelles, s’il sera possible d’y parvenir en modifiant des paramètres, ou s’il faudra
un développement important ; il connaît les référentiels utilisés, les règles de gestion, les
échanges et interfaces avec les autres applications, etc.
Souvent, le MOAO est une personne seule qui possède une expertise précieuse. La
situation peut être catastrophique s’il tombe malade, ou quand il prend sa retraite. Trop peu
d’entreprises pensent à ce type de risque, mais souvent le MOAO lui-même n’est pas enclin à
partager son savoir.
e. L’assistant à maîtrise d’ouvrage (AMO ou AMOA
Le travail que doivent réaliser un MOAD ou un MOAO comporte des périodes de surcharge
lorsqu’il faut spécifier, suivre ou recetter une importante évolution du système d’information
; lorsqu’il faut concevoir ou mettre en place des méthodes nouvelles ; lorsqu’il faut mettre en
œuvre une expertise que l’entité ne possède pas.
Dans ces cas, l’entité fait appel, pour réaliser les travaux dévolus à la maîtrise d’ouvrage, à des
consultants externes ou à des personnes que l’entreprise a mis à sa disposition : elles rédigent
les spécifications ou documents méthodologiques, tiennent à jour les tableaux de bord, etc.
On appelle ces personnes «assistants à maîtrise d’ouvrage» (AMO ou AMOA).
I.2.2 Maîtrise d’Œuvre (MOE)

La MOA est l’entité retenue par la MOA en qualité de chef de projet responsable des choix
techniques. Elle est garante de la bonne réalisation technique des solutions, elle fournit le
produit. Elle peut réaliser elle-même cette solution, ou missionner un ou plusieurs fournisseurs
pour sa réalisation.
Les principaux rôles de l’équipes- projet MOE :
• Les concepteurs / architectes: Responsables de concevoir le système aux étapes

d’étude préalable (ou générale) et études détaillées. Le rôle est généralement
tenu par un informaticien, mais peut parfois être tenu par des organisateurs ou
des gestionnaires
• Les développeurs / programmeurs: Responsables de l’écriture des programmes
et de leurs premiers contrôles. Le rôle est tenu par un informaticien
• Les testeurs: Responsables de vérifier que le comportement du système est
conforme à ses spécifications générales et détaillées. Le rôle peut être tenu par
des informaticiens ou des gestionnaires ; les équipes mixtes sont à privilégier.
10
Le schéma suivant reprend les principales interactions entre les différents acteurs concernés par
un projet informatique:
II. Le cycle de vie d’un projet

Les définitions du cycle de vie d’un projet sont multiples mais elles s’accordent tout de même
à le définir comme étant la décomposition d’un projet en un ensemble d’étapes nécessaires au
développement d’un produit ou d’un service. Cette décomposition participe également à la
gestion des risques ainsi qu’à l’évaluation du produit fini.
Le cycle de vie d’un projet est les étapes de développement d’un produit de sa conception
à sa disparition. Il s’applique à tous les produits dont les produits informatiques : logiciels et
systèmes d’information…
On distingue deux types de cycle de vie
• Le cycle de vie des produits s›applique à tous les types de produits, et peut être
considéré comme un outil de gestion.
• Le cycle de développement des logiciels s›insère dans le précédent, on l›appelle
souvent cycle de vie des logiciels
11
II.1 Les activités d’un cycle de vie d’un projet informatique
II.1.1. Etude d’opportunité et de faisabilité (Définition des Objectifs)

Cette première étape est cruciale et donnera lieu à la production du schéma directeur du
projet qui répondra à un ensemble d’interrogations :
la finalité stratégique du projet: Le management étudie la stratégie et décide de la nécessité

de fabriquer ou acheter un nouveau produit;
• l’analyse coût/bénéfice ;
• l’analyse des risques ;
• les ressources nécessaires ;
• l’état de l’art en la matière ;
• l’étude et l’analyse de solutions alternatives ;
• les critères d’évaluation du projet ;
etc.
II.1.2. Analyse du système (Définition des Besoins)

Cette étape fournira la description détaillée du logiciel à développer aussi bien d’un point de
vue fonctionnel que technique. Le produit de cette étape peut être associé à un cahier des
charges décrivant les besoins. Un appel d’offres est éventuellement lancé
II.1.3. Spécification et conception (Définition du Produit)

La phase de conception conduit à l’élaboration d’une solution abstraite du produit à
implémenter satisfaisant aux besoins préalablement identifiés. La solution reste encore
majoritairement indépendante des contraintes techniques.
Les spécifications précises du produit sont décrites ainsi que les contraintes de réalisation.
A l’issue de cette phase, les fournitures intermédiaires sont le dossier de spécifications
fonctionnelles et une première version du manuel utilisateur.
Pendant cette phase l’architecture du logiciel est définie ainsi que les interfaces entre les
différents modules. On doit veiller à rendre les différentes parties constituants du produits aussi
indépendants que possible de manière à faciliter à la fois le développement parallèle et la
maintenance future.
II.1.4 Planification et gestion de projet

La phase de planification permet de découper le projet en tâches, de décrire leur
enchaînement dans le temps, d’affecter à chacune une durée et un effort calculé en
homme*mois.
12
II.1.5. Implémentation du système

Il s’agit ici de la mise en œuvre du système opérationnel : développement hardware et
software, formation des utilisateurs, tests par modules et tests d’intégration, conversion du
système existant.
II.1.6. Maintenance du système

Cette dernière étape concerne l’évolution du projet développé. Elle peut prendre la forme de
maintenance de type corrective si le projet révèle à l’usage des dysfonctionnements ou des
erreurs de programmation. Elle peut également tenir en certains travaux visant à faire évoluer
le projet en fonction des problèmes nouveaux rencontrés ou des desiderata des utilisateurs.
II.2 Typologie des cycles de vie

Un certain nombre de méthodologies ou encore de modèles de développement de projet ont
été élaborés depuis les années 60, afin d’aider les gestionnaires de projet dans leur tâche. Ces
divers modèles se caractérisent par un agencement particulier des étapes de base décrites
précédemment, selon la complexité du projet à développer, l’environnement organisationnel,
le degré de complexité des spécifications ou encore le degré d’implication souhaité des
utilisateurs.
II.2.1 Le modèle traductionnel

Il vise avant tout le contrôle et à la réduction des incertitudes du projet. Il favorise la régulation
et se caractérise par une approche top down, enfermant le projet dès le départ dans des choix
assez strictement définis et peu adaptables en cours de développement. Cette rigidité permet
d’isoler le projet des perturbations de la réalité sociale. La séparation des rôles de concepteurs
et d’utilisateurs est flagrante, l’implication des utilisateurs étant réduite au strict minimum. Le
cycle de vie du projet est strictement défini avec un début et une fin clairement identifiés.
Nous pouvons citer comme modèles faisant partie de cette catégorie : Le cycle de vie en
cascade, le cycle de développement en V, ...etc.
II.2.2 Le Modèle flexible ou expérimental

Ce type de modèle s’attache d’avantage à la gestion de l’incertitude de la réalité sociale
avec un projet plus modularisé, fragmenté dans le temps et en fonction des changements et
évolutions survenus suite à l’expérimentation du projet par les utilisateurs.
Les concepteurs font donc évoluer le projet en fonction des réactions des utilisateurs, mais ils
restent aux commandes du projet. Les rôles de concepteurs et d’utilisateurs restent toujours
séparés.
13
Le cycle de vie du projet n’est pas clairement fini dans le temps : le projet apparaît comme
étant toujours en cours de développement.
Les choix techniques sont flexibles et peuvent être adaptés au cours du processus de
développement.
Les cycles de vie les plus classiques appartenant au modèle flexible sont sans conteste le cycle
de vie évolutif ou encore celui du développement en spirale.
II.2.3 Modèle intermédiaire

Ce dernier modèle tend à conjuguer les avantages des deux modèles précédents. Parmi les
modèles intermédiaires, citons l’approche RAD.
II.3 Modèles de cycle de vie
II.3.1 Modèle en cascade

Le modèle en cascade est hérité de l’industrie du Bâtiment et travaux publics. Ce modèle
repose sur les hypothèses suivantes :
• on ne peut pas construire la toiture avant les fondations ;

• les conséquences d’une modification en amont du cycle ont un impact majeur sur
les coûts en aval (on peut imaginer la fabrication d’un moule dans l’industrie du
plastique).
Les phases traditionnelles de développement sont effectuées simplement les unes après les
autres, avec un retour sur les précédentes, voire au tout début du cycle.
Les étapes préconisées sont :
• l’étude de faisabilité
• la définition des besoins
• la conception
• l’implémentation
• la maintenance
Le modèle en cascade est d’avantage adapté aux projets de petite taille. Il a connu au cours
du temps plusieurs variantes destinées à pallier à sa rigidité, la principale critique qui lui est
adressée.
14
Les avantages du modèle en cascades :
• les étapes sont clairement définies et il est facile d’y associer un output
documentable et vérifiable ;
• la découpe des tâches est simple et intuitive ;
• la responsabilité humaine est facilement associable à chaque étape du projet;
• le suivi des étapes et de l’évolution du projet reste relativement aisé ;
• cette méthode permet la réduction du risque de changement continuel des
spécifications du projet.
Les inconvénients :
• la rigidité des phases et la complexité du retour ;

• l’estimation du coût est difficile à faire ;
• on constate une mauvaise intégration et anticipation du changement ;
• le point de contrôle reste principalement basé sur la production d’un document.
II.3.2 Le cycle en V
Le modèle du cycle en V a été imaginé pour pallier le problème de réactivité du modèle en
cascade. Ce modèle est une amélioration du modèle en cascade qui permet en cas d’anomalie,
de limiter un retour aux étapes précédentes. Les phases de la partie montante doivent
renvoyer de l’information sur les phases en vis-à-vis lorsque des défauts sont détectés afin
d’améliorer le logiciel.
15
De plus le cycle en V met en évidence la nécessité d’anticiper et de préparer dans les étapes
descendantes les « attendus » des futures étapes montantes : ainsi les attendus des tests de
validation sont définis lors des spécifications, les attendus des tests unitaires sont définis lors
de la conception, etc.
II.3.3 Le Cycle de vie évolutif

Basé sur le modèle du prototype à jeter, le modèle évolutif améliore sans cesse la version
initiale du prototype jusqu’à l’obtention du produit fini.
Il est plutôt adapté à une conception participative avec un nombre réduit d’utilisateurs.
Les avantages :
• meilleure adéquation du produit fini aux besoins des utilisateurs ;

• flexibilité et bonne prise en considération des changements éventuels ;
• participation des utilisateurs.
• manque de méthode ;
• il n’est pas toujours aisé de terminer ce genre de projets ;
• risque de logiciel mal structuré, manque de vue globale.
16
II.3.4 RAD (Développement rapide d’applications)

Cette approche peut être considérée comme un intermédiaire entre le modèle de l’épure et le
modèle évolutif. En effet, la première phase du projet se caractérise plutôt par une approche
en cascade, la suite du projet étant davantage caractérisée par une approche itérative-
incrémentale du besoin de l’utilisateur afin d’assurer l’adéquation des résultats finaux aux
besoins exprimés.
Le cycle RAD introduit par James Martin comporte trois phases :
cadrage (Joint Requitement Planning) : cette étape couvre l’analyse des besoins, le périmètre
et la planification de l’itération ;
conception (Joint Application Design) : elle couvre la conception, la description, l’organisation

des données et des traitements avec les utilisateurs ;
construction (Construction Assistance Team) : cette ultime étape couvre le développement et

les tests.
Le modèle de développement RAD est plus particulièrement adapté aux projets où les
utilisateurs sont largement impliqués.
17
Les avantages :
• assure la conformité de l’application aux exigences des utilisateurs. Il participe

ainsi à l’assurance qualité.
• le gestionnaire de projet doit faire preuve d’une certaine expérience en la matière

;
• parce qu’il initialement conçu pour une culture de projet américaine, il faudra
s’assurer des conditions et du contexte d’un projet RAD avant d’y souscrire.
18
II.3.5 Cycle en spirale

Le développement reprend les différentes étapes du cycle en V. Par l’implémentation de
versions successives, le cycle recommence en proposant un produit de plus en plus complet et
robuste.
Le cycle en spirale met cependant plus l’accent sur la gestion des risques que le cycle en V.
En effet, le début de chaque itération comprend une phase d’analyse des risques. Celle-ci est
rendue nécessaire par le fait que, lors d’un développement cyclique, il y a plus de risques de
défaire, au cours de l’itération, ce qui a été fait au cours de l’itération précédente
19
III. Outils Pour La Gestion De Projet
III.1 Outils de conception de formalisation

Les outils de conception permettent d’avoir une vision globale, de se poser les bonnes
questions. Il existe plusieurs outils mais les plus utilisés sont les deux suivant:
III.1.1 La méthode MERISE

MERISE est une méthode de conception, de développement et de réalisation de projets
informatiques. Le but de cette méthode est d’arriver à concevoir un système d’information.
MERISE constitue depuis le milieu des années 80 un standard de fait dans le domaine des
systèmes d’information de gestion en France et dans les pays francophones.
Cette méthode intègre à la fois les aspects décisionnels et techniques, elle s’apparente en cela
au modèle en spirale mais procède plutôt en cascade. Elle est utilisée pour développer des
systèmes d’information complets et subit des mises à jour fréquentes. Elle traite l’ensemble du
cycle de vie d’un système d’information et adopte une approche systémique de l’entreprise.
Elle tient compte des 3 axes: cycle de décision, cycle d’abstraction et cycle de vie.
Merise procède par étapes :
• Schéma directeur: approche globale du problème prenant en compte la stratégie

• Étude préalable de chaque domaine
• Étude détaillée de chaque sous domain
• Étude technique par projet
• Réalisation par projet
• Mise en œuvre projet par projet
• Exploitation du produit
• Maintenance du produit
Comme dans le cycle de vie en spirale ou dans le modèle incrémental on met en exploitation
les projets issus des différents domaines les uns après les autres jusqu’à obtenir un système
complet.
La méthode opère par une modélisation descendante des systèmes et utilise une séparation
données / traitements /communication
Le système d’information est décomposé en différents niveaux
- conceptuel (description de l’activité: QUOI)
- organisationnel (QUI, OU, QUAND)
- physique (description des moyens, COMMENT, avec quelle ressource)
20
Ces trois niveaux s’appuient sur un certain nombre de modèles, Modèle de communication
Modèles de données, Modèles de traitements.
MERISE est en constante évolution, en particulier MERISE intègre aujourd’hui les

concepts et techniques de l’ approche objets.
III.1.1.2 Le langage de modélisation UML

UML (Unified Modeling Language ) ou Langage de modélisation unifié, est un langage de
modélisation graphique à base de pictogrammes. Il est utilisé en développement logiciel, et
en conception orientée objet. UML est également utilisé dans les projets logiciels. ...
Cette modélisation objet permet de créer une représentation informatique des éléments du
monde réel auxquels on s’intéresse, sans se préoccuper de l’implémentation, ce qui signifie
indépendamment d’un langage de programmation.
L’intérêt d’une méthode objet c’est qu’elle permet de définir le problème à haut niveau sans
rentrer dans les spécificités d’un langage. Il représente ainsi un outil permettant de définir un
problème de façon graphique, afin par exemple de le présenter à tous les acteurs d’un projet
et les différents cas d’utilisation.
III.2 Outils de planification et de suivi

La planification c’est l’activité qui consiste à déterminer et à ordonnancer les tâches du projet,
à estimer leurs charges et à déterminer les profils nécessaires à leur réalisation.
La planification du projet est initialisée au début d’un projet et mise à jour pendant toute sa
durée de vie. L’outil requis est le planning. Un même projet peut faire l’objet de plusieurs
plannings : un planning global et un ou des planning(s) détaillé(s). L’ensemble de ces plannings
permet de gérer les principales tâches et jalons du projet.
Les objectifs du planning sont les suivants :
déterminer si les objectifs sont réalisés ou dépassés
suivre et communiquer l’avancement du projet
affecter les ressources aux tâches
21
III.2.1 Le diagramme de Gantt

Le diagramme de Gantt permet de planifier un projet et rendre plus simple le suivi de son
avancement. Il est l’un des outils les plus efficaces pour représenter visuellement l’état
d’avancement des différentes activités (tâches) qui constituent un projet. Il permet de visualiser
facilement le déroulement du projet, ainsi que de prévoir suffisamment à l’avance les actions à
penser. On pourra aussi gérer plus facilement les conflits de ressources et les éventuels retards
en visualisant l’impact de ceux-ci sur le déroulement du projet.
En outre, le diagramme de GANTT est un bon outil de communication avec les différents
acteurs du projet.
Le diagramme permet donc de visualiser d’un coup d’œil :
· Les différentes tâches à envisager
· La date de début et la date de fin de chaque tâche
· La durée escomptée de chaque tâche
· Le chevauchement éventuel des tâches, et la durée de ce chevauchement
· La date de début et la date de fin du projet dans son ensemble
Dans un diagramme de GANTT chaque tâche est représentée par une ligne, tandis que les
colonnes représentent les jours, semaines ou mois du calendrier selon la durée du projet. Le
temps estimé pour une tâche se modélise par une barre horizontale dont l’extrémité gauche
est positionnée sur la date prévue de démarrage et l’extrémité droite sur la date prévue de
fin de réalisation. Les tâches peuvent s’enchaîner séquentiellement ou bien être exécutées en
parallèle.
Tache Semaine1 Semaine2 Semaine3 Semaine4 .... Semainen
Préparation
Conception
Développement
Maintenance
Un exemple de diagramme de Gantt simple
22
III.2.2 Le diagramme PERT : exploration des réseaux de tâches

Le diagramme PERT (Project Évaluation and Review Technique) permet d’évaluer la durée de
réalisation d’un projet complexe et de détecter les parties de ce projet ne supportant aucun
retard. Elle résout des problèmes appelés problèmes d’ordonnancement.
Le projet sera subdivisé en tâches. En général, elles ne pourront toutes être réalisées
simultanément, certaines tâches devront être achevées avant que d’autres ne puissent débuter.
On utilise un graphe de dépendances PERT pour chaque tâche, on indique une date de début
et de fin au plus tôt et au plus tard.
Le diagramme permet de déterminer le chemin critique qui conditionne la durée minimale du

projet. Ces techniques ne pas propres au projet informatique; elles sont aussi appliquées dans
tout type de projet.
Exemple:
Supposons un projet composé des taches, A, B,C,D avec contraintes suivantes:
· A et B sont indépendants
· L›exécution de la tâche D ne peut commencer que si A et B sont exécutées.
· L›exécution de C peut commencer si D est exécuté
Le graphe sera un graphe valué dont les arcs seront les tâches et les sommets représenteront
des états d›avancement du projet, numérotés de 1 à n
23
III.2.3 La courbe en S
La courbe en S permet de mettre en évidence les différences entre les prévisions et la réalité
du projet. Elle peut par exemple être utile si l’on souhaite visualiser la différence entre les
dépenses effectuées et les dépenses prévisionnelles:
III.2.4 Tableau de bord

Un Tableau de bord ou “journal de bord” est tenu à jour et permet de garder une trace
des informations communiquées, des problèmes rencontrés, des décisions prises, des
responsables désignés pour mener à bien les actions et la date de réalisation de l’action
III.3 Les outils informatiques

Il existe divers outils informatiques permettant de nous assister dans les différentes phases
d’un projet. Le travail de ces outils de gestion de projet est généralement d’automatiser des
tâches de sauvegarde et/ou de la gestion du temps. Par exemple, les systèmes de gestion de
versions, ou les systèmes de gestion de configuration enregistrent différents états d’un projet
et gardent une trace de la date de modification.
Une part importante des logiciels de gestion de projet s’occupent de la planification des
projets, c’est-à-dire de l’ordonnancement de tâches en vue de leur réalisation future par
exemple permet de modéliser les outils de gestion (diagrammes de Gantt, diagrammes
PERT,...).
MSProject: est un outil complet de gestion de projet qui permet de bâtir un planning très
rapidement et de piloter les gros projets comme les petits. Il offre en outre la possibilité de
faire des présentations graphiques personnalisées avec les affichages GANTT / PERT /
CALENDRIER. Les version récentes de MS Project utilise les technologies d’Internet pour
améliorer la communication des informations relatives à un projet et permet d’informer les
intervenants et de leur faire saisir le réalisé.
24
D’autre permettent de faciliter la phase de développement comme:
• VS (Concurrent Version System): CVS permet de gérer le développement

simultané
• SourceForge: Site d’hébergement de projets de développement coopératif de
logiciel.
IV. La Documentation du projet
La documentation d’un projet c’est l’outil de communication et de dialogue entre les membres
de l’équipe projet et les intervenants extérieurs (membre des instances de pilotage, chef de
projet, utilisateurs, etc...). Elle assure aussi la pérennité des informations au sein du projet.
La documentation associée à un projet doit être le reflet de la vie de ce projet. Elle est
élaborée et mise à jour tout au long du projet.
Afin d’organiser la gestion de la documentation produite par projet, il convient au préalable

d’identifier tous les types de documents relatifs aux diverses phases du projet, de les
référencer de manière homogène pour ensuite définir un mode de gestion commun à tous les
projets.
Documents de référence
Il s’agit des diverses documentations associées au projet, on distingue les éléments

destinés aux utilisateurs, ceux destinés aux développeurs pendant le développement et aux
mainteneurs en phase de maintenance.
Documents liés à une phase du cycle de vie (essentiellement destiné aux développeurs et
mainteneurs)
–– cahier des charges

–– document de spécifications fonctionnelles
–– plan d’intégration
–– manuel de conception globale et détaillée
–– procédures de validation tests unitaires, d’intégration, de validation, de non
régression
–– code
Documents transversaux à la vie du projet
- Le glossaire, la liste des abréviations.
- Le plan projet
- Le plan qualité
25
Documents remis au client
- Le manuel utilisateur
- Le manuel d’installation
- Le manuel de maintenance
V. gestion du changement
Le changement déstabilise les acteurs d’un projet au travers de certaines situations, telles
qu’une perte de repères dans les actes de gestion quotidiens, un manque de maîtrise des
nouvelles procédures ou encore des difficultés liées à une nouvelle organisation.
Une conduite du changement doit faire l’objet d’un travail continu tout au long du projet de
la part de la MOA. Elle doit couvrir trois domaines clés: la communication, l’information et la
formation.
V.1. Les objectifs de la gestion du changement

Une nouvelle représentation basée sur les trois piliers de l’entreprise que sont l’homme, la
fonction et l’organisation permet d’ores et déjà de se rappeler que les 3 objectifs majeurs de la
conduite du changement en système d’information sont :
• L’appropriation de l’outil par l’utilisateur final en le sensibilisant dès la naissance

du projet SI, en lui apportant une visibilité régulière sur son avancement et en le
responsabilisant dans ses attributions futures.
• L’adéquation et la pertinence de l’outil dans la fonction en définissant les
nouvelles méthodes de travail à adopter ainsi que les règles, les process et les
procédures associées.
• L’intégration de l’outil dans l’organisation en impliquant les acteurs à tous les
niveaux de la ligne hiérarchique et en tenant compte des nouvelles interactions
transversales générées par l’outil.
26
V.2 Méthodologies de la gestion du changement

La méthodologie adoptée pour piloter la conduite du changement doit permettre d’atteindre
plusieurs objectifs:
• En étude préalable, démontrer et faire savoir l’implication de la Direction afin

d’impulser le changement et de le traduire en organisation et en processus de
travail nouveaux clairs.
• En phase de conception/réalisation, faire travailler de façon efficace MOA et
utilisateurs de façon à élaborer un plan de conduite du changement réellement
adapté au projet et au terrain
• En phase de déploiement, faire en sorte que les opérations de conduite du
changement décidées permettent au projet d’être vite et bien compris, bien
admis, vite et bien utilisé, grâce à une information et une formation efficaces,
c’est-à-dire parvenant à temps aux bons destinataires et répondant à leurs
préoccupations réelles.
Démarche de conduite du changement (change management) en trois étapes
La mise en place d’une démarche de gestion du changement permet de minimiser la perte de

productivité au démarrage, d’ancrer le changement dans les habitudes et les comportements
ainsi qu’optimiser le retour-sur-investissement.
Permet également d’analyser les impacts sur les populations concernées par le changement
(rôles et responsabilités des différents acteurs, cartographie des populations, importance du
changement et de la résistance des acteurs),
Définition et mise en œuvre du plan de changement, dont l’intensité et la forme sont adaptées
en fonction de l’importance du changement, des résistances précédemment identifiées et de
la culture de l’organisation :
• Plan de formation : définition de la stratégie de formation, du planning, des

cursus, du matériel pédagogique, animation des formations etc., pour une prise
en main et une montée en compétence des utilisateurs,
• Plan de communication : définition de la stratégie, des messages en fonction des
populations, du planning, création de supports différenciés adaptés à la culture
de l’entreprise, mise en œuvre de la communication pour une sensibilisation des
utilisateurs et une adhésion enthousiaste au projet,
• Assistance utilisateurs : définition et dimensionnement du plan d’assistance et des
structures à mettre en place (hotline, référents métiers etc.)
Ce qui permet d’améliorer le suivi du changement en entreprise
La reconnaissance et les incitations
Les formations
Le contrôle des processus
27
La présence d’une tierce personne de soutien
Un moyen de diffusion de l’information simple et le retour d’information
L’homogénéisation de l’accès à l’information
Expliquer clairement l’importance des changements
L’implication des personnes concernées par le changement dans tout le processus de

développement du projet.
support utilisateurs au moment du déploiement
La planification du projet de conduite du changement et son intégration dans le projet

“principal”
Ce qu’il faut éviter
Ne pas tenir compte des enjeux et risques individuels
Ne communiquer que sur l’objectif
Mauvaise utilisation de l’outil par manque de formation des utilisateurs,
Manque d’information des utilisateurs et du management opérationnel.
28
Liens & Références

1. Anne-Marie Hugues © 19/12/02
2. “ Le management de projet “ de J-M HAZEBROUCQ et O.BADOT
3. “ Animer et Gérer un projet “ de L.BELLENGER et M-J COUCHAERE
4. “Fonctions dans la maîtrise d’ouvrage », de Michel Volle (2002), sous licence de

documentation libre GNU.
5. De l’Informatique : Savoir vivre avec l’automate, Michel Volle, Economica, 2006,

ISBN 2717852190)
6. DeMarco, Tom, Controlling Software Projects, New York: Yourdon Press,1982.
7. Jones,Capers. Assessment and Control of Software Risks. Englewood Cliffs

N.J.:Yourdon Press,1994. Estimation,Project management.
8. Lobet-Maris Claire, Nigot Sylvie, Henin Laurent (2002), Valorisation des résultats de
recherches COST, Namur, Mai 2002, 202 pages
9. Winston W. Royce. Managing the Development of Large Software Systems. IEEE

Wescon, p. 1-9, 1970
10. John McDermid et Knut Ripken. Life cycle support in the ADA environment.
University Press, 1984.
11. Barry W. Boehm. A Spiral Model of Software Development and Enhancement. IEEE
Computer, 21(5), p. 61-72, 1988.
12. James Martin. Rapid Application Development. Macmillan Coll. Div., 1991.
13. Philippe Kruchten. The Rational Unified Process: An Introduction. Addison-Wesley,

Longman Publishing, Co., Inc. Boston, Massachusetts, 2000.
14. PRATIQUES DE LA CONDUITE DU CHANGEMENT, Comment passer du discours

à l’action, David Autissier, Jean-Michel Moutot, DUNOD – 2003
15. http://www.gestion-projet-informatique.vivre-aujourdhui.fr/
16. GPI : http://projetsinformatiques.free.fr
17. Comment ç a marche : ht tp://w w w.commentc amarche.netht tp://w w w.

commentcamarche.net/
18. http://www.commentcamarche.net/
19. Gilb,Tom. Principles of Software Engineering Management. Workingham,Englang:

Addison Wesley,1988. Practical advices for estimating software schedule.Focus on
the importance of controlling the project to achieve your objectives rather than
passive prediction about it.
20. Shepperd, Martin, Fundation of Software Measurement, (1994) Le pourquoi et

comment des différentes méthodes de mesure de logiciels.
29
21. Katwijk, J. van, Inleiding software engineering, (1994)
22. Pressman, Roger S., (adapted by Darrel Ince) Software engineering “A practitioner’s
approach”, (1994)
30
Droits d’auteur
31
Siège de l’Université Virtuelle Africaine
The African Virtual University

Headquarters
Cape Office Park
Ring Road Kilimani
PO Box 25405-00603
Nairobi, Kenya
Tel: +254 20 25283333
contact@avu.org
oer@avu.org
Bureau Régional de l’Université

Virtuelle Africaine à Dakar
Université Virtuelle Africaine
Bureau Régional de l’Afrique de l’Ouest
Sicap Liberté VI Extension
Villa No.8 VDN
B.P. 50609 Dakar, Sénégal
Tel: +221 338670324
bureauregional@avu.org
2017 UVA
32

CSI 1205 - FR La Gestion de Projets Informatiques

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CSI 1205 - FR La Gestion de Projets Informatiques

Hochgeladen von

Copyright:

Verfügbare Formate

INFORMATIQUE APPLIQUÉE: CSI 1205

Ce module a été développé dans le cadre d’un programme de diplôme et diplôme en

Au nom de l’Université Virtuelle Africaine et notre patron, nos institutions partenaires,

L’Université Virtuelle Africaine (UVA) est une organisation intergouvernementale

Université Virtuelle Africaine

UVA – Coordination Académique

Dr. Marilena Cabral

Coordinateur global Sciences Informatiques Apliquées

Prof Tim Mwololo Waema

Barry Savala Mercy Tabi Ojwang

Edwin Kiprono Josiah Mutsogu

Kelvin Muriithi Kefa Murimi

Victor Oluoch Otieno Gerisson Mulongo

Projet Multinational II de l’UVA financé par la Banque africaine de développement.

La Gestion de Projets informatiques 7

I.1.1Qu’est-ce qu’un projet 7

I.1.2 Projet informatique : Une définition 7

I.1.3 La gestion de projet 7

I.2. Acteurs du projet 8

I.2.1 Maître d’Ouvrage (MOA) 8

Différentes fonctions MOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

I.2.2 Maîtrise d’Œuvre (MOE) 10

II. Le cycle de vie d’un projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

II.1 Les activités d’un cycle de vie d’un projet informatique 12

II.1.1. Etude d’opportunité et de faisabilité (Définition des Objectifs) 12

II.1.2. Analyse du système (Définition des Besoins) 12

II.1.3. Spécification et conception (Définition du Produit) 12

II.1.4 Planification et gestion de projet 12

II.1.5. Implémentation du système 13

II.1.6. Maintenance du système 13

II.2 Typologie des cycles de vie 13

II.2.1 Le modèle traductionnel 13

II.2.2 Le Modèle flexible ou expérimental 13

II.2.3 Modèle intermédiaire 14

II.3 Modèles de cycle de vie. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

II.3.1 Modèle en cascade 14

II.3.3 Le Cycle de vie évolutif 16

II.3.4 RAD (Développement rapide d’applications) 17

II.3.5 Cycle en spirale 19

III. Outils Pour La Gestion De Projet. . . . . . . . . . . . . . . . . . . . . . . . 20

III.1 Outils de conception de formalisation 20

III.1.1 La méthode MERISE 20

III.1.1.2 Le langage de modélisation UML 21

III.2 Outils de planification et de suivi 21

III.2.1 Le diagramme de Gantt 22

III.2.2 Le diagramme PERT : exploration des réseaux de tâches 23

III.2.4 Tableau de bord 24

III.3 Les outils informatiques 24

IV. La Documentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 25

V.1. Les objectifs de la gestion du changement 26

V.2 Méthodologies de la gestion du changement 27

Liens & Références. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

La Gestion de Projets informatiques

I.1.1Qu’est-ce qu’un projet

I.1.2 Projet informatique : Une définition

I.1.3 La gestion de projet

• les ressources disponibles et les attentes;

• la MOA, maîtrise d’ouvrage : le client du projet (mais pas forcément l’utilisateur) ;

I.2. Acteurs du projet

I.2.1 Maître d’Ouvrage (MOA)

Différentes fonctions MOA

a. Maître d’ouvrage délégué (MOAD)

b. La maîtrise d’ouvrage stratégique (MOAS)