Cours Des MCP 2019 - 2020 - L2Info

Cours de Méthode de Conduite de Projet Informatique à l’usage des étudiants de L2 Informatique (ISS / KIN)
Version 2019-2020 –=============================➔ Prof. Dr. Ir. Jeampy MBIKAYI MPANYA
PLAN DU COURS
❖ I. Introduction
• I.1. Entreprise comme système
• I.2. Concepts de base
✓ II.2.1. Méthode
✓ II.2.2. Méthodologie
✓ II.2.3. Mise en œuvre
✓ II.2.4. Plan informatique
✓ II.2.5. Processus
✓ II.2.6. Information
✓ II.2.7. Maître d’œuvre
✓ II.2.8. Maître d’ouvrage
✓ II.2.9. Projet
❖ II. Techniques de collecte des informations
❖ III. Panorama des méthodes de conduite d’un projet informatique
❖ IV. Modélisation de conduite d’un projet informatique
✓ IV.1. Préalables
✓ IV.2. Etapes de conduite d’un projet informatique
✓ IV.3. Cycles de vie d’un projet informatique
✓ IV.4. Les acteurs d’un projet informatique
✓ IV.5. Organisation interne du projet
✓ IV.6. Dynamique des groupes de prise de décision
✓ IV.7. Contractualisation des relations
▪ IV.7.1. Cahier des charges
▪ IV.7.2. Contrat
❖ V. Planification
• V.1. Evaluation
• V.2. Suivi des charges d’un projet
• V.3. Outils de planification
• V.4. Suivi des projets ou outils de suivi du budget
• V.5. Schéma directeur
• V.6. Evaluation des charges
❖ VI. Etude des cas
❖ VII. Conclusion Générale.
❖ VIII. Annexes.
-1-
BIBLIOGRAPHIE
1. Marcel SUBERMAN, En suivi des logiciels en Informatique de gestion, Tome I, II, III et IV, éd
Eyrolles, 1994 – 1995.
2. GEDIN, Méthodes de projets informatiques, Méthodes d’analyse d’informatisation et

des conduites des projets, Tome I, II et III, 2dition Masson, 1996.
3. Emile BORDAIS, Conception du système d’informations, éd. Dunod.
4. HUBERT TARDIER et les autres, L’Approche Merise dans la conception du système

d’information, éd. Dunod.
5. Hubert Tardieu, Arnold Rochfeld, René Colletti (1983). La méthode Merise -Tome 1
Principes et outils. Editions d'organisation (Paris) : 328 p.
6. Hubert Tardieu, Arnold Rochfeld, René Colletti, Georges Panet, Gérard Vahée (1985). La
méthode Merise - Tome 2 Démarches et pratiques. Editions d'organisation (Paris) : 460 p.
7. Arnold Rochfeld, José Morejon (1989). La méthode Merise - Tome 3 Gamme

opératoire. Editions d'organisation (Paris) : 264 p.
8. Yves Tabourier (1986). De l'autre côté de Merise. Editions d’organisation (Paris.)
9. Georges Panet, Raymond Letouche (1994). Merise/2 - Modèles et techniques

avancées. Editions d'organisation Paris) : 366 p.
10. Prof. MVIBUDUKU et le CT MPUTU KINSALA, Méthode de conduite des projets en

informatique, 1986 à 1997, cours de 75 heures à l’I.S.C / Kinshasa.
11. Nanci, Ingénierie des systèmes d’information, 2ème génération, 4ème édition.
Ed. Sybex.
-2-
CHAPITRE PREMIER: INTRODUCTION
René NOLAN au début des années 80 a défini un schéma de l’évolution des

investissements informatiques dans les organisations suivant les 5 phases d’appréhension ci-après :
voir schéma d’appréhension ci-après :
III IV
I II V
PLANIFICATION PLANIFICATION
DEMARRAGE CROISSANCE MATURITE
TACTIQUE STRATEGIQUE
Toute entreprise peut retrouver son évolution propre et se situer dans ses phases.
Actuellement nombreuses entreprises se posent les problèmes de savoir si elles doivent recourir à
l’ordinateur pour les aider à résoudre leurs problèmes de gestion. Pour d’autres, qui déjà
informatisées, mais dont le matériel est âgé environ 5 à 7 ans, il s’agit de repenser le problème de
l’organisation existante avec un matériel adapté à l’évolution actuelle pour rester compétitives.
C’est le chef d’entreprise, qui très souvent décide de recourir à l’ordinateur pour résoudre ses
problèmes de gestion. Mais avant d’acheter un ordinateur et de l’installer dans une pièce ou
dans un endroit quelconque de l’entreprise, il est nécessaire de procéder à une analyse
approfondie.
• De l’entreprise,
• De son organisation en général,
• De l’organisation des flux d’information entre les services
• Du volume d’informations à traiter,
• Des délais demandés pour réaliser ce traitement,
• Du stockage ou conservation d’une partie de ses informations
• Mais aussi du personnel, des moyens dotés pour réaliser le travail au sein de chaque
service.
En définitive, c’est donc une approche globale qui est nécessaire dans un premier
temps. Cette analyse devant permettre aux chefs d’entreprises, aux dirigeants, aux chefs de
service de définir en quelque sorte les projets ou « les projets informatiques de l’entreprise ». Ainsi,
la décision d’automatiser le traitement d’un problème sur l’ordinateur devient un « projet
d’informatisation », qu’il faut définir, concevoir, développer et réaliser. D’où la réalisation d’un
projet informatique passe par plusieurs étapes telles que :
• L’étude d’opportunité (qui prend 5 à 10 % d’efforts ;)

• La conception du projet (prend 20 à 30 % d’efforts ;)
• Le développement du projet (prend 40 à50 % d’effort ;)
• Le démarrage du projet (prend 20 à 30 % d’efforts.)
-3-
BUT DU COURS
Le but du cours est d’initier les futurs ingénieurs en informatique aux techniques et
méthodes de conduite des projets informatiques et non pas à la conception d’un projet
informatique.
Le parallélisme qui existe entre la topologie et le volume de besoins traités,

l’architecture technique et le moyen de production du logiciel, fait en sorte que l’architecte en
système informatique doit mettre en musique tous ses facteurs s’il veut fournir le logiciel à l’état de
l’art et sans s’engager trop tôt dans une technique non maîtrisée.
I.1. ENTREPRISE COMME SYSTEME
Remarque : Quel que soit le produit, le processus conduisant à son élaboration relève de trois
grandes étapes :
• Conception;
• Réalisation ;
• Mise en œuvre.
Lorsque l’informatique dépasse l’automatisation quelque peu mécaniste d’un

processus de gestion ou comptable, la complexité de l’organisation entre les moyens à mettre
en œuvre, les acteurs et services concernés, les objectifs à atteindre.
D’où, l’entreprise peut être considérée comme un système à trois niveaux :
Objectifs
Système de Pilotage
SP
Produits
Système d’Information
SI
Flux sortants
Flux entrants
Système Opérant
SO
1. LE SYSTEME OPERANT
Agit suivant les décisions qui lui sont transmises, et à partir des flux des matières
monétaires, logistiques, … dont il dispose pour fournir en sortie.
2. LE SYSTEME DE PILOTAGE
Il prend les décisions macroscopiques de l’organisation en fonction des informations

externes et internes qui lui sont transmises et les envoie au système opérant.
-4-
3. LE SYSTEME D’INFORMATION
Il fournit une structure de mémorisation, de traitement et de communication des
informations avec les autres systèmes. Ainsi, la qualité des décisions et leurs suivi par le système
opérant définit pour une large part du système d’information mis en place, d’où son
automatisation constitue un projet informatique.
I.2. CONCEPTS DE BASE
I.2.1. METHODE :
Est un ensemble résultant de la combinaison d’un cadre procédural et des
techniques en vue de la réalisation d’un processus (exemple méthode de conduite de projet.)
I.2.2. METHODOLOGIE :
Est une démarche fondée sur l’utilisation des méthodes et d’outils avec une
répartition claire du rôle et des responsabilités de tous les acteurs.
I.2.3. MISE EN ŒUVRE :

Ensemble des procédures concourant à la fourniture et au maintien d’un produit.
I.2.4. UN SCHEMA DIRECTEUR INFORMATIQUE
Document synthèse exprimant les objectifs à long terme de l’entreprise dans le

domaine de l’informatique. Le schéma directeur permet de préparer, dans les meilleures
conditions, l’extension du système informatique. Il réalise le lien entre les objectifs à long terme et
le plan informatique qui n’en représente que la partie immédiate et la mieux définie.
I.2.5. PLAN INFORMATIQUE :
• C’est un tableau de bord qui fournit la planification des projets et des moyens
correspondants afin de répondre aux objectifs de l’entreprise. Il en assure l’évolution par
l’inscription au schéma directeur des nouvelles applications.
• Est un document fixant dans le cadre plus vaste du schéma directeur et des objectifs
généraux, les secteurs et les objectifs de développement à court et à moyen termes, de
l’informatique dans l’entreprise. Il précise les modalités de réalisation, les résultats attendus
et prépare les décisions nécessaires, en temps voulu et de manière cohérente.
• Est un processus de consultation entre la direction générale, les utilisateurs et le
département informatique en vue d’établir et de mettre à jour périodiquement un
document de base définissant :
✓ La politique globale de traitement de l’informatique au sein de l’entreprise ;
✓ Les orientations concernant les règles de gestion ;
✓ Le schéma global des principaux systèmes à développer ou à modifier ; etc.
• Synonymes
On parle parfois de plan cadre ou plan directeur pour désigner un plan
informatique.
I.2.5. PROCESSUS :
En matière de projet, c’est un ensemble de procédés et des tâches permettant
d’obtenir le produit atteindre.
I.2.6. INFORMATION :
C’est l’élément de la connaissance susceptible d’être traité ou stocké sous forme
d’une donnée.
-5-
I.2.7. MAITRE D’OEUVRE :

C’est un Coordinateur auquel (à qui) le maître d’ouvrage délègue la responsabilité
de réalisation du projet par contrat. (Il est responsable des écarts constatés par rapport au cahier
des charges).
I.2.8. MAITRE D’OUVRAGE :

C’est la personne chargée du suivi de l’avancement d’un projet sur les aspects
techniques, délais, coûts et décisions à prendre tout au long du déroulement du projet enfin de
respecter les objectifs.
I.2.9. PROJET :
C’est le regroupement d’acteurs et des ressources en vue de réaliser des objectifs
identifiés dans un délai et par les moyens prévus en faisant appel ou non à des moyens
extérieurs.
• La gestion d’un projet (aspect économique et administratif) a pour but le suivi et la

rationalisation des efforts de développement en maîtrisant les coûts et délais, l’organisation
et la visualisation des tâches et ressources du projet, l’affichage des écarts aux provisions.
-6-
CHAPITRE DEUXIEME : TECHNIQUES DE COLLECTE D’INFORMATIONS (DONNEES)
1. Observation
2. Interview
3. Documentation
4. Enquêtes
5. Questionnaire
6. Réunions & séances des travaux.
==➔QUELQUES CONSEILS A PRENDRE EN COMPTE POUR LA SPECIFICATION D’UN PROJET
- Etudes des besoins d’un projet
- Savoir écouter le client

- Interpréter les besoins du client.
- L’architecture du système
- Choix du type de client
- Les services.
- Modélisation de l’architecture logicielle.
- Déduction de l’architecture matérielle
- Surveillance et gestion des erreurs du système

- Support d’enregistrement des logs & actions à surveiller
- Comportement du système face aux erreurs non gérées
- Implémentation de la sécurité.
- Les entrées utilisateurs.
- Les entrées non utilisateur.
- Les tentatives d’attaques.
Les tests :
- Tests unitaires. Un test unitaire est une portion de code qui va permettre de tester une
autre portion de code en exécutant celle-ci et en analysant son résultat. Les tests unitaires
permettent de rendre une application le plus robuste possible en testant comment elle
réagit à diverses situations (erreurs, performances,…). De plus, le temps gagné par
l’exécution de tests automatisés est très appréciable !
Il existe plusieurs types de bonnes pratiques pour la mise en place des tests préconisées par
la méthode Extreme programming :
• Implémenter les tests unitaires avant d’écrire le code afin de pouvoir tester du début à la
fin du développement de notre portion de code (appelée Test Driven Programming).
• Il existe aussi la programmation croisée qui nécessite deux développeurs : l’un implémente
les tests pendant que l’autre écrit le code.
• Implémenter les tests unitaires après l’écriture du code afin d’avoir une vue d’ensemble
des fonctionnalités à tester.
Par définition, un test unitaire doit pouvoir être autant disponible que le code qu’il teste. En
effet un autre développeur doit pouvoir tester la portion de code. De ce fait, il doit aussi être
exécutable sur le poste d’un autre développeur : il doit donc être indépendant de
l’environnement de travail. Pour assurer un gain de temps optimal, le test unitaire doit pouvoir être
exécuté automatiquement : par exemple juste après la compilation de la portion de code à
tester afin de pouvoir immédiatement répertorier les éventuels bugs.
-7-
- Tests d’intégration
Les tests d’intégration permettent de vérifier que les différents composants réalisés lors de la
phase de développement fonctionnent correctement entre eux et avec le reste de l’application.
Voyons un exemple simple : Il pourra être testé le bon fonctionnement d’un composant
permettant d’afficher une liste d’utilisateurs et un autre composant permettant d’ajouter un
utilisateur. Lorsqu’on ajoutera un utilisateur il devra s’être affiché dans le composant listant tous les
utilisateurs. Pour être bien sûr de valider la totalité des composants et de leurs fonctionnalités, il est
fortement recommandé de garder une trace de tous ces tests en réalisant des fiches. Dans ces
fiches on pourrait répertorier deux grandes parties : la présentation du test d’intégration et le
rapport de test afin de garder une trace du résultat obtenu. Voici les grandes lignes de ce que
l’on peut trouver dans la présentation d’un test d’intégration :
• L’objectif du test reprenant les différents composants à tester
• Une description permettant de détailler la démarche à suivre pour réaliser le test
• L’environnement nécessaire (matériel et logiciel)
• Le résultat attendu
Voici une liste non exhaustive des points abordés dans un rapport de test d’intégration :
• La date à laquelle a été réalisé le test
• Les intervenants qui ont réalisé le test
• Les numéros de version des composants intégrés testés
• L’environnement de test
• Le résultat obtenu ainsi qu’une partie pour commenter ce résultat
- Tests de validation :
Les tests de validation permettent de vérifier que les fonctionnalités développées sont bien
en accord avec la spécification de départ réalisée en collaboration avec le client. En effet, il
paraît évident de vérifier la bonne concordance entre le produit créé et les volontés du client. Les
tests de validation de composent en général de plusieurs phases :
• Une validation fonctionnelle permettant de tester les fonctionnalités de chaque
composant afin d’être sûr qu’elles correspondent bien à la specification
• Une validation solution permettant de tester les cas d’utilisations afin d’agréer que
l’application réagira comme il le faut ainsi que le respect des standards applicables au
projet.
Tout comme pour les tests d’intégration il est fortement recommandé de tenir à jour une
documentation de compte-rendu de tests de validation. En effet, il est possible que ce soit des
équipes de développement différentes qui testent l’application de celles qui développent
l’application. De ce fait, il est important pour l’équipe en charge du développement d’avoir une
trace de ce qui a été réalisé au niveau des tests. Voici les informations que peuvent contenir une
fiche de test de validation :
• L’objectif du test ainsi qu’une courte description comme par exemple : tester le cas
d’utilisation « connexion à l’application »
• La description des actions que l’utilisateur doit réaliser pour atteindre l’objectif du test
• L’environnement nécessaire pour mener à bien le test
• Le résultat obtenu ainsi qu’un commentaire
- La spécification pour Chef de projet ou développeur
- Définition du mot spécification dans ce support
-8-
Le mot « spécification » est à la base le document intervenant après un cahier des charges et
avant le processus de conception préliminaire. Dans ce support nous allons nous intéresser à une
spécification au sens « large » du terme, ce qui est souvent le cas lors de projets où le
développeur est lui-même le chef de projets. Nous allons voir comment il est possible, en un seul
document, d’architecturer notre SI.
- L’intérêt d’une spécification
Dans notre expérience passée, nous avons eu l’occasion de travailler avec des entreprises où la
spécification était inexistante ou se résumait à un bout de papier écrit sur un coin de table. Le
problème était que les directeurs ne souhaitaient pas dépenser de l’argent pour une analyse
qu’ils trouvaient sans intérêts. On se retrouvait avec :
• Des délais non respectés.

• Des délais respectés car le temps imparti était trop conséquent (le développeur se
permettant alors de travailler un jour sur deux).
• Un client revenant toujours sur ce qui avait été validé au préalable. Normal rien n’était mis
noir sur blanc.
Vous remarquerez que sur ces trois points, l’entreprise perd de l’argent.
- Les outils
Nous allons voir dans ce support quelques outils à utiliser, tels que :
• Microsoft Visual Studio 2008 Team System Architect Edition.
• Team Foundation Server & Windows Sharepoint Services, pour le travail collaboratif.
• Microsoft Visio 2007, pour la modélisation objet.
• NUnit, pour les tests unitaires.
• Microsoft Office Project 2007, pour la gestion du temps.
- Etablir une maquette de l’IHM
Créer une maquette d’IHM dans le dossier de spécification est primordial et doit être validé par le
client. Peu importe que vous utilisiez « Paint » ou un logiciel plus évolué. L’intérêt n’est pas de
montrer vos talents de graphiste mais surtout l’ergonomie de base et l’enchainement des fenêtres
C’est à dire le design.
N’hésitez surtout pas à attacher à côté un schéma simplifié montrant les interactions entre
chaque interface. C’est un travail fastidieux mais qui se révélera utile lors de la validation avec le
client.
-9-
CHAPITRE TROISIEME: PANORAMA DES METHODES
III. 0. Panorama des méthodes

Un point rapide sur les méthodes les plus couramment utilisées en gestion de projet
(PmBok, Prince2...). Ce dossier présente les phases fondamentales de la conduite de projet
comme la planification, l'estimation des coûts, délais et besoins en ressources, ainsi que les
principaux outils méthodologiques, diagrammes de Gantt, Pert et CPM, Work Breakdown
Structure. Ce dossier consacre un chapitre particulier pour traiter des méthodes de type agiles,
spécifiques aux projets informatiques.
• Conduite de projet
• Les phases du projet
• Exploration détaillée des principales phases de la conduite de projet.
• Définition du projet
• Conseils et recommandations pour traiter la phase initiale de définition du projet.
• Planification projet
• Planifier le projet
• Planifier et ordonnancer le projet, méthode et outils.
• Estimer les délais du projet
• Comment estimer les délais du projet, évaluer la durée de chacune des tâches ?
• Réaliser le diagramme de Gantt
• Planifier le projet, comment réaliser un diagramme de Gantt, les outils et produits open
source.
• Réaliser le diagramme de Pert
• Ordonnancer le projet, comment réaliser le diagramme de Pert, les outils et produits open
source.
• Réaliser le WBS Work Breakdown Structure
• Le découpage prévisionnel du projet, le WBS Work Breakdown Structure, les outils et
produits open source.
• La démarche de bon sens
• Les points d'impact de la démarche de bon sens présentée dans le livre de référence du
site.
• Estimer les délais
• Estimer les délais du projet
• Comment estimer les délais du projet, évaluer la durée de chacune des tâches ?
• Maitriser les délais du projet
• Quelques réflexions à propos de la maîtrise des délais du projet partie 1/3
• Gestion des délais du projet
• Quelques réflexions à propos de la maîtrise des délais du projet partie 2/3
• La culture projet et la Maitrise des délais
• Quelques réflexions à propos de la maîtrise des délais du projet partie 3/3 Pmbok
• Le PmBok
• Le PMBOK, Project Management Body of Knowledge du PMI, présentation de la
démarche, les ressources.
• Prince2
• Prince2, la méthode
• Prince2, présentation de la démarche, description du principe, les ressources.
• Prince2, pros & cons
• Prince2, les avantages et les inconvénients de la méthode Prince2.
• Formation Prince2
• Les formations et certifications Prince2, remarques à propos de l'usage de Prince2, les
ressources.
• Modélisation & formalisation
- 10 -
• La méthode Merise une méthode standard de conception et de conduite des projets

informatique.
• Le langage UML
• UML, langage de modélisation unifié est un outil incontournable pour formaliser et
modéliser en utilisant un langage standard reconnu.
• Développement Agile
• Les méthodes agiles, le dossier
• Dossier complet à propos des méthodes agiles, définition, exemples, conseils et
recommandations de terrain.
• Les méthodes agiles
• Comment conduire les projets informatiques sans faire exploser les budgets et les délais
tout en répondant aux attentes des clients.
• Les méthodes agiles pour les projets informatiques
• Les méthodes agiles pour les projets de développement informatique, une démarche
fondée sur le dialogue continu.
• Les méthodes agiles, réussir le projet
• Les conditions de réussite, le dialogue avec le client, la planification flexible et l'importance
clé de la réunion.
• La méthode RAD
• La méthode RAD, Rapid Application Development.
• La méthode XP
• La méthode XP, eXtreme Programming Une méthode agile orientée projet informatique.
• La méthode SCRUM
• Le nom de la méthode SCUM, terme de rugby désignant la mêlée, est révélateur des
aspects dynamiques et coopératifs de la méthode.
III.1. LES MÉTHODES : DIVERSITÉ ET PROLIFÉRATION
MCPI
ENTREPRISE CONCEPTION REALISATION
M.ES.DI MCSI ANALYSE PROGRAMMATION
AXIAL MERISE MERISE PS

RACINES MCX MCX OOP
MERISE R. REIX R REIX
OOD OOA VP
III.1.1. METHODE SDM/S

Diagramme de GANTT : qui est orienté sur la gestion du temps et indique les dates
de début et de fin des différentes tâches (activités) composant un projet.
➔ La planification repose sur un calendrier qui tient compte des jours ouvrables, des jours fériés,
des absences (maladie, etc.) et des vacances.
• Racines : Rationalisation des choix informatique dans une entreprise.

- 11 -
•AXIAL : La méthode AXIAL est une méthode d'analyse, de conception et de

gestion de projet initialement utilisée dans le monde IBM.
Issue de l'analyse systémique, la méthode AXIAL est une méthode qui a été
concurrente de la méthode Merise.
• OOD : Object oriented design
• SD : Systèm design
• VP : Visual programming
• VB : Visaul Basic
• V Dbase : Visual Dbase
• VC++ :
MERISE
MCP DE gedin
MCP – J
MCPi SDM/S
- Evolution technologique
- Novicité
- Caractère inactive
III.2. METHODES DE CONDUITE DE PROJETS INFORMATIQUES
III.2.1. METHODES AGILES
1. OBJECTIFS
Le mouvement de méthodes agiles a commencé en 2001 aux Etats-Unis regroupant 17 experts en

développement logiciel. Ces derniers ont travaillé et mis au point ces méthodes suite à un taux
d’échec important des projets observés dans les années 1990.
Les méthodes agiles sont les méthodes de développement informatique qui permettent de
concevoir des logiciels tout en impliquant le client. Elles sont pragmatique que les méthodes
classiques. Les méthodes agiles visent la satisfaction réelle du besoin du client et non celle d’un
contrat établi préalablement.
Elles utilisent le principe de développement itératif qui consiste à découper le projet en plusieurs
étapes appelées itérations.
Ces itérations sont comme des mini-projets définis avec le client en détaillant les différentes
fonctionnalités qui seront développées en tenant compte de ce qui est prioritaire.
Le développement itératif a pour avantage :

- Meilleure qualité de la communication
- Meilleure visibilité
- Meilleur contrôle de qualité
- Meilleure détection des risques
- Motivation et confiance de l’équipe
- Contrôle des coûts.
Les méthodes agiles sont plus utilisées pour les gros projets parce qu’elles offrent une meilleure
adaptabilité, visibilité et gestion des risques. Elles sont également utilisées pour les projets qui
manquent de documentations détaillées.
- 12 -
Les méthodes agiles prônent 4 valeurs fondamentales :
1. Personnes et interactions par rapport aux procédures et outils

Ce n’est pas le suivi de procédure stricte qui garantit la réussite mais plutôt une équipe
soudée et constituée des bons développeurs. La communication est privilégiée.
2. Applications fonctionnelles par rapport à une documentation complète

Il est important que l’application fonctionne. La documentation représente une charge de
travail importante mais peut être néfaste si elle n’est pas mise à jour. Les méthodes agiles
privilégient une documentation succincte et précise qui décrit les grandes lignes du projet
et qui sera régulièrement mise à jour.
3. Collaboration avec le client par rapport à la négociation du contrat

Le client doit être impliqué dans le développement. Ceci est un gage de réussite du projet.
Travailler en collaboration avec le client est la meilleure façon pour lui de contrôler le
projet. Ça permet au client de fournir un feed-back régulier sur l’adaptation du logiciel.
4. L’acceptation du changement par rapport à la planification

La planification doit être souple et accepter le changement. Elle doit être flexible pour
permettre l’évolution du besoin du client tout au long du projet.
2. TABLEAU COMPARATIF DES METHODES AGILES AUX METHODES CLASSIQUES
Thème Approche traditionnelle Approche agile

Cycle de vie En cascade ou en V, sans Itératif et incrémental
rétroaction possible
Planification Prédictive, caractérisée par Adaptative avec plusieurs

des plans plus ou moins niveaux de planification
détaillés sur la base d’un (macro et microplanification)
périmètre et d’exigences avec ajustements si nécessaire
définis et stables au début du au fil de l’eau en fonction des
projet changements
Documentation Produit en quantité importante Réduire au strict nécessaire au

comme support de projet d’incréments
communication de validation fonctionnels opérationnels
et de contractualisation pour obtenir le feedback du
client
Equipe Une équipe avec des Une équipe responsable où
ressources spécialisées, l’initiative et la communication
dirigées par un chef de projet sont privilégiées, soutenue par
le chef de projet.
Qualité Contrôle qualité à la fin du Un contrôle qualité précoce et

cycle de développement. Le permanent au niveau du
client découvre le produit fini. produit et du processus. Le
client visualise les résultats tôt
et fréquemment
- 13 -
Changement Résistance voir opposition au Accueil favorable au

changement. Processus lourds changement inéluctable,
de gestion des changements intégré dans le processus.
acceptés.
Suivi de Mesure de la conformité aux Un seul indicateur

l’avancement plans initiaux. Analyse des d’avancement : le nombre de
écarts. fonctionnalités implémentées
et le travail restant à faire.
Gestion des Processus distinct, rigoureux, Gestion des risques intégrée

projets de gestion des risques. dans le processus global, avec
responsabilisation de chacun
dans l’identification et la
résolution des risques. Pilotage
par les risques.
Mesure du Respect des engagements Satisfaction du client par la

succès initiaux en termes de coûts, de livraison de valeur ajoutée
budget et de niveau de
qualité
III.2.2. SDM/S
La plus connue des méthodes de conduite de projet informatique, SDMS, d’origine anglo-
saxonne, organise le cycle de vie du projet autour de trois autres cycles :
• Le cycle de développement, de base pour les grands systèmes avec un cycle court pour
les petits projets ;
• Le cycle de maintenance ;
• Le cycle d’évolution.
Un cycle de décision permet la prise des décisions par les responsables afin
d’assurer l’avancement du projet. Un cycle de développement d’un projet est découpé en onze
phases :
• DS-EO : Demande de service et étude d’opportunité ;
• DBS : Définition des besoins du système ;
• CAS : Choix d’architecture du système ;
• SES : Spécifications externes du système ;
• SIS : Spécifications internes du système ;
• PRG : Programmation ;
• CONV : Conversion ;
• TST : Test ;
• MPP : Mise en place pilote ;
• GENE : Généralisation ;
• BILAN : Bilan.
- 14 -
PHASE OBJECTIFS PRINCIPALES TACHES

- Définition des objectifs du domaine d’études, des
Fournir à la hiérarchie contraintes, des utilisateurs.
les informations - Détermination des besoins des utilisateurs
DS-EO permettant la décision - Etude des différentes solutions possibles
d’engagement de la - Justification du projet
conception. - Etude d’impact, risques et coût
- Planification et charge
- Définition des limites et de la portée du projet.
- Analyse et modélisation du SI existant
Définir précisément les
- Bilan de l’existant
besoins et exigences
DBS - Orientation du futur système
des utilisateurs et les
- Modélisation conceptuelle globale du futur
objectifs du projet
système
- Identification des contraintes de conception

Choix du scénario - Identification des scénarios possibles
CAS
d’information - Comparaison des scénarios et choix
-
- Description de l’environnement support du SI
pour les traitements et le stockage de données.
- Production des spécifications externes
Etude détaillée du
- Etude des communications
SES fonctionnement du
- Exigences de sécurité
système
- Etude des plans de conversion, de reprise de
l’existant et de mise en place du futur SI
- Etude de l’architecture interne du système

- Spécifications internes des programmes
- Spécifications de tous les éléments techniques
Spécifications internes
SIS - Etablissement des modèles logiques de données
pour les réalisateurs
- Finalisation de la conception des entrées-sorties
- Finalisation des plans d’acceptation,
conversion, mise en place pilote.
- Codage des programmes et modules
- Préparation des procédures d’appel (job
control language, shells …)
Production et test du - Mise en place de la gestion des librairies de
PRG
code programmes et procédures
- Tests unitaires et d’intégration
- Préparation des dossiers de programmes et
tests.
- Préparation du plan de conversion
- Définir des caractéristiques attendues en entrée
CONV Conversion de l’existant et en sortie de la conversion
- Rédaction du dossier de conversion et mise en
place des procédures manuelles éventuelles
Recettes - Définition des critères d’acceptation du système
TST d’acceptation du - Tests de recette (réalisateurs, utilisateurs,
système d’acceptation globale)
MPP Lancement du système - choix du site pilote
- 15 -
en pilote - installation et recette de l’environnement

nécessaire
- préparation de la documentation
- formation - lancement du système
- recette d’acceptation du système
- planification de la généralisation
GENE Généralisation
- exécution et suivi de la généralisation
Bilans de la mise en
- Fournir les éléments objectifs sur ces phases, sur les
place pilote, de la
BILAN plans de la qualité de service, économique,
généralisation, en
technique, social
régime permanent
Les cycles de maintenance et d’évolution sont inclus dans la méthode avec :
• L’enregistrement des demandes de correction et d’évolution ;

• L’évaluation de leur priorité et des charges induites, en vue de décision d’action ou de report
sur de nouvelles versions du logiciel.
Le cycle de maintenance n’utilise que les phases SIS, PRG, TST. Le cycle court, prévu
pour les petits projets, regroupe les onze phases en deux :
CYCLE COURT CYCLE DE BASE

CDA : Conception Détaillée de l’Application DBS, CAS, SES
SIS, PRG, CONV, TST
REA : Réalisation de l’Application (éventuellement : MPP, GENE,
BILAN)
Un cycle est également prévu en cas d’acquisition de progiciel. Chaque phase est
décrite précisément dans un guide structuré en sept chapitres :
1. Introduction, situation de la phase et objectifs ;

2. Préface sur l’équipe et sur les revues informelles et formelles à réaliser ;
3. Guide des tâches générales et élémentaires ;
4. Guide de la documentation ;
5. Guide des imprimés ;
6. Guide des estimations de charges et des enchaînements des tâches ;
7. Notes.
Ces chapitres sont complétés par des fiches techniques.

La méthode SDMS est maintenant largement appliquée. Elle présente l’avantage d’une
indépendance par rapport aux méthodes de conception et réalisation employées, d’une grande
précision dans les tâches à réaliser et les objectifs à remplir. Sa contrepartie est en échange la
volumineuse documentation de cette méthode-douze tomes épais ! - et donc sa difficile
assimilation.
III.2.3. MCP ET MCPJ
Une méthode a pris en France et a plus ou moins servi de base à beaucoup

d’organismes. Il s’agit de MCP (méthode de conduite de projet) conçue par M. GEDIN pour la
RATP et qui a fait l’objet d’un livre. Elle distingue quatre grandes phases ou étapes (nous les
nommerons ici étapes pour respecter nos conventions avec des phases intermédiaires) dans le
vie d’un projet :
- 16 -
III.2.3.1. L’ETAPE DE CONCEPTION
Elle comprend les phases suivantes :
• Expression des besoins d’automatisation par le promoteur de la demande en vue d’inscription

au schéma directeur ;
• Etude d’opportunité qui définit les objectifs à atteindre, les options techniques possibles, la
fiabilité technique et économique en vue d’une inscription au plan informatique annuel.
• Dossier d’étude du système d’information qui sera approuvée par le maître d’œuvre de la
solution proposée ; cette étape reprend pratiquement l’étude préalable et l’étude détaillée
proposée par Merise ;
• Elaboration du cahier des charges qui définit à la fois la stratégie de développement, la
responsabilité, la planification et la charge de réalisation.
III.2.3.2. ETAPE DE REALISATION
L’étape de réalisation recouvre l’étude technique générale et détaillée (analyse

organique), le codage et les tests.
III.2.3.3. LA MISE EN ŒUVRE
Elle comprend :
• La réception provisoire du système par l’utilisateur à partir de leurs jeux d’essais ;

• Le lancement sous contrôle.
III.2.3.4. L’EXPLOITATION
Elle clôture le projet après un bilan quantificatif et qualitatif donné sur un temps de
fonctionnement significatif. La méthode définit bien de rôle des acteurs de la décision en
identifiant le promoteur par rapport à la maîtrise d’ouvrage. Les fiches à établir par phase sont
précises. Elle est à compléter sur certains points comme la gestion de sous-traitant, la recherche
d’optimisation des coûts de développement autour d’outils communs et la démarche qualité.
MCP a été conçue dans les années 70. Cette méthode n’est pas liée à Merise, mais
les deux sont tout à fait conciliables. Plutôt que de prendre une méthode externe et de vouloir
l’appliquer à tout prix, il peut être intéressant de partir de la démarche inverse et de définir la
méthode propre à un organisme avec des groupes de travail constitués des futurs acteurs des
projets. Il faut bien entendu que cette recherche soit guidée par des consultants externes ou
internes, une cellule normes et méthodes par exemple, ayant une bonne connaissance des
tâches à accomplir et des interactions entre cycles, outils, acteurs.
C’est ce qu’a fait le ministère de la Justice qui a établi sa méthodologie propre :

MCPJ (J pour Justice). Cela donne un ensemble extrêmement solide, les outils et les méthodes
étant étroitement liés, et les acteurs étant impliquées dans la définition et la mise en œuvre de
cette méthode et ayant décidé de leur propre rôle et système de relations. A partir du contexte :
• Méthode de conception : Merise

• Atelier de génie logiciel : Espace micro et espace central pour la conception cariatides pour
la réalisation, super projet expert pour le suivi ;
• Choix d’un SGDB relationnel pour toutes les applications ;
• Réfection de la quasi-totalité des applications ;
- 17 -
• Recherche d’un équilibre entre les directions utilisatrices et celle unique, de l’informatique ;
• Faiblesse quantitative des informations, ce qui implique un très fort taux de sous-traitance. On
y trouve : Un découpage en étapes.
Après l’étude d’opportunité :
• Etude préalable avec choix de scénario, et élaboration de 80% des MCC (1), MCD, MCT,
MOT ;
• Etude détaillée finalisant le MCD, et établissant les spécifications externes et internes ;
• Réalisation débutant par l’étude technique générale et détaillée puis le codage et les VQR
(Vérifications de qualité de réalisation) ;
• mise en œuvre du site pilote.
(1) Modèle de flux de communication (méthode Merise Gamma)

- 18 -
On notera le parallélisme méthode-outils :
ETAPE TÂCHES OUTILS

Espace micro
ETUDE PREALABLE Etude des scénarios MCC, MCD, MCT, MOT
Espace central
Finalisation MCD
Espace micro
ETUDE DETAILLEE Finalisation MLD
Espace central
Spécifications externes et internes
Etude technique générale et détaillée
Cariatides
REALISATION Codage
Oracle
Vérification de qualité de réalisation
MISE EN ŒUVRE Mise en œuvre site pilote Oracle
- 19 -
CHAPITRE QUATRIEME : MODELISATION DE CONDUITE D’UN PROJET INFORMATIQUE
Le projet constitue un ensemble destiné à répondre à des objectifs précis,

dans un temps limité en rassemblant les ressources financières, matérielles, humaines nécessaires
suivant un processus cohérent. Le projet est caractérisé par le triplet :
PROJET = {OBJECTIFS, MOYENS, DELAI}
Un projet représente souvent la réunion des caractéristiques suivantes :
• Technique d’avant-garde ;
• Durée de travaux longue et peu visible avant la fin de processus ;
• Réunion d’efforts massifs en plus du fonctionnement normal d’une entreprise ;
• Diversité des responsables et des acteurs ;
• Milieu aléatoire et mal maîtrisé
• Complexité.
Les responsables du projet se trouvent souvent pour décider en face de quatre

facteurs de risques glissants et liés :
• Les délais
• Les coûts
• La technique
• Les acteurs
Ainsi, la conduite de projet doit suivre donc et replanifier en continu les tâches, la
nature et la quantité des ressources à affecter.
IV.1. PREALABLES
Le projet informatique doit être précédé :
1. D’une étude d’opportunité qui permet tout d’évoluer préalablement le retour sur
investissement (qu’il soit financier ou non) attendu, contenant éventuellement des études
de faisabilité.
2. D’une définition complète, précise, détaillée des objectifs stratégiques et opérationnels à
atteindre et des limites du champ de l’étude.
3. D’une définition au moins grossière des structures et de l’organisation du projet, tenant
compte éventuellement de partenaires multiples, et de la mise en place des circuits de
décision avec des responsables nommément désignés.
4. D’une identification des principales étapes et des principales tâches à l’intérieur de
chaque étape, du lancement à l’achèvement du projet, et du résultat attendu à chaque
fois.
5. D’une analyse des ressources à affecter au projet et d’une première planification des
périodes où elles seront nécessaires.
6. De l’engagement de décideurs sur les moyens et la priorité à affecter au projet.
Un projet ne débute qu’après que la décision de son lancement a été prise au

niveau le plus élevé avec l’engagement de tous les partenaires sur les objectifs à atteindre et les
moyens à mettre en œuvre. Tout projet informatique peut suivre le schéma suivant :
➢ Etude de faisabilité et examen
- 20 -
➢ Conception
➢ Réalisation
➢ Mise en œuvre
IV.2. ETAPES DE CONDUITE D’UN PROJET INFORMATIQUE
Tout projet informatique peut se décomposer en un certain nombre d’étapes :
➢ Etude de faisabilité,
➢ Conception (spécifications fonctionnelles) ;
➢ Spécifications techniques ;
➢ Développement ;
➢ Implantation (Mise en œuvre ;)
➢ Explication (Maintenance.)
Ainsi, comme tout produit qui doit être mis à la disposition d’un client, passe par une
phase de conception ou ses caractéristiques principales sont pensées, une phase de fabrication
où il est matériellement réalisé et une phase de vente où son utilisation finale l’acquiert, l’utilise, le
cas échéant le fait réparer après usage.
Le schéma du cycle de vie d’un projet informatique se présente comme suit :
Dossier d’étude
ETUDE D’OPPORTUNITE d’opportunité
ETUDE FONCTIONNELLE DU SYSTEME Cahier des charges

INFORMATIQUE ET PROTOTYPAGE
CONCEPTION DU SYSTEME D’INFORMATION Cahier des charges des

réalisateurs
Manuels utilisateur
REALISATION
Cycle de développement
RECETTE UTILISATEUR
Dossier de Maintenance
MISE EN ŒUVRE EXPLOITATION
MAINTENANCE
➢ Etude de l’existant ;
➢ Modélisations conceptuelles ;
- 21 -
➢ Modélisation de l’organisation ;
➢ Modélisation logique ;
➢ Modélisation physique.
Existent d’autres méthodes tels que :
➢ Outils statistiques ;
➢ Outils de R.O ;
➢ Méthode de gestion (budget);
➢ Méthode de programmation.
Remarque : Pour chaque cycle de vie sera montée une fiche synthétique
précisant les acteurs impliqués, les tâches exécutées et les résultats produits.
A. ETAPE 1 : ANALYSE DE LA DEMANDE
➢ Objectif : Analyser une demande.

➢ Acteurs :
• Qui formule la demande ?
• Qui analyse la demande ? (Directeur chargé d’étude)
➢ Tâches :
• Enoncé clair et complet de la demande ;
• Etude de la demande face à la planification ;
• Etude d’opportunité (existant) ;
• Champs de l’étude ;
• Situation existante ;
• Problématique- objectif et contraintes, solution possibles, coûts.
➢ Résultat :
• Demande spécifiée (appelée aussi étude d’opportunité) ;
• Aboutissant à proposer :
- Un projet nouveau ;
- Un projet ancien à adopter ;
- Rejet de la demande.
➢ Dossier : Etude d’opportunité transmise pour la décision.
➢ Rôle de la conception : Analyse de l’existant.
ETAPE 2 : SPECIFICATION DU PROJET
➢ Objectif : Reprendre et pousser plus loin l’analyse de la demande

➢ Acteurs : Chef de projet et les utilisateurs
➢ Tâches :
• Approfondissement de l’étude de l’existant ;
• Diagnostic sur l’analyse de la demande (erreur possible) ;
• Accord définitif sur les objectifs et en domaine d’activité ;
• Nouvelle évaluation des moyens, des coûts ;
• Nouvelle évaluation du matériel.
➢ Résultat :
• Projet spécifié fixant :
- Les objectifs ;
- Le diagnostic de l’existant ;
- Les coûts et délai prévisionnel.
➢ Dossier : Dossier de spécification transmis pour décision au comité de direction
ou directeur de l’informatique
- 22 -
➢ Rôle de la conception : L’analyse de l’existant par les interviews de direction,

des responsables, d’organisation, de spécialistes de postes de
travail, puis les validations permettant d’approfondir l’étude de
l’existant, élaboration du modèle de niveau conceptuel.
ETAPE 3 : CONCEPTION GENERALE
➢ Objectif : Proposer des choix d’organisation et des choix techniques entre

plusieurs solutions.
➢ Acteurs : Le chef de projet et son équipe avec les utilisateurs.
➢ Tâches :
• Choix d’un sous ensemble représentatif du champ de l’étude(Conception et modélisation de
la N solutions ;
• Choix de gestions définies (imposées ;
• Choix d’organisation proposés (contraintes éventuelles) ;
• Choix techniques proposés.
• Maquettes montrant les choix proposés ;
• Scénarios de développement (sans-profils) ;
• Etude comparative sur :
- Satisfaction des besoins

- Risques en cours
- Coûts
➢ Résultat : Proposition des plusieurs solutions.
➢ Dossier : Dossier de choix.
➢ Rôle de la conception : Etude de l’existant, proposition de travail, MCD, MCT, MOT.
ETAPE 4 : CONCEPTION DETAILLEE
➢ Objectif : Concevoir une solution conforme au choix d’organisation et aux choix

techniques.
➢ Acteurs : Le chef de projet et son équipe avec les utilisateurs.
➢ Tâches :
• Conception de solution détaillée en appliquant :
- Des choix de gestion imposée ;
- Des choix techniques retenus.
• Préparation des plans d’action pour assurer :
- Réalisation-tests fonctionnels-conclusion-mise en œuvre- information-formation.
➢ Résultat : Description complète de 10 solutions détaillées pour passer à la réalisation.
➢ Dossier : Cahier des charges transmis au Directeur des études ou Directeur Technique.
ETAPE 5: REALISATION
➢ Objectif : Produire les logiciels en état de fonctionnement.

➢ Acteurs : Le chef de projet associé ou chef d’application et l’équipe de réalisation.
➢ Tâches :
• Etude technique défaillie ;
• Architecture physique des données ;
• Architecture de programmes.
- Temps différé ;
- Temps réel.
• Production des logiciels
• Tests ; mise en pied
- 23 -
• Préparation de la mise en exploitation

➢ Résultat : Logiciels opérationnels et documents permettant d’en assurer + la recette finale.
➢ Dossier : Dossier réalisation ou Dossier d’exploitation. Manuel utilisateur.
➢ Rôle de la conception : Etude technique s’appuie sur ce modèle physique des données et le
MOPT.
ETAPE 6 : MISE EN OEUVRE
➢ Objectif : Lancement de l’application pour l’exploitation.

➢ Acteurs : Le chef d’application et son équipe, participation des utilisateurs, assistance chef
projet.
➢ Tâches :
• Affichages des plans de mise en œuvre.
• Matériels - Logiciels – organisation - Personnelle
• Affichage des plans : de conversion d’information, de formation ;
• Mise en place de moyens (matériels, logiciels, formation, organisation);
• Exécution des plans de conversion ;
• Explication en grandeur réelle.
➢ Résultat : Application en exploitation et suivi de celle – ci.
➢ Dossier : Cahier de recettes, cahier d’incidents, Bilan de performance.
➢ Rôle de la conception : Néant.
ETAPE 7: MAINTENANCE
➢ Objectif : Maintenir l’application en état de fonctionnement en absorbant les nouveaux choix,

techniques, gestion, organisation.
➢ Acteurs : Le chef d’application et l’équipe de maintenance. Responsable de l’application et
les utilisateurs.
➢ Tâches : Analyse de la demande d’adaptation : - Contenu – Impact - Urgence
➢ Résultat : - Demande rejetée - Demande acceptée et MAJ effectuée.
➢ Dossier : Dossier de projet mis à jour et conservé par l’équipe de maintenance.
➢ Rôle de la conception : En fonction des niveaux d’impact.
En conclusion : Pour Manager des Organisations en informatique on s’appuie sur les

points suivants :
• Convertir sa stratégie en action

• Exécuter sa stratégie grâce au leadership
• Maîtriser le portefeuille de projets
• Conduire le changement
• Diriger des équipes efficacement
• Exécuter des programmes complexes
1 – Convertir sa stratégie en action
Dans cette partie, vous devez :
• Harmoniser initiatives de projet et objectifs stratégiques
• Faire des choix et établir des priorités pour gérer un portefeuille de projets lors du
développement d'un produit ou dans tout autre contexte commercial à évolution rapide
• Accélérer la finalisation des projets en déployant les ressources plus efficacement
• Utiliser de nouveaux outils pour améliorer la planification et l'exécution, et ainsi réduire les
délais de commercialisation
• Faire face aux situations d'urgence grâce à une gestion du temps plus efficace
- 24 -
• Promouvoir la gestion de projet avancée aussi bien avec des équipes en contact direct
qu'avec des équipes à distance
• Réduire l'écart entre savoir et action
• Créer un modèle de maîtrise organisationnel personnalisé à partir des meilleures pratiques
et l'appliquer directement à votre entreprise
• Mettre en place une organisation matricielle plus solide car axée sur les projets pour plus
de performance et de régularité.
2 – Exécuter sa stratégie grâce au leadership

Dans cette partie vous devez :
• Gérer la prise de décision et la communication dans une planification d'exécution de la
stratégie
• Assurer l'équilibre avec la stratégie et garantir le bon fonctionnement de l'entreprise
• Évaluer et planifier les risques liés à l'activité de l'entreprise
• Créer des partenariats par le biais de sponsoring et d’alliances
• Planifier et conduire les changements induits par de nouveaux portefeuilles de projets
3 – Maîtriser le portefeuille de projets
• Instaurer une conduite efficace dans la gestion d'un ou plusieurs portefeuilles de projets
• Évaluer la valeur et les risques associés aux projets du portefeuille
• Harmoniser projets et objectifs stratégiques
• Choisir entre plusieurs opportunités attractives quand vous n'avez pas assez de ressources
pour toutes les réaliser
• Personnaliser, mettre en œuvre et institutionnaliser le processus de gestion de portefeuille
qui conviendra le mieux à votre entreprise.
• Faire preuve de bon sens pour bien gérer les détails du portefeuille au quotidien
• Réduire l'impact négatif des relations de pouvoir dans l'entreprise
• Faire coexister le processus de gestion de portefeuille et d'autres processus commerciaux.
• Promouvoir la cohérence à travers l'entreprise en matière d'objectifs de gestion de
portefeuille, de procès, de rôles et de responsabilités.
• Travailler efficacement avec les clients ou les consommateurs pour les aider à organiser
leur portefeuille de projets
• Comparer les projets en cours aux nouveaux projets, tout en gérant une dynamique dans
laquelle les projets sont constamment ajoutés, conclus et réadaptés.
• Comparer les ressources demandées aux ressources disponibles
• Mieux comprendre l'interdépendance des projets
• Répondre aux chefs de projet et aux chefs de fonction lorsqu'ils réclament plus de temps,
d'argent et de ressources
4 – Conduire le changement
• Définir les différents types de changement et diagnostiquer les raisons profondes du besoin
de changement
• Analyser la psychologie du changement et comprendre pourquoi certaines tentatives de
changement échouent
• Établir un échéancier de 90 jours pour acquérir l'assurance et l'approbation nécessaires à
la planification et la mise en œuvre du changement, tout en soutenant votre stratégie et
vos initiatives de projet
• Répondre à des challenges courants par la mise en pratique de différents outils et
techniques lors d'études de cas réels, sélectionnés dans le monde entier.
5 – Diriger des équipes efficacement
• Gérer le conflit plus efficacement et à le transformer en source d'innovation
- 25 -
• Modifier votre façon de créer, développer et évaluer vos équipes pour dégager des
stratégies et techniques de pointe
• Identifier des questions de culture et de langage qui peuvent créer des problèmes au sein
des équipes
• Surmonter des difficultés dues à la distance et aux limites des technologies de
communication
• Développer une culture d'équipe qui encourage l'innovation dans les équipes de projets
• Gérer la participation de coéquipiers occasionnels
• Maximiser l'usage des technologies de communication
6 – Exécuter des programmes complexes
• Acquisition d'un soutien durable de la direction et des investisseurs clés
• Gestion d'équipes inter-entreprises et inter fonctionnelles
• Compréhension et gestion d'interfaces et d’interdépendances de programme dans des
systèmes complexes
• Stratégies prédictives contre stratégies empiriques : comment gérer des projets complexes
dont le périmètre évolue rapidement ?
IV.3. CYCLE DE VIE DE CONDUITE D’UN PROJET INFORMATIQUE
Toute solution informatique peut se décomposer en un certain nombre d’étapes.

Celles – ci, indépendantes de la méthode elle–même sont cependant liées à des familles de
méthodes.
1. Analyser de la demande
2. Spécification du projet
3. Conception générale (ou étude préalable)
4. Conception détaillée (ou étude détaillée)
5. Réalisation
6. Mise en œuvre
7. Maintenance
Ainsi, la conduite d’un projet est le parcours de ces étapes même si le projet n’existe
réellement qu’à la fin de la première et disparaît dès la 5ème pour devenir application.
Remarques :- La planification de l’activité informatique d’une entreprise peut être

traduite par la mise en place d’un schéma directeur ;
- Toute méthode de conduite de projet informatique permet de voir le
projet à travers trois cycle : CYLCE DE VIE, CYCLE DE DECISION, CYCLE
D’ABSTRACTION. Autrement dit, toute méthode vous enseigne :
1. Comment enchaîner les étapes ?

2. Quelles décisions sont à prendre au fil de celle – ci ?
3. Quels outils permettent de les mener ?
a) CYLCE DE VIE
Il permet de décrire la vie du système d'information. On distingue trois périodes :
• La conception du système d'information qui aboutit à la conception détaillée des spécifications

fonctionnelles et techniques, (Gestation + Conception) ;
• La réalisation qui consiste à produire des programmes et des consignes d'utilisation
correspondant aux spécifications détaillées, (Développement, Mise en œuvre) ;
- 26 -
• La maintenance du système d'information qui a pour objectif l'adaptation aux évolutions de son
environnement. (Exploitation + Evolution.
L’ordre chronologique énuméré au niveau des étapes, traduit la démarche à suivre.
b) CYCLE DE DECISION
Il concerne les différents choix qui sont effectués tout au long du cycle de vie. La
plupart de ces décisions marquent la fin d'une étape et le début d'une autre. Pour chaque étape
Merise prévoit trois actions : préparer, exécuter, contrôler.
c) CYCLE D’ABSTRACTION
Il offre les concepts nécessaires à la description du monde réel dans le système

d'information. On y trouve les quatre (ou trois) niveaux d'abstraction de Merise (conceptuel,
organisationnel, logique et physique).
- 27 -
Exemple : d’organigramme d’un projet

CHEF DE PROJET
Type général
PLANIFICATEUR BIBLIOTHECAIRES RESPONSABLE QUALITE
RESPONSABLE S/P
EQUIPE DE
DEVELOPPEMENT
Remarques :
➢ Le bibliothécaire recouvre les fonctions de gestion de configuration et de consolidation

par rapport à l’administration des données ;
➢ La maîtrise d’ouvrage :
• Définit les objectifs et les résultats attendus ;

• Fournit les moyens financiers et les ressources en personnel utilisateur ;
• Valide les résultats de chaque étape.
➢ La maîtrise d’œuvre
• Fournit les compétences informatiques et veille à l’application de l’état de l’art en fonction de
l’environnement technique propre à l’organisme.
• S’engage sur les résultats.
➢ La taille du projet ne doit pas dépasser une cinquantaine d’intervenants internes, afin que
le chef de projet soit en mesure de la manager.
Exemple : d’organigramme de grand projet
➢ Rôle de la conception : Utilisation pleine de la méthode.
IV.4. LES ACTEURS D’UN PROJET INFORMATIQUE
Les acteurs d’un projet peuvent être regroupés suivant les typologies.
A) 1. UTILISATEURS
• Utilisateurs finaux ;
• Les utilisateurs représentant les premiers.
2. INFORMATICIENS
• Concepteurs et spécificateurs (concepteurs, analystes, analystes programmeurs, …) ;

• Réalisateurs ;
• Experts des différentes spécialisés ;
• Ingénieurs systèmes et réseaux ;
- 28 -
• Techniciens et ingénieurs de maintenance.
B) TYPOLOGIE B
Maîtrise d’ouvrage / Maîtrise d’œuvre.
• Maîtrise d’ouvrage : les commanditaires de la prestation.

• Maîtrise d’œuvre : chargé de son exécution/ sous-traitance.
Les instances de décision comprennent :
• Comité de direction
• Comité de pilotage
• Comité de suivi réunissant l’ensemble des acteurs dont les sous–traitant.
Remarque :
Il n’y a qu’un maître d’œuvre unique, la sous-direction informatique.

Les acteurs principaux en sont le CPU (Chef de projet utilisateur) et le CPI (Chef de
projet informatique). La Sous-traitance est pilotée par le maître d’œuvre. La réalisation est confiée
au forfait, par lots, à des sous-traitants sur des plates formes de développement externes et fait
l’objet d’une recette sur une plate forme interne.
IV.5. ORGANIGATION INTERNE
a) Organisation générale
Le projet doit certes avant tout produire du logiciel, mais de nombreuses actions
d’accompagnement doivent également être assurées :
• L’ordonnancement des tâches ;

• La qualité du produit et du processus ;
• La coordination et le suivi de la planification ;
• L’administration du projet (Budget) (gestion des ressources).
- 29 -
DIRECTEUR DE COMMERCIAL
PROJET COMMUNICATION
Bureau Responsable Direction Administration

d’ordre Qualité Technique Données
Planification Intégration
Chef de
projet
Bibliothécaire
Responsable
Projet
Remarque : Bureau d’ordre
• Secrétariat ;
• Gestion personnelle ;
• Logistique (petit).
III. EVOLUTION PENDANT LE CYCLE DE PRODUCTION
Pendant le cycle de production, les acteurs différents nettement entre la

conception et la réalisation ainsi la conception a pour objectif de produire une modélisation
validée des données et activités du S.I., des scénarios organisation et technique. D’où
l’organisation est en trois grands groupes.
• Groupe de projet (solution ;)

• Groupe utilisateurs (dessins ;)
• Le comité directeur (grandes orientations) ;
• Experts.
- 30 -
Comité
Directeur
Experts
Groupe de
Consultants projet
GROUPE UTILISATEURS
IV.6. DYNAMIQUE DE GROUPE ET PRISES DE DECISION
a) Animation du groupe de travail
La commission du chef projet est de :
1. Définition Technique
• Définir, préserver les objectifs et le champ du projet ;

• Décrire exhaustivement toutes tâches ;
• Analyser les facteurs de risque et les lever par des études préliminaires de faisabilité de
rechercher les solutions alternatives ;
• Déterminer l’équilibre économique.
2. Le planning
• Estimer les délais au plutôt, au plus tard par tâches et étapes ;

• Déterminer les interfaces avec les interventions extérieures ;
• Déterminer les points fixes obligés ;
• Lever les incompatibilités ;
• Mettre en place le suivi et le tableau de bord.
3. L’organisation du projet
• Découper le projet et les structures ;

• Définir le circuit d’information ;
• Formaliser les responsabilités et l’autorité de chaque secteur ;
• Etablir les contrats ;
• Coordonner.
En outre, le chef du projet doit ainsi :
• Diriger l’équipe comme un chef d’orchestre,

• Aider au tissage de liens interpersonnels dans les équipes afin de faciliter un esprit de corps,
subdiviser les responsabilités.
- 31 -
Remarque : L’entretien, la réunion sont vitaux dans un projet informatique.
CONSEILS :
• Définir l’objectif de l’entretien ou d’une réunion ;

• Définir l’ordre du jour ;
• Préparer la réunion (présence, réservation de salle, etc. ;
• Débuter autant que possible à l’heure ;
• Désigner un secrétaire de séance ;
• Présenter si nécessaire les participants ;
• Rappeler l’ordre du jour ;
• Valider le compte rendu ;
• Conduire les entretiens ;
• Bien marquer les décisions intermédiaires ;
• Faire la synthèse ;
• Prévoir la date et le lieu de la prochaine réunion.
Des décisions sont demandées régulièrement auprès des responsables de la maîtrise

d’œuvre et de la maîtrise d’ouvrage (délais courts) etc.
IV.7. CONTRACTUALISATION DES RELATIONS
IV.7.1. CAHIER DES CHARGES
Définition : Un cahier des charges permet de synthétiser et fixer par écrit l’objet d’une prestation
que celle-ci soit réalisée en interne ou sous-traitée :
• Il définit les besoins ;
• Il est un outil de dialogue entre la maîtrise d’ouvrage, les informaticiens, les services juridiques,
les soumissionnaires.
Remarque : Si le cahier de charge est destiné à une consultation externe, il comprend les
informations ci-après :
• La présentation générale du projet et sa place dans le cadre de l’entreprise,

• Les objectifs généraux,
• Le type de prestation ;
• Description du cadre organisationnel, mission de l’organisme, organigramme précisant la
mission de chaque cellule.
• Les spécifications techniques du résultat attendu,
• La décomposition en lots et sous-lots,
• Possibilités du contractant à la sous-traitance,
• Le contexte technique,
• Les clauses d’assurance qualité (PAQL) et les conditions des recettes,
• Le cadre de réponse des offres sur le plan technique et commerciale,
• Les critères de sélections des candidats.
Ces éléments sont explicités au niveau des contrats ou marchés dont un projet
peut–être joint au dossier de consultation.
- 32 -
CANEVA :
A) Introduction :
• Contexte : Décrire brièvement l'environnement dans lequel s'inscrit le projet

(stratégie, enjeux, domaine, etc.)
• Historique : Il est possible de donner un bref historique du contexte dans lequel s'inscrit le
projet si cela est pertinent. Gardez à l'esprit que ceci n'est qu'un exemple de cahier de
charge. Vous ne devez pas tout appliquer à la lettre.
B) Description de la demande
• Les objectifs : Définir les résultats que le projet doit atteindre.

• Méthode : Un énoncé d'objectif doit comporter un verbe d'action à l'infinitif et un objet.
• Produit du projet : Proposer une description générale de ce produit.
• Les fonctions du produit : Lister et justifier les principales fonctionnalités du produit.
• Critères d'acceptabilité et de réception : Formuler des indicateurs précis qui
permettent de mesurer si les objectifs de
performance du produit sont atteints.
Exemple : Le produit doit répondre à la norme XX0.
C) Contraintes
• Contraintes de coûts : Spécifier le budget alloué au projet.

• Contrainte de délais : Spécifier la date de livraison du produit et les éventuelles échéances
intermédiaires.
• Autres contraintes : Spécifier les éventuelles autres contraintes à prendre en compte dans
le cadre du projet (normes techniques, clauses juridiques, etc.)
D) Déroulement du projet
• Planification : Représenter l'articulation des grandes phases du projet et des principaux

jalons.
• Ressources : Lister les ressources humaines et matérielles que le client peut mettre à la
disposition du prestataire.
E) Authentification : Date et signature du chef de projet et du maître d'ouvrage.
F) Annexes : Lister et joindre au cahier des charges les éventuels documents que le client peut
mettre à disposition
IV.7.2. CONTRATS
Remarque : Les rapports entre la maîtrise d’ouvrage et la maîtrise d’œuvre (interne ou externe)
doivent être par écrit (les objectifs, le contexte technique et organisationnel, les
modalités de suivi, recette, règlements des prestations).
Un contrat doit comporter :
• Le rappel du cahier des charges

• Les modalités de recette et de réfaction
• La période de garantie et de maintenance
- 33 -
• Les finalités
• La planification
• Les conditions de prix et formules de révision, de paiement
• Les conditions de propriété.
ESTIMATION DE LA CHARGE
Remarque : Les estimations de réalisation d’un projet informatique partent sur deux
éléments :
• Le charge : C’est-à-dire le nombre d’homme mais nécessaire pour réaliser le projet.

• Le délai : C’est-à-dire la durée de réalisation
Remarque 2 : Différentes techniques et période sont utilisées
A. LE MODELE COCOMO DE BOEHM
B. BOEHM a établi à partir de 63 projets réels un modèle de base COCOMO

(« CONSTRUCTIVE, COST MODEL »). L’estimation de base est du type H.M = 2,4(KISL) 1,05
Avec H.M = charge en homme.mois

KISL = Nombre d’instruction source livrées x 1.000
T. DEV = 2,5(H.M) 0,38 avec T. DEV = Durée du projet.
Remarques :
• Le KSL est toute instruction source hors commentaire.

• La distribution de la charge et du délai est faite selon la taille du projet.
TAILLE CHARGE 2 KISL 8 KISL 32 KISL 128 KISL 512 KISL
ETUDE TECHNIQUE
(Conception générale de 16 %
16 % 16 % 16 % 16 %
taille)
PRODUTION DE LOGICIEL 84 %
84 % 84 % 84 % 84 %
(Codage, test, intégration)
Dont : Pour intégration de tests 22 %

16 % 19 % 29 % 31 %
TAILLE
DELAI
Etude Technique
19 % 19 % 19 % 19 % 28 %
Production du logiciel
81 % 81 % 81 % 81 % 72 %
(dont pour intégration 2 test)
18 % 22 % 16 % 30 % 32 %
Remarque : Vu la stabilité de charge et délais, en pratique, on utilise les formules

ci-après :
CHARGE = 2,02(KISL) 1,05
)0,38
DELAI = 2,02(CHARGE
- 34 -
Exemple : Pour un projet de taille moyenne (32 .000 instructions). On a les valeurs
suivantes :
• CHARGE = (2,02 x 32)1,05 = 76,62 MOIS – HOMME

• DELAI = 2,02 x (76,6)0,38 = 10,5 MOIS dont une charge de 20 mois et un délai de 2,7 $ mois
pour l’intégration et tests
NOTA : La productivité de la partie production de logiciel est de 420 instructions par homme et
par mois et le nombre de personne est de 9 personnes.
En dehors de ces formules, BOEHM a redéfini son modèle en trois modes de
développements.
1. Pour les petits projets (taille < 50 KISL), c’est le mode Organique.
CHARGE = 2,02(KISL)1,05 Projets petits et moyens

DELAI = 2,02(CHARGE)0,38
2. Pour les projets intermédiaires (taille < 300 KISL) où le personnel a une expérience et des
connaissances variées :
C’est le mode SEMI DETACHE ou MEDIAN (la charge de l’étude technique 17% contre 85% pour
la production de logiciel.
CHARGE = 2,5(KISL) Gros projets

3. Pour les projets à contraintes sévère (matériels et logiciels imbriqués) avec des interfaces
complexe : c’est le mode IMBRIQUE
CHARGE = 2,95(KISL)1,20 Projet en informatique

Télécommunication
LES COEFFICIENTS MULTIPLICATEURS
BOEHM a introduit dans son modèle les multiplicateurs (15 au total) et s’appliquent
sur la charge calculée dans le modèle de base ou le modèle intermédiaire. Ces coefficients
multiplicateurs concernent le produit, l’ordinateur, le personnel et le projet. Ces coefficients sont
classés dans une échelle allant « TRES BAS à EXTREMEMENT ELEVE ».
Exemple : - Moyenne coefficient = 1

- Fiabilité basse coefficient = 0 ,88
- Fiabilité élevée coefficient = 1,55
Les différents coefficients sont résumés dans le tableau ci-après :
FACTEUR MULTIPLICATEUR BAS MOYEN ELEVE

- Fiabilité requise 0,88 1 1,15
- Taille des bases de données 0,95 1 1,06
PRODUIT
- Complexité du produit 0,85 1 1,15
- 35 -
- Contrainte de temps d’exécution - 1 1,11

- Contrainte de taille mémoire - 1 1 ,06
ORDINATEUR - Instabilité du logiciel de base 0,87 1 1,15
- Délai de restitution des travaux 0,87 1 1,07
- Qualification de l’analyste 1,09 1 0,86
- Expérience du domaine 1,13 1 0,91
- Qualification du programmeur 1,17 1 0,86
PERSONNEL - Familiarité avec logiciel 1,10 1 0,90
- Expérience du langage 1,07 1 0,95
- Utilisation de méthodes Modernes de 1,10 1 0,91
programmation
- Utilisation d’outils d’aide à la 1,10 1 0,91
PROJETS programmation
Contraintes délais 1,08 1 1,04
Exemple : Soit le projet ci-dessus de 32 000 instructions réalisées en mode organique, on peut
imaginer les caractéristiques suivantes :
MULTIPLICATION CARACTERISTIQUE COEFFICIENT

1. Fiabilité Elevée 1,1
2. Taille de la Base de données Elevée 1,08
3. Complexité du produit Faible 0,85
4. Contrainte temps d’exécution Elevée 1,11
5. Contrainte faille mémoire Moyenne 1
6. Instabilité du logiciel de base Moyenne 1
7. Délai de restitution des travaux Moyen 1
8. Qualification de l’analyste Moyenne 1
9. Expérience domaine Elevée 0,91
10. Qualification du programmeur Moyenne 1
11. Familiarité avec le logiciel de base Elevée 0,9
12. Expérience du langage Elevée 0,9
13. Utilisation de méthode moderne de programmation Elevée 0,91
14. Utilisation d’outils Elevée 0,91
15. Contraintes de délai Moyen 1
• La charge est aussi réduite à 54,6 mois hommes

• Le délai à 7,7 mois
• La productivité passant à 586 instructions par hommes et par mois.
B. LE MODELE DIEBOLD
Il couvre l’étude technique et la production du logiciel.
CHARGE = I0 X A X B X C
Avec I0 = Nombre de millions d’instruction
• A = Complexité
• B = Savoir faire
• C = Connaissance dans le type de PGM
Remarque : EN retenant que la partie production de logiciel on a pour A le
- 36 -
tableau suivant :
COMPLEXITE PHASE SIMPLE MOYEN DIFFICILE
1. Production logiciel (dont intégration 2

10,5 (4) 15,5 (8) 29 (17)
tests
L’unité retenue est le nombre de jours/homme pour 1.000 lignes de COBOL.

B. Le savoir - faire : intervient de façon suivante :
Programmeur Très bon 0,65

Bon 0,80
Moyen 1,00
Faible 1,35
Débutant 2,00
C. Connaissance dans le type du Programme
• Premier PGM 2,00

• Second PGM 1,40
• Plusieurs expériences 1,00
Exemple : voir exemple ci – dessus :
L’estimation de charge sera :
CHARGE = 32 X 15,5 x 0,8 x 1 = 396,8 Jours/Hommes
Pour une complexité moyenne, on aura : 19,84 mois/homme.
CHARGE = 32 x 29 x 0,8 x 1 = 742,4 jours/homme
Pour une complexité difficile = 37,12 mois/homme
C. LES EVALUATIONS PAR JUGEMENTS D’EXPERT
Dans cette technique, on s’appuie sur les estimations faites par des experts soit
individuellement, soit par groupe en utilisant la méthode DELPHI ou chaque expert fait une
estimation individuelle puis ou fait la moyenne du groupe et ou ensuite chaque expert corrige son
estimation.
D. LES EVALUATIONS PAR ANALOGIE
On s’appuie sur des résultats obtenus avec des projets similaires et on met en
évidence les écarts.
REPARTITION DELA CHARGE DURANT LES PHASES DE PRODUCTION DE LOGICIEL
En pratique au lieu d4utiliser la formule nombre de personnes = EFFORT / DELAI on

s’appuie sur la courbe de RAYLEIGH qui donne une bonne approximation de la distribution du
travail.
- 37 -
L’équation correspondante s’écrit : NP(T) = H.M x T X e – T2/2TD2

T . De
• Avec : NP(T) : Nombre de personnes à l’instant T
• HM : Nombre d’homme / mois total
• TD : Le mois à la taille de l’équipe atteint son maximum
- 38 -
TD = 8
5
3
TD = 15
2
1 TD = 28
6 10 20 30 40 50
Commentaire
• Le nombre de mois homme reste constant et se trouve égal à l’aire sous la courbe.
• La dissymétrie de la courbe est le fait que la taille maximum de l’équipe est atteinte durant
la phase de codage, les phases d’intégration puis de test pouvant s’effectuer avec moins
de personnes.
QUALIFICATION DES PERSONNES DE L’EQUIPE
Remarque : L’organisation des équipes pour la phase de production de logiciel est en général très
différente de celle utilisée par les étapes précédentes (Etude détaillée, EP, ET Technique).
Souvent, on envisage les types d’organisation ci-après :
• L’organisation industrielle
• L’organisation type chef programmeur.
CHEF DE PROJET
DOCUMENTALISTE BIBLIOTHECAIRE
RESPONSABLE DES TESTS RESPONSABLE DE

PRODUCTION
ANALYSTES ANALYSTES
PROGRAMMEURS PROGRAMMEURS
NB : Organisation industrielle
- 39 -
3.3. SUIVI DU PROJET
Remarque : Le chef du projet est le principal concerné par le suivi et le contexte d’avancement
du projet.
Pour cela, les documents suivants sont indispensables :
1. LIVRE DE BORD : Noter jour pour jour les différents événements internes et externes survenus
dans le projet.
2. LES RAPPORTS D’ACTIVITES : Voir modèle diagramme de GANTT, Rapports souvent
hebdomadaires.
3. LES ETATS DE COMPTABILITE ANALYTIQUE : (Connaissance de la situation comptable du
projet)
4. LES FICHES D’ALERTES : La fiche d’alerte est ouverte. Toutes les fiches qu’une tâche devient
critique.
5. REUNIONS D’AVANCEMENT : De contrôle qualité, inspections techniques
6. ACTIONS CORRECTIVES : Dans le cas des écarts en réunion d’avancement que les alertes
ont été analysées et que des mesures ont été prises, le chef du projet peut prendre des
actions correctives.
• Allocation des ressources supplémentaires.
• Remise en course de la planification
Remarque : Le temps minimum
Exemple :
1. Charge = 32 x 15,5 x 0,8 x 1 = 396,8 jours/hommes

• Pour une complexité moyenne = 19,84 /mois/hommes
2. Charge = 32 x 29 x 0,8 x 1 = 742,4 jours/homme
• Pour une complexité difficile = 37,12 mois/hommes
III. EVALUATION PAR JUGEMENT D’EXPERT
On s’appuie sur des estimations faites par des experts, soit en groupe soit
individuellement en utilisant la méthode DELPHI. Où chaque expert fait une estimation ou
individuelle puis on fait la moyenne du groupe. Et on demande ensuite à chaque expert de
corriger son estimation.
Remarque : On utilise aussi la technique d’évaluation par ANALOGIQUE, en s’appuyant sur des
résultats obtenus avec des projets similaires et on met en évidence les écarts.
IV. REPARTITION DE LA CHARGE DURANT LES PHASES DE PRODUCTION DE LOGICIEL : COURBE DE

RAYLEIGH
Remarque : Pour la répartition de charge pendant les phases de la production du logiciel, on

utilise la courbe de RAYLEIGH.
Cette courbe donne une approximation de la distribution du travail par la phase de
développement du logiciel.
L’équation de correspondance est :
(T2)
2TD2
NP (T) = H.M x Tx l
T . D2
- 40 -
• Avec : NP = Nombre de personnes à l’instant T

• HM = Nombre d’hommes/mois total
• TD = Le mois ou la taille de l’équipe atteint son maximum.
La courbe se présente comme suit :
4 TD = 15
2 TD = 15
1
TD = 28
6 10 20 30 40 50
Remarques
• Le nombre de mois/homme total reste constant et se trouve égal à l’aire sons + la courbe.
• La taille maximum de l’équipe est atteinte durant la phase de codage, les phases
d’intégration puis de test pouvant s’effectuer avec moins de personnes estimées pour le
développement d’un projet est de :
3
TD = 2,15 MH
V.1. DEMARCHE DE PLANIFICATION ET D’ORGANISATION DU CONTROLE DE

L’AVANCEMENT
Le point de départ est :
1. L’étude détaillée qui permet de fournir les estimations de charge pour la phase de codage
d’intégration et de test ainsi que les délais de réalisations par application.
2. L’étude technique qui définit l’architecture des modules temps réels et temps différé et
donc une estimation du nombre de lignes de code à écrire.
3. L’étude technique qui définit les moyens de développement de l’équilibre et les plans de
test et de réception.
RESULTATS ATTENDUS
• Un planning détaillé des tâches à réaliser (date de fin de la qualification interne)

• Une définition de la structure et de la taille de l’équipe nécessaire pour la production du
logiciel
• Une description de l’organisation et des documents à utiliser dans l’étape de production du
logiciel.
- 41 -
La démarche peut être synthétisée comme suite :
Estimation de la charge et durée du développement en fonction de

la taille du code et des facteurs de développement
ECART (ESTIME. D, ESTIME. T) > 10 %
Compte-rendu comité Directeur
Etablissement d’un planning global s’appuyant

sur un graphe de séquence
Application des personnels aux tâches. Définition

de la structure et de la taille de l’équipe
Etablissement d’un planning détaillé s’appuyant sur un

diagramme de GANTT
Mise en place des documents de suivi et de

l’organisation des réunions
Remarque : En pratique les outils de suivi sont les graphiques permettant de mieux visualiser
l’ensemble des tâches et les ressources des projets.
(PERT, MPM, GANTT.)
V.2. SUIVI DU BUDGET
Un audit informatique lucide fonctionnement de la plupart d’entreprises congolaise

relèvent que ces dernières ont fonctionnée sans plan. Su quelques grandes entreprises étatiques
telles que ONATRA, LAC, OFIDA, etc. … sont dotés d’un PDI, il s’avère que ce document est
inexistant dans la plupart PME, PMI congolaise. Or, l’inexistence d’un tel document diminue ces
entreprises d’information fiable susceptible de fournir une base aux décisions rationnelles.
Le manque d’un PDI constitue un obstacle sérieux pour la gestion d’une entreprise.
Bref, diriger une entreprise sans PDI, c’est comme piloter un avion à vue. Les causes de l’absence
du PDI sont multiples. Les plus importantes sont :
1. Manque de volonté politique dans le chef de décideurs ;

2. Altitude indifférente caractérisée par un manque d’intérêt à l’égard du phénomène
informatique dans l’entreprise ;
3. Le manque de sensibilité ou d’informations sur l’incidence du PDI dans la politique informatique
de l’entreprise ;
4. Le manque d’expert dans le domaine.
CONCLUSION postulat fondamental : toute entreprise désireuse de développer les

applications informatiques doit préalablement se doter d’un SDI ou d’un PDI, d’une commission
de l’information qui sera chargée d’adapter le SDI et PDI. Il arrêtera les devoirs concernant le
déroulement du projet. C’est lui qui va lancer des études d’opportunités le cas échéants.
- 42 -
V.3. DEMARCHE D’ELABORATION D’UN PDI OU D’UN SDI
Nous posons un :
Les points clés de la planification
On distingue 2 catégories du plan :
Les plans nationaux (PIN) => on peut avoir aussi les plans multinationaux.
V.4. EVALUATION DES CHARGES
Estimation de réalisation projet. Ici on tient compte de deux types aspects :
1. Charges / Homme-mois ;
2. Délai de réalisation.
En pratique, il existe différentes méthodes :
BOEM
1. Modèle Algorithmique
DIEBOLD
2. Modèle de Jugement d’experts
En quoi consiste le modèle algorithmique :
Le modèle algorithmique consiste une fonction mathématique exprimant la charge

et le délai de lois en fonction d’élément mesurable.
➢ Monsieur BOEHM a recensé 63 projets informatiques.
Il a estimé la charge, le délai.
1. H.M = 2,4 (KISL) 1,05

Unité de mesure d’une instruction d’un algorithme
2. T. DEV = 2,5(HM) 0,38

• HM – CHARGE – HOMME – MOIS
• KISL – NOMBRE D’INSTRUCTION SOURCE LIVREES X 100
• T.DEV = TOTAL DUREE DU PROJET
• KISL : KILO INSTRUCTION SOURCE LIVRE
Il y a deux :
1. Etude technique ;
2. Etude production logique.
Annexes.
Techniques de planification : GANTT, PERT, ...

La construction du planning passe par la modélisation du réseau de dépendance
entre tâches sous forme graphique. Il s’agit d’une décomposition structurée du travail. Il faut
- 43 -
décomposer le projet en sous-ensembles plus simples (OT ou WBS). Plusieurs représentations

existent, à la base de toute construction de planning :
• La technique GANTT : planning à barres ;
• La technique PERT : méthode des potentielles étapes et planning des tâches ;
• Le réseau des antécédents : méthode des potentielles tâches.
Au programme:
1. Le diagramme de GANTT
Le diagramme de GANTT est la technique et représentation graphique permettant

de renseigner et situer dans le temps les phases, activités, tâches et ressources du projet. En ligne,
on liste les tâches et en colonne les jours, semaines ou mois. Les tâches sont représentées par des
barres dont la longueur est proportionnelle à la durée estimée. Les tâches peuvent se succéder
ou se réaliser en parallèle entièrement ou partiellement. Ce diagramme a été conçu par un
certain Henry L. GANTT (en 1917) et est encore aujourd'hui la représentation la plus utilisée.
Exemple d’un diagramme de GANTT :
1.2 La technique PERT
La technique PERT est une technique américaine de modélisation de projet qui vient
de l’américain Program Evaluation and Review Technique, ou technique d’évaluation et de
révision de Programme. Elle consiste à mettre en ordre sous forme de réseau plusieurs tâches qui
grâce à leurs dépendances et à leur chronologie permettent d’avoir un produit fini. Les
Caractéristiques de PERT sont les suivantes :
• Les tâches sont représentées par des flèches ;
• Le réseau visualise des dépendances entre tâches ;
• Limites de la technique PERT : pas de représentation de notion de durée et de date.
Exemple de la technique PERT
- 44 -
- 45 -
1.3 Le réseau des antécédents

L’établissement de ce réseau correspond à la méthode des potentiels tâches ou
méthode du Chemin critique ou encore CPM (Critical Path Method). Ce réseau est aussi appelé
PDM (Precedence Diagramming Method). Chaque activité y est représentée par une boîte. Les
activités sont liées entre elles par des liaisons de dépendances représentées par des flèches C’est
une représentation synthétique des relations logiques entre activités, construit de gauche à droite
pour représenter la chronologie d’un projet. L’avantage de ce réseau des antécédents est qu’il
permet une visualisation claire de la logique des dépendances, il donne la possibilité de relations
avec des délais (écart/recouvrement). Cette représentation a été notamment retenue dans les
outils de gestion de projet suivants : PMW (Project Management Workbench) et Microsoft Project.
Exemple de réseau des antécédents
Légende:
• DTO : début au plus tôt
• FTO : Fin au plus tôt
• DTA : début au plus tard
• FTA : Fin au plus tard
• ML : Marge Libre
• MT : Marge Totale
1.7 Logiciels de gestion de projet

De nombreux logiciels de gestion de projet existent sur le marché, permettant de
planifier et d’optimiser la gestion d’un projet :
PMW (Project Management Workbench), GPM (Galaxys Project Management), MSP (Microsoft
Project) ou son alternative Open Source Open Workbench et bien d'autres...
- 46 -
Les fonctionnalités attendues d’un outil de gestion de projet sont les suivantes :
• Groupware : possibilité d’indexer des comptes-rendus de réunion et de comités
de pilotage, tous les livrables d’un projet (étude préalable fonctionnelle, étude
technique, guide d’utilisation ...), de planifier les réunions
• Intervenants (affectation des ressources) : un espace pour consulter la liste des
intervenants, leurs coordonnées professionnelles, leur rôle dans le cadre du projet et
le ou les projets auxquels ils sont affectés.
• Livrables : un espace où l’on peut indexer et consulter des livrables ainsi que leur
statut (non entamé, en cours, finalisé, validé) et la date liée à ce statut.
• Risques : Une matrice des risques peut être remise à jour automatiquement à partir
de la saisie manuelle de chaque facteur de risque avec le de gré de
• Probabilité et de gravités associées. Des graphiques associés à ces risques (degré
de gravité en abscisse, degré de probabilité en ordonnée) sont générés
automatiquement.
• Planification du projet : possibilité de gérer la planification du projet avec les
chevauchements des sous-projets
• Reports : pouvoir éditer facilement des diagrammes de GANTT
• Gestion des phases de test : permettre d’indexer l’ensemble des cas de tests servant
à tester des applications informatiques et d’assurer leur suivi précisément grâce à un
système de gestion des incidents (en cas d’échec d’un cas de test).
Cette dernière fonctionnalité est souvent présente dans des logiciels spécifiques à la
gestion des tests informatiques. La tendance des outils de gestion de projet est l’apparition de
fonctionnalités administratives en sus des traditionnelles fonctionnalités de planification. Les outils
permettent souvent de gérer la facturation du projet par exemple.
2.2 Indicateurs de pilotage

2.2.1 La notion d’indicateur
Tout projet implique la détermination d’indicateurs de pilotage du projet qui sont
des outils de navigation et de décision. Ils permettent de mesurer une situation ou un risque, de
donner une alerte ou au contraire de signifier l'avancement correct du projet. Le choix des
indicateurs dépend des objectifs du projet. Les indicateurs de pilotage peuvent être regroupés
sous la forme d'un tableau de bord, véritable outil de gestion des responsables du projet. Les
tableaux de bord sont aussi souvent nommés "scoreboards".
2.2.2 Exemples d’indicateurs
Voici quelques indicateurs que l'on peut trouver sur un tableau de bord:
• Utilisation des ressources (en %) ;
• Tâches réalisées/tâches planifiées
• Jalons
• Date de fin initiale
• Date de fin finale
• Avancement en délai (%)
• Nombre de tâches terminées par rapport au nombre de tâches prévues
• Nombre de changements
• Nombre de risques réalisés
Des indicateurs spécifiques au projet doivent être établis.
2.3 La démarche qualité

Les projets liés à l’évolution ou à l’implémentation d’un SI sont souvent sujets à des
dérives en termes de coûts et de durée, et recouvrent rarement le périmètre initialement défini.
La démarche Qualité est nécessaire pour fiabiliser la gestion de projet, au moyen de différents
outils de normalisation des méthodes de travail et de vérification/validation. L’adoption de cette
démarche doit amener à une meilleure maîtrise des coûts et de la durée du projet.
- 47 -
Au programme:
2.3.1 Définition de la démarche qualité

La démarche Qualité consiste à trouver l’adéquation entre la réponse aux besoins
du projet, l’expression correcte de ces besoins par des spécifications adéquates qui passent par
une écoute attentive du client, et une réalisation répondant à l’expression des besoins. Si les
spécifications sont conformes aux besoins mais que la réalisation ne répond pas aux
spécifications et donc aux besoins, on parle de défauts dans la réalisation. C’est de la non-
qualité. Si la réalisation est conforme aux besoins alors que les spécifications n’étaient pas bonnes,
on a eu de la chance, on parle de qualité aléatoire. Enfin, si la réalisation est conforme aux
spécifications mais que ces dernières ont surévalué les besoins, on parle de sur-qualité.
2.3.2 La démarche qualité au cours du projet

La démarche qualité doit s’intégrer à toutes les phases du projet. Phases d’études
préalables et de définition fonctionnelle du besoin. Lors des phases d’étude préalable et de
définition fonctionnelle des besoins, la qualité se caractérise par la capacité des études produites
à adresser les véritables objectifs du projet et de complètement satisfaire les attentes associées.
Lors de ces phases, les contrôles qualité reposent d’une part, sur la vérification du respect des
principes de la méthodologie mise en œuvre et d’autre part, sur des revues visant à garantir
l’adéquation et la cohérence des solutions proposées avec les attentes entre les différentes
phases (schéma directeur, puis analyse préalable puis définition fonctionnelle du besoin). Le
processus qualité s’attachera également à s’assurer du bon fonctionnement du cycle de
validation pour vérifier que tous les principes et solutions proposées ont fait l’objet d’une
validation ad hoc.
Phases de réalisation
Le contrôle de la qualité porte d’une part, sur la vérification de la méthodologie
mise en œuvre et d’autre part, sur des revues de code permettant de garantir les performances
et la maintenabilité des applications développées.
Phases de test
Les phases de test permettent de vérifier d’une part, le bon fonctionnement

intrinsèque des applications livrées et d’autre part, l’adéquation entre les fonctions réalisées par
ces applicatifs et les fonctions spécifiées dans les dossiers de définition du besoin. En
conséquence, lors de ces phases, le contrôle de qualité va consister à vérifier le bon
fonctionnement de ce processus.
Contrôle
Contrôle de l’élaboration des fiches de tests (cycle de test, cas de test, description
des jeux de test, description des résultats attendus),
Reproduction de test par sondage

Lors des phases de test, il est important de refaire quelques tests aléatoirement par
une autre personne pour limiter les risques d'erreur.
Cas d'entreprise :
Lors de la recette d'un module comptable, un consultant qui a passé les écritures
comptables de test dans le système comptable selon les cas de tests prévus les a passé sans les
valider mais les a sauvegardés. Un autre consultant a contrôlé toutes les écritures passées avant
de les valider. Dans cet exemple, la démarche d'intervention de deux consultants différents
s'inscrit dans une démarche qualité.
- 48 -
Contrôle du cycle de traitement des anomalies

Les anomalies détectées lors des phases de test doivent donner lieu à une
correction en termes de paramétrage/développement. De nouveaux tests doivent alors avoir lieu
dans le cadre de la démarche qualité, afin de s'assurer que les corrections apportées
fonctionnent.
2.3.3 Présentation du cycle de Shewart-Deming

Le célèbre cycle de Shewart-Deming est encore appelé le cycle Deming ou le
cycle PDCA (Plan, Do, Check and Act). Au départ, dans les années 1920, le statisticien Shewart
est à l'origine d'une première version du cycle : planifier, agir et voir le résultat. Ce cycle a été
revu et amélioré par Edward Deming selon les modalités que nous allons voir. Le cycle Deming
montre comment appliquer les principes de la Démarche Qualité au processus projet, mais aussi
à ses tâches élémentaires.
Il se compose de quatre phases:
• La planification ("Plan"): Phase au cours de laquelle sont formalisés les attentes, les moyens
et les objectifs ;
• La réalisation ("Do"): Elle s'appuie sur les modes opératoires préalablement définis ;
• La vérification ("Check"): Elle doit, elle aussi, se conformer aux processus définis en amont
avec un souci d'exhaustivité ;
• L'action correctrice ("Act"): correction des erreurs constatées et mise en place de mesures
pour éviter qu'elles ne se reproduisent.
Résultat : la réussite de cette démarche dépendra de la mobilisation de chacun
pour une recherche permanente d'amélioration et des moyens mis en œuvre par les instances de
décision pour l'application de la démarche.
ANNEXES :
Nous apprendrons les méthodes pratiques pour être en mesure de participer à un

projet d'amélioration sur le terrain :
• Calcul du T.R.G. (Taux de Rendement Global).

• Calcul du M.T.B.F. (Mean Time Between Failure, Moyenne des Temps de Bon
Fonctionnement).
- 49 -
• Calcul du M.T.T.R. (Mean Time to Repair, Moyenne des Temps de Tâches de

Réparation).
• Analyse causale et chiffrage des aléas.
• Recherche de solutions.
- 50 -
Exemple :
Availability par
Town Site PC End time Down time
Start time Direction*
D. FIN TRESORERIE 2 8:02 8:04 0:02
CAISSE 2 8:02 8:04 0:02
BANQUE 2 8:02 8:04 0:02
6 99.86%
D. INFORM RX 1 0:00 16:11 16:11 32.57%
DRH PAIE 3 0:00 16:11 16:11 32.57%
DT CHAR 1 0:00 0:00 0:00 100.00%
DLOGIST APPRO 2 0:00 0:00 0:00
DEPOT 2 0:00 0:00 0:00
4 100.00%
D. MEDICAL LABO 2 0:00 0:00 0:00 100.00%
Total PC 17
RAISSA SHOPPING* 84.08%

Commentaire
H5====> *=1-((G2*C2+G3*C3+G4*C4)/C5/1440)
H6====> *=1-G6/1440
H15===> *=1/C13*(H5*C5+H6*C6+H7*C7+H8*C8+H11*C11+H12*C12)
- 51 -
Sûreté des fonctionnements et cryptographie appliquée aux échanges
Exercice : MTTR/MTBF
Soient deux systèmes informatiques identiques interconnectés via les services d'un
opérateur et une liaison téléphonique de secours. Quel est, pour l'ensemble du système, la
disponibilité, l'indisponibilité et la MTBF du système, compte tenu des éléments du tableau ci-
dessous ? Par hypothèse, on admettra que la MTBF de l'opérateur inclut la liaison d'abonné et les
modems d'extrémité.
MTBF MTTR
Système 1 4 mois 8 heures
Modem 2 ans 5 heures
RTC 2 ans 24 heures
Telcos 2 ans 2 heures
On considérera qu'un mois représente 200 heures et une année 2400 heures.
Exercice : Chiffrement symétrique et asymétrique
Un groupe de n personnes souhaite utiliser un système cryptographique pour
s'échanger deux à deux des informations confidentielles. Les informations échangées entre deux
membres du groupe ne devront pas pouvoir être lues par un autre membre. Le groupe décide
d'utiliser un système symétrique de chiffrement.
1. Quel est le nombre minimal de clefs symétriques nécessaires ?
2. Donner le nom d'un algorithme de chiffrement symétrique reconnu.
Le groupe décide ensuite de remplacer ce système par un système asymétrique.
1. Quel est le nombre minimal de couples de clés asymétriques nécessaires pour
que chaque membre puisse envoyer et recevoir des informations chiffrées et/ou signées ?
2. Alice souhaite envoyer des informations chiffrées et signées à Bob (Alice et Bob
appartiennent tous les deux au groupe). Quelle(s) clef(s) Bob doitil utiliser ?
3. Donner le nom d'un algorithme de chiffrement asymétrique reconnu.
Le groupe décide finalement d'utiliser un système hybride pour le chiffrement (i.e.
qui utilise à la fois la cryptographie symétrique et asymétrique)
1. Donner les raisons qui ont poussées le groupe à utiliser un tel système.
Pour définir une politique de maintenance, prioriser les interventions ou établir le budget, le
responsable maintenance doit pouvoir choisir les moyens et modes d'intervention les plus adaptés
à son parc machines. De même, un groupe de travail visant à fiabiliser des machines, une ligne,
une cellule ou un atelier nécessite une méthode structurée pour attaquer son chantier. Voici
quelques indicateurs simples permettant d'aider à la décision.
• Indice de fiabilité : MTBF ;

• MTBF désigne le temps moyen entre défaillances consécutives ;
• MTBF = Somme des Temps de Bon Fonctionnement / nombre de défaillances ;
La Somme des Temps de Bon Fonctionnement inclut les temps d'arrêt hors
défaillance et les temps de micro arrêts. La MTBF peut s'exprimer en unités plus parlantes pour les
opérationnels, par exemple : nombre de pannes pour 100 heures de production.
Indice de maintenabilité : MTTR

La maintenabilité s'entend, pour une entité utilisée dans des conditions données,
comme la probabilité pour qu'une opération donnée de maintenance puisse être effectuée sur
un intervalle de temps donné, lorsque la maintenance est assurée dans des conditions données
et avec l'utilisation de procédures et moyens prescrits. L'indicateur MTTR (Mean Time To Repair)
littéralement : temps moyen pour réparer, exprime la moyenne des temps de tâches de
- 52 -
réparation. Il est calculé en additionnant les temps actifs de maintenance ainsi que les temps
annexes de maintenance, le tout divisé par le nombre d'interventions.
MTTR = Temps d'arrêt Total / nombre d'arrêts
Par Temps actifs on entend l'ensemble des temps : Les temps annexes comprennent les temps :
Sûreté des fonctionnements et cryptographie appliquée aux échanges
Exercice : MTTR/MTBF
Soient deux systèmes informatiques identiques interconnectés via les services d'un
opérateur et une liaison téléphonique de secours. Quel est, pour l'ensemble du système, la
disponibilité, l'indisponibilité et la MTBF du système, compte tenu des éléments du tableau ci-
dessous ? Par hypothèse, on admettra que la MTBF de l'opérateur inclut la liaison d'abonné et les
modems d'extrémité.
MTBF MTTR
Modem 2 ans 5 heures
RTC 2 ans 24 heures
Telcos 2 ans 2 heures
On considérera qu'un mois représente 200 heures et une année 2400 heures.
Exercice : Chiffrement symétrique et asymétrique
Un groupe de n personnes souhaite utiliser un système cryptographique pour
s'échanger deux à deux des informations confidentielles. Les informations échangées entre deux
membres du groupe ne devront pas pouvoir être lues par un autre membre. Le groupe décide
d'utiliser un système symétrique de chiffrement.
1. Quel est le nombre minimal de clefs symétriques nécessaires ?
2. Donner le nom d'un algorithme de chiffrement symétrique reconnu.
Le groupe décide ensuite de remplacer ce système par un système asymétrique.
1. Quel est le nombre minimal de couples de clés asymétriques nécessaires pour
que chaque membre puisse envoyer et recevoir des informations chiffrées et/ou signées ?
2. Alice souhaite envoyer des informations chiffrées et signées à Bob (Alice et Bob
appartiennent tous les deux au groupe). Quelle(s) clef(s) Bob doitil utiliser ?
3. Donner le nom d'un algorithme de chiffrement asymétrique reconnu.
Le groupe décide finalement d'utiliser un système hybride pour le chiffrement (i.e.
qui utilise à la fois la cryptographie symétrique et asymétrique)
1. Donner les raisons qui ont poussées le groupe à utiliser un tel système.
Pour définir une politique de maintenance, prioriser les interventions ou établir le budget, le
responsable maintenance doit pouvoir choisir les moyens et modes d'intervention les plus adaptés
à son parc machines. De même, un groupe de travail visant à fiabiliser des machines, une ligne,
une cellule ou un atelier nécessite une méthode structurée pour attaquer son chantier. Voici
quelques indicateurs simples permettant d'aider à la décision.
• Indice de fiabilité : MTBF ;

• MTBF désigne le temps moyen entre défaillances consécutives ;
• MTBF = Somme des Temps de Bon Fonctionnement / nombre de défaillances ;
La Somme des Temps de Bon Fonctionnement inclut les temps d'arrêt hors
défaillance et les temps de micro arrêts. La MTBF peut s'exprimer en unités plus parlantes pour les
opérationnels, par exemple : nombre de pannes pour 100 heures de production
Indice de maintenabilité : MTTR

La maintenabilité s'entend, pour une entité utilisée dans des conditions données,
comme la probabilité pour qu'une opération donnée de maintenance puisse être effectuée sur
- 53 -
un intervalle de temps donné, lorsque la maintenance est assurée dans des conditions données
et avec l'utilisation de procédures et moyens prescrits. L'indicateur MTTR (Mean Time To Repair)
littéralement : temps moyen pour réparer, exprime la moyenne des temps de tâches de
réparation. Il est calculé en additionnant les temps actifs de maintenance ainsi que les temps
annexes de maintenance, le tout divisé par le nombre d'interventions.
MTTR = Temps d'arrêt Total / nombre d'arrêts

Par Temps actifs on entend l'ensemble des temps : Les temps annexes comprennent les temps :
de localisation de la défaillance de détection
de diagnostic d'appels à la maintenance
d'intervention d'arrivée de la maintenance
de contrôles et d'essais propre à la logistique d'intervention
Taux de disponibilité
La notion de disponibilité exprime la probabilité qu'une entité soit en état de
"disponibilité" dans des conditions données à un instant donné en supposant que la fourniture des
moyens extérieurs soit assurée. (NFX 60-010. La disponibilité, ou taux de disponibilité est le rapport
du "Temps effectif de disponibilité" / Temps requis ou encore le rapport du Temps de
fonctionnement / (Temps de fonctionnement + Temps propre d'indisponibilité).La disponibilité
s'exprime en fonction des indicateurs précédents de la manière suivante :
Disponibilité = MTBF / (MTTR + MTBF)
FMD
L'abréviation FMD désigne le tryptique Fiabilité, Maintenabilité, Disponibilité, avec :
• Fiabilité = 1 / MTBF ;
• Maintenabilité = 1 / MTTR ;
• Disponibilité = MTBF / (MTTR + MTBF).
Les indicateurs FMD permettent de classer les machines selon leurs valeurs et de
décider d'une politique ou des priorités d'action circonstanciées.
Fiabilisation
Une machine peu fiable s'arrête souvent. Pour une machine automatique, cela
signifie qu'elle ne peut rester sans supervision. Les pertes dues au manque de fiabilité d'un
équipement sont liées à sa conception (fiabilité intrinsèque) mais aussi aux conditions d'utilisation
et aux travaux entrepris pour améliorer la fiabilité. Ainsi la fiabilisation peut se décliner en actions
propres au service maintenance, en formation pour les utilisateurs et en chantiers thématiques de
fiabilisation associant maintenance et production, plus éventuellement d'autres services (qualité,
achats, approvisionnements.)
Amélioration de la maintenabilité
Un MTTR long dénote la difficulté à réparer et intervenir sur un équipement défaillant.
Les causes peuvent être propres à l'équipement (complexité, accessibilité, manque de pièces
disponibles...) ou liées au manque de connaissances et savoir-faire. On peut améliorer la
maintenabilité par des travaux visant à éliminer ou réduire les causes et par les formations.
- 54 -
Temps moyen entre pannes

Le temps moyen entre pannes, expression souvent désignée par son sigle anglais
MTBF (mean time between failures), est une des valeurs qui indiquent la fiabilité d'un composant
d'un produit ou d'un système. C'est la moyenne arithmétique du temps entre pannes d'un système
réparable. L'expression anglaise mean time between failures est parfois traduite à tort en français
par « moyenne des temps de bon fonctionnement ».
Mais le temps moyen entre deux défaillances intègre dans son calcul les temps de
réparation et de maintenance, alors que la moyenne des temps de bon fonctionnement ne les
intègre pas1, 2,3.
Le MTBF (mean time between failures) est la mesure du taux de défaillances

aléatoires dans un lot de composants, à l'exclusion des pannes systématiques dues par exemple
aux défauts de fabrication (« défauts de jeunesse ») et à l'exclusion de l'usure due à l'usage (wear-
out en anglais). La valeur du MTBF ne peut être définie que dans un usage et un environnement
donnés. Par exemple, une chaussure a un MTBF extrêmement élevé si l'on marche peu, il est très
peu probable qu'elle se déchire spontanément en deux. Mais si l'on marche beaucoup, il ne
faudra que quelques mois pour que la semelle soit complètement usée.
Le MTBF est une notion statistique sur un lot de fabrication identique : dans l'exemple
de la chaussure, si le cuir utilisé a un défaut passé inaperçu, la chaussure ne durera que quelques
jours, mais cela ne change pas la statistique sur une grande quantité.
Calculs de MTBF
Le MTBF d'un composant ou d'un ensemble de composants peut être exprimé en
heures, ou en son inverse, en FIT (failure(s) in time). Le FIT est le taux de défaillances aléatoires,
généralement exprimé en giga-composants-heure. C’est-à-dire FIT = (proportion de composants
en panne) x (durée cumulée de fonctionnement en heures) x 109. Lorsqu'un système est
composé de plusieurs composants, on fait le produit de tous les FIT de chacun des composants
en supposant que la panne d'un seul composant provoque la panne du système. Dans le cas
d'un système redondant, il faut ajuster le calcul en conséquence. Toutefois, le calcul est
relativement complexe car les taux de défaillances ne sont alors plus constants et il faut faire
appel à des calculs de moyennes intégrales. On a alors MTBF = 109 / FIT dans le cas de
composants présentant un taux de défaillance constant (répartition exponentielle).
Définition précise
Pour un système réparable, le MTBF est le temps moyen entre la fin de la réparation
et la panne suivante. Le temps moyen entre la panne et la remise en état de fonctionnement
(dans lequel entrent les temps de diagnostic, d’approvisionnement, de réparation, etc.) est
appelé « temps moyen avant réparation » (en anglais mean time to repair ou MTTR) ou « temps
moyen d’indisponibilité » (en anglais mean downtime ou MDT).
Le MTTF (Mean Time To Failure = temps moyen de fonctionnement avant panne) est
l’inverse du taux de défaillance " ":
- 55 -
Mathématiquement, le MTBF est donc la somme du MTTF et du MTTR4,5.
(Sur une échelle de temps, de l'origine de l'étude à la fin de l'étude, s'il s'est produit n
pannes il y aura n + 1 périodes de bon fonctionnement
On peut « oublier » le « + 1 » si le nombre de défaillances est très important.

Le MTTF est souvent désigné par
Le taux de pannes et le MTTF étant inverses l’un de l’autre, on les utilise
indifféremment. Le MTTF peut être défini en termes de la fonction « densité de pannes » f(t)
avec :
Il se déduit également du taux de réparation. Le MTBF ne donne l’instant moyen où

la probabilité de fonctionnement égale la probabilité de panne, que dans des distributions
statistiques symétriques. En distribution exponentielle, la probabilité qu’un élément soit défaillant
après le MTBF est de 0,63. Les produits commerciaux se définissent en général par leur « durée de
vie » ou leur « temps moyen de fonctionnement » dans un usage normal et un environnement
défini.
Par exemple, les disques durs d'aujourd'hui ont souvent un MTBF supérieur à 100 000
heures, ce qui correspond, pour un serveur tournant en permanence, à plus de onze années de
fonctionnement moyen sans panne. Intel a annoncé en 2008 des disques SSD ayant un MTBF de
1, 2 million d'heures 7.Cette spécification est toujours accompagnée de conditions de milieu
(température, humidité) et d'utilisation selon une norme définie (par exemple la norme MIL-HDBK-
217F).
Méthode COCOMO
"Proposée par B.W. Boehm en 1981 (Construct Cost Model)"
En fonction des hypothèses:
• Il est facile à un informaticien d'estimé le nombre de lignes source.

• La complexité d'écriture d'un programme est la même quelque soit le langage de
programmation. Il propose une méthode basée sur la corrélation entre la taille d'un projet
et sa charge.
Formule:
• Charge = a . (K isl)b
• Délai = c . (Charge)d
• Taille moyenne d'équipe = Charge / Délai
• Avec: K isl nombre de milliers de lignes sources.
Et les paramètres a, b, c et d qui dépendent de la catégorie du projet.

Classification:
- 56 -
• Projet simple: < 50 000 lignes

• Projet moyen: 50 000 ≤ lignes ≤ 300 000
• Projet complexe: > 300 000 lignes
Type de projet Charge en M/h Délai en M

Simple a = 3.2
b = 1.05
c = 2.5
d = 0.38
Moyen a = 3
b = 1.12
c = 2.5
d = 0.35
Complexe a = 2.8
b = 1.2
c = 2.5
d = 0.32
Facteurs: pris en compte pour calculer la "charge nette".

Fiabilité, complexité, taille de la mémoire, temps d'exécution...
Tous ces paramètres dépendent de l'entreprise dans laquelle est développé le
logiciel.
Charge net = Produit (facteurs) x Charge (brute).
- 57 -
EXERCICES.
Exercice 1:
Estimer la taille moyenne de l'équipe qui faudrait prévoir pour développer un logiciel estimé à
environ 40 000 instructions sources. Nous appliquons la méthode COCOMO et nous nous
apercevons que c'est un projet simple. Nous avons donc pour le calcul de la charge et et du
délai, les coefficients suivant:
a = 3.2 et b = 1.05 c = 2.5 et d = 0.38
Donc selon la formule de la charge: charge = 3.2 (40)1.05 ≈ 154 M/h
délai = 2.5 (154)0.38 ≈17 Mois.
Ce qui nous donne: Taille équipe = charge / délai = 154/17 = 9 personnes.
Exercice 2:
Sachant que la phase d'observation représente environ un tiers de la charge de l'étude

préalable, calculer la charge du projet en M/h et sa répartition dans le cycle de développement.
Nous supposons que la charge de la phase d'observation a été estimée à 7,5 J/h.
• Charge étude préalable = 3 x phase observation ≈ 22 J/H
• Charge totale = 10 x charge étude préalable ≈ 22x10 ≈ 220 J/h ; ≈ 11 M/h
2.1) Définitions
• Définition: c'est la quantité de travail qu'une personne peut réaliser.

• Unité: en jour / homme, mois / homme, année / homme.
• Remarques: mois / homme (charge sur un mois): en général 20 jours.
• Taille du projet: la taille du projet se mesure à sa charge.
• Ordre de grandeur: selon les normes ISO:
• Charge < 6 M/h ⇒ très petit projet
• 6 M/h ≤ à charge ≤ à 12 M/h ⇒ petit projet
• 12 M/h ≤ à charge ≤à 30 M/h ⇒ projet moyen
• 30 M/h ≤à charge ≤ à100 M/h ⇒ grand projet
• 100 M/h ≤ à charge ⇒ très grand projet
• Durée: dépend de la charge et du nombre de personnes affectées.
Exemple: 60 M/h peut être 1 personne pendant 5 ans ou10 personnes pendant 6
mois ou 60 personnes pendant 1 mois.
I. TYPES DE MAINTENANCE
1.1) Maintenance perfective (évolutive)
Elle consiste à maintenir les fonctionnalités antérieures tout en ajoutant des nouvelles
fonctionnalités qui modifient profondément l'architecture.
Exemple :
1) changement de OS.
2) changement de SGBD…
1.2) Maintenance adaptative
Ajout de petites fonctionnalités qui ne modifie pas l'architecture.

Exemple :
1) Mise en franc congolais.

2) Passage de données par fichiers…
- 58 -
=SI(MIN(B6:F6)=B6;"MICROCOM";SI(MIN(B6:F6)=C6;"MICROCONCEPT";SI(MIN(B6:F6)=D6;"MISS";SI(MIN(B6:F6)=E6;"DIGITAL";SI(MIN(B6:F6)=F6;"STAN
DARD")))))
MEILLEUR CHOIX
Revisé par le Prof. Dr. Ir. Jeampy MBIKAYI 2015-2016
MICROCONCE
MICROCOM MISS DIGITAL STANDARD BEST PARTNER
PT
0,044 0,142 0,0449 0,039 0,0615 DIGITAL
Angola
0,147 0,323 0,1626 0,1552 MICROCOM
Algerie 0,1655
0,0386 0,173 0,0591 0,039 0,0522 MICROCOM
Argentina
0,17 0,188 0,1118 0,1113 STANDARD
Congo Braza 0,2128
0,1185 0,314 0,1655 0,1478 0,1007 STANDARD
Congo RDC
0,2128 0,314 0,2447 0,2128 0,2044 STANDARD
Armenia
0,213 0,377 0,2 0,2 0,1993 STANDARD
Belgique
0,1265 0,377 0,1714 0,1561 0,1457 MICROCOM
Bolivia
0,2137 0,713 0,3428 0,2835 0,2135 STANDARD
Cambodia
0,2185 1,4 0,3428 0,2835 0,2144 STANDARD
Zambie
0,2451 0,571 0,2719 0,2601 0,2441 STANDARD
Zimbabwe
0,0748 0,182 0,0828 0,0728 0,0905 DIGITAL
France
- 59 -
MEILLEUR CHOIX
Revisé par le Prof. Dr. Ir. Jeampy MBIKAYI 2013-2014
MICROCOM MICROCONCEPT MISS DIGITAL STANDARD
Angola 0,044 0,142 0,0449 0,039 0,0615

Algerie 0,147 0,323 0,1655 0,1626 0,1552
Argentina 0,0386 0,173 0,0591 0,039 0,0522
Congo Braza 0,17 0,188 0,2128 0,1118 0,1113
Congo RDC 0,1185 0,314 0,1655 0,1478 0,1007
Armenia 0,2128 0,314 0,2447 0,2128 0,2044
Belgique 0,213 0,377 0,2 0,2 0,1993
Bolivia 0,1265 0,377 0,1714 0,1561 0,1457
Cambodia 0,2137 0,713 0,3428 0,2835 0,2135
Zambie 0,2185 1,4 0,3428 0,2835 0,2144
Zimbabwe 0,2451 0,571 0,2719 0,2601 0,2441
France 0,0748 0,182 0,0828 0,0728 0,0905
1.3) Maintenance corrective
Critère important de la qualité qui corrige les anomalies ou erreurs mises à jour par le
client et non pas lors des tests de vérification et de validation.
1.4) Distribution de l'effort : 17%,18%,65%.
IV. PILOTAGE DE PROJET
Suivre un projet, c’est un ensemble d’actions à faire :
• Mesurer l’état d’avancement,

• Mesurer ce qui a été consommé,
• Comparer les écarts entre les réalisations et les prévisionnels,
• Expliquer les écarts,
• Proposer les actions correctives.
DE LA NECECITE DE L’AUDIT INFORMATIQUE DANS LES ENTREPRISES CONGOLAISES.
Après avoir passé en revue quelques considérations théoriques sur l’audit

informatique en général, notamment son importance, son objectif, les méthodes de conduite de
cette opération et son champ d’application au sein d’une organisation, on s’appesantit sur les
points faibles qui se dégagent de l’observation de la situation des CTI des entreprises publiques en
RDC. Il s’agit de la vétusté des matériels informatiques, des difficultés de trouver des pièces de
rechange, du manque de recyclage du personnel informaticien, de la maintenance irrégulière
des matériels informatiques, de l’inexistence du PDI, de l’insuffisance des matériels informatiques.
Ce sont là autant d’écueils qui ne peuvent garantir un bon fonctionnement de ces CTI.
Pour créer un environnement informatique favorable au sein des entreprises
publiques congolaises, il est préconisé, dans le cadre d’un audit à réaliser de manière
permanente ou ponctuel, selon les besoins :
• De suivre particulièrement les performances des matériels, des logiciels et du personnel

informatiques en place ;
- 60 -
• De veiller également à la sécurité des matériels, des logiciels et des données.
CALCUL DE LA PUISSANCE.
• POWER 0
• 48,10198415 3,2 154
• 6,780439948 2,5 17 9,080611315
Nous avons donc pour le calcul de la charge et et du délai, les coefficients

suivant:
• a = 3.2 et b = 1.05 c = 2.5 et d = 0.38
Donc selon la formule de la charge: charge = 3.2 (40)1.05 ≈ 154 M/h
• Délai = 2.5 (154)0.38 ≈17 Mois
• Charge = a . (K isl)b
• Délai = c . (Charge)d
POWER 0
48,10198 3,2 154
6,78044 2,5 17 9,080611
Nous avons donc pour le calcul de la charge et et du délai, les coefficients suivant:
a = 3.2 et b = 1.05 c = 2.5 et d = 0.38
Donc selon la formule de la charge: charge = 3.2 (40)1.05  154 M/h
délai = 2.5 (154)0.38 17 Mois
Charge = a . (K isl)b
Délai = c . (Charge)d
- 61 -
TABLE DES MATIERES
PLAN DU COURS ___________________________________________________________________ - 1 -
BIBLIOGRAPHIE ____________________________________________________________________ - 2 -
CHAPITRE PREMIER: INTRODUCTION _________________________________________________ - 3 -
BUT DU COURS ____________________________________________________________________ - 4 -
I.1. ENTREPRISE COMME SYSTEME _________________________________________________ - 4 -
I.2. CONCEPTS DE BASE __________________________________________________________ - 5 -
I.2.1. METHODE : _______________________________________________________________ - 5 -
I.2.2. METHODOLOGIE : ________________________________________________________ - 5 -
I.2.3. MISE EN ŒUVRE : _________________________________________________________ - 5 -
I.2.4. UN SCHEMA DIRECTEUR INFORMATIQUE ____________________________________ - 5 -
I.2.5. PLAN INFORMATIQUE : ____________________________________________________ - 5 -
I.2.5. PROCESSUS : _____________________________________________________________ - 5 -
I.2.6. INFORMATION : ___________________________________________________________ - 5 -
I.2.7. MAITRE D’OEUVRE : _______________________________________________________ - 6 -
I.2.8. MAITRE D’OUVRAGE : _____________________________________________________ - 6 -
I.2.9. PROJET : _________________________________________________________________ - 6 -
CHAPITRE DEUXIEME : TECHNIQUES DE COLLECTE D’INFORMATIONS (DONNEES) _______ - 7 -
CHAPITRE TROISIEME: PANORAMA DES METHODES __________________________________ - 10 -
III. 0. Panorama des méthodes __________________________________________________ - 10 -
III.1. LES MÉTHODES : DIVERSITÉ ET PROLIFÉRATION _________________________________ - 11 -
III.1.1. METHODE SDM/S________________________________________________________ - 11 -
III.2. METHODES DE CONDUITE DE PROJETS INFORMATIQUES _______________________ - 12 -
III.2.2. SDM/S__________________________________________________________________ - 14 -
III.2.3. MCP ET MCPJ __________________________________________________________ - 16 -
CHAPITRE QUATRIEME : MODELISATION DE CONDUITE D’UN PROJET INFORMATIQUE ___ - 20 -
IV.1. PREALABLES _______________________________________________________________ - 20 -
IV.2. ETAPES DE CONDUITE D’UN PROJET INFORMATIQUE __________________________ - 21 -
1 – Convertir sa stratégie en action ______________________________________________ - 24 -
2 – Exécuter sa stratégie grâce au leadership ____________________________________ - 25 -
3 – Maîtriser le portefeuille de projets ____________________________________________ - 25 -
4 – Conduire le changement ____________________________________________________ - 25 -
5 – Diriger des équipes efficacement ____________________________________________ - 25 -
6 – Exécuter des programmes complexes ________________________________________ - 26 -
IV.3. CYCLE DE VIE DE CONDUITE D’UN PROJET INFORMATIQUE ____________________ - 26 -
IV.4. LES ACTEURS D’UN PROJET INFORMATIQUE___________________________________ - 28 -
IV.5. ORGANIGATION INTERNE ___________________________________________________ - 29 -
IV.6. DYNAMIQUE DE GROUPE ET PRISES DE DECISION _____________________________ - 31 -
IV.7. CONTRACTUALISATION DES RELATIONS ______________________________________ - 32 -
IV.7.1. CAHIER DES CHARGES __________________________________________________ - 32 -
IV.7.2. CONTRATS _____________________________________________________________ - 33 -
1.7 Logiciels de gestion de projet ________________________________________________ - 46 -
2.2 Indicateurs de pilotage ______________________________________________________ - 47 -
Temps moyen entre pannes _______________________________________________________ - 55 -
Calculs de MTBF ________________________________________________________________ - 55 -
Définition précise _______________________________________________________________ - 55 -
TABLE DES MATIERES ______________________________________________________________ - 62 -
- 62 -

Cours Des MCP 2019 - 2020 - L2Info

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours Des MCP 2019 - 2020 - L2Info

Transféré par

Droits d'auteur :

Formats disponibles

Cours de Méthode de Conduite de Projet Informatique à l’usage des étudiants de L2 Informatique (ISS / KIN)

Version 2019-2020 –=============================➔ Prof. Dr. Ir. Jeampy MBIKAYI MPANYA

2. GEDIN, Méthodes de projets informatiques, Méthodes d’analyse d’informatisation et

3. Emile BORDAIS, Conception du système d’informations, éd. Dunod.

4. HUBERT TARDIER et les autres, L’Approche Merise dans la conception du système

7. Arnold Rochfeld, José Morejon (1989). La méthode Merise - Tome 3 Gamme

8. Yves Tabourier (1986). De l'autre côté de Merise. Editions d’organisation (Paris.)

9. Georges Panet, Raymond Letouche (1994). Merise/2 - Modèles et techniques

10. Prof. MVIBUDUKU et le CT MPUTU KINSALA, Méthode de conduite des projets en

CHAPITRE PREMIER: INTRODUCTION

René NOLAN au début des années 80 a défini un schéma de l’évolution des

• L’étude d’opportunité (qui prend 5 à 10 % d’efforts ;)

Le parallélisme qui existe entre la topologie et le volume de besoins traités,

I.1. ENTREPRISE COMME SYSTEME

Lorsque l’informatique dépasse l’automatisation quelque peu mécaniste d’un

Il prend les décisions macroscopiques de l’organisation en fonction des informations

I.2. CONCEPTS DE BASE

I.2.3. MISE EN ŒUVRE :

I.2.4. UN SCHEMA DIRECTEUR INFORMATIQUE

Document synthèse exprimant les objectifs à long terme de l’entreprise dans le

I.2.5. PLAN INFORMATIQUE :

I.2.7. MAITRE D’OEUVRE :

I.2.8. MAITRE D’OUVRAGE :

• La gestion d’un projet (aspect économique et administratif) a pour but le suivi et la

CHAPITRE DEUXIEME : TECHNIQUES DE COLLECTE D’INFORMATIONS (DONNEES)

==➔QUELQUES CONSEILS A PRENDRE EN COMPTE POUR LA SPECIFICATION D’UN PROJET

- Etudes des besoins d’un projet

- Savoir écouter le client

- Surveillance et gestion des erreurs du système

- La spécification pour Chef de projet ou développeur

- Définition du mot spécification dans ce support

- L’intérêt d’une spécification

• Des délais non respectés.

- Etablir une maquette de l’IHM

CHAPITRE TROISIEME: PANORAMA DES METHODES

III. 0. Panorama des méthodes

• La méthode Merise une méthode standard de conception et de conduite des projets

III.1. LES MÉTHODES : DIVERSITÉ ET PROLIFÉRATION

ENTREPRISE CONCEPTION REALISATION

M.ES.DI MCSI ANALYSE PROGRAMMATION

AXIAL MERISE MERISE PS

III.1.1. METHODE SDM/S

• Racines : Rationalisation des choix informatique dans une entreprise.

•AXIAL : La méthode AXIAL est une méthode d'analyse, de conception et de

III.2. METHODES DE CONDUITE DE PROJETS INFORMATIQUES

III.2.1. METHODES AGILES

Le mouvement de méthodes agiles a commencé en 2001 aux Etats-Unis regroupant 17 experts en

Le développement itératif a pour avantage :

Les méthodes agiles prônent 4 valeurs fondamentales :

1. Personnes et interactions par rapport aux procédures et outils

2. Applications fonctionnelles par rapport à une documentation complète

3. Collaboration avec le client par rapport à la négociation du contrat

4. L’acceptation du changement par rapport à la planification

2. TABLEAU COMPARATIF DES METHODES AGILES AUX METHODES CLASSIQUES

Thème Approche traditionnelle Approche agile

Planification Prédictive, caractérisée par Adaptative avec plusieurs

Documentation Produit en quantité importante Réduire au strict nécessaire au

Qualité Contrôle qualité à la fin du Un contrôle qualité précoce et

Changement Résistance voir opposition au Accueil favorable au

Suivi de Mesure de la conformité aux Un seul indicateur

Gestion des Processus distinct, rigoureux, Gestion des risques intégrée

Mesure du Respect des engagements Satisfaction du client par la

PHASE OBJECTIFS PRINCIPALES TACHES