Conduite de Projet et Techniques

Première partie :
Rappel Cahier des Charges
Principes et Concepts de la
Planification
Page 1

Yves LALOUM
 Plan
• 1 Qu’est-ce qu’un projet ?
– Rappel des principaux concepts et du
vocabulaire
– Cahier des Charges
– Principes et concepts de la Planification
– Les logiciels de Gestion de Projet

Page 2

Yves LALOUM
 1. Qu’est-ce qu’un projet?

• Un projet se distingue par :

- Un besoin unique, non répétitif
- Une durée déterminée
- Une activité créatrice
- Une complexité
- Une variété d’intervenants indépendants
qu’il faut coordonner.

Page 3

Yves LALOUM
 Définition d ’un projet :
AFNOR, X50-105d ’août 91

• D’après l’AFNOR, X50-105 d’août 91, “ un projet

se définit comme une démarche spécifique, qui
permet de structurer méthodiquement et
progressivement une réalité à venir.Un projet est
défini et mis en œuvre pour élaborer la réponse
au besoin d’un utilisateur, direct ou d’une
clientèle et il implique un objectif et des actions
à entreprendre avec des ressources données ”.
Page 4

Yves LALOUM
 Les phases d’un projet
Faisabilité ?
Maître d’ouvrage

Contrôle de la
Payeur
validité du besoin ?
Conception

Définition

Réalisation Maître d‘oeuvre

Mise en place
Réalisateur
Constructeur
Mise à disposition

Essais

Besoin satisfait Maître d’ouvrage

Utilisation
Utilisateur

Page 5

Yves LALOUM
 Piloter un Projet

Le pilotage d’un projet

doit se faire en
Technique
recherchant en
permanence l’équilibre
délai-coût, dans le
Projet respect de la
technique, pas plus ni
Délai Coût
moins.

Page 6

Yves LALOUM
 Rôle du Chef de Projet

• répondre au cahier des charges à la bonne date,

au coût prévu ou inférieur

• À chaque aléa, l’art du planificateur est alors de

savoir trouver le meilleur compromis, entre le
délai et le coût.

Page 7

Yves LALOUM
 Rappel sur le cahier des charges

Page 8

Yves LALOUM
 GÉNÉRALITÉS SUR
LE CAHIER DES CHARGES (CDC)
1. Introduction
2. L’infrastructure de développement
3. Les composants de développement
4. Les attributs du système
5. Définition et rôle
6. Les études de besoins des utilisateurs
7. Différents types de cahiers des charges
8. Les caractéristique générales d’un CDC
Page 9 9. Les risques techniques d’un CDC incomplet
Yves LALOUM
 Le cahier des charges :
Introduction
• Le cahier des charges = la présentation contractuelle de
la synthèse de l’expression des besoins.

• La notion de cahier des charges vient de la nécessité

d’engagements réciproques entre un donneur d’ordre et
un sous-traitant (interne ou externe), relation
client/fournisseur.

• Un environnement de développement a une

infrastructure de développement, des composants de
développement et des attributs.
Page 10

Yves LALOUM
 L’infrastructure de développement
• Des objets externes (générateur de requêtes SQL,
générateur d’états, outils de communication, gestionnaire
de base de données).

• Des interfaces qui comprennent elles-mêmes :

- Les outils de définition des interfaces utilisateurs et
dans un mode client/serveur, les outils des clients ;
- Les appels à des sous-systèmes , en particulier les
API ;
- Les interfaces du système avec le ou les réseaux
locaux ou distants.
Page 11

Yves LALOUM
 Les composants de développement
• Les supports aux outils de développement,
documentation, formation et assistance.
• Les outils de gestion du projet pour la gestion du
développement et des processus de développement.
• Les outils d’ingénierie de production décomposées en :
- Outils de spécification pour définir des applications à partir de
l’analyse des besoins et de définition de l’architecture logicielle ;
- Outils de génération de code, de spécialisation et d’affinage du
code, de débogage et d’assemblage ;
- Outils de tests ;
- Outils d’analyse conceptuelle, de simulation et d’analyse de la
consistance;
Page 12 - Outils de simulation, d’analyse de la consistance et conceptuelle.
Yves LALOUM
 Les attributs du système
• Les caractéristiques du produit final :
- L’assurance de bon fonctionnement, de pérennité ;
- L’interopérabilité du système avec d’autres;
- La facilité d’usage ;
- L’évolutivité ;
- La réutilisabilité de tout ou partie pour d’autres applications ;
- La performance ;
- La portabilité sur d’autres matériels et/ou d’autres systèmes;
- La gestion des risques techniques propres au produit.
• Les caractéristiques propres au projet et à son
management :
- Les coûts du projet ;
- Le planning de mise en œuvre et de réalisation du projet ;
- La gestion des risques financiers et des risques inhérents au
management du projet.
Page 13

Yves LALOUM
 Quand faire un cahier des charges ?
Client Cahier des charges Fournisseur

Dialogue

Produit ou Service

Page 14

Yves LALOUM
 Quand faire un cahier des charges ?
• Le concept de CDC peut être utilement utilisé à chaque
fois qu ‘il y a une relation de sous-traitance ou de
délégation entre un client et un fournisseur.
• Le CDC est le document qui permet à un client (interne ou
externe) d’indiquer à un fournisseur (interne ou externe)
quel est son souhait et à partir d’un dialogue, de permettre
au fournisseur d’y répondre par un produit ou un service.
• L’important par rapport à la réalisation d’un CDC est de
définir les objectifs principaux et de déterminer parmi
ces objectifs ceux qui sont en opposition, et pour lesquels
il faudra mettre en place des compromis.
Page 15

Yves LALOUM
 Cahier des Charges :
Définition et rôle
• Le cahier des charges relève de la responsabilité du
client. Il doit garantir que son expression traduise bien les
besoins initiaux et qu’il soit compréhensible par des tiers.
• Il est donc nécessaire de bien identifier le destinataire du
cahier des charges pour qu’il soit rédigé sous une forme,
dans un langage et avec un vocabulaire compréhensible.
• Un dialogue pendant la phase d’exécution sera souvent
nécessaire pour préciser la demande et supprimer les
ambiguïtés et les incompréhensions.
• -> Deux éléments influent sur le contenu du cahier des
charges : La complexité du besoin et Le montant que
Page 16
l’entreprise est prête à mettre pour satisfaire le besoin.
Yves LALOUM
 Un cahier des charges doit préciser :

• Le cadre général de la demande ;

• Les objectifs à satisfaire ;
• Les fonctions et résultats qui sont attendus ;
• Les contraintes de réalisation et de mise en œuvre ;
• Les exigences du client en termes d’expérience du
fournisseur, de suivi de la qualité, de moyens à mettre en
œuvre, de délai de réalisation.

Page 17

Yves LALOUM
 Cahier des Charges :
Rôle
• Le cahier des charges constitue une demande de
réponses ; cette opération se nomme appel d’offres.

• Le rôle du cahier des charges dans appel d’offres est de

provoquer l’engagement du fournisseur.

• Il existe un certain nombre de normes françaises qui

peuvent être utilisées comme éléments de référence à la
structuration d’un cahier des charges.

Page 18

Yves LALOUM
 La norme Z67-102 :
Structuration d ’un CDC
• 1. Phase de conception
– 1/ Description de chaque sortie.
– 2/ Description hiérarchique de l’ensemble des données à obtenir.
– 3/ Vérification de la cohérence entre les entrées et les sorties.
– 4/ Description hiérarchique de l’ensemble des données à utiliser en
vue de l’obtention des résultats.
– 5/ Jeu d’essais logique de l’unité de traitement.
• 2. Phase de programmation
– 1/ Description hiérarchique de l’unité de traitement.
– 2/ Liste des instructions logiques par fonction à réaliser.
– 3/ Liste des instructions logiques ordonnées par séquence logique.
– 4/ Codification des instructions.
Page 19 – 5/ Codification du jeu d’essai.
Yves LALOUM
 Les études de besoins des utilisateurs
• L’analyse des besoins s’inscrit dans le cycle de
conception du système d’information (Cycle en U ou V).

Page 20

Yves LALOUM
 Le cycle de développement
La notion de CDC et le cycle de développement
Conception des Tests de
opérations réception

Prévoir et planifier les tests Tests

Spécification
d ’intégration
du système
système

Dès la phase de conception Tests de

Spécification
validation
sous-système
sous-système

Tests
Conception d ’intégration
sous-système sous-système

Conception des Tests des

modules modules
Code
Page 21

Yves LALOUM
 Techniques d ’investigation
des outils de la qualité
Questions Réponses
Quoi Le document cible à produire :
- sa forme ;
- son plan ;
- son contenu.
Qui - Qui met la phase en œuvre ?
- Quels sont les interlocuteurs qui y participent ?
- Qui valide le document ?
- Qui l’utilise ?
Où - Où trouver l’information ?
Quand - Quelles sont les actions avant et les actions après ?
- Quels sont les délais de réalisation ?
Comment - Choix des moyens et choix des méthodes ?
Pourquoi - Quelle est l’utilisation du document ?
Combien - Quelles sont les contraintes quantitatives de la phase ?
- Quel est le budget de la phase ?
Critères - Quels sont les indicateurs qui permettent de mesurer
l’avancement des travaux ?
- Quels sont les critères de réussite ?

Page 22

Yves LALOUM
 Les caractéristique générales
d’un cahier des charges
• Un CDC doit être : • le cahier des charges doit :

- Cohérent - Définir le domaine

- Non ambigu - Être complet
- Faisable - Être utilisable pour l’exploitation
- Vérifiable et la maintenance
- Modifiable - Préparer l’étape suivante
- Traçable
- Définitif
Page 23

Yves LALOUM
 Les risques d’un cahier des charges
incomplet
• Les risques techniques
. Les performances ne seront pas au niveau des performances attendues.
. La réalisation ne pourra pas être utilisée sur l’environnement technique de
l’entreprise.
. L’interopérabilité avec les autres sous-systèmes n’est pas assurée…
• . Les risques sur les délais
. Les délais de réalisation sont dépassés du fait de modifications du CDC.
. Les délais sont incompatibles avec les échéances de l’entreprise.
. La livraison tardive entraîne des pertes de part de marché pour l’entreprise.
• Les risques humains
. Les équipes de développement sont démotivées par les multiples changements
d’analyse.
. Les utilisateurs ne veulent plus collaborer avec l’informatique.
. Les services opérationnels sont désorganisés.
Page 24

Yves LALOUM
 Les risques d’un cahier des charges
incomplet
• Les risques sur les coûts
. Les budgets de développement sont dépassés du fait des modifications.
. Des parties entières de logiciel sont à refaire après la présentation aux
utilisateurs.
. L’entreprise est obligée d’avoir recours à la sous-traitance pour faire face
à ses engagements.
. Les performances obligent à acquérir de nouveaux matériels plus rapides.
• Les risques sur l’organisation
. Les objectifs de l’organisation ne peuvent plus être remplis.
. Des dysfonctionnements provoquent la perte de clientèle et de chiffre
d’affaires.
. La dégradation des marges met en péril la survie de l’entreprise.
Page 25

Yves LALOUM
 Les risques dans un projet informatique et
les répercutions sur l ’ensemble du projet
- Conflits
- Spécifications vagues,
- Rétention d ’informations
Gérer les incomplètes, changeantes
équipes Définir
l ’énoncé
- Non-planification des tests
Assurer la - Sous projet trop vaste
- Régression Découper
qualité
- Imprécision
Projet
- Méconnaissance du Documenter Estimer
produit - Oublis
- Absence d ’outils et de Suivre et - Optimisme
méthodes contrôler Planifier
- Absence de formation

- Écarts non détectés

- Organisation inadaptée
- Plannings glissants
Page 26 - Contraintes omises
Yves LALOUM
 La synthèse de l’analyse des besoins

• Les sept points essentiels pour bien définir ses besoins

1/ Définir clairement ses objectifs.

2/ Décrire précisément les résultats escomptés.
3/ Présenter l’organisation actuelle.
4/ Indiquer les volumes significatifs d’informations à traiter
5/ Prévoir les évolutions futures éventuelles.
6/ Préciser les temps souhaités de réponse et de traitement
7/ Spécifier les caractéristiques propres à l’entreprise.
Page 27

Yves LALOUM
 Investigation selon trois axes

Expression des Contraintes de l’entreprise

besoins utilisateurs (besoins des affaires)
(besoins humains)

Expression
des besoins

Contraintes des tâches à exécuter (besoins

opérationnels et d’informations)

Page 28

Yves LALOUM
 Le cahier des charges : un projet
• La réalisation d’un cahier des charges concerne la mise en
œuvre d’un projet.
• Ce projet se caractérise par :
- Une durée de vie limitée ;
- Un objectif à atteindre ;
- Des ressources affectées ;
- Des règles d’organisation et de fonctionnement.
• Le projet met en œuvre un client : le maître d’ouvrage et
un fournisseur : le maître d’œuvre.
• Ils sont tous les deux conjointement responsables du bon
achèvement du projet.
Page 29

Yves LALOUM
 Exigences de pilotage
pour le maître d ’oeuvre
• Il doit connaître le métier et plus particulièrement le
domaine fonctionnel du projet ;
• Il doit savoir rédiger un cahier des charges complet et
précis, compréhensible par les utilisateurs comme par les
réalisateurs ;
• C’est sa responsabilité de conduire et gérer le projet en
relation avec le maître d’ouvrage ;
• Cette responsabilité suppose le découpage du projet en
phases et la planification des différentes phases ;
• Enfin, il doit rendre compte de l’avancement des
travaux et des éventuelles difficultés au maître d’ouvrage.
Page 30

Yves LALOUM
 Exigences de pilotage
pour le maître d ’ouvrage

• Il doit être capable d’avoir une estimation des

coûts et des délais pour contrôler le maître
d’œuvre, et doit mettre en place un suivi de ces
coûts et de ces délais pour contrôler des dérives
éventuelles ;
• C’est lui qui définit les critères d’achèvement et
les règles de qualités ;
• C’est sur lui que reposent les contrôles
d’avancement, de réception et d’application des
règles de qualité.
Page 31

Yves LALOUM
 La validation du cahier des charges
Analyste

. Exprime des besoins

. Comprend les besoins de
l’utilisateur.
Utilisateur
. Traduit les besoins en terme Développeur
informatique : le cahier des charges
. Valide l’adéquation de la
compréhension du cahier . Comprend le
des charges à ses besoins cahier des charges
Analyste

. Valide la
compréhension du
cahier des charges par
le développeur

Une double finalité :

1/ Que le développeur comprenne les besoins de l’utilisateur.
2/ Que l’utilisateur s’assure que ses besoins ont été compris.
Page 32

Yves LALOUM
 Principes et Concepts de la
Planification

Page 33

Yves LALOUM
 Plan
• L’Analyse
• L’Estimation
• L’Evaluation financière
• Principe de la Planification

Page 34

Yves LALOUM
 L’analyse
• L’analyse d’un projet c’est :
– Définir la liste des tâches
– Définir la liste des résultats
– Structurer les différents parties du projets.

Page 35

Yves LALOUM
 Les outils d’analyse
• Outils :
– WBS (Work Breakdown Structure)
• arbre des tâches
– PBS (Product Breakdown Structure)
• Arbre des résultats
– OBS (Organisation Breakdown Structure)
• Tableau des affectations Ressources ---> Tâches

Page 36

Yves LALOUM
 Exemple de WBS
• Repeindre une salle de bain

Repeindre

Acheter le matériel Peindre Nettoyer

Passer 1ere couche Passer 2eme couche

Page 37

Yves LALOUM
 Exemple de PBS
• Repeindre une salle de bain

Salle de bain repeinte

Matériel disponible Salle de bain peinte Salle de bain nettoyée

1ere couche passée 2eme couche passée

Page 38

Yves LALOUM
 Exemple d ’OBS

TACHE Mr A Mr B Mr C
T1 X X
T2 X X

Définit la liste des intervenants aux projet

Page 39

Yves LALOUM
 L’estimation

• Estimation d’un projet :

– Chiffrage approximatif du coût de réalisation
d’un projet
– chiffrage tâche par tâche ou ressource par
ressource
– en unités correspondant aux besoins du suivi
• Objectifs :
– Etude d’opportunité
– Budgétisation d’un projet
Page 40

Yves LALOUM
 L’évaluation des délais

Méthode Avantages Désavantages

Algorithmique . Objectivité, répétabilité, . Les éléments entrant dans le
efficacité. calcul sont subjectifs.
. Basée sur l’application de . Ne peut pas être utilisé pour des
formules. développements exceptionnels (il
. Utilisable que si l’analyse est est nécessaire d’avoir une
détaillée. expérience).
. Le calibrage de la méthode peut . Basée sur des données historiques
être fonction de l’expérience. (elles ne prennent pas en compte
les évolutions technologiques).
Par expertise . Basée sur l’expérience . Dépend de la qualité des experts.
accumulée. . Peut être influencé.
. L’expert peut prendre en compte . Lié à la représentativité de
les éléments exceptionnels l’expérience
Par . Objective, répétable. . Basé sur une connaissance
point/fonction . Les éléments du calcul peuvent historique.
être mesurés objectivement. . Doit faire l’objet d’un calibrage.
. Focalisé sur les aspects externes
de l’application.
Page 41

Yves LALOUM
 La méthode par expertise

• Faire une évaluation par plusieurs experts qui ne se

connaissent pas.

• Si les résultats sont concordants, il peuvent être utilisés.

• Si les résultats ne sont pas concordants, il est nécessaire
d’examiner avec chaque expert les causes de divergences
et éventuellement de rectifier les évaluations en fonction
de ces causes.

Page 42

Yves LALOUM
 Les méthodes par fonction

• Une des méthodes possible est :

1/ Estimer le nombre de fonctions par type
2/ Estimer le nombre de lignes de code pour chaque fonction.
3/ Appliquer la table de productivité (toutes les lignes de code
n’ont pas la même valeur selon le type de fonction à
développer et à valider).
4/ Sommer les temps.

Page 43

Yves LALOUM
 Les méthodes par fonction (suite)

Type de fonction Mois Homme/1 000 lignes de code (LOC)

Math ématique 6 Mois Homme
Édition 8 Mois Homme
Log ique 12 Mois Homme
Traitemen t de signaux /Cont rôle de p rocess 20 Mois Homme
Cont rôle t emps réel 40 Mois Homme

Exemple d’appl ication

Nombre Fonctions Valeur en ligne de code
5 Mathématique 2 000 LOC
15 Édition 8 000 LOC
25 Logique 5 000 LOC
6 Traitement de signaux/Contrôle de process 1 200 LOC
0 Contrôle temps réel 0 LOC

Ce qu i donne : (6x2) + (8x8) + (12x5) + (20x1,2) + (40x0) = 160 Mois Homme

Page 44

Yves LALOUM
 Les méthodes algorithmiques

• La méthode algorithmique la plus utilisée est la méthode

CoCoMo (Composite Cost Model) d’après Boehm et
Barry (1981). Dans cette méthode, l’unité de mesure est le
KDSI (Kilo of Delivered Source Instructions), c’est-à-dire
des instructions finies et incorporées au projet final.
• La démarche est la suivante :
1/ Évaluer le KDSI.
2/ Déterminer le type d’organisation du projet.
3/ Corriger le KDSI en fonction du type de langage de
développement utilisé et de sa complexité.
4/ Appliquer les formules de calcul.
Page 45

Yves LALOUM
 Les méthodes algorithmiques (suite)

Types d’organisation du projet Définition

Normal . Développement en interne à l’entreprise.
. Projet de taille moyenne.
. Utilisation d’une technologie connue.
Partiellement sous-traité . Développement pour partie en interne et pour partie
en sous-traitance.
. Projet de taille intermédiaire.
. Utilisation d’une technologie connue.
Important . Sous-traitance total.
. Projet de taille intermédiaire à projet de grande taille.
. Utilisation de l’état de l’art du moment et utilisation
de technologies non maîtrisées.

Page 46

Yves LALOUM
 Les méthodes algorithmiques (suite)

Tai lle de projet Nombre de K DSI

Petit 2
Interméd iaire 8
Moyen 32
Grand 128
Très grand 512 e t plu s

Table d e formul es du CoCo Mo :

Type d’orga nisation du Investissement en Mois Déla is de réali sation

projet Homme ( MH)
Normal 2,4 (KDSI 1,05) 2,5 (MH 0,38)
Partiellement sous -traité 3 (KDSI 1,12) 2,5 (MH 0,35)
Impo rtant 3,6 (KDSI 1,20) 2,5 (MH 0,32)

Page 47

Yves LALOUM
 Évaluation financière

• Charge de travail à produire

• Acquisition de matériels ou de logiciels à réaliser
• Coûts de fonctionnement du nouveau système
• Économie de matière
• Économie sur le matériel
• Économie sur les coût de fonctionnement
• Économie sur le personnel

-> Ces différentes évaluations sont facilitées si le projet a été

découpé en sous-ensembles suffisamment petits.
Page 48

Yves LALOUM
 Évaluation financière (suite)

->Le dépassement des délais et des budgets, une maladie des

services informatiques !

• Les raisons des sous-estimations sont cependant connues :

- Expérience limitée
- L’optimisme
- Vision parcellaire du projet
- Oubli de la documentation
- Sous-estimation des tâches annexes

Page 49

Yves LALOUM
 Principes de la planification

- PRÉVOIR un programme d’action (en terme de

délai et de coût)
- ORDONNANCER son exécution
- CONTRÔLER le déroulement, les coûts et les
délais
- ADAPTER le plan aux nouvelles exigences

- DÉCIDER en continu, jusqu’au but final

Page 50

Yves LALOUM
 Le Réseau PERT
• Représentation des tâches et des liaisons :

T4
T2

T7
T1 T5

T3

T6

Page 51

Yves LALOUM
 Planning de projet : Diagramme de GANTT

Lancement

Analyse des besoins

Rédaction du CdC

Développement
Prépa jeu d'essai
Test

5 10 15 20

Page 52

Yves LALOUM
 Différentes types de liaisons
entre tâches
• Fin à Début (FD) A B

• B ne peut débuter avant que A ne soit terminée

• Début à Début (DD) A B

• B ne peut débuter avant que A ne soit commencée

• Fin à Fin (FF) A B

• B ne peut pas être achevée avant que A soit terminée

• Début à Fin (Début à Fin) A B

• B ne peut pas se terminer avant que A ne débute

Page 53

Yves LALOUM
 Définitions
• Date au plus tôt/Date au plus tard
– Date au plus tôt : la date à laquelle une tâche
peut commencer en fonction des dépendances
aux autres tâches

– Date au plus tard : la date à laquelle une tâche

peut commencer au plus tard sans remettre en
cause la date de fin de projet

Page 54

Yves LALOUM
 • Marge Totale :
• Intervalle de temps pendant lequel une tâche peut
être retardée sans affecter la date de fin de projet.
= Date de début au plus tard - date de début au plus tôt
• Marge Libre :
• Intervalle de temps pendant lequel une tâche peut
être retardée sans affecter d’autres tâches.
= Date de début au plus tôt du successeur le plus
immédiat - Date de fin au plus tôt
• Chemin critique :
• Suite des tâches ayant une marge totale égale à 0.
Tout retard sur une tâche du chemin critique affecte
la date de fin de projet
Page 55

Yves LALOUM
 Principes de calcul
• Dates au plus tôt de chaque tâche :
–

Taches durée prédécesseurs Date de Date

début au de fin
plus tôt au plus tôt
A 3j t t+3
B 2j A t+3 t+5
C 4j A t+3 t+7
D 2j B t+5 t+7
E 5j B,C t+7 t+12

Page 56

Yves LALOUM
 Principes de calcul
• Dates au plus tard de chaque tâche :
– Taches durée prédécesseurs Date de Date
début au de fin
plus tard plus tard
A 3j t t+3
B 2j A t+5 t+7
C 4j A t+3 t+7
D 2j B t+10 t+12
E 5j B et C t+7 t+12

Page 57

Yves LALOUM
 Principes de calcul
• Marge totale, Marge libre :
– Taches A, B,C ,D et E

Taches durée prédécesseurs Marge Marge

Totale Libre
• A 3j 0 0
• B 2j A 2 0
• C 4j A 0 0
• D 2j B 5 5
• E 5j B et C 0 0
Page 58

Yves LALOUM
 Les principaux outils de Gestion
de Projet

Page 59

Yves LALOUM
 Les Logiciels de Gestion de
Projet

• Il existe plus de 200 logiciels de gestion de

projet et il n’est pas toujours facile de faire
un choix.
• L’outil de référence et le plus répandu est
Microsoft Project.

Page 60

Yves LALOUM
 Les caractéristiques des logiciels
de Gestion de Projet
• Planification (ils permettent tous de le faire
plus ou moins bien)
• Libres ou licences
• Système de suivi des incidents
• Gestion des ressources : gèrent les ressources
affectés au projet et les conflits de ressources
• Gestion collaborative : permettent un travail
collaboratif entre tous les acteurs du projet
• Gestion d’un portefeuille de Projet: permettent
de gérer plusieurs projets regroupés en portefeuille utilisant
Page 61
les mêmes ressources et la même organisation
Yves LALOUM
 Les caractéristiques des logiciels
de Gestion de Projet
• Pilotage par les livrables : suivi des résultats
des différentes tâches
• Logiciel accessible en ligne ou pas.
• Gestion « Agile » (pour méthodes Agile)
• Gestion des documents
• Ils utilisent tous les méthodes de
planification décrites :
Pert, Gantt, dépendances des tâches, date au
plus tôt, date au plus tard, chemin critique…
Page 62

Yves LALOUM
 Les principaux logiciels
• Les Payants :
– Microsoft Project de Microsoft
– Teamwork
– Zoho
– Basecamp
– ASANA
– PROOFHUB
– COENDI
– Office Timeline
Page 63

Yves LALOUM
 Les principaux logiciels
• Les gratuits :
- Gantt Project : logiciel que l’on utilisera
- Propulse
- ProjeQtor
- Tree.io
- Trello
- Collabtive
- ChiliProject
- FeedCamp…..
Page 64

Yves LALOUM
 Les Outils de Conduite de Projet

Deuxième partie :
Pilotage et Gestion des Risques
Le suivi du projet
Rôle de la MOA
Page 65

Yves LALOUM
 Plan
• Pilotage et Gestion des Risques
• Suivi des projets
• Rôle de la MOA

Page 66

Yves LALOUM
 Pilotage et Gestion de Risques
• Management des risques :
• La gestion des risques est une activité qui consiste à :
– Identifier et Traiter les évènements de toute nature
susceptibles d’altérer la capacité du projet à atteindre
ses objectifs

L’analyse des risques consiste à évaluer leurs causes et leurs

conséquences sur le déroulement du projet.

Les risques sont classés par criticité.

• Intégré dans les rôles et responsabilités
• Constitue une aide pour les chefs de projet et les
Page 67

ingénieurs
Yves LALOUM
 Pourquoi Gérer les risques
• Anticiper les difficultés pour mieux les
surmonter

• Partager la responsabilité du projet avec

l’ensemble des décideurs concernés

• Ajuster le pilotage du projet au fur et à

mesure des évolutions de son environnement

• C’est se mettre en situation d’anticiper

plutôt que de subir
Page 68

Yves LALOUM
 Typologie des Risques
• Risques organisationnels
– Organisation du Projet, Clarté des objectifs, cahier des charges...
• Risques de type humain
– Disponibilité des ressources, compétences, formation, motivation...
• Risques commerciaux et marketing
– Offres de la concurrence, clients...
• Risques techniques
– Normalisation, cohérence des spécifications, documentation...
• Risques liés à la maîtrise de la sous-traitance
• Risques juridiques
• Risques liés à la sécurité des moyens informatiques et du site
Page 69

Yves LALOUM
 Les risques d’un cahier des charges
incomplet
• Les risques techniques
. Les performances ne seront pas au niveau des performances attendues.
. La réalisation ne pourra pas être utilisée sur l’environnement technique de
l’entreprise.
. L’interopérabilité avec les autres sous-systèmes n’est pas assurée…
• . Les risques sur les délais
. Les délais de réalisation sont dépassés du fait de modifications du CDC.
. Les délais sont incompatibles avec les échéances de l’entreprise.
. La livraison tardive entraîne des pertes de part de marché pour l’entreprise.
• Les risques humains
. Les équipes de développement sont démotivées par les multiples changements
d’analyse.
. Les utilisateurs ne veulent plus collaborer avec l’informatique.
. Les services opérationnels sont désorganisés.
Page 70

Yves LALOUM
 Les risques d’un cahier des charges
incomplet
• Les risques sur les coûts
. Les budgets de développement sont dépassés du fait des modifications.
. Des parties entières de logiciel sont à refaire après la présentation aux
utilisateurs.
. L’entreprise est obligée d’avoir recours à la sous-traitance pour faire face
à ses engagements.
. Les performances obligent à acquérir de nouveaux matériels plus rapides.
• Les risques sur l’organisation
. Les objectifs de l’organisation ne peuvent plus être remplis.
. Des dysfonctionnements provoquent la perte de clientèle et de chiffre
d’affaires.
. La dégradation des marges met en péril la survie de l’entreprise.
Page 71

Yves LALOUM
 Les risques dans un projet informatique et
les répercutions sur l ’ensemble du projet
- Conflits
- Spécifications vagues,
- Rétention d ’informations
Gérer les incomplètes, changeantes
équipes Définir
l ’énoncé
- Non-planification des tests
Assurer la - Sous projet trop vaste
- Régression Découper
qualité
- Imprécision
Projet
- Méconnaissance du Documenter Estimer
produit - Oublis
- Absence d ’outils et de Suivre et - Optimisme
méthodes contrôler Planifier
- Absence de formation

- Écarts non détectés

- Organisation inadaptée
- Plannings glissants
Page 72 - Contraintes omises
Yves LALOUM
 Démarche et Méthodes
La gestion des risques s’applique tout au long
du projet depuis la phase 0 jusqu’à la
livraison et l’exploitation
Commence par une analyse préliminaire
Mise à jour régulière tout au long du projet
Communication à chaque jalon ou revue de
projet

Page 73

Yves LALOUM
 Etapes

Page 74

Yves LALOUM
 Mise en oeuvre
• Définir la politique de management des risques
• Identification de l’ensemble des ressources ayant
un impact sur les risques
• Identification des objectifs et des contraintes du
projet
• Mise en oeuvre de modèles de cotation de la
gravité des conséquences
• Mise en oeuvre de modèles de cotation de la
probabilité d’occurrence
• Politique détaillée dans le plan de management ou
Page 75 le plan de management des risques du projet
Yves LALOUM
 Cotation de la gravité des risques
• Mise en oeuvre de modèles de cotation de la
gravité des conséquences ou des impacts
(performances ; délais, coût)

Exemple de cotation de la gravité des conséquences :

• 5 Catastrophique Entraine la fin du projet
• 4 Critique Augmentation du coût du projet de > x %
• 3 Majeure Augmentation du coût du projet de > x %
• 2 Significative Augmentation du coût du projet de > x %
• 1 Négligeable Augmentation du coût du projet de > x %
Page 76

Yves LALOUM
 Cotation de la probabilité
d’occurrence du risque
Exemple de cotation de la probabilité :
• 5 Maximale Se produira avec certitude,
une à plusieurs fois
• 4 Elevée
• 3 Moyenne
• 2 Faible
• 1 Minimale Se produira presque jamais

Page 77

Yves LALOUM
 Criticité du risque
• La criticité d’un risque se définit par la
formule :

Criticité = Gravité*Probabilité

Page 78

Yves LALOUM
 Matrice de criticité

Page 79

Yves LALOUM
 Identifier les risques
• Identifier et évaluer les scénarios de risques
y compris les causes et les conséquences
• Identifier chacun des évènements redoutés
afin d’évaluer leur criticité individuelle en
vue de leur classification et traitement
• Identifier les moyens d’alerte rapide
(détection)
• Si un événement indésirable se produit pour
éviter la propagation des conséquences
• Déterminer les objectifs projets concernant
Page 80

Yves LALOUM
la maîtrise des risques
 Méthodes d’identification
• L’identification des risques est un travail collectif
animé par le chef de projet avec les équipes par :
• - Brainstorming
• - Entretiens structurés et semi structurés
• - Envisager tous les types de risques pour chaque tâche
et pour chaque étape avec les acteurs de la tâche
• Examiner particulièrement les risques des tâches sur le
chemin critique
• Etablir une fiche de risque pour chaque risque identifié

Page 81

Yves LALOUM
 Exemple de fiche de risque

Page 82

Yves LALOUM
 Acceptabilité des risques
• Pour chaque risque identifié, décider si le
risque est acceptable ou non en fonction de
sa criticité et de ses conséquences évaluées.
• Le critère d’acceptation est lié à la criticité
• Les risques inacceptables devront faire
l’objet d’une réduction (ou mitigation)
• Déterminer le niveau de management qui
doit valider la décision

Page 83

Yves LALOUM
 Classification des risques par critères
d’acceptabilité
Criticité = Probabilité (ou Occurrence) X Impact (ou
Gravité)
La criticité sur 5 niveaux :
Risque négligeable Probabilité

• Lister uniquement Zone 5

Risque acceptable Inacceptable
• Analyse régulière Zone 4

Risque significatif Critique

• Analyse + traitement Zone 3
Risque critique Significatif
• Analyse + traitement
Zone 2
• Scenarios de rechange
Risque inacceptable Acceptable
• Traitement pour élimination Impact

• Ne pas démarrer ou continuer le projet

Page 84

Yves LALOUM
 Réduction ou Mitigation des
risques
• définition de mesures/d’options préventives et
d'atténuation pour chaque risque inacceptable ;
• détermination des critères de réussite, d'échec et
de vérification de la réduction des risques ;
• choix des mesures de réduction des risques les
plus efficaces et définition des priorités de mise en
œuvre;
• vérification de la réduction des risques ;
• identification des risques qui ne peuvent être
réduits à un niveau acceptable et présentation de
ces risques au niveau approprié du management en
Page 85

Yves LALOUM vue d’une prise de décision

 Présentation Synthétique de la
répartition des risques

Page 86

Yves LALOUM
 Conclusion sur la Gestion des
Risques
• L’analyse des risques se fait tout au long du projet
• C’est un outil pour le chef de projet
• C’est aussi un outil (pas suffisamment utilisé)
pour les développeurs
• Il est très important de définir une politique
claire dès le début du projet.
• Présentation des risques à chaque revue de projet
• Veiller au maintien de l’exhaustivité de la liste et à
la mise en place de moyens de réduction de la
Page 87
criticité de chaque risque
Yves LALOUM
 Suivi de projet

Suivi d’avancement
Suivi budgétaire

Page 88

Yves LALOUM
 Le Suivi de Projet
• Le suivi de projet est de la responsabilité du Chef
de Projet
• Suivi régulier tout au long du cycle de vie du
projet.
• Le suivi comporte deux aspects qui doivent être
traités séparément pour en faire une synthèse
ensuite :
– Le suivi d’avancement qui permet d’identifier les
retards et les nouveaux risques et de les prendre en
compte
- Le suivi bugdétaire et financier permettant d’anticiper
les dépassements de budget et de prendre les décisions
Page 89 appropriés
Yves LALOUM
 Principe du suivi de Projet

Fiche Action
Suivi de projet
Suivi du chemin critique

Mise à jour et révision du planning

Avec équipe projet
Point d ’avancement
avec comité de pilotage
Page 90

Yves LALOUM
 Démarche de suivi
1. Mesurer l’avancement
des tâches

3. Projeter
2. Faire le point
à achèvement

4. Envisager
des scénarios

5. Valider
un scénario

Page 91

Yves LALOUM
 Gestion des retards
• Suite à l’identification d’un ou plusieurs retards
plusieurs scénarios sont possibles ou une
combinaison de scénarios :
Renégocier les délais
-Risques de conflits et impact sur autres projets
Comprimer le planning
- Risques qualité
Reporter certains livrables
- Risques sur les délais
Rajouter des ressources
Page 92 - Risque sur les coûts
Yves LALOUM
 Les indicateurs
• Les indicateurs de suivi sont des éléments
recueillis permettant d’évaluer la bonne
santé du projet à un instant donné, les écarts
de coûts et les dépassements de délai.
• C’est à partir de ces indicateurs que l’on
pourra prendre les bonnes décisions
• Pour chaque tâche du planning, les premiers
indicateurs à relever sont :
– Le pourcentage d’avancement de chaque tâche.
– Le coût dépensé au point d’avancement pour
Page 93 chaque tâche (en fonction de l’unité choisie).
Yves LALOUM
 Planning Gantt initial

Tâche A

Tâche B

Tâche C

Tâche D

Tâche E

Tâche F

t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12

Page 94
Point d ’avancement
Yves LALOUM
 Mesure des écarts
Temps passé /
consommé

Tâche A

Tâche B

Tâche C

Tâche D

Tâche E

Tâche F % de réalisation
de la tâche

t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12

Point d ’avancement
Page 95

Yves LALOUM
 Courbe d’avancement/ligne brisée

Tâche A

Tâche B

Tâche C

Tâche D

Tâche E

Tâche F

t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12

Point d ’avancement
Page 96

Yves LALOUM
 Le CBTP
• CBTP = Coût Budgété du Travail Prévu.
Le CBTP constitue la référence de ce qui aurait dû être
réalisé au jour du point d’avancement en fonction du
planning.*

• Il se calcule en additionnant les coûts prévus sur les

tâches qui auraient dû être complètement ou
partiellement réalisées au moment du point
d’avancement.

• Le CBTP peut se calculer à tout moment en fonction de

ce qui a été prévu au planning et ne dépend pas des
Page 97

Yves LALOUM
relevés d’avancement et de coût en cours de projet
 Le CRTE
• CRTE : Coût Réel des Travaux effectués
Il représente l’ensemble des coûts qui ont été
dépensés sur le projet au moment du point
d’avancement depuis le début du projet.

Pour le calculer, il suffit donc de faire la

somme de tout ce qui a été dépensé pour
chaque tâche au moment du point
d’avancement.
Page 98

Yves LALOUM
 Le CBTE
• CBTE : Coût Budgété du Travail Effectué.
Il représente les coûts qui avaient été prévus
initialement pour tous les travaux qui ont été
effectivement réalisés complètement ou
partiellement au moment du point d’avancement.
On l’appelle aussi la Valeur Acquise du Projet au
point d’avancement, c’est-à-dire en fait la valeur
budgétée initialement de tout ce qui a été
effectivement réalisé pour chaque tâche du projet
Il se calcule en additionnant pour chaque tâche
effectuée complètement ou partiellement au point
d’avancement, le coût qui avait été initialement
Page 99

Yves LALOUM
prévu pour le travail effectué.
 Les courbes en S
Coûts CRTE
Coûts Réel des
Travaux Effectués
(Ressources
consommées))
CBTP
Coût Budgété
du Travail
Prévu (Planning
de référence)

CBTE
Coût Budgété des
Travaux Effectués
(Avancement du
projet)

Point Fin prévue

d’avancement
Page 100
du projet
Yves LALOUM
 Les courbes en S
Coûts

CRTE CBTP

Écart sur les couts Écart en production

CBTE
Écart délai

Point Fin prévue

d’avancement
Page 101
du projet
Yves LALOUM
 Indicateurs et Formules à retenir
Ecart de coût :
CRTE-CBTE
l’écart de coût indique en fait le dépassement de
budget au point d’avancement.

Indice de performance sur les coûts :

CBTE/CRTE.
Cet indice permet de mesurer la performance
globale sur la tenue des coûts par les équipes de
développement.
Page 102

Yves LALOUM
 Indicateurs et Formules à retenir
Ecart de production (ou écart de planning):
CBTE-CBTP
L’écart de production représente la différence de coût entre ce
qui ce qui a été réellement produit au point d’avancement (la
valeur acquise) et ce qui aurait du être produit à cette date.
Différent de l’écart de coût dans la mesure où on ne prend pas
en compte ce qui a été dépensé mais ce qui a été produit.
Indice d’activité :
CBTE/CBTP indice d’activité du projet
Cet indice représente le pourcentage global de ce qui a été
réalisé par rapport à ce qui aurait dû être réalisé au point
Page 103 d’avancement
Yves LALOUM
 Indicateurs et Formules à retenir
Ecart de délai :

Date courante –Date où CBTP= CBTE

courant
• Cet indicateur permet d’évaluer le retard
global sur le projet

Page 104

Yves LALOUM
 Tableau de bord de suivi de
Projet
• Un certain nombre d’indicateurs
– Sur un simple tableau excel au T
Global :
– CBTP, CBTE, CRTE (au temps T)
– Ecart de production
– Ecart de coût
– Ecart de délai
– Indice d’activité

Page 105

Yves LALOUM
 Tableau de Bord par Tâche
Tâche ( responsable, (WBS)
Dates (début-fin : prévues, estimées,
réelles)
Charge (prévue, consommée, reste à
faire)
Observations : identification de
problèmes, cause des retards, des
surcoûts

Page 106

Yves LALOUM
 Analyse
• Reste à faire :
A partir du réalisé pour chaque tâche on
refait une estimation de ce qui reste à faire
en fonction de scénarios retenus

Point à prendre en compte pour l’analyse :

- les écarts
- l’indice d’activité
Page 107

Yves LALOUM
 Actions correctrices
• Modifier les durées des tâches du
Gantt
• Compléter le PERT
• Recalculer les dates et les marges
• Identification du nouveau chemin
critique
• Revoir le plan de charge en
fonction des décisions prises
Page 108

Yves LALOUM
 Exercice
Reprendre l’exercice de planification et le Gantt.
1) Calculer le CBTP à la fin de projet (en nombre de jours, 1j=500 € )
2) Calculer le CBTP du projet à T+10, T+20 , T+26, T+30

• Vous faites un premier point d’avancement à T+30

Vous recueillez les informations suivantes lors de l’avancement :
– Tache ETV2 : Consommé 20 jours, Tache terminée
– Tache ETBAN : Consommé 28 jours, avancement 75 %
– Tache RMOD : Consommé : 10 jours, avancement : 20 %
– Tache RV2 : Consommé 10 jours, avancement 90%

3) Calculer le CRTE, le CBTE au point d’avancement T+30

4) En déduire : l’écart de coût, l’écart de délai, l’écart de production
5) En déduire, le taux global d’activité sur le projet

Page 109

Yves LALOUM
 Exercice
• 5) revoir le planning en tenant compte de ce qui reste à
faire pour chaque tâche.
Quel est l’écart constaté sur la date de fin de projet?

• 6) Proposer des scénarios pour tenir les délais initialement

calculés

Page 110

Yves LALOUM
 Extrapolation des coûts
• DR = delta de rendement
• DR = (CRTE – CBTP) /CBTP
• CT = coût total prévu (CBTP en fin
prévue de projet)
• CT’ = extrapolation des dérives
• CT’ = (1 + DR) x CT

Page 111

Yves LALOUM
 Rôle de la MOA en Gestion de
Projet

Page 112

Yves LALOUM
 Le bilan d’un projet
• Le bilan d’un projet consiste à :
– Déterminer la satisfaction des utilisateurs par
rapport à la solution
– Déterminer le coût réel du projet et de mesurer les
écarts par rapport :
• Au coût prévu
• Au délai prévu
– Faire le bilan de l’acquisition de l’expérience
Possibilité d’utiliser les bases de connaissances pour la
capitalisation de l’expérience
- Enrichir le modèle d’estimation des tâches
Page 113 d’un projet
Yves LALOUM
 Bilan financier d’un projet
RETOUR SUR INVESTISSEMENT (Ang.
Return On Investment ou ROI) :
Formule simplifiée :
ROI= (Total des gains-Total des coûts)/Total des coûts)
Dans la pratique, le calcul du ROI se fait sur une période
finie (nombre d’années) correspondant à la durée de
vie du produit.
POINT MORT ou Point d’équilibre (Payback Period) : il
s’agit du temps nécessaire à partir du déploiement du
projet pour que s’équilibrent les bénéfices et les coûts.

Page 114

Yves LALOUM
 Les éléments du calcul
• Le coût total d’un projet + coût de
maintenance+ coût de fonctionnement
• Les bénéfices attendus d’un projet (en
période d’évaluation et de décision)
• Les bénéfices réels (en période
d’exploitation)
Le calcul du ROI est déterminant dans les
décisions projet, il doit aussi tenir compte
des délais de mise en service
Page 115

Yves LALOUM
 Eléments à prendre en compte pour les
bénéfices
• Amélioration de la productivité des utilisateurs (gains
en temps et en amélioration des performance)
• Amélioration de la satisfaction clients (gains en nombre
de clients et en commandes)
• Réduction des coûts IT par le remplacement de solutions
existantes (plus grande automatisation)
• Automatisation de processus métiers augmentant leur
efficacité (gain en performance métier)
• Augmenter les profits (exemple solution Web de vente
en ligne)
• Autres….
Page 116

Yves LALOUM
 Du besoin à la mise à en
place de services
informatiques

Page 117

Yves LALOUM
 Situation des Entreprises
 Rapidité de l’évolution de leur contexte / Concurrence /
Technologie
 Rythme accéléré de renouvellement de l’offre au client
 Evolution de leurs produits , de leur organisation : besoins
changeants, anticipation
 L’entreprise Agile : Réactivité, Flexibilité, Compétitivité,
Efficacité, Souplesse
 Enjeux :
 Stratégiques : Fusions/Acquisitions, recentrage cœur de métier,
cession d’activité
 Opérationnels : Transversalité des processus / Approche
Client, Externalisation partielle, …
 Financiers : Analyse et gestion de plus en plus approfondis et
Page 118

Yves LALOUM
de plus en plus pointus, rythmes de plus en plus rapides
  Situation des SI
Complexification du patrimoine SI à chaque évolution ( spaghettis, strates géologiques,
sédimentation, résultant d’une longue évolution et maintenance des SI)
Incohérences, hétérogénéité, mauvaise communication, maîtrise difficile d’une
multiplicité d’interfaces
Coût d’exploitation et administration croissants des SI dans les entreprises
Coût / MCO de l’existant , parfois 60 à 70 % du Budget Annuel
Besoins d’échange des SI : B2B Ouverture vers/aux partenaires, B2C aux clients

Enjeux des SI

Gouvernance : audit, contrôle, gestion coût qualité délais, ROI justifiés et rapides
Adéquation avec la stratégie et soutien opérationnel primordiaux
Accroître la capacité à évoluer en maîtrisant les risques et les impacts
Augmenter la cohérence, réduire les redondances entre applications (fonctions et données)
Préparer le patrimoine SI à la flexibilité exigée par la nécessaire évolution de l’entreprise

Page 119

Yves LALOUM
 Quelques définitions
• Qu’est ce que la stratégie d’entreprise ?
– « Élaborer la stratégie de l’entreprise, c’est choisir les domaines
d’activité dans lesquels l’entreprise entend être présente et allouer
des ressources de façon à ce qu’elle s’y maintienne et s’y
développe. » [Source : Strategor]
– La stratégie se décline à deux niveaux :
• Stratégie de groupe : détermine les domaines d’activité de
l’entreprise
• Stratégie concurrentielle : mise en oeuvre dans chacun des
domaines d’activités
• Qu’est ce qu’une stratégie système d’information ?
– « Une stratégie système d’information doit définir un système
d’information cible, les priorités, les étapes et les moyens
nécessaires pour l’atteindre. »
• « Par ailleurs cette définition insiste sur le fait que ce sont les choix
d’allocation de ressources (investissements et désinvestissements
notamment), qui, davantage que les discours des dirigeants, font la
stratégie. » [Source : Strategor] Les citations proviennent de sources CIGREF
Page 120

Yves LALOUM
 Concepts et définitions
• Architecture : Elaborer un « édifice » dans le cadre fixé par le POS
Concevoir et construire un ouvrage
• Terme très employé depuis les années 80/90 : structure d’un ensemble de composants et leur
mode de relation/interactions pour former un tout
• Consiste à se préoccuper de mettre en œuvre un nouvel applicatif selon une démarche moderne
et optimale, nouvelles méthodologies
• Réponse positive mais partielle aux impératifs de l’entreprise en matière de SI

Urbanisation : Concevoir et faire évoluer un SI global

Faire évoluer dans le temps un espace composé d’ouvrages
• Remonter d’un niveau d’abstraction : au niveau de l’ensemble du SI
• Objectif majeur : Acquérir une appréhension globale du SI, Coordonner les actions et
décisions sur l’évolution du SI pour le faire évoluer au même rythme que l’entreprise et
pouvoir prédire les conséquences d’une évolution incontournable.
• Moyens : Collecte des objectifs stratégiques, besoins métier, cartographie,
• Communiquer, convaincre, fédérer des acteurs de tous profils et de tous horizons

• Urbanisme / Architecture : Deux Termes plus voisins qu’opposés « on

peut urbaniser une partie et architecturer le tout »

Page 121

Yves LALOUM
 Positionnement en 4 niveaux

Page 122

Yves LALOUM
 Les différentes Architectures

Quels Métiers ?
Architecture Métier

Quoi ?
Architecture fonctionnelle
Gestionnaire Opération
échange de flux
Pilotage Décisionnel Données Comment ?
Architecture applicative
WEB WEB

Avec quoi ?
Architecture technique
Page 123

Yves LALOUM
 Positionnement

Page 124

Yves LALOUM
 Modélisation Stratégie et Processus
• 1- Modéliser la Stratégie :

Diagramme d’Ishikawa pour les Objectifs stratégiques

Métiers
Diagrammes d’entreprise, actuel et cible.
Matrice Objectifs Métier/Objectifs S.I.

• 2- Architecture Métier :

Cartographie des processus. Situations actuelle et cible.

Matrice Objectifs Stratégiques Métiers/ Processus.
contributions (fortes ou faibles).
met en lumière les processus sensibles
Faire les modèles de processus pour chacun des processus.
Page 125

Yves LALOUM
 Diagramme D’Ishikawa

Page 126

Yves LALOUM
 Stratégie : Ishikawa Entreprise

Page 127

Yves LALOUM
 Stratégie : Ishikawa SI

Page 128

Yves LALOUM
 Processus et Processus Métier
• Définitions
Un Processus :
est un ensemble d’activités ayant pour objectif le traitement d’un
événement de gestion initiateur de ces activités. Il doit produire des
flux de résultats définis dans les conditions de délais et de qualité
fixés pour répondre aux besoins de tiers internes ou externes.

Processus métier :
processus mis en œuvre dans le cadre d’une organisation structurée.
Il désigne une séquence d’opérations effectuées par des acteurs
agissant sur des données et régies par des règles de gestion. Une
processus métier est déclenché par une demande et finalisée par
l’acceptation d’un résultat.
Page 129

Yves LALOUM
 Matrice Processus/Objectifs Stratégiques
La matrice « Processus/Objectifs Stratégiques » permet de contrôler
l’alignement des processus métier sur la stratégie de l’entreprise ou de
l’organisation
• Les objectifs stratégiques sont en colonne (autant que de flèches sur le
diagramme d’Ishikawa moins une qui correspond à l’objectif central de
l’entreprise)
• Les processus sont en ligne
• Les cellules intersection des lignes et colonnes permettent d’indiquer la
contribution du processus à l’atteinte de l’objectif :
– Pas de contribution
– Contribution faible : un dysfonctionnement sur le processus ne met pas en cause à lui
seul l’atteinte de l’objectif
– Contribution forte : un dysfonctionnement sur le processus peut mettre en cause à lui
seul l’atteinte de l’objectif
• Sur la matrice, on peut identifier :
– Les processus ne contribuant à aucun objectif stratégique
– Les objectifs stratégiques non adressés par au moins un processus
Page 130

Yves LALOUM
 Exemple de cartographie des processus

Page 131

Yves LALOUM
 Les processus métiers
• Modélisation de processus métiers
– Enchaînement d'activités
– Echange de messages XML
• Intégration des Services Web
– API standards décrites en WSDL
– Langages d'orchestration (WFSL, XLANG,
BPEL, ...)
• Interpréteur de ces langages
– Généralement centralisé
Page 132
– Pilote les processus et échanges
Yves LALOUM
 Exemple de processus métier

Source G.GARDARIN
Page 133

Yves LALOUM
 Le BPM
• Business Process Management :
– Analyse et modélisation logicielle des procédures mises
en place par l'entreprise pour réaliser ses activités.
• Le BPM permet d « ORCHESTRER » les
processus de l’entreprise autour du Système
d’Information
• Le BPM déclenche un processus métier suite à la
demande d'un utilisateur ou à la requête d'une
application interne ou externe. Il achemine les
requêtes vers l'EAI qui met en place les transferts
et les transformations de données entre les
Page 134 applications et met en œuvre le workflow
Yves LALOUM
 Point sur le BPM
•Le BPM permet de gérer les processus métier du début à
la fin
–Modélisation
•Le BPM va permettre d’exprimer les processus métier dans un formalisme
standard BPMN
•Aux modèles de processus sont associées des règles de gestion qui
permettent d’opérer des choix contextuels – les processus sont exécutés en
fonction du contexte
–Exécution
•Le BPM permet d’exécuter les processus modélisés en orchestrant
l’intervention aussi bien d’acteurs humains que d’applications
•Les processus sont exprimés dans un langage d’exécution BPEL, en voie
de devenir un standard, mettant en œuvre la technologie des web services
–Pilotage (Monitoring)
•Des indicateurs et des points de contrôle sont associés aux processus, ils
permettent de piloter l’activité
•Les solutions de BPM qu’offre le marché aujourd’hui, à l’évaluation près
de leur degré d’industrialisation, se combinent donc avec du BAM
(Business Activity Monitoring)
Page 135

Yves LALOUM
 Points clés d’un projet (1/2)
D’une manière générale, certains points clés du projet vont
fortement conditionner sa réussite. Ils seront d’ailleurs à
rappeler dans le Plan de Management de Projet (PMP). Ces
points sont :

– Objectifs du projet : Objectifs stratégiques,

économiques, marketing …
– Périmètre « métier » : qui sera détaillé en
« exigences fonctionnelles ».
– Cadre et méthodes de travail : qui sera détaillé
en « organisation du projet ».
– Ressources et Budget : doivent être allouées
explicitement au projet
– Planning : il doit être réaliste et suivi
Page 136

Yves LALOUM
 Points clés d’un projet (2/2)
• Taux de réussite des projets
– Une étude statistique mondiale (Standish Group)
montre que seulement 40% des projets respectent
totalement leurs objectifs (Coût, délai, fonctions,
qualité), et même que 25% sont arrêtés et passés en
profits et pertes.
– Une des causes principales d’échecs est la
mauvaise définition (ou son évolution non
contrôlée) du cahier des charges utilisateur qui
finit par aboutir par la non acceptation du logiciel
livré.
• D’où l’importance de la phase amont de collecte et
validation des besoins utilisateur ainsi que l’importance
Page 137

Yves LALOUM
du respect de standards
 Rôle Maîtrise d ’ouvrage et Maîtrise d ’œuvre (1/3)
• La relation client/fournisseur fondamentale est celle qui
existe entre la maîtrise d ’ouvrage et la maîtrise d ’œuvre.
– La maîtrise d ’ouvrage (MOA) émet un cahier des charges (en direct ou
sur appel d ’offre).
– La maîtrise d ’œuvre (MOE) répond par une proposition (coûts, délais,
contenu)
– Si l ’accord se fait (après négociation), il y a contractualisation et
définition de critères d ’acceptation par la MOA.
– La MOE réalise le projet et livre à la MOA.
– La MOA procède à des tests d ’acceptation (recette)
– Si la recette est OK, le nouveau SI est mis en production
– Les conditions de support et maintenance (après garantie) sont
Page 138 normalement définies dans le contrat
Yves LALOUM
 Rôle Maîtrise d ’ouvrage et Maîtrise d ’œuvre (2/3)

• Au delà de l ’aspect contractuel, il doit exister une véritable

coopération entre MOA et MOE tout au long du projet.

• Dans sa phase de réalisation, le projet va être géré par le Chef

de projet, mais il y aura des réunions de pilotage en commun
avec la MOA, dans lesquels l ’avancement projet, mais aussi
les risques seront présentés et discutés.

• Des revues conjointes MOA/MOE peuvent être organisées.

• Les documents de conception générale (ou des prototypes) sont

aussi validés par la MOA pour renforcer encore la coopération.

Page 139

Yves LALOUM
 Rôle Maîtrise d ’ouvrage et Maîtrise d ’œuvre (3/3)

• Les sous-traitants
– Dans des phases d ’études sur les processus métiers, la
MOA fait quelquefois appel à des consultants externes,
mais la sous-traitance la plus importante concerne la
maîtrise d ’œuvre.
• Les sous-traitants « en régie » sont directement intégrés à l ’équipe
projet, sous l ’autorité du chef de projet.
• Dans le cas de développement au forfait, les activités confiées au
sous-traitant doivent être décrites de façon précise et
contractualisée.
• Le processus de livraison par le sous-traitant et les conditions
d ’acceptation doivent être décrites de façon précise.
– Attention aux aspects gestion de configuration et tests d ’intégration
si les composants sous-traités doivent s ’intégrer avec d ’autres
composants.
Page 140

Yves LALOUM
 LES RESPONSABILITES MOA & MOE :
Domaines /Phases Maître d’ouvrage Maître d’oeuvre
Analyse des besoins Animation de groupe d’utilisateurs, Démarche, rédaction.
validation.
Spécifications Validation. Démarche, rédaction.
Architecture Approbation par la direction. Réalisation de l’étude.

Développement Suivi de travaux, contrôles. Totalité des travaux.

Intégration Suivi de travaux, contrôles. Totalité des travaux.
Validation, recette Totalité des opérations. Assistance du MOA.
Changement, Totalité des travaux. Assistance du MOA.
formation
Système pilote Suivi, contrôle, validation. Mise en ordre de marche.
Déploiement Préparation des sites, validation. Mise en ordre de marche.
Système qualité Procédures propres, audits projet. Mise en place, contrôles.
Pilotage Pilotage, gestion, coordination de Pilotage, gestion,
son équipe projet. coordination de son équipe
projet.
Autres projets
Page 141 Coordination. Assistance du MOA.
Yves LALOUM
141
 Les autres intervenants (1/3 )
• Les utilisateurs
– Les utilisateurs sont ceux dont les besoins ont été collectés
(par la MOA), et qui vont donc utiliser le SI.
– On distingue entre « utilisateurs métiers », ceux dont les
processus métiers sont automatisés par le SI considéré, et
« administrateurs », qui remplissent plutôt des fonctions
d ’administration, supervision, contrôle …et qui ont eux
aussi accès à certaines fonctions du SI.
– Les utilisateurs peuvent accéder au SI directement à
travers des interfaces écran, mais aussi à travers des flux
qui extraient des informations du SI.
– Dans le cycle projet normal, les utilisateurs interviennent
en amont (collecte des besoins, validation de
Page 142 spécifications ou prototypes ..) et en aval (phases pilotes).
Yves LALOUM
 Les autres intervenants (2/3)
• Les exploitants
– Il faut intégrer les exigences d ’exploitation le plus en
amont dans le cycle projet.
• L’automatisation de l ’exploitation fait appel à des méthodes et
outils : outils de supervision d ’exploitation, outils de sauvegarde,
outils de sécurité … et il faut s ’assurer que les exigences
correspondantes sont prises en compte ainsi que la cohabitation et
la collaboration avec les autres éléments du SI.
• Les référentiel d’exploitation comme ITIL ou COBIT intègrent
ces exigences, on parle de Gouvernance ou d’Urbanisation des
SI avec des règles associées.
– Ces exigence doivent être gérées par le Chef de Projet
MOE qui doit donc intégrer ces aspects dans la totalité du
Projet.
Page 143

Yves LALOUM
 Les autres intervenants (3/3)
• Les fonctions de support
– Essentielle, la fonction support ou Centre de
Services assurent la communication avec les
utilisateurs.
– Une fois mis en exploitation (ou même dès la
phase pilote), les utilisateurs peuvent faire appel à
des fonctions de support.
• Les niveaux de support (1er, 2eme et 3eme niveaux )
doivent être organisés
– Un transfert de compétence vers l’organisation de
support (documentation, formation) doit donc
intervenir durant le projet.
Page 144

Yves LALOUM
 Méthodes agiles ou classiques

Page 145

Yves LALOUM
145
 Le cycle itératif : une mini-cascade

Scénarios sélectionnés • Resultats des itérations précédentes

• Evaluation révisée des risques
• Modèles, composants et tests validés

Planification de l ’itération

Expression des exigences

Analyse & Conception

Réalisation

Tests

Production de version

Référentiel de version
Evaluation de risque mise à jour
Composants validés

Page 146

Yves LALOUM
 Avantages d’un processus itératif
 Permet de limiter les coûts, en termes de risques, aux
strictes dépenses liées à une itération.

 Permet de limiter les risques de retard de mise sur le

marché du produit développé (identification des problèmes
dès les premiers stades de développement et non en phase
de test comme avec l’approche « classique »).

 Permet d’accélérer le rythme de développement grâce à

des objectifs clairs et à court terme.

 Permet de prendre en compte le fait que les besoins des

utilisateurs et les exigences correspondantes ne peuvent
être intégralement définis à l’avance et se dégagent peu à
peu des itérations successives
Page 147

Yves LALOUM
 Profil de risque
dans un développement itératif

Risque

Lancement
Cascade
Elaboration

Construction

Transition

Itération Itération Itération Itération Itération Itération Itération Itération Maintenance

Préliminaire Architecture Architecture Développement Développement Développement Transition Transition
Temps

Page 148

Yves LALOUM
 Réduction des risques

Planification de l’itération N
Développement de
l’itération N
•Evaluation initiale
des risques du
projet Evaluation de
Itération N
l’itération N

Révision du plan général du projet

(coût, délai, portée, contenu) Risques éliminés
Révision des risques
Re-définition des priorités

CHAQUE ITERATION DOIT PERMETTRE DE VALIDER UN CHOIX

Page 149

Yves LALOUM
 Processus de développement O.O.

Principaux
Jalons

Lancement Elaboration Construction Transition

temps

Unified Process = 4 phases:

• Lancement —Définir les objectifs du projet
• Elaboration — Planification, spécification des exigences et
conception d’architecture
• Construction —Développement du produit
• Transition —Transfert du produit dans la communauté des
utilisateurs

Page 150

Yves LALOUM
 Les phases
Phase Description et Enchaînement d’activités
Traduit une idée en vision de produit fini et présente une étude de rentabilité pour ce
produit
- Que va faire le système pour les utilisateurs ?
Phase de création - A quoi peut ressembler l’architecture d’un tel système ?
- Quels sont l’organisation et les coûts du développement de ce produit ?
On fait apparaître les principaux cas d’utilisation.
L’architecture est provisoire, identification des risques majeurs et planification de la
phase d’élaboration.

Permet de préciser la plupart des cas d’utilisation et de concevoir

l’architecture du système. L’architecture doit être exprimée sous forme de
Phase d’élaboration vue de chacun des modèles.Emergence d’une architecture de référence.
A l’issue de cette phase, le chef de projet doit être en mesure de prévoir
les activités et d’estimer les ressources nécessaires à l’achèvement du projet.
Moment où l’on construit le produit. L’architecture de référence se
métamorphose en produit complet, elle est maintenant stable. Le produit
Phase de construction contient tous les cas d’utilisation que les chefs de projet, en accord avec les
utilisateurs ont décidé de mettre au point pour cette version. Celle ci doit
encore avoir des anomalies qui peuvent être en partie résolue lors de la phase
de transition.
Le produit est en version bêta. Un groupe d’utilisateurs essaye le produit et
détecte les anomalies et défauts. Cette phase suppose des activités comme la
Phase de transition fabrication, la formation des utilisateurs clients, la mise en œuvre d’un
service d’assistance et la correction des anomalies constatées.(où le report de
Page 151 leur correction à la version suivante)
Yves LALOUM
 Distribution des activités
Phases
Lancement Elaboration Construction Transition
Activités de Production
Analyse Préliminaire
Spécification & Conception
Réalisation
Intégration & Tests
Déploiement
Activités support
Gestion de Configuration
Conduite de Projet
Mise en place initiale
Itération(s) Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Préliminaire(s) #1 #2 #n #n+1 #n+2 #m #m+1

Page 152

Yves LALOUM
 Méthodes agiles ou classiques
Les quatre variables d’un projet
Les coûts
trop d’argent trop vite  inutile et dangereux
trop peu  projet incomplet

Les délais
long  espoir augmentation qualité et périmètre
 peu de feedback

La qualité
insuffisante  bénéfice à court terme
 augmentation du coût à long terme

Le périmètre
réduit  livraison plus tôt
Page 153

Yves LALOUM
 Méthodes agiles ou classiques
Le coûts du changement
coût
Méthode
classique

Méthode
XP

Page 154
durée
Yves LALOUM
 Synthèse méthodes Agiles
Les principales méthodes
Crystal Clear (Alistair Cockburn) Communication et du feed-back client
Deux grandes phases: Conception / Planning Itérations
eXtreme programming (spécialisées dans le développement
XP objet)
(ADM et WMARK software (spécialisées dans le
développement objet) Phase initiale (planning, risque,
Scrum budget) / Sprint 30 jours en équipe isolée, réunions scrum
quotidiennes / Clôture Finalisation de la documentation,
livraison
Feature Driven Development (Jeff de Luca et Peter Coad)
Phase initiale : développer un modèle global /Etablissement
FDD
de la liste détaillée de features / Planification, conception et
construction à partir des features
DSDM Dynamic Software Development Method () Etude de
faisabilité / Etude du businessn / Cycles itératifs impliquant
MO, ME
Adaptive Software Development (Jim Highsmith)
Spéculation De l’initialisation du projet jusqu’à la liste des
ASD taches Collaboration Délivrance des composants.
Apprentissage Contrôle qualité, suivi, bilan
RUP Rational Unified Process (Réutisation d'XP)
Rapid Application Development (James Martin ) Etapes en
RAD trois temps (pré-session, session, post-session) très
Page 155
formalisé. Respect de la time box

Yves LALOUM
 Conclusion
La Gestion de Projets nécessite :
Une bonne communication et collaboration entre
MOE/MOA pour des solutions efficaces et
innovantes.
Le rôle du chef de projet est de maîtriser
l’ensemble des dimensions du projet : Coûts,
délais et technicité en détectant tout écart au
plus tôt et en prenant les bonnes décisions.
La MOA a un rôle essentielle sur l’ensemble du
cycle de vie afin de garantir l’adéquation au
Page 156
besoin
Yves LALOUM