INITIATION A LA GESTION DE

PROJET
UNA/SFA/L2 MI
Laboratoire de Mathématiques et
Informatique
2022 – 2023

Prof EDI Kouassi Hilaire

Maître de Conférences
Objectifs
À la fin de ce cours, l'étudiant(s) aura acquis les habiletés qui lui
permettront de :
• Comprendre les concepts de base en gestion de projets
• Définir le vocabulaire associé à la gestion de projet
• Décrire les outils et les ressources de la gestion de projet
• Décrire les cycles de la vie d'un projet
• Nommer les principaux éléments d'une proposition de projet
• Expliquer les principes d'organisation et de gestion efficace
du temps
• Expliquer l'importance d'identifier clairement les bénéfices
escomptés d'un projet, avant sa mise en chantier
La notion de projet

• Innovation = Projet
• Créer plus de valeur : innover

Création de Valeur
Productivité =
Coût

Coûts : n’est plus la solution idéale

• Concurrence
• Mondialisation
1
 Définition des critères pour les projets

 Toutes les initiatives ne sont pas des projets. Beaucoup

peuvent être gérées dans le cadre des opérations.
L’analyse de viabilité du projet détermine à partir de
quel point une initiative doit être traitée comme un
projet.
 Cette analyse peut aider à différentier les projets selon
le type de projet (mineur/normal / majeur) et vous
permettra de définir les méthodes à utiliser.
Définition des critères pour les projets
Différence entre projet et opérations
PROJET
Milieu
Inconnu, Innovant, organisation
temporaire
Processus historique
Décisions irréversibles
Incertitude forte
variables exogènes, degrés de
liberté
Cash-flow négatif
Il faut investir avant d’avoir un retour
Créer les futures activités
qui assurent l’avenir de l’entreprise
Difficulté
Gérer un “saut dans l’inconnu”
complexe
OPERATIONS
Milieu
Répétitif, organisation stable
Processus récurrent
Décisions réversibles
Incertitude faible
variables endogènes, actions encadrées
Cash-flow positif
le fonctionnement dégage un bénéfice
Maintient les activités existantes
celles qui font vivre l’entreprise
Difficulté
Intervenir rapidement en cas de
blocage 8
 La notion de projet
➢ Assurer, sur une « affaire » donnée, quelle qu’elle soit :
▪ la continuité dans le déroulement
• l’anticipation des contraintes et si possible des problèmes
• le partage des informations
• la coordination permanente entre les différents acteurs

➢ Le problème à résoudre :
• assurer au mieux les objectifs énumérés ci-dessus

➢ La solution :
• faire travailler ensemble, le plus tôt possible, et jusqu’au bon
achèvement, des représentants des principaux
acteurs concernés

➢ ... à partir de là, cette « affaire » devient un projet 2

 Le paradoxe de la gestion de projet
Capacité d’action sur le projet
Connaissance du projet

temps

• En début de projet : Marge de manœuvre plus importante

• En fin de projet, on sait ce qu’il aurait fallu faire, mais trop
8 tard… 3
 De l’étudiant au professionnel…
Un étudiant (projet personnel) :
1. Une seule personne
2. un problème isolé, abstrait…
3. …clairement défini : les données disponibles…
4. …bien posé : à solution unique
Exemple : Etude universitaire, Mobile money, taxi (« woro woro »), ….

Un professionnel (Entreprise) :
1. en équipe, pour un client
2. des problèmes liés, concrets
3. mal définis
4. ayant de nombreuses solutions possibles
Exemple : Infrastructure routière, barrage électrique, … 4
Quelques définitions

1993 : «Système complexe d’intervenants, de moyens et

d’actions, constitué pour apporter une réponse au besoin, exprimé ou
implicite, d’un maître d’ouvrage; le projet implique un objectif physique
ou intellectuel, des actions à entreprendre avec des ressources données.
Par assimilation, on appelle également projet l’ensemble des documents
produits pour réaliser le système, et le groupe de personnes constitué
dans ce but.»

2000 : « 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. »6 5
Quelques définitions

Projet = Entreprise ponctuelle ayant un début et une fin,

nécessitant la mise en œuvre de ressources humaines et
matérielles pour sa réalisation.

Un projet est une entreprise temporaire décidée dans le but de créer

un produit, un service ou un résultat unique.
Un projet est crée pour répondre à des stimuli de différents types:

- Résoudre un problème au sein de l’organisation

- Une avancée technologique
- Un besoin de marché
- Un alignement légal
- ….

6
 Caractéristiques d’un projet

➢ Caractéristiques fondamentales d’un projet :

❖ Unique par définition
• Même si on triche un peu des fois ...
❖ Limité dans le temps
• même si aucune limite précise n'est connue à ce stade
❖ Elaboration progressive
• Même si pour certain produit on connait la nomenclature

➢ Caractéristiques communes des projets :

❖ Défini par des objectifs en terme de durée, de coût et de conformité
• Vrai de toute activité industrielle
❖ Correspond à la mise en place d'une structure spécifique
• Vrai pour tout service fonctionnel (production notamment) 7
 Les missions dans le projet
Les missions se résume à trois points essentiels :

1) Mesure des écarts :

gestion de projet
Confiée à une équipe – projet

2) Conséquences à achèvement et mesures correctives :

pilotage de projet
Responsabilité d’un chef de projet

3) Modification d'objectif(s) :
Direction de Projet
Directeur de projet?
Comité de pilotage multi-projets?
9
Typologie des projets :
On classifie les projets selon deux types :
 origine de la demande
▪ Projets – clients
▪ Projets de développement
▪ Projets internes

 destination du produit
▪ Ouvrage unique
▪ Produit destiné à la série

 Essence matérielle ou non du produit

10
 Typologie des projets
Classification des projets selon l’origine de la demande :
« Projets – clients » : il existe un maître d’ouvrage identifié
• Il a la responsabilité de spécifier – on exécute conformément
• Finalité : un résultat attendu pour lui – même : bâtiment, usine, navire ...
• Aussi appelés « projets-ouvrages » ou « projets d’ingénierie »
... ou one-shot projects ...
« Projets de développement » : plein de clients potentiels (marché),
mais pas de maître d’ouvrage
• On a la responsabilité de spécifier et d’exécuter.
• Le marché sanctionnera ... après le projet.
• Aussi appelés « projets-produits » ou « projets marché »
Entre les deux : « Projets internes » :
• Ressemblent à des projets clients
• ... pour lesquels MOE et MOA sont confondus (« projets-ouvrages »
réalisés en interne)
• Ex : Plan de formation, déploiement d’un logiciel, déménagement ... 11
 Typologie des projets
Classification selon la destination du produit :
• Ouvrage unique (en général, projets - client)
Projet également unique par définition
La fourniture principale (ouvrage) n’a aucune vocation a être reproduite à
l’avenir

• Produit destiné à la série (en général, projets de développement)

Débouche sur des activités de production
Evolutions futures en fonction des attentes du marché (projets à venir?)

Classification selon l’essence matérielle ou non du produit

• Construction d’un barrage : éminemment matériel
• Plan d’assurance qualité : éminemment substanciel
• Produit logiciel ou travaux de recherche : aspect matériel (rapport, disque)
anecdotique ...
12
 Mise en place du projet
❖ Désignation du Chef de Projet
• polyvalent, expérimenté, animateur

❖ Former l'équipe de pilotage du projet

• Réflexion sur l’ensemble du projet, jusqu’à achèvement
• Les compétences concernées doivent être représentées
• Reste à désigner les individus …

❖ Définir les responsabilités

• des métiers
• des clients, des fournisseurs, des partenaires
• au sein de l'équipe projet
• entre le projet et la direction, entre le projet et les services

❖ Définir le mode de fonctionnement de l’équipe

• « informel, statutaire, formel »… 13
INFLUENCES
ORGANISATIONNELLES
Les projets sont généralement exécutés au sein des organisations. Ces
dernières peuvent par conséquent influencer l’achèvement des objectifs
des projets par leur maturité organisationnelle, leur style de
management leur culture, leur structure organisationnelle, et même leur
bureau de projet.

Systèmes organisationnelles
Certaines organisations sont basées sur les projets par exemples les
cabinets de consultation, les cabinet d’architectes, les sociétés de
construction. Leur source de revenu est basée sur les projets, chaque
contrat est un projet. Dans ce genre d’organisation le management de
projet est facilité.

14
INFLUENCES
ORGANISATIONNELLES
Dans les organisations qui ne sont pas basées sur les projets, ils n’ont
généralement pas de système de management de projet il devient en
effet plus difficile d’y opérer les projets.

Cultures et styles organisationnelles

Chaque organisation définit une culture et un style organisationnel
propre à elle, cela se définit par les politiques et procédures internes, les
convictions et valeurs, les perception des relations d’autorité, l’éthique
de travail et les horaires de travail

Structures organisationnelles
Il existe trois catégories de structures organisationnelles
- Structure fonctionnelle
- Structure Matricielle
- Structure orientée projets 15
INFLUENCES
ORGANISATIONNELLES
Coordination du projet

Directeur
Général

Responsable
Responsable Responsable
fonctionnel
fonctionnel fonctionnel

Chef Service Chef Service Chef Service Chef Service Chef Service Chef Service Chef Service

Personnel Personnel Personnel Personnel Personnel Personnel Personnel

Personnel Personnel Personnel Personnel Personnel Personnel Personnel

Organisation fonctionnelle
16
 INFLUENCES
ORGANISATIONNELLES
Organisation Directeur
Matricielle faible Général

Responsable Responsable Responsable

fonctionnel fonctionnel fonctionnel

Personnel Personnel Personnel

Personnel Personnel Personnel

Coordination
Personnel Personnel Personnel du projet

Personnel Personnel Personnel

17
 INFLUENCES
ORGANISATIONNELLES
Organisation Directeur
Matricielle Général
équilibrée
Responsable Responsable Responsable
fonctionnel fonctionnel fonctionnel

Personnel Personnel Personnel

Personnel Personnel Personnel

Coordination
du projet
Personnel Personnel Personnel

Chef de
Personnel Personnel
projet 18
 INFLUENCES
ORGANISATIONNELLES
Organisation Directeur
Matricielle Général
forte
Responsable Responsable Responsable des
fonctionnel fonctionnel chefs
de projet
Personnel Personnel
Chef de
projet
Personnel Personnel
Chef de
projet
Coordination
Personnel Personnel du projet
Chef de
projet
Personnel Personnel
Chef de
projet 19
 INFLUENCES
ORGANISATIONNELLES
Organisation Directeur
par projets Général
Chef de Chef de Chef de
projet projet projet

Personnel Personnel Personnel Coordination

du projet
Personnel Personnel Personnel

Personnel Personnel

Personnel Personnel

Personnel 20
21
 Les étapes du projet
 Chaque étape fait l'objet d'un livrable et d'une validation à partir
d'un document spécifique.
=>Cela permet de maîtriser la conformité des livrables à la
définition des besoins ainsi que de s'assurer de l'adéquation aux
objectifs de coûts et de délai.
=> A chaque étape, il peut être décidé d'arrêter le projet si la
maîtrise d'ouvrage estime que les objectifs ne pourront pas être
tenus.

 On appelle " cycle de vie du projet " l'enchaînement dans le temps

des étapes et des validations entre l'émergence du besoin et la
livraison du produit.
22
 Les étapes du projet
La transition d’une phase à une autre nécessite une sorte de validation du
livrable intermédiaire. Cette validation de phase peut être appelée de
plusieurs façons: Portes, GO/NO GO, Kill Point, Stage Gate, Revue de
Phase, VAR Value assurance review suivant l’organisation utilisatrice.
Toutefois il est possible qu’une phase commence avant la validation totale
des livrables de la phase précédente et ceci n’est possible que lorsque les
risques auxquelles l’organisation s’expose sont jugés acceptables.
Il n’existe pas de cycle de vie unique pour les projets néanmoins il est
possible de trouver des cycles de vie privilégié par secteur d’activité.
Généralement on trouve trois grandes étapes.
❖ L’avant projet : la phase préparatoire
❖ La phase de réalisation
23
❖ Phase de mise en œuvre
 L’avant projet : la phase préparatoire

Définir précisément ce que sera le projet afin d'aboutir à la mise au

point de documents contractuels (faisant lieu d'un contrat) permettant
d'engager la maîtrise d'œuvre et la maîtrise d'ouvrage dans le lancement
du projet. Cette phase regroupe quatre étapes :

 L'étude d'opportunité
 L'étude de faisabilité
 L'étude détaillée
 L'étude technique
24
 L’avant projet : la phase préparatoire
 L'étude d'opportunité
◼ But : étudier la demande des utilisateurs par rapport aux
objectifs généraux de l'organisation et décider si le concept est
viable.
 définir le périmètre du projet (contexte) = définir les
utilisateurs finaux, c'est-à-dire ceux à qui l'ouvrage est
destiné (on parle de ciblage ou profilage).
 Identifier les besoins généraux de la maîtrise d'ouvrage. Il
est nécessaire de s'assurer que ces besoins correspondent à
une attente de l'ensemble des utilisateurs cibles et qu'ils
prennent en compte les évolutions probables des besoins.
25
 L’avant projet : la phase préparatoire
 L'étude d'opportunité

 rédaction d'un document nommé " note de cadrage « (= le

livrable), validée par le Comité de Pilotage du projet (et
éventuellement les instances décisionnelles selon l'enjeu du projet).
La note de cadrage officialise l'intention de projet.

 Lorsque l'idée du projet est formalisée, le Comité de Pilotage doit

officialiser la mission du responsable de projet et en définir les
clauses. La lettre de mission (éventuellement note de mission) est
le document qui officialise la mission du responsable de projet.
26
 L’avant projet : la phase préparatoire
 L'étude de faisabilité
◼ vise à analyser la faisabilité économique, organisationnelle et technique
de projet.
◼ Analyse des besoins : à partir de l'analyse sommaire des besoins il
convient de faire une estimation grossière du coût d'investissement et
de fonctionnement du projet (en terme de moyens humains et
matériels), des délais envisagés et des éventuels retours sur
investissement.
◼ L'étude de scénarii : l'étude de faisabilité conduit à envisager plusieurs
scénarii pour évaluer les risques pesant sur le projet et s'accompagne
d'un bilan prévisionnel présentant le coût et les avantages du scénario.
Cette étape fait l'objet d'un livrable, le dossier de faisabilité, remis au
27
Comité de Pilotage afin que chaque scénario soit étudié.
 L’avant projet : la phase préparatoire

 L'étude détaillée
◼ Étude plus approfondie des besoins (" conception générale « )
pour que la maîtrise d'ouvrage et la maîtrise d'œuvre puissent
s'entendre sur un document contractuel.
◼ Les besoins sont exprimés uniquement de manière
fonctionnelle et non en terme de solutions. L'analyse
fonctionnelle des besoins permet ainsi de dégager les
fonctionnalités nécessaires de l'ouvrage.

28
L’avant projet : la phase préparatoire
❑ L'étude détaillée
◼ L'analyse fonctionnelle aboutit à la mise au point d'un
document définissant fonctionnellement le besoin
(indépendamment de toute solution technique) : cahier des
charges fonctionnel (généralement abrégé sous la forme
CdCf) ou dossier de conception.
◼ Le Cahier des charges permet à la maîtrise d'ouvrage
d'exprimer son besoin de manière fonctionnelle, ainsi que de
clarifier les contraintes imposées à la maîtrise d'œuvre.
◼ Le cahier des charges fonctionnel constitue donc un document
contractuel entre le maître d'œuvre et le maître d'ouvrage.
29
 L’avant projet : la phase préparatoire
 L'étude technique
◼ L'étude technique est la phase d'adaptation de la conception à
l'architecture technique retenue, tout en décrivant et
documentant le fonctionnement de chaque unité du logiciel.
◼ Le livrable de l'étude technique est le Cahier des Clauses
Techniques Particulières (CCTP) ou cahier des charges
détaillé. L'étude détaillée peut éventuellement s'accompagner
de la création d'une maquette, ou prototype, permettant aux
représentants des utilisateurs de vérifier que la solution retenue
répond bien à leurs attentes.
30
 La phase de réalisation

 La préparation
◼ découper le projet en tâches afin de planifier l'exécution de ces
tâches et de définir les ressources à mobiliser. Les outils et
méthodes suivantes sont généralement utilisées :
 L'organigramme des tâches, parfois appelé organigramme
technique de projet (OTP), permettant de découper les
projets en tâches élémentaires (itemisation)
 La méthode Pert
 Le tableau GANTT
◼ Il revient au maître d'oeuvre de mettre en place des procédures 31
 La phase de réalisation

 La réalisation
◼ étape de développement de l'ouvrage sous la responsabilité du
maître d'œuvre, et sous contrôle du maître d'ouvrage. L'accent
doit être mis sur la communication afin de pouvoir prendre
les décisions au plus vite en cas de problème.
◼ La mise en place d'un plan de communication permet
d'animer le projet, par exemple au travers :

32
 La phase de réalisation
 La réalisation
 de l'utilisation d'un tableau de bord de pilotage, présentant
graphiquement les résultats du projet, permettant au chef de
projet de prendre les décisions d'arbitrage en cas de
déviations.
 d'un rapport d'avancement permettant à tous les acteurs du
projet d'être informé des actions en cours et achevées
(« reporting » = ensemble des actions de préparation et de
présentation de rapports d'activité).
 réunions régulières afin de manager l'équipe projet, c'est-à-
dire faire un point régulier sur l'avancement du projet et fixer
les priorités pour les semaines suivantes. 33
 La phase de réalisation
 Documentation
◼ Elle accompagne nécessairement l'ouvrage lors de la livraison. La
documentation est souvent incomplète ou non à jour et pourtant il
s'agit d'une des facettes essentielles de l'ouvrage car elle constitue le
référentiel de base concernant l'ouvrage après réalisation.
 Validation
◼ Lorsque l'ouvrage est réalisé, il convient que le maître d'œuvre
s'assure qu'il répond au cahier des charges. On parle de tests unitaires
pour désigner la validation par le maître d'œuvre de la conformité du
produit à chacune des clauses du cahier des charges.
34
 Phase de mise en œuvre
 Recette
◼ " recette " (ou essais de réception) = vérification de la conformité de
l'ouvrage à la demande formulée dans le dossier validé de conception
générale.
◼ processus rigoureux et méthodologique effectué dès la réception de la
commande.
◼ est parfois dite provisoire pendant une période de temps appelée délai
de garantie.
◼ Cette étape se conclue lors de l'expiration du délai de garantie par la
rédaction d'un dossier de recette (procès-verbal de réception définitive)
cosigné par le maître d'œuvre et le maître d'ouvrage contenant les
remarques du maître d'ouvrage et éventuellement le refus de l'ouvrage
35
s'il n'est pas conforme au cahier des charges.
 Phase de mise en œuvre

 Qualification
◼ La qualification consiste à vérifier la conformité des capacités
de l'ouvrage aux spécifications techniques du maître d'ouvrage.
◼ Mise en production
 Sites pilotes : la mise en place de sites pilotes permet de
tester l'ouvrage dans sa dimension technique, comme dans
celle de l'organisation et de l'adhésion des utilisateurs.
L'expérience des sites pilotes permet de préparer le
déploiement, de mieux en apprécier la charge, et d'en
identifier les difficultés a priori.
36
 Phase de mise en œuvre
◼ Généralisation
 déploiement en masse de l'ouvrage auprès des utilisateurs finaux.
 Un déploiement réussi sur les sites pilotes ne signifie pas
systématiquement que le déploiement généralisé va réussir. En
effet, lors de l'expérimentation, les utilisateurs ont une motivation
que les utilisateurs finaux n'ont pas. De plus chaque
dysfonctionnement de l'ouvrage est mis sur le compte de
l'expérimentation. La généralisation implique généralement des
changements dans la façon de travailler des utilisateurs, ce qui
freine l'adoption du produit par les utilisateurs.

37
 Phase de mise en œuvre

◼ Généralisation
 On désigne ainsi par " conduite du changement " tous les
éléments permettant de faire en sorte que les utilisateurs
finaux utilisent réellement le produit, et donc changent leurs
habitudes. Ce terme englobe notamment la formation des
utilisateurs à l'utilisation du produit ainsi que
l'accompagnement des utilisateurs (hot line).

38
 Phase de mise en œuvre
◼ Généralisation
 lorsque le projet vise un nombre d'utilisateurs finaux très
important, il n'est souvent pas envisageable de passer
directement d'une expérimentation à une généralisation. Selon
l'ouvrage il peut être nécessaire de faire des tests de montée en
charge (on trouve parfois le terme de montée en cadence), c'est-
à-dire simuler un nombre d'utilisateurs de plus en plus grand
afin d'estimer si le produit est potentiellement capable de
supporter la charge totale (utilisation simultanée par le nombre
d'utilisateurs prévu dans le cahier des charges).
39
 Phase de mise en œuvre
 Capitalisation
◼ archiver, l'expérience métier (savoir-faire) qui découle du projet
afin d'améliorer l'efficacité de la conduite pour les projets futurs.
◼ Une réunion de bilan sur le projet (debriefing) est bénéfique pour
les acteurs du projet car elle permet de passer en revue toutes les
déviations du projet et les mesures correctives entreprises.
 Maintenance
◼ ensemble des opérations de modification d'un logiciel opérationnel
laissant intactes ses fonctionnalités de base.
◼ permet de maintenir un système en fonctionnement en rectifiant les
anomalies de l'ouvrage et en prenant en compte les demandes
d'évolution des utilisateurs. 40
Définition de gestion de projet

On appelle " gestion de projet " (éventuellement " conduite de

projet ") l'organisation méthodologique mise en œuvre pour faire
en sorte que l'ouvrage réalisé par le maître d'œuvre réponde aux
attentes du maître d'ouvrage et qu'il soit livré dans les conditions
de coût et de délai prévus initialement, indépendamment de sa "
fabrication ".
La gestion de projet a pour objectifs d'assurer la coordination des
acteurs et des tâches dans un souci d'efficacité et de rentabilité.

41
Bureau du projet :
comité de pilotage
Un Bureau de Projet est une unité organisationnelle qui centralise le
management de projet.

Un Bureau de Projet prend habituellement un des 3 rôles suivants :

1. Fournit les politiques, méthodologies, modèles pour manager les
projets a l’intérieur de l’organisation.
2. Donne des conseils et soutient les autres de l’organisation sur comment
manager les projets, les forme en management de projet ou logiciel de
management de projet, les assiste avec les outils spécifiques de
management de projet.
3. Affecte les chefs de projet aux différents projets et est responsable des
résultats de ces projets. 42
 Fonction du bureau du projet
Une fonction clé du bureau des projets est d’apporter aux chefs de
projet un soutien qui peut revêtir divers aspects, dont entre autres :

▪ Le management des ressources partagées entre tous les projets gérés par
le bureau
▪ L’identification et le développement d’une méthodologie de management
de projets, des meilleures pratiques et des normes.
▪ L’animation, le mentorat, la formation et la supervision
▪ La surveillance, par des audits de projet, de la conformité aux politiques
de normes, procédures et modèles de management de projet.
▪ L’élaboration et la gestion pour ce qui est des projets, des politiques,
procédures, modèles et autres documentations partagées (actifs
organisationnels)
▪ La coordination de la communication entre les projets. 43
La gestion projet : un paradoxe?

Le choix d'une méthodologie pour conduire un projet parait

souvent contraignante,
Mais c’est un atout permettant à tous les acteurs de projet de mener
conjointement une action organisée selon des règles clairement
exprimées.
Cette méthodologie commune est importante car les acteurs du
projet sont parfois amenés à changer en partie au cours du
projet.

44
Méthodologie de la gestion de projet

AFITEP Monde Francophone (France, Québec)

PMI Méthodologie de management de projet

sponsorisée par les USA

Prince2 Méthodologie de management de projet

sponsorisée par la Grande Bretagne

V-Modell Méthodologie de management de projet

sponsorisée par l’Allemagne

HERMES Méthodologie de management de projet

sponsorisée par la Suisse 45
L’utilité de la méthodologie de la gestion
de projet

 Multiplicité des acteurs mobilisés = source de difficultés

=> l'expression du besoin et la satisfaction de ce besoin sont
portés par des acteurs généralement distincts.
=> il 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 ".

46
 Une des particularités de la gestion de
projet
Projet ≠ relation " vendeur / acheteur " classique
1. un client achète un produit déjà réalisé afin de satisfaire
un besoin
2. le projet vise à produire une création originale répondant
à un besoin spécifique qu'il convient d'exprimer de
manière rigoureuse. Cette expression des besoins est
d'autant plus difficile que le projet n'a généralement pas
d'antériorité au sein de l'entreprise étant donné son
caractère novateur.
47
 De la théorie à la pratique…
 La gestion de projets est souvent réalisée dans
l’à peu prés :
◼ équipes inadaptées,
◼ chefs de projet peu impliqués,
◼ périmètre de projets élastiques,
◼ plannings fantaisistes,
◼ coûts mal maîtrisés.

48
 Théorie : Coût, délais, qualité
 Coût :
◼ respecter le budget définis lors du lancement du projet,
◼ identifier les risques de déviation
◼ mettre en oeuvre les mesures de correction appropriées
 Délais :
◼ réaliser le projet dans le respect des délais annoncés au
client, (en respectant les principaux jalons).
◼ Identifier les risques de dérapage de planning
◼ mettre en oeuvre les mesures de correction appropriées
 Qualité :
◼ réaliser le projet dans le respect de l'état de l'art
◼ valider chaque étape de la réalisation avec les différents
intervenants. 49
 Pratique : Coûts, délais, qualité
 Coût: le coût a été volontairement sous estimé
◼ dès le départ pour faire passer le projet,
◼ parce que toutes les difficultés du projet, ou toutes les tâches à réaliser n'ont
pas été identifiées,
 Délais :
◼ la pression de la Direction étant forte, les délais sur les plannings ont été tirés
au delà du bon sens. Le respect du planning est donc impossible avant même
que le projet ne commence…
 Qualité :
◼ au début, les développeurs perfectionne leur code, mais au fur et à mesure de
l'avancement, les besoins de l'utilisateur n'étant pas exprimés ou mal
exprimés, les "rustines" informatiques se multiplient. L'application devient
petit à petit l'usine à gaz classique. Alors on peut dire adieu à la qualité.
50
Coût d’un projet et d’un produit

Coûts d’utilisation
Coûts de
Lancement du production Utilisation et
projet Après-vente
Production
en série
Conception
Développeme
01 02 A B nt
C D

Investissement

51
 Les tâches dans la gestion de projet

 La gestion de projets ≠ planification.

◼ la planification consiste à ordonnancer des tâches
les unes par rapport aux autres et à les positionner
dans le temps

◼ la planification n'est qu'une des tâches de la

gestion de projets : il y en a beaucoup d'autres.

52
 Les tâches dans la gestion de projet

 La définition du projet : s'assurer que la définition du projet

est correcte tant sur le fond - les réels besoins, que sur la
forme - a t on toutes les données ?
 La définition du périmètre du projet (interventions, ...)
 L'identification des ressources nécessaires et suffisantes
 L'identification des coûts du projet, et des financements
 L'élaboration des dates jalons, des délais nécessaires à la
réalisation (élaboration du planning)
 La maîtrise des dépenses dans le cadre des budgets alloués
53
 Les tâches dans la gestion de projet
 La définition des critères de qualité nécessaires, des moyens de contrôle et
du contrôle final
 Le management des différentes équipes pour s'assurer d'une cohérence des
objectifs de chacun avec l'objectif final
 La gestion des avancements de tous les acteurs pour identifier au plus tôt
tous les problèmes rencontrés, les dérapages de planning ou de coûts :
(pour pouvoir mettre en place les mesures les plus appropriés au meilleur
moment)
 La coordination et contact avec tous les acteurs dans le cadre du projet,
 Etc...
=> Les tâches de gestion sont très diversifiées et s'étendent bien au delà
de la simple définition du " Quand ". 54
Les parties prenantes d'un projet

 Maîtrise d’ouvrage (MOA)

 Maitrise d’œuvre (MOE)

 L’Equipe projet

 Les responsable Hiérarchiques

 Les partenaires

 Le comité de pilotage

55
Introduction
 Suivant la nature du projet il peut exister
plusieurs types de parties prenantes qui
peuvent avoir des intérêts parfois divergents.
 Dans certains projets certaines parties
prenantes peuvent jouer plusieurs rôles à la
fois.
 Nous allons présenter les principales parties
prenantes qui peuvent être des individus ou
des organisations.
 Maîtrise d’ouvrage et maîtrise d’œuvre
 La maîtrise d'ouvrage :
◼ l'entité responsable de l'expression du besoin. Cette expression de besoin se
fait en langage courant, sans utilisations de termes informatiques, au besoin à
l'issue d'un Audit interne sur le sujet.
◼ équipe (souvent composée de non informaticiens) qui maîtrise l'idée de
base du projet, et initialise toute la démarche permettant de lancer la
concrétisation de l'idée.
◼ doit s'assurer qu'il existe un budget pour sa réalisation ainsi qu'un besoin réel.
◼ centralise la connaissance métier nécessaire à la réalisation
◼ est en en relation directe avec les futurs utilisateurs dont elle connaît
parfaitement les méthodes de travail : les grandes fonctionnalités, les
principales règles de gestion, ...
◼ doit pouvoir trancher sur toutes les questions fonctionnelles qui pourraient se
56
poser pendant l'étude
 Maîtrise d’ouvrage et maîtrise d’œuvre
 La maîtrise d'ouvrage déléguée
◼ équipe intermédiaire plus rompue à la gestion de projet :
 composée de collaborateurs habitués à la poursuite de projets,
intervient en renfort méthodologique et épaule la maîtrise
d'ouvrage à la fois dans la démarche projet et dans l'expression de
leur besoin.
 composées de quelques informaticiens ou de collaborateurs ayant
une bonne idée des contraintes informatiques et des besoins en
formalisation, les maîtres d'ouvrage délégués savent
généralement dialoguer avec la maîtrise d'oeuvre.
◼ chargée de faire l'interface entre le maître d'oeuvre et le maître
d'ouvrage :
 aider le maître d'ouvrage à définir clairement ses besoins et de
vérifier auprès du maître d'oeuvre si l'objectif est techniquement
réalisable.
◼ ne se substitue pas pour autant à la maîtrise d'ouvrage et n'a donc pas
de responsabilité directe avec le maître d'oeuvre.
57
Maîtrise d’ouvrage et Maîtrise d’œuvre

 maître d'ouvrage ≠ maître d'œuvre : la distinction est cruciale

et cette ignorance peut coûter cher au projet.
 souvent les responsabilités des maîtrises d'ouvrage de projets
informatiques se déportent partiellement ou complètement
vers les maîtrises d'œuvre :
◼ dans certains cas que la maîtrise d'ouvrage délègue à la maîtrise
d'oeuvre des choix d'ordre fonctionnel sous prétexte d'une
insuffisance de connaissances techniques (de façon concrète le
service informatique d'une organisation prend la main et pilote
le projet dès la phase d'expression des besoins).
◼ Or seul le maître d'ouvrage est en mesure de connaître le besoin
de ses utilisateurs. Une mauvaise connaissance des rôles des
deux entités risque ainsi de conduire à des conflits dans
lesquels chacun rejette la faute sur l'autre. 58
Maîtrise d’ouvrage et Maîtrise d’œuvre

 La distinction entre maîtrise d'oeuvre et

maîtrise d'ouvrage est encore plus difficile
lorsque les deux entités font partie de la même
structure d'entreprise.

=> il est essentiel de bien définir

contractuellement les rôles respectifs des
deux entités.
59
 Maîtrise d’ouvrage et Maîtrise d’œuvre
 Les conséquences de l’indistinction :
◼ la maîtrise d'oeuvre joue les deux rôles à la fois : c'est elle qui
décide des fonctionnalités, des règles de gestion, des process
métiers à mettre en place, et c'est elle qui réalise l'ensemble, en
espérant qu’elle réponde au réel besoin de son client.
=> ce qui est développé ne correspond en rien à ce
qu'attendait secrètement la maîtrise d'ouvrage, et les ennuis
commencent.
◼ le conflit est assuré. Chacun va dépenser une énergie folle à se
défendre et à accuser l'autre, à chercher les responsables.
Personne n'en sort indemne ni d'un côté ni de l'autre, et surtout
pas l'entreprise entière qui attend toujours son projet
informatique. 60
 Maîtrise d’ouvrage et Maîtrise d’œuvre

 Pour le bon déroulement du projet:

◼ il est nécessaire de définir clairement les rôles de chaque entité
et d'identifier au sein de la maîtrise d'ouvrage et de la maîtrise
d'oeuvre un représentant.
◼ Un groupe projet associant les chefs de projet de la maîtrise
d'ouvrage, de la maîtrise d'œuvre(et de la maîtrise d'ouvrage
déléguée éventuelle) doit ainsi se réunir lorsque cela est
nécessaire pour résoudre les conflits liés aux exigences de la
maîtrise d'ouvrage ou à la coordination du projet.
 Enfin, il est essentiel d'établir un plan de formation
permettant à la maîtrise d'oeuvre et à la maîtrise d'ouvrage
d'avoir un langage commun et de s'entendre sur une méthode
de conduite de projet, de conduite d'entretiens ou de réunions,
etc. 61
Chef de projet

Un " chef de projet " est nommé au niveau de la

maîtrise d'ouvrage (MOA) afin d'être en relation
permanente avec le chef de projet du côté de la
maîtrise d'œuvre (MOE).
L'AFNOR préconise que " responsable de projet "
soit utilisé de façon préférentielle pour désigner le
chef de projet de la maîtrise d'ouvrage.
Les termes " chef de projet utilisateur " ou "
directeur de projet " sont parfois également
employés.

62
Portrait du chef de projet (MOE)

 ses missions
◼ Le chef de projet est celui qui va animer tout le projet, celui qui va battre la
mesure pour que toutes les équipes pagayent de la meilleure façon possible
et surtout dans la même direction.
 Le chef de projet est la personne responsable chargée d’atteindre les objectifs
du projet.
 Selon la structure organisationnelle, un chef de projet peut dépendre
hiérarchiquement d’un responsable fonctionnel.
 Il a en charge de bien définir le périmètre de son projet,
 Il doit définir les ressources nécessaires au projet et les délais nécessaires pour
chaque tâche,
 Il coordonne les différentes équipes qui vont se charger de la réalisation
 Il fait le lien avec le client final (la maîtrise d'ouvrage)
 Il reporte tous problèmes et communique sur l'avancement du projet
 Il gère les dépenses en charges, en coûts,...
63
 Etc...
Portrait du chef de
projet (MOE)
 Le chef de projet doit être dégagé de ses activités et
de ses responsabilités courantes afin de se consacrer
à la gestion du projet :
◼ le chef de projet mène une activité à temps plein
 Sinon : absence de surveillance, retards dans les
prises de décisions et dans les actions correctrices,
manque de définition du périmètre fonctionnel,
absence de moteur véritable pour piloter l'ensemble
des acteurs du projet...

64
Comment choisit-on un chef de projet ?

 Le choix du chef de projet est capital.

 En fonction des disponibilité du
personnel…
◼ Souvent le choix se résume aux collaborateurs
disponibles !
 En fonction des niveaux hiérarchiques du
personnel
◼ Quelque fois, ce poste est tenu tout simplement
par le manager ayant le niveau hiérarchique le
plus élevé. Sinon = perdre un peu de pouvoir. Or,
on peut être à la fois excellent manager et très
mauvais chef de projet 65
 Comment choisit-on un chef de projet ?

 En fonction du parcours dans l’entreprise

◼ la fonction de chef de projet comme promotion au meilleur développeur
informatique.
 C'est souvent une bonne idée si le développeur
◼ est motivé : s’il a l'envie de faire plus de management que de
programmation,
◼ a développé au cours des années une bonne connaissance du métier et
de ses contraintes.
◼ s’il est capable de voir le projet dans sa globalité, sur des aspects
autres que techniques.
 C'est quelque fois aussi une très mauvaise idée :
◼ le collaborateur peut accepter le poste sans pour autant ni avoir l'envie
ni avoir la connaissance pour les choses de gestion. Le risque serait
donc qu'il tente par tous les moyens de rester plongé dans sa
technique, négligeant par manque d'intérêt tous les aspects de gestion
des coûts / délais / qualité, et aussi tous les autres aspects annexes
(communication avec les autres acteurs, ...).
66
 Le chef de projet idéal…

Être Rigoureux
= la faculté de ne laisser passer aucun détail du projet :
◼ ambiguïté sur une décision ou une fonctionnalité, etc...
◼ prévoir tous les risques potentiels
◼ noter chaque décision et vérifier la bonne prise en compte,
◼ identifier toutes les tâches sans en oublier une seule,
◼ identifier toutes les questions restées en suspend et n'en
laisser aucune sans réponse,
◼ garder des traces de chaque décision, etc ...
≠ raideur : l'impossibilité d'accepter de changer d'idée, de
s'adapter à une nouvelle situation, à un nouveau contexte.
67
 Le chef de projet idéal…

 Être un bon communicant

◼ Savoir exprimer ces idées à l’oral et par écrit
◼ Savoir écouter : être ouvert au dialogue
 = compréhension des autres (à l'écrit et à l'oral), ouverture sur
leurs idées.
 Être convaincant
◼ ≠ " avoir un mauvais caractère " !
◼ Les positions de la hiérarchie ou de la maîtrise d'ouvrage
sont quelque fois à l'opposé des conditions optimales pour
la réussite du projet, et il est du devoir du chef de projet
de faire entendre sa parole et de convaincre ses
interlocuteurs. 68
 Le chef de projet idéal…
 Avoir une vision d’ensemble du projet
◼ Prendre les bonnes décisions dans un cadre réaliste : un bon
chef de projet ne s’aventurerait pas à réaliser un développement
avant une étude technique…
 Être compétent en informatique
◼ Pour juger de la pertinence d'un planning
◼ Pour défendre le projet et en connaître les contraintes et les
risques techniques.
 Avoir quelques connaissances de ce qu’est la gestion de projet.
◼ sur les techniques et le vocabulaire utilisé dans la gestion de
projet pour savoir vraiment de quoi on parle.
69
 Le chef de projet idéal…
 Être réactif
◼ = faculté de réagir vite et bien à un événement.
 Exemple : si le chef de projets a la connaissance d'une
adéquation entre les technologies utilisées par ses prestataires
et les contraintes de sa plateforme technique, s'il réagit après
plusieurs jours, tous les développements réalisés pendant ce
laps de temps sont bons pour la poubelle.
 Être reconnu par sa hiérarchie
◼ l'identification et la reconnaissance du statut par la hiérarchie
auprès des autres acteurs du projet est primordiale = désigner
officiellement le collaborateur comme étant chef de projets et
unique interlocuteur auprès des autres acteurs du projet.
70