Seminaire L2 Ig 2020

Cours de Séminaire Informatiques
L2 Informatique de Gestion UPL

Conception des systèmes d’information
La réussite est liée à la patience mais elle dépend également de beaucoup

de bonne volonté.
Gilbert BREVART
Le succès du projet se mesure, à la satisfaction du client et à la qualité du

résultat, c’est-à-dire à la conformité du produit, à ce qui est attendu, livré dans
le respect du délai imparti et du budget alloué.
Hilaire LUFULUABO KENDA

2019-2020
I
PLAN DU COURS
BUT ET OBJECTIF DU COURS

CHAPITRE Ier : NOTIONS DE PROJETS INFORMATIQUES
CHAPITRE II : CAHIER DES CHARGES ET ACTEURS D’UN PROJET
CHAPITRE III : DETAILS TECHNIQUES D’UN PROJET INFORMATIQUE
CHAPITRE IV : PRINCIPES DE GESTION D’UN PROJET INFORMATIQUE
CHAPITRE VI : VALIDATION
BIBLIOGRAPHIE
1. Didier HALLÉPÉE, « Conduite et maîtrise des projets informatiques »,

Mantes la jolie, Mai 2000. (Cours).
2. GEDIN M., « Méthodes de conduite des projets informatiques », éditions

d’Organisation, Paris, 1986.
3. Hubert TARDIEU, Arnold ROCHFELD, Réné COLLETTI, Georges PANET,

Gérard VAHEE, « La méthode MERISE Tome 2 Démarche et
pratiques », éditions d’Organisation, Paris, 1985.
4. Véronique MESSAGER ROTA, « Gestion de projet vers les méthodes

agiles », édition Eyrolles, Paris, Avril 2009.

2019-2020
II
BUT ET OBJECTIF DU COURS
La réalisation d’un projet informatique peut se faire même

lorsqu’on n’utilise pas une méthodologie. Dans ce cas, seules les expériences du
chef de projet ainsi que celles des différents acteurs du projet pourront faire
face à tous les événements inattendus qui pourraient en entraver la bonne fin.
Cependant, dès que le projet dépasse une certaine ampleur, les

capacités personnelles du chef de projet ne lui permettent plus de tout contrôler
seul.
En outre, les différents responsables concernés tant chez le client
que chez le réalisateur ont besoin d’être informés tout au long du projet afin
de savoir que le contenu du projet sera conforme à leurs attentes et respectera
les budgets envisagés.
Il est également nécessaire d’avoir des processus qui permettent aux
différents acteurs un processus de décision éclairé et rapide face aux différents
aléas.
Enfin, il faut aussi être en mesure de fournir tous les éléments
permettant de pérenniser les investissements réalisés (organisation de la
maintenance, de la production, capitalisation des résultats).
L’utilisation d’une méthode de conduite de projets permet de

faciliter la maîtrise de ceux-ci et diminue notablement le coût des non
conformités. Elle représente une économie importante sur le coût réel des
projets.

2019-2020
III
CHAPITRE I : NOTIONS DES PROJETS INFORMATIQUES

I.1. Définition
Un projet informatique est un ensemble des tâches indissociables qui

doivent être accomplies en vue de répondre à un besoin exprimé. Il est caractérisé
par une durée déterminée et des ressources nécessaires à sa réalisation.
Tout projet informatique est centré essentiellement autour de la prise de

décision et de l’arbitrage.
Un projet provient d’une idée qui doit être concrétisée en action à réaliser
sur base de ce qui existe dans l’organisation et à l’extérieur de l’organisation.
Un projet informatique implique :

1. Une connaissance exacte de l’objet (intention poursuivi), et de
l’objectif (but à atteindre) du projet,
2. Un relevé exact des acteurs concernés,
3. Une maîtrise des outils de gestion concernant la communication et la
planification,
4. Une idée exacte des performances, des délais, des coûts, des risques
et de la qualité du produit final.
Tout projet informatique est caractérisé par un résultat final tangible. Cela
signifie que, dès son démarrage, tout projet doit nécessairement être doté
d’actions et de moyens destinés à produire à la fin les résultats attendus.
Un projet est généralement subdivisé en phases, chacune d’entre elles

devant aboutir à la mise à disposition de livrables. On parle aussi de cycle de vie
pour décrire l’enchainement de ces phases.
Le succès du projet se mesure, à la satisfaction du client et à la qualité du

résultat, c’est-à-dire à la conformité du produit, à ce qui est attendu, livré dans
le respect du délai imparti et du budget alloué.
Pour atteindre l’objectif, le chef de projet doit toutefois prendre en

compte les trois contraintes (les 3C) que constituent le contenu du projet, le
calendrier et le coût.

2019-2020
1
Contenu = Qualité
Coût = Ressource Calendrier = Temps
Les relations entre les acteurs impliqués dans un projet informatique

s’établissent comme suit :
Comité de projet
Porte feuille
Pilote Comite de pilotage

(Maître d’ouvrage)
Chef du projet
Projet (Maître d’œuvre)
Contributeurs
(Experts)
Tout projet, et en particulier tout projet informatique, nécessite donc la

mise sur pied d’une équipe composée essentiellement du comité de projet (schéma
directeur informatique), du pilote, du comité de pilotage, du chef de projet et des
contributeurs.
De cette équipe, devront sortir un animateur et un communicateur.

L’animateur fédère (tient soudé) l’équipe du projet.
Le communicateur est :
 le pont entre le système d’information et le système de pilotage

(Système de pilotage = comité de pilotage),
 le garant de la gestion de configuration.
Le rôle du communicateur est très important car c’est lui qui procède au
reporting interne et externe, qui gère le fond documentaire et qui permet une
communication rapide et sincère entre partenaires.

2019-2020
2
Il doit entre autre s’exercer à découvrir des dérives. Plus tôt qu’une dérive
est connue, mieux elle se gère.
Le pilote, appelé aussi maître d’ouvrage, est l’initiateur du projet, il compte

sur le chef du projet pour traduire le projet en action.
Le chef du projet, appelé aussi maître d’œuvre, est le personnage central

de l’équipe. Il doit :
1. Définir clairement le projet, son objet, son but et son résultat final,
2. Identifier les grandes phases du projet, les principaux jalons et les
principaux experts,
3. Valider ces phases et ces jalons avec les experts,
4. Responsabiliser les experts,
5. Planifier le projet,
6. Piloter le projet,
7. Mener des négociations internes et externes pour l’avancement du projet.
I.2. Gestion des projets

I.2.1. Introduction
Un projet informatique nécessite essentiellement deux gestions :

1. Une gestion d’analyse qui propose des techniques de
représentation et de modélisation.
2. Une gestion des projets qui offre un espace méthodologique qui

devra apporter au projet des solutions en termes de pilotage, de
conduite et de développement des projets. La gestion de projet est
la mise en œuvre de connaissances, de compétences, d’outils et de
techniques appliqués au point afin d’en respecter les exigences vis-
à-vis du client (interne ou externe) et de sa propre hiérarchie.
Les méthodes de gestion d’analyse sont indépendantes de l’environnement

dans lequel elles sont utilisées, mais les méthodes de gestion des projets sont
dépendantes de cet environnement.
Les raisons essentielles pour lesquelles un projet informatique (Gros projet

informatique étant entendu) doit être géré sont :
1. la gestion des contraintes principales telles que la qualité technique du

projet, le respect de délais et de coût, la garantie d’atteindre l’objectif

2019-2020
3
final, … en réalisant le meilleur compromis entre ces diverses contraintes

ne peut pas s’accomplir efficacement en dehors de structures
organisationnelles de gestion de projet.
2. la favorisation de l’atteinte des résultats attendus par l’optimisation de

la planification des moyens et des méthodes de management n’est
possible qu’au travers des structures organisationnelles de gestion de
projet.
3. l’inadéquation de l’environnement du projet et de l’organisation qui initie
ce projet exige des structures organisationnelles stables pour le projet
et des produits finaux de plus en plus adaptables.
Le but essentiel des structures pour la gestion de projet est de pouvoir

maîtriser à l’aide des quelques éléments méthodologiques les différentes étapes
du cycle de vie d’un projet. Les structures organisationnelles de gestion de projet
doivent s’occuper entre autre de l’organisation du travail en équipe et de la gestion
de configuration.
Schématiquement, les aspects de base d’un projet sont :
Temps
Ensemble des tâches qui sont identifiées par

les responsables au sein des experts pour
Métiers
atteindre le jalon 1 et le jalon 2 du moment
T1 et T2
Tt1 T2
Jalon 1 Jalon 2
Domaine d’expertise,
compétences qui constituent
l’axe d’analyse
Ces aspects de base fournissent déjà une idée sur les éléments qui doivent
nécessairement constituer une méthodologie de gestion de projet.
Les fonctions principales d’un chef de projet en ce qui concerne la définition
du projet et l’identification des phases sont :
Le chef de projet pourra sur base des jalons déterminer avec plus d’aisance
et d’exactitude les éléments nécessaires pour le restant du projet.

2019-2020
4
I.2.2. Remarques
1. les chances de réussite d’un projet partagé entre plusieurs acteurs
et la qualité du produit final dépendent énormément de la maîtrise de
différentes phases de ce projet.
2. un jalon est en fait considéré comme un produit intermédiaire

reconnu qui peut servir de base, pour le chef de projet, à la
négociation, à la délégation des sous objectifs et même à la
production des manuels d’utilisateur du produit final.
I.2.3. Outils de pilotage du projet

Une gestion de projet nécessite une démarche opérationnelle qui peut
rendre possible l’atteinte des objectifs en gérant et en coordonnant de manière
optimale tous les paramètres du projet (ressources, compétences, sous objectifs,
jalons,…).
Une des finalités de tous les outils et méthodes qui servent de support à la
gestion efficace de projet est la maîtrise des risques.
Les supports essentiels de pilotage de projet sont :
1. des règles générales de management,
2. réunions préparées,
3. des outils d’aide,
4. un tableau de bord,
5. une communication adaptée.
a. Règles générales de management
Tout chef de projet doit intégrer les règles de gestion et de bon sens en
ce qui concerne la prévision des ressources nécessaires au projet, l’organisation
et la planification de ces ressources et le contrôle des tâches réalisées.
Ces règles exigent que tout projet soit préparé avant sa mise en œuvre et
qu’il passe, enfin par une phase de bilan.
La phase de préparation du projet concerne :

1) La détermination des grandes parties (phases) et thèmes du projet,
2) L’établissement de la liste et de la configuration des tâches par chaque
contributeur opérationnel,

2019-2020
5
3) Le collationnement de toutes les listes de tâches, ce collationnement

peut être délicat si chaque liste de tâches utilise sa propre technique
de représentation (tableau graphique, réseau PERT,…), l’équipe du
projet devra alors uniformiser tous les aspects de toutes ces listes
afin de produire la structure initiale du projet,
4) L’optimisation et la validation (itératives) de la structure initiale du
projet,
5) La publication de la structure initiale du projet par le chef du projet.
La phase de mise en œuvre du projet concerne :

1) La réalisation des tâches planifiées,
2) La gestion de la communication remontante (des nouveaux événements
par les contributeurs),
3) La gestion de la communication descendante (des éléments correctifs
ou autres par le chef du projet),
4) La tenue des réunions pour la prise des décisions,
5) La mise à jour du projet (en fonction des tâches terminées).
La phase de bilan du projet concerne :

1) L’analyse des écarts des prévisions et des réalisations (études des
origines des causes,…),
2) L’examen des efficacités visées par le projet (économique,
informationnelles, organisationnelles,…),
3) L’unification et la publication des divers états des bilans.
b. Réunions préparées
C’est généralement au chef de projet que revient l’initiative de convoquer :

 Des réunions au sein de l’équipe du projet
 Des réunions avec la maîtrise de l’ouvrage
 Des réunions avec le comité du projet
Le but de chaque réunion doit être connu de tous les participants et ses
éléments de travail doivent être soigneusement préparés.
b. 1. Réunions au sein de l’équipe du projet
Ces réunions sont essentiellement des réunions techniques qui mettent des
idées au point (Réunions sur l’avancement des étapes du projet) qui ont pour but

2019-2020
6
essentiel de mesurer l’état d’avancement des travaux et de décrire les problèmes

éventuels rencontrés.
A l’issu de ces réunions, le chef de projet rédige une synthèse qui sera
présentée au comité de pilotage.
Les actions correctives retenues y sont signalées et seront évaluées lors

des réunions suivantes.
b. 2. Réunions avec la maîtrise d’ouvrage
Ces réunions sont essentiellement des réunions stratégiques (où intervient
la personne ayant une idée du projet) dans lesquelles sont prises et appliquées des
décisions majeures.
Elles sont généralement présidées par le pilote, et sont animées par le chef
de projet.
Le chef de projet y présente l’état d’avancement du projet :
 En relevant les événements majeurs et le suivi économique du projet,
 En indiquant les écarts observés par rapport aux objectifs initiaux, les
risques de dérive et les actions correctives mises en place.
Le chef de projet sollicite dans ces réunions les décisions qui ne sont pas de
son niveau.
b. 3. Réunions avec le comité des projets
Ces réunions sont généralement et normalement convoquées par le directeur
du comité directeur pour arbitrer les conflits au sein d’un projet (pour des
décisions qui ne peuvent pas être prises au niveau du pilote) ou entre différents
projets.
c. Outils d’aide
Il s’agit des outils (automatiques généralement) qui apportent au chef de
projet et à son équipe essentiellement une aide à la décision, à la planification et
à la documentation.
Ces outils automatiques d’aide sont précieux mais il faut relever que
l’acquisition de compétence sur ces outils peut nécessiter du temps et qu’ils ne
sont pas efficaces sans méthodes, car ils sont généralement intégrés.
Les outils automatiques d’aide à la décision peuvent aider les gestionnaires

d’un projet dans le choix et la détermination des paramètres de performance pour
des prises de décision.

2019-2020
7
Exemple :
- S.I.A.D. = Système d’Information d’Aide à la Décision
- S.I.A.D.G.= Système d’Information d’Aide à la Décision du Groupe
Les outils (automatiques) d’aide à la planification permettent de
déterminer et de contrôler l’enchaînement des tâches ou d’autres actions au sein
d’un projet.
Tous les outils d’aide à la planification exigent que chaque tâche soit
identifiée et ait un délai d’exécution probable.
Le délai d’exécution probable d est généralement déterminé comme suit :
a  b  4m
d Où
6 a= délai minimum
b= délai maximum
m= délai moyen
Les différentes tâches considérées individuellement peuvent être

répétitives, séquentielles, exclusives ou parallèles, la détermination des délais
d’exécution probables devra tenir compte de cet aspect.
Exemple : La liste de préséance, Diagramme de GANTT, Réseau PERT et
variantes
La liste de PRESEANCE est un outil de planification qui permet

essentiellement d’établir l’enchaînement logique des tâches et des contraintes de
cet enchaînement.
Date de Date de fin Responsable
N° Nom de la tâche prévue Durée prévue Lien
début prévue Remarques
Projet de gestion des
1
paiements des clients
2 Etude de faisabilité 8 semaines
Spécification des
3 8 semaines 2
besoins
La tâche 3 ne peut débuter que si la tâche 2 est terminée.
Le réseau PERT (Program Evaluation Review Technique) est un outil très

utile surtout pour l’ordonnancement du projet mais qui ne fait pas apparaître de
manière visuelle l’importance et la durée des tâches.

2019-2020
8
2 3 8 10
Projet de gestion
des paiements des
9
clients
1 300 jours
01-févr 30-nov
A partir du graphe PERT, les gestionnaires peuvent :
 Déterminer les tâches critiques.

Une tâche critique est une tâche qui lorsqu’elle dérape en délai,
fait déraper le projet dans sa globalité.
 Déterminer le chemin critique.
Qui est en fait l’enchaînement de toutes les tâches critiques.
 Calculer la marge.
La marge est l’intervalle de temps sur lequel peut glisser une tâche
non critique sans affecter le reste du projet ; au-delà de cette
marge, la tâche devient critique.
Le diagramme de GANTT est un outil de planification qui offre une
représentation très visuelle de l’enchaînement et de chevauchement des diverses
tâches d’un projet ou d’une partie de ce projet :
ANNEE X
N Nom de la tâche
Jan Fév Mar Avri Ma Jui Jui Aoû Sep Oc No De
° prévue
v r s l i n l t t t v c
Projet de gestion des
1
paiements des clients
2 Etude de faisabilité
Spécification des
3
besoins
Les outils d’aide à la documentation servent à documenter un projet et à en

réaliser efficacement les dossiers.
Plusieurs autres outils de gestion de projet qui se définissent comme des

outils de SYNTHESE peuvent être d’un bon secours pour le chef de projet. Parmi
ces outils, le TABLEAU DE BORD, qui est un outil synthétique de contrôle et de

2019-2020
9
suivi de projet qui privilégie les représentations graphiques en dégageant de

manière particulière des indicateurs de coût, de délai, et de performance.
I.3. Gestion de configuration
A. Notion de gestion de configuration

L’évolution des produits du projet et les modifications des besoins sont les
principales mises à jour qui interviennent tout au long du développement du projet.
Pour un projet de développement informatique toutes ces mises à jour se
traduisent par des répercutions sur le système d’information (modification des
traitements, des données, de la documentation,…)
La gestion des configurations permet de façon METHODIQUE de contrôler
les diverses modifications apportées par les personnes impliquées dans le
développement d’un projet dans le but d’éviter des sérieuses complications qui
peuvent naître d’un suivi inadéquat de ces modifications comme par exemple :
 La destruction d’une modification utile apportée auparavant par une
personne X dans un fichier,
 L’utilisation d’une mauvaise version des modules développés, conçus,
spécifiés, testés,… par une personne de l’équipe.
B. Objectifs de gestion de configuration

De manière générale, le développement d’un produit logiciel aboutit à la
confection :
 Des fichiers sources du produit,
 Des fichiers objets,
 Des scripts qui constituent le système, et
 De la documentation.
Ces éléments peuvent être de nature et d’organisations variées. Au cours
de développement du projet, ces différents éléments évoluent et fournissent des
nombreuses versions différentes. Il faudrait s’assurer entre autre :
 Que ce sont les bonnes versions des documents qui ont été utilisées ou
envoyées,
 Que ce sont les versions des modules sources qui ont été assemblées,
 Que le produit logiciel est complet.
L’objectif principal de la gestion de configuration est de gérer l’évolution
de la configuration d’un projet ou d’un système logiciel.
La gestion de configuration DOIT, par conséquent :
1. Suivre L’état des modules et des programmes :

2019-2020
10
 Un programme en état « EN DEVELOPPEMENT » est un programme qui

est en phase de développement. (Qui n’a subi de compilation)
 Un programme « EN VALIDATION » est un programme en phase de
validation (Programme validé si on l’a accepté pour être compilé)
 Un module est généralement en état « TEST UNITAIRE », « TEST
SYSTEME » ou « NON TESTE ».
2. Gérer les VERSIONS des modules et des programmes :
Si un programme doit être modifié ce suivi garantit que les modifications
sont apportées à la dernière version du programme pour ne perdre aucune
modification antérieure.
3. Gérer les DEMANDES des modifications simultanées d’un module ou d’un
programme :
On pourrait gérer la simultanéité en ne permettant qu’un seul accès en mise
à jour à la fois… gérer la consolidation qui garantirait que toutes les
modifications simultanées se retrouvant dans la version finale.
4. Gérer les MODIFICATIONS :
Il s’agit de défaire toute modification qui a été correctement répercutée
dans un fichier ou dans tout autre objet ou
- d’empêcher des mises à jours non autorisées ou indésirables.
5. Gérer le SUIVI des demandes de modification.
Etant donné une demande de modification, il s’agit de suivre toutes
modifications, tous les acteurs de chacune des modifications, tous les
objets ou fichiers concernés par chacune des modifications, l’état de
chaque programme ou module concerné.
6. Gérer les SYSTEMES et leurs versions
Cette gestion permet :
- de rassembler tous les objets relatifs à un système,
- de restaurer ces objets en cas des problèmes.
Toutes ces fonctions exigent le respect des certains principes et standards
dans la désignation des noms des objets et dans la désignation des emplacements
de ces objets.
C. Processus de gestion de configuration

Le processus de gestion de configuration doit déterminer la séquence des
activités nécessaires pour garantir l’intégrité de la gestion de configuration.
Les activités sont :
 Planification des objets de la gestion de configuration
Il s’agit :

2019-2020
11
1. D’identifier tous les objets qui doivent être suivis (spécification

des besoins, documents de conception, plan des tests, script de
test, code source, code objet, jalons, fichiers, base des données,
…). Tous ces objets ne sont pas obligatoirement connus lors de la
planification, mais le processus est entièrement dynamique.
2. D’établir des conventions dans le nommage des objets.
3. De définir les procédures de contrôle d’accès et de modification.

4. De définir les procédures de sauvegarde, de conservation et
d’archivage.
 Mise en œuvre de contrôle de configuration.
Ce contrôle est effectué principalement lors des changements d’états des

objets.
 Conduite de l’audit.
Un élément de la configuration comme on vient de le voir, peut avoir
plusieurs états, le nombre de ces états différents selon la nature de
l’élément et la finesse de gestion envisagée.
Il s’agit ici de vérifier PERIODIQUEMENT l’état de tous les
éléments de la configuration de produire un rapport des erreurs et
décalages observés et de les résoudre.
I.4. AVANTAGES DE FONCTIONNEMENT PAR PROJET

Un PROJET, résulte comme on le voit de la prise en charge d’un besoin ou
d’une action temporaire complexe ou innovant.
Ce besoin ou cette action est généralement TRANSVERSAL avec des
objectifs NETS, QUANTIFIES et fixés à priori, un calendrier jalonné, un résultat
tangible sous contrainte des délais et des ressources.
Le fonctionnement par projet permet l’évolution des organisations et des
techniques, LIBREMENT et de FACON INCREMENTALE.
Les activités permanentes (menée quotidiennement à l’intérieur d’une
organisation garantissent le QUOTIDIEN (C’est-à-dire le service vendu aux
clients à un instant donné) ne doivent pas être confondues avec celles menées dans
un projet.
Le projet rentre donc dans le cadre d’une STRATEGIE.
Le projet est un processus qui consomme du temps. Dans le contexte de
fonctionnement par projet, les gestionnaires devraient pouvoir analyser
continuellement leur organisation afin de trouver une DEMARCHE DE PROGRES
2019-2020
12
pour libérer du temps permanent à consacrer à des projets (innovant), c’est pour
cela que le fonctionnement par projet nécessite des structures organisationnelles
souples.
Les principaux avantages de FONCTIONNEMENT PAR PROJETS sont :
 Une mobilisation des ressources STRICTEMENT NECESSAIRES,
surtout en cas d’opération extraordinaire, d’actions à risque ou
d’objectifs ambitieux,
 Une plus GRANDE VITESSE dans l’accomplissement des phases, car
les phases identifiées sont exactement celles qui ne sont relatives
qu’à ce seul projet,
 Une plus GRANDE MAITRISE de la transversalité
(La transversalité détermine les domaines d’expertise qui doivent
être présents et impliqués tout au long du projet et qui sont
nécessaires pour l’avancement et la cohérence globale du projet.
(Exemple : Service commercial, sécurité, finance, …)
 Une coordination EXCEPTIONNELLE à cause de la gestion des
équipes multidisciplinaires et des objectifs partagés :
La PLANIFICATION DE PROJET doit donc être distinguée de la conduite
des activités quotidiennes, car la planification de projets :
 Est tournée essentiellement vers l’atteint d’un objectif clairement
qualifié,
 Est non répétitive,
 Est réactive (face aux aléas de la réalisation et aux arbitrages
éventuels, on aboutit couramment à des modifications du cahier des
charges)
 Est personnalisée (par le chef de projet ayant une OBLIGATION de
résultat)
 Est soumise à diverses contraintes (délais, coûts,…)
I.5. GARDE-FOUS DE FONCTIONNEMENT PAR PROJET

On comprend facilement qu’un projet nécessite d’être structuré et préparé
avant sa mise en œuvre.
La structuration d’un projet permet d’améliorer sa visibilité en cernant
mieux les risques qui peuvent le faire échouer.
Les principaux écueils à éviter au sein de la structuration d’un projet sont :
- Une mauvaise définition des phases,
- Un mauvais séquencement des phases.

2019-2020
13
Un chef de projet doit pouvoir situer son projet dans l’ensemble de

l’organisation car les contextes en amont et en aval de son projet peuvent cacher
des bénéfices pour une capitalisation possible et utile à ces deux contextes.
Les dix garde-fous pour éviter la plupart des risques qui guettent tout
projet sont :
1. Seul le maître d’ouvrage fixe les orientations générales du projet et avalise
toute modification de ses objectifs.
2. Le maître d’ouvrage est garant de la conformité du projet aux objectifs
stratégiques et de sa rentabilité.
3. La maîtrise d’ouvrage et la maîtrise d’œuvre doivent être séparées.
4. Le maître d’œuvre (réalisateur du projet) est garant de l’atteinte des
objectifs du projet.
5. Le maître d’œuvre détermine le découpage de son projet en sous projets
et en phases avec des résultats intermédiaires à des dates bien
déterminées.
6. Le maître d’œuvre arbitre sur tous les problèmes qui surviennent dans la
réalisation du projet.
7. Chaque service contributeur est responsable vis à vis du maître d’œuvre,
des objectifs, des coûts, des délais et des performances.
8. Chaque service contributeur doit systématiquement informer le maître
d’œuvre.
9. Chaque service contributeur peut communiquer sans contrainte avec les
autres contributeurs du projet.
10. Chaque responsable de centre de compétence garantie l’efficacité des
moyens qu’il engage sur le projet.

2019-2020
14
CHAPITRE II : CAHIER DES CHARGES ET ACTEURS

D’UN PROJET
II.1. Définition
On appelle CAHIER DES CHARGES un document écrit exprimant les besoins des
utilisateurs, destiné à un fournisseur potentiel pour lui permettre de proposer une
solution. Il constitue la base de l’APPEL D’OFFRES aux fournisseurs de matériels, de
logiciels, de services.
Le cahier des charges vise à définir simplement les ‘‘spécifications de base’’ d’un
produit ou d’un service à réaliser.
C’est un document contractuel entre le client et le prestataire/vendeur, mais il ne
constitue pas à lui seul le contrat commercial. Il permet aussi de remplir l’obligation
générale d’information du vendeur ou du prestataire vis-à-vis de son client.
Il est souhaitable que ce document soit rédigé dès que le moment où l’on souhaite
consulter des fournisseurs extérieurs à l’entreprise. L’absence ou l’insuffisance de cahier
des charges interdit en pratique à l’entreprise cliente un recours efficace contre la
défaillance des fournisseurs.
Le cahier des charges prend des formes variables selon le type d’activité
(production ou service récurrent, projet ponctuel,…), selon le domaine d’activité principal
concerné et selon la culture d’entreprise. Cependant, le cahier des charges sert à
formaliser les besoins et à les expliquer aux différents acteurs pour s’assurer que tout
le monde soit d’accord. Il permet notamment de cadrer la ou les missions des acteurs
impliqués, dont celles du directeur de projet (côté maîtrise d’ouvrage) et/ou du chef de
projet (côté maîtrise d’œuvre).
Il sert ensuite à sélectionner le prestataire ou maître d’œuvre (dans le cas d’un
appel d’offres), et à organiser la relation tout au long du projet. Il est considéré comme
un référentiel partagé par le prestataire et l’équipe interne, et décliné dans les documents
contractuels. Vers l’externe, c’est en outre un outil fondamental de communication du
directeur de projet et/ou du chef de projet.
II.2. Différentes sortes des cahiers des charges
Le cahier premier document établi est appelé CAHIER DES CHARGES DE

CONSULTATION. Il peut être établi dans différents cas :
 Lorsque l’entreprise est non informatisée ou mal informatisée :
L’entreprise désire s’équiper en matériel et logiciel ; elle lance un appel
global comportant plusieurs applications.
 Lorsque l’entreprise est déjà informatisée et n’envisage pas de
changement de matériel :
L’entreprise lance un appel d’offres spécifique pour la réalisation d’une
application particulière, donc la fourniture de logiciels et de services

2019-2020
15
annexes. Dans ce dernier cas, le cahier des charges peut être adressé à des
fournisseurs externes à l’entreprise ou au fournisseur interne.
Il est possible qu’à l’issue de l’appel d’offres, des discussions approfondies avec le
fournisseur entraînent certaines modifications des besoins exprimés. Le document ainsi
modifié est souvent appelé CAHIER DES CHARGES CONTRACTUEL. Cette convention
définit les engagements précis que doit respecter le fournisseur et sera utilisée lors de
la réception du projet réalisé. Elle peut contenir des spécifications détaillées concernant
les données et les traitements.
II.3. Appel d’offres et choix des fournisseurs

Il est souhaitable d’adresser le cahier des charges de consultation à plusieurs
fournisseurs (en moyenne 10). Une première sélection permet d’éliminer les fournisseurs
dont la proposition est manifestement inadaptée, les fournisseurs restants, sont appelés
à préciser leur proposition à partir des informations complémentaires éventuelles. Il est
souhaitable que les modifications apportées aux propositions soient confirmées par écrit.
Il est important de préparer un tableau de dépouillement résumant les
caractéristiques de chacune des propositions. Il est important de définir un certain
nombre de critères. Les principaux critères sont :
 Le matériel,
 Le logiciel proposé,
 Le fournisseur.
Il est recommandé de vérifier les références des fournisseurs sur des expériences
en clientèle proches du problème posé par l’entreprise. Il est également possible d’exiger
des démonstrations de logiciels sur des données de l’entreprise. Après sélection d’une
proposition, le cahier des charges contractuel va décrire de façon précise les termes de
l’accord conclu au cours de la phase de consultation.
II.4. Organisation générale du cahier des charges

L’efficacité d’un cahier des charges repose entièrement sur la précision des divers
éléments de son contenu. Pour rédiger un cahier des charges standard, pratique et
pertinent, il doit comprendre les éléments suivants :
a. Présentation de l’entreprise :
Dans cette partie, il est question de donner un court exposé devant permettre
de situer l’entreprise dans ses activités et sa dimension (son effectif, son
implantation, son évolution,…)
b. Spécifications générales :
Nous distinguons deux sortes de ces spécifications :
b.1. Objectifs poursuivis
On exprime les objectifs généraux prioritaires (sécurité, réduction des délais
de traitement,…)

2019-2020
16
b.2. contraintes à observer

Ce sont des contraintes générales, applicables à toutes les applications.
Exemple
 Lieux d’implantation des matériels et nombre d’ordinateurs minimum,
 Compatibilité avec le matériel existant,
 Qualification du personnel en place (et habitudes de travail…),
 Environnement (Bruit, Poussière, Eclairage,…).
c. Spécifications propres à chaque application

Elles constituent le cœur du cahier des charges.
d. Spécifications à caractère administratif et financier

Peuvent être demandées ici toutes les précisions jugées d’un intérêt notable
pour l’entreprise, qui sont :
 Les conditions de FORMATION (techniciens et utilisateurs),
 La DOCUMENTATION fournie,
 Les DELAIS estimés pour la livraison du matériel et la réalisation du logiciel,
 Les TARIFS DE MAINTENANCE et les CONDITIONS DE GARANTIE,
 Les MODALITES DE FINANCEMENT,
 Les POSSIBILITES DE DEMONSTRATION offertes,
 L’indication des PRIX DETAILLES et les clauses éventuelles de révision.
II.5. Contenu du cahier des charges

1. Brève historique de l’entreprise
Cette section doit présenter au maitre d’œuvre une synthèse de l’évolution de
l’entreprise en mentionnant entre autres les noms des propriétaires, la raison d’être de
l’entreprise, ses principales activités, son chiffre d’affaires, ses phases d’expansion. Il
faut se limiter à un maximum d’une page.
2. Description du contexte actuel

Il est important de faire ressortir les éléments qui caractérisent la situation
présente de l’entreprise : les résultats obtenus en fonction des objectifs visés, les
changements survenus dans votre environnement interne ou externe, les difficultés, les
menaces, les opportunités, vos forces, vos faiblesses afin de présenter aux consultants
l’état réel de la situation globale de l’entreprise ou d’une fonction spécifique.
3. Définition du problème
L’analyse de votre situation doit faire ressortir le problème à corriger ou la
situation à améliorer. Il est important de préciser les éléments et les causes connus du
problème ou de la situation, en se posant les questions suivantes : quoi ?, qui ?, quand ?,
comment ?, combien ?, où ? et pourquoi ? L’identification du problème peut se faire à l’aide
d’observations, de discussions avec les employés et collaborateurs, des sondages auprès
des clients, d’analyse financière et de diagnostic. Vous pouvez avoir recours à des
conseillers externes pour vous aider à préciser le problème ou le besoin d’amélioration.
2019-2020
17
4. Objectifs visés par l’invention

Il est important de préciser à la maitrise de l’œuvre les résultats que vous
attendez de leur intervention. Plus les objectifs visés sont quantifiables et les résultats
mesurables, plus vous serez satisfait de l’intervention des consultants. Pour garantir le
succès de l’intervention, il est essentiel de préciser la nature du mandat d’intervention,
les objectifs visés et les résultats attendus.
5. Règles d’acquisition du cahier des charges

Les règles suivantes sont recommandées afin d’établir une procédure standard
pour l’acquisition du cahier des charges :
5.1. Confidentialité
Le contenu du présent cahier des charges est divulgué à titre confidentiel. Toute
société ou consultant qui reçoit ou détient le présent cahier des charges s’engage à n’en
dévoiler la teneur et le contenu que pour les besoins de l’élaboration éventuelle d’une ou
plusieurs offres de service.
5.2. Représentation du maître d’ouvrage

Aux fins d’assurer une uniformité d’interprétation du cahier des charges et pour
faciliter les échanges d’information, le maître d’ouvrage mandate la personne suivante
pour le représenter :XXXXXXXXXXXX le maître d’ouvrage oblige le maître d’œuvre à
s’adresser exclusivement au représentation et/ou à toute personne désignée par écrit par
le maître d’ouvrage dans le cadre de la présente acquisition et pour obtenir des précisions
additionnelles sur le cahier des charges.
5.3. Représentation du maître d’œuvre

Dans les meilleurs délais suivant la réception du présent cahier des charges, le
maître d’œuvre devra informer le maître d’ouvrage par écrit du nom, titre, adresse et
numéro de téléphone de son représentant. Toute communication subséquente sera
adressée à ce dernier.
5.4. Amendement du cahier des charges

Le maître d’ouvrage se réserve le droit :
 D’amender le cahier des charges,
 D’exiger des informations additionnelles.
5.5. Propriété de l’offre de service

L’offre de service présente ainsi que les documents afférents demeurent la
propriété exclusive du maître d’ouvrage et ne seront pas retournés au maître d’œuvre.
5.6. Durée de la validité de l’offre de service

L’offre de service déposée doit demeurer valide pour une période de quatre-vingt-
dix jours (du calendrier) à compter de la date d’ouverture des offres de service.

2019-2020
18
5.7. Portée des documents

Le contenu du cahier des charges, de l’offre de service et des documents
afférents peut être retenu comme obligation contractuelle, à la charge du maître d’œuvre
choisi, sans aucune négociation avec le maître d’ouvrage lors de la préparation du contrat.
5.8. Coût de préparation des offres de service

Tous les coûts de préparation des offres de service sont à la charge exclusive de
la maîtrise d’œuvre.
5.9. Frais additionnels pour les offres de service

Le maître d’œuvre assume tous les frais encourus pour fournir les précisions
demandées par le maître d’ouvrage à la suite du dépôt des offres de service.
5.10. Services offerts par le maître d’ouvrage

Pour la durée du contrat, le maître d’ouvrage offre au fournisseur, au moyen de
ses ressources régulières :
 Des espaces de travail,
 La collaboration du responsable du projet.
5.11. Etapes
5.11.1. Calendrier
Date Etape
XXXXXXX Demande d’offres de service
XXXXXXX Réception des offres de service
XXXXXXX Analyse des offres de service
XXXXXXX Présentation ou rencontre avec les consultants
XXXXXXX Choix final du fournisseur
XXXXXXX Début des travaux
XXXXXXX Rapport d’étape
XXXXXXX Rapport final
5.11.2. Diffusion de renseignements supplémentaires

La société-conseil désirant obtenir d’autres renseignements devra confirmer ses
demandes par écrit ou contacter le représentant autorisé du maître d’ouvrage.
5.11.3. Dépôt des offres de service

Une date devra être fixée pour que les potentiels maîtres d’œuvre déposent leurs
offres.
5.11.4. Présentation des offres de service

Le maître d’ouvrage se réserve le droit d’inviter le maître d’œuvre de son choix à
faire une présentation de leur offre de service ou à fournir des informations
additionnelles et complémentaires.

2019-2020
19
5.11.5. Résiliation de l’entente

Le maître d’ouvrage se réserve le droit de résilier toute entente future avec le
maître d’œuvre retenu, à la suite du non-respect d’une obligation ou d’un élément liant les
deux parties.
6. Instructions aux maîtres d’œuvres

Les règles suivantes visent à uniformiser la présentation des offres de service
pour en assurer un emploi simple et efficace et pour aider le maître d’œuvre à préparer
un document complet rencontrant les exigences du maître d’ouvrage.
Contenu de l’offre de service

Le maître d’œuvre doit fournir tous les éléments d’information nécessaires et
suffisants pour évaluer correctement l’offre de service.
Les informations fournies doivent être succinctes et toucher à tous les aspects.
Le maître d’œuvre doit démontrer en quoi il possède les qualifications requises pour
réaliser le mandat.
Le maître d’œuvre peut ajouter toute information jugée pertinente. Ces
renseignements additionnels devront être présentés en annexe de façon à limiter le plus
possible le volume du document de base.
Chaque offre de service doit être indépendante l’une de l’autre. Par conséquent, si
plus d’une solution est proposée, le maître d’œuvre présentera une offre de service
complète dans chaque cas.
La présentation de chaque offre de service doit respecter le schéma proposé par
le maître d’ouvrage.
7. Schéma proposé de l’offre de service

Chaque offre de service doit contenir les éléments suivants :
7.1. Introduction
Le maître d’œuvre peut présenter une brève introduction faisant état de son
intérêt à réaliser le présent mandat d’intervention et des avantages que retirera le maître
d’ouvrage à utiliser ses services professionnels.
7.2. Présentation de la mise en situation

Le maître d’œuvre devra présenter la mise en situation à faire face précisant les
éléments importants du contexte, de la problématique et des objectifs visés par le maître
d’ouvrage. Pour mieux la comprendre, le maître d’œuvre pourra, s’il le désire, obtenir une
rencontre à ses propres frais avec le maître d’ouvrage sans aucun engagement de la part
de ce dernier.
7.3. Détermination des services proposés

Le maître d’œuvre sera appelé dans cette section à préciser son offre de service
en fonction du problème à corriger, de la situation à améliorer ou des objectifs visés par
le maître d’ouvrage. Il devra déterminer les résultats attendus et décrire les biens
livrables au cours et à la fin de son intervention.

2019-2020
20
II.6. Acteurs d’un projet

Les acteurs forment la structure de pilotage de tout projet
informatique.
De manière plus pratique, la gestion d’un tel projet exige un COMITE DE
PROJET dont la structure et souvent issue d’un schéma directeur informatique.
Un des objectifs du schéma directeur informatique est d’adapter certaines
structures d’organisations conventionnelles au type de fonctionnement par
PROJET.
Les acteurs au sein d’un projet doivent avoir une grande propension
(disposition) à communiquer avec les utilisateurs finaux qui ont besoin du service
ou du produit informatique qui doit être développé.
Les objectifs, les sous- objectifs, les enjeux, les jalons l’avancement du
projet informatique, les risques, les résultats intermédiaires et l’organisation de
l’équipe doivent être clairement connus de tous les acteurs.
Un comité de pilotage est le groupe de dirigeants chargé de veiller au

bon fonctionnement d'un projet au sein d'une entreprise, pour améliorer le suivi
d'un projet et valider les choix stratégiques. Il est généralement constitué d'un
membre de chaque métier impliqué dans le projet (exemple : le directeur
recherche, le directeur production, le directeur financier pour un projet
d'industrialisation d'un nouveau produit).
Un comité de pilotage peut être créé pour :

 planifier les dates-clés du projet ;
 analyser les options proposées par le chef de projet ;
 décider des orientations stratégiques, des actions à entamer sur un
processus de :
o diminution des coûts,
o suivi du projet,
o d'amélioration des processus Qualité.
Le comité de pilotage joue un rôle prépondérant dans le projet. Il est le

relais de la volonté politique. Il impulse la dynamique à l’ensemble des acteurs.
Tout au long du projet, il assure :
 Les choix stratégiques : communication autour du projet, lien avec les
institutionnels…,
 La validation des étapes essentielles,
 La surveillance de son bon déroulement,
 La remontée d’information au conseil municipal,
 L’identification des investissements nécessaires le cas échéant.

2019-2020
21
Il n’est pas indispensable de le réunir très fréquemment. Il faut

réserver les rencontres à des moments clés du projet, au minimum à la fin de
chaque grande étape afin de les valider (plans d’actions, diagnostic des risques…).
On appelle maître d'ouvrage (parfois maîtrise d'ouvrage, notée MOA)

l'entité porteuse du besoin, définissant l'objectif du projet, son calendrier et le
budget consacré à ce projet. Le résultat attendu du projet est la réalisation d'un
produit, appelé ouvrage.
La maîtrise d'ouvrage (en anglais Project Owner) maîtrise l'idée de

base du projet, et représente à ce titre les utilisateurs finaux à qui l'ouvrage est
destiné.
Ainsi, le maître d'ouvrage est responsable de l'expression

fonctionnelle des besoins mais n'a pas forcément les compétences techniques liées
à la réalisation de l'ouvrage.
Il impulse la dynamique à l’ensemble des acteurs.
Le chef de projet informatique est désigné par le COMITE DE PROJET

en accord avec le COMITE DE PILOTAGE de projet. Il est unique, il détermine
les compétences nécessaires du développement du projet et sur les divers
matériels, les logiciels et plateforme informatique nécessaire au développement.
C’est lui qui rédige le cahier des charges du projet en contactant les services
compétents et les partenaires.
Il doit être multicompétent : c'est-à-dire maîtriser les techniques de
gestion de projet, appréhender, chaque fois, les spécificités du projet et en plus
être un bon leader d’équipe. Ensuite, il est souvent seul, pour faire face,
notamment, à l’incertitude qui l’entoure. Alors, gérer un projet serait-ce une
mission (im)possible.
Le chef de projet a la responsabilité de définir l’étendu du projet, ses
limites, son architecture et son découpage. Lorsque le cahier des charges est
accepté par le comité de projet et par le comité de pilotage, le chef de projet
peut :
1. Constituer officiellement l’équipe,
2. Réaliser avec elle (équipe) le dossier d’analyse détaillée qui
seul permet l’action quotidienne.
Le chef de projet informatique est donc une personne clé lors de la

négociation des éléments du cahier des charges avec la direction, de laquelle il
pourra obtenir l’engagement des moyens nécessaires à l’exécution du projet
essentiellement.
2019-2020
22
CHAPITRE III : DETAILS TECHNIQUES D’UN

PROJET INFORMATIQUE
A. RISQUES D’UN PROJET INFORMATIQUE
Les causes d’échecs d’un projet informatique ont comme principales

sources les risques potentiels liés naturellement à la notion du projet.
Techniquement, ces risques potentiels sont :
o Les risques organisationnels :

Ces risques sont dus essentiellement à des imprécisions dans le cahier des
charges, dans la définition des objectifs et à des demandes de modification des
besoins de la part du demandeur.
o Les risques liés aux ressources humaines :

Ces risques s’accroissent avec l’indisponibilité des ressources humaines,
avec le manque de compétences, de formation, de motivation nécessaire et avec le
départ d’effectifs.
o Les risques techniques :

Ces risques liés à un non-respect de la normalisation et de la standardisation
informatique, à l’incohérence des spécifications et de la documentation et à la
fixation des délais non réalisables.
o Les risques commerciaux et de marketing :

Ce sont des risques qui naissent suite à la non connaissance du marché
informatique et au manque d’appréciation correct des offres de la concurrence.
o Les risques juridiques :

De manière générale, les tribunaux de travail ne doivent pas accuser un vide
juridique dans la résolution des conflits nés de la conduite de projet.
o Les risques liés à la sécurité :
L’atteinte des objectifs en un délai à respecter obligatoirement peut
pousser les acteurs à ignorer des aspects de sécurité liés à l’utilisation de certains
produits et matériels nouveaux, nécessaires au projet.
o Les risques liés à la maîtrise de la sous-traitance :

Les risques principaux liés à des parties de projet dont la réalisation c’est
confié à des sous-traitances sont ceux qui naissent essentiellement de la non
connaissance exacte de l’environnement du projet.

2019-2020
23
o Les risques liés au suivi des coûts :

Des nouveaux paramètres non maîtrisés au départ du projet peuvent
apparaître durant l’exécution du projet, c’est pour cela qu’il est parfois nécessaire
de procédé à un suivi efficace des coûts :
 Aux échéances fixées (au jalon)
 Par une reprogrammation éventuelle du projet
o Les risques liés à la communication et à l’information :

Ces risques concernent surtout la sécurité d’utilisation des informations.
Pour diminuer des risques, il sera nécessaire d’établir une distinction nette des
informations utilisées :
 Selon leur contenu
 Selon leur destinataire
 Selon leur phase d’avancement du projet
 Selon leur intensité d’utilisation
 Selon leur qualité
o Résistances au changement :
Pour diminuer ce genre de risque, il faut essentiellement maîtriser les
concepts de base nécessaire à la réussite d’un changement :
L’information, la compréhension, la contribution et l’adhésion.
L’information a comme rôle principal de présenter les faits, l’information qui

véhicule ces faits ne doit être ni trop complexe, ni trop abondante, ni trop rapide,
ni incomplète.
La compréhension est nécessaire pour susciter et stabiliser un échange
adéquat et pour faciliter l’appropriation.
La contribution est un aspect important pour permettre l’acceptation des
règles de jeu.
L’adhésion est un concept qui doit impulser l’action, pour cela, il faut
essentiellement une gestion technocratique du projet informatique et plus de
transparence au niveau de réponse et explications fournies.
- Situations conflictuelles :
Une situation conflictuelle résulte du comportement d’un individu, d’un
groupe ou d’une organisation qui entrave ou qui restreint l’attente des objectifs
poursuivis par le projet.
Les formes courantes de ces situations conflictuelles sont :

2019-2020
24
 L’isolement social
 La participation négative
 Les manifestations extérieures
 L’obstruction
 Cessation volontaire ou concertée de la participation au projet
 La résistance au changement
Les comportements possibles du chef de projet en cas de conflits sont :

 Le compromis
 L’évitement
 L’accommodation
 La compétition et la collaboration
B. ACTIONS DE LIMITATION DES RISQUES

Il n’existe pratiquement aucune solution universelle à tous les problèmes
générés par les risques cités ci-avant.
C’est la raison pour laquelle, il est très important d’envisager des actions de
limitation des risques avant le lancement du projet.
Ces actions de limitation des risques sont considérées comme des canevas
généraux pouvant aider le chef de projet et les acteurs à générer et à étudier des
actions efficaces, nécessaires pour améliorer l’environnement de développement
du projet informatique.
Ces actions de limitation sont entre autres :
 Mise en place des programmes de formation
 Attribution de plusieurs ressources sur les domaines clés du projet
 Négociation de meilleurs délais
 Identification rigoureuse des tâches du projet qui peuvent se dérouler en
parallèle
 Multiplication de dialogues avec le maître d’ouvrage
 Développement des prototypes (maquettes comprenant les fonctionnalités
réutilisables ou nécessaires au développement des logiciels mais une
maquette n’a rien comme fonctionnalité).

2019-2020
25
C. MODELISATION DU CYCLE DE VIE D’UN PROJET

INFORMATIQUE
Les principales phases de développement d’un projet informatique ont été

identifiées et peuvent être regroupées par le chef de projet, en thèmes ou
éclatées en sous-phases selon divers critères bien identifiés par le chef de projet.
Ces phases de développement prennent place après celles de l’analyse.
Les phases de développement peuvent remettre en cause plus ou moins
profondément une ou plusieurs décisions de l’Analyse.
Le processus de développement des logiciels passe donc par différentes
phases fondamentales ordonnées et coordonnées qui déterminent son cycle de vie.
Ces principales phases de développement sont :
1. Etude de faisabilité et Analyse du système
2. Spécification et Planification
3. Conception générale
4. Conception détaillée
5. Codage
6. Intégration et Tests
7. Installation et mise en œuvre
8. Exploitation et Maintenance
 L’étude de faisabilité et l’analyse du système

Se basent essentiellement sur l’analyse des besoins, c’est-à-dire une analyse
minutieuse du domaine dans laquelle les concepteurs doivent mettre en exergue :
 La définition globale du problème, les ressources disponibles, les
coûts et les délais,
 Les performances attendues,
 Le rôle principal du système
 L’état actuel de l’environnement, …
 Les qualités fonctionnelles attendues (en termes des services
offerts),
 Les qualités non fonctionnelles attendues (efficacité, sûreté,
sécurité, …),
 Les modélisations conceptuelles et logiques du domaine.

2019-2020
26
 La spécification et la planification
La phase de spécification et planification se base sur les résultats de
l’étude de faisabilité, sur les considérations techniques et sur la faisabilité
informatique pour produire une description de ce que doit accomplir le système
(c’est-à-dire la description du QUOI).
 La conception générale
Conçoit une structure générale (architecture logicielle) du domaine ou
d’un sous domaine du système et en définit les grandes parties. L’application est
organisée en grandes fonctionnalités dotées chacune d’une spécification
informelle.
 La conception détaillée
Décrit le comment d’une spécification en enrichissant la description de
départ par des détails d’implémentation. C’est donc une conception architecturale
qui devra décomposer le système (ou le domaine) en composants plus simples
définis par leurs interfaces et leurs fonctions (modules).
A la fin de cette phase, les concepteurs devront fournir, pour chaque
composant, une description de la manière dont les fonctions et les services sont
réalisés :
 Le codage
C’est la traduction des algorithmes de niveau le moins virtuel en langage
de programmation.
 L’intégration et tests
Permet essentiellement :
 De gérer les configurations, ce qui permet de suivre et de maîtriser l’évolution
et la mise à jour des composants tout au long du processus de développement.
 De procéder à des tests, à la vérification des composants, des révisions des

spécifications, à des inspections des concepts à des prototypes, … par la
validation, la démonstration ou par la conduite des jeux de test.
Cette phase doit attester que le système produit répond correctement

aux attentes de l’utilisateur.
Elle compose progressivement les modules du système en testant leur
regroupement.

2019-2020
27
 L’installation et mise en œuvre

Concerne les aspects de la mise en œuvre de la solution sur une
configuration physique donnée.
 L’exploitation et maintenance
Constitue la phase où le système est utilisé ou exploité et où il est
maintenu. Il a été formellement démontré que c’est la maintenance qui coûte le
plus cher.
Le cahier des charges issu de la phase de l’étude de faisabilité inclut
généralement une partie destinée aux clients (définition de ce que peuvent
attendre les clients) et une partie destinée aux concepteurs (spécification des
besoins).
Les activités visibles dans toutes les étapes du cycle de vie sont, la
spécification, la documentation, la validation, la vérification, et la gestion.
Les coûts de différentes étapes du cycle de vie se répartissent en
moyenne comme suit :
TYPE DE SYSTEME CONCEPTION IMPLANTATION TEST
Gestion 44 28 28
Scientifique 44 26 30
Industriel 46 20 34
Les quatre (4) modèles de cycle de vie les plus utilisés sont :
C1 Modèles de la CASCADE
Le principe de ces modèles est que chaque phase doit se terminer à une
date déterminée et produire à cette date certains documents, logiciels ou parties
de logiciels.
La phase suivante ne peut commencer que lorsque la phase précédente
soit terminée à une date déterminer sont jugés satisfaisants. Ces modèles, en
principe n’admettent pas de retour en arrière, mais les activités comme le contrôle
technique et la gestion de la configuration (gestion des mises à jour apportées au
système au fur et à mesure de son développement) peuvent intervenir tout au long
du processus.
Nous voyons donc que le développement reste fondamentalement
linéaire, car son hypothèse principale est de considérer que l’on peut dès le départ
définir complètement et en détail ce que l’on veut réaliser.

2019-2020
28
Etude de
faisabilité
Spécification
et planification
Conception
générale
Conception
détaillée
Codage
Intégration et
tests
Installation et
mise en œuvre
Exploitation et
maintenance
C2 Modèles en V
Le principe est que toute décomposition des composants est

accompagnée d’une recomposition et, toute description d’un composant est
accompagnée des tests qui permettront de s’assurer qu’i correspond bien à sa
description.
Cela permet essentiellement d’éviter que l’on énonce une propriété dans
la spécification qui est impossible de vérifier objectivement après la réalisation.
Ce cycle de vie reste linéaire, mais il fait mieux apparaître les produits
intermédiaires à des niveaux d’abstraction et de formalisé différents, et des
procédures d’acceptation (validation et vérification) de ces produits
intermédiaires.
Le V est donc parcouru de gauche vers la droite en suivant la forme de

la lettre V. les activités de construction précédent celles de validation e de
vérification. L’acceptation et préparée dès la construction (flèches marquées *),
cela permet de mieux approfondir la construction et de mieux planifier la
remontée (partie montante de la lettre V).

2019-2020
29
Orientation Utilisation et
faisabilité maintenance
Analyse des besoins et

du système
* Tests d’acceptation
Conception architecturale Tests d’intégration

**
générale
Conception *** Tests unitaires

détaillée
* Préparation de la validation
** Préparation de la vérification
*** Préparation des tests
Codage
CONSTRUCTION ACCEPTATION
C3 Modèles en spirale
Ces modèles mettent l’accent sur l’analyse des RISQUES et proposent

que chaque cycle de la spirale se déroule en 4 phases :
A. DETERMINATION à partir des résultats des cycles précédents (ou de

l’analyse préliminaire des besoins) des objectifs du cycle des alternatifs les
atteindre et des contraintes,
B. ANALYSE des risques : évaluation des alternatives et maquettage éventuel,
C. DEVELOPPEMENT et VERIFICATION de la solution retenue (par un

modèle en cascade ou en V),
D. REVUE des résultats et vérification du cycle suivant.

2019-2020
30
Analyse des risques Détermination
Revue des
Développement et résultats
vérification
Les risques majeurs du développement des logiciels ciblés par ces modèles
sont principalement :
 La défaillance du personnel,
 Les calendriers et budgets irréalistes,
 Le développement d’interfaces d’utilisateur inappropriées,
 La volatilité des besoins,
 Le manque des composants externes,
 Les exigences demeurées par rapport à la technologie,
 Les problèmes de performance, …
C4 Modèles par incrément

Dans tous les modèles procèdent, un logiciel est, au fil des étapes,
décomposés en composants plus ou moins élémentaires qui sont développés
séparément et intégrés à la fin du processus.
Dans les modèles par incrément, un seul ensemble de composants est

développé à la fois, et des INCREMENTS viennent s’intégrer à un noyau de logiciel
développé ou formé au préalable. Chaque composant est développé selon l’un des
procédés précédents.
Les avantages de ces modèles sont :

 Chaque développement est moins complexe (cfr. Réutilisable),
 Les intégrations sont progressives,
 Possibilité de mise en service après chaque incrément.
Les risques en sont :
 Mise en cause du noyau ou des incréments précédents,
 Impossibilité d’intégrer des nouveaux incréments, …

2019-2020
31
Pour diminuer les risques, les incréments doivent être aussi

indépendants que possible, fonctionnellement, mais aussi sur le plan du calendrier
de développement.
Ce modèle a été proposé à cause de certaines dérives bureaucratiques
de certains gros projets et à l’impossibilité de procéder de manière aussi linéaire
que celle présenté par le modèle en cascade et modèle en V.
Le produit est délivré en plusieurs fois de manière incrémentale en le
complétant au fur et à mesure sur base des incréments précédents.
Chaque incrément peut donner lieu à un cycle de vie classique plus ou
moins complet.
Les premiers incréments sont généralement des MAQUETTES
(jetables s’il s’agit juste de comprendre les besoins des utilisateurs) ou des
PROTOTYPES (réutilisables pour passer au prochain incrément en les complétant).
Ce modèle exige des spécialités de très haut niveau.
Il n’existe pas le modèle idéal, tout dépend des circonstances :
 Le modèle en cascade ou en V est risqué pour les développements innovants
car les spécifications et la conception risquent d’être inadéquates et
souvent remises en cause.
 Le modèle incrémental ne donne pas beaucoup de visibilité sur le processus
complet, …
Très souvent, un même projet mêle en son sein différentes approches
comme par exemple, le prototypage pour les sous-systèmes à haut risque et la
cascade pour les sous-systèmes bien connus et à faible risque.
D. TYPOLOGIE DES ERREURS D’UN PROJET INFORMATIQUE

A cause d’un ou plusieurs risques évoqués ci avant, un projet
informatique peut présenter les principes types d’erreurs suivants :
 Erreurs de spécification
 Erreurs de conception
 Erreurs de codage et
 Erreurs d’intégration.
En moyen, les coûts relatifs de ces erreurs dans un projet informatique

sont respectivement : 64%, 25%, 8%, 3%.
Les erreurs les plus chères sont celles de spécification. Il est vital
qu’une erreur de spécification soit découverte plus tard, dans la phase de
conception de codage ou d’intégration elles coûtent en moyenne respectivement
2,5 fois plus chères.

2019-2020
32
Le coût de correction des erreurs représente 50% du coût total de

développement et des maintenances des projets informatiques.
D.1. Erreurs d’intégration
Les erreurs d’intégration les plus courantes sont :
 Erreurs de séquencement d’activation des modules (les erreurs
modifient généralement la vision qui a été définie dans
l’architecture logicielle),
 Erreurs d’interfaçage physique (qui naissent souvent des
problèmes de paramétrage).
Il existe deux types d’intégration : intégration INCREMENTALE et
intégration NON INCREMENTALE.
Dans l’intégration non incrémentale, chaque module est testé et validé
indépendamment des autres modules, et un ensemble représentatif de
combinaison est ensuite identifié et généralement testé par une SIMULATION
des effets des modules souches au point d’activation du module à intégrer.
Dans le corps du module à intégrer, l’invocation des modules SOUCHES
sera simplement remplacée par des valeurs d’arguments.
Un module SOUCHE est un module qui est invoqué par le module à
intégrer.
L’invocation du module à intégrer par les modules conducteurs sera
simplement remplacée par les résultats de ce module à intégrer.
Dans l’intégration incrémentale chaque module est testé et validé en
combinaison avec tous les autres modules déjà testés et intégré et en commençant
l’intégration par le bas de la hiérarchie.
Exemple : soient les 6 modules suivants A, B, C, D, E, F.
B D
C
E F
En intégration NON INCREMENTALE on aura combien de tests
d’intégration :
Le module appelle
o Le module A a 3 souches
o Le module B a 1 souche
o Le module D a 1souche

2019-2020
33
Le module est appelé

o Le module B a 1 conducteur
o Le module C a 1 conducteur
o Le module D a 1 conducteur
o Le module E a 1 conducteur
o Le module F a 1 conducteur
Nous aurons 5 tests d’intégration
En intégration INCREMENTALE on aura combien de tests d’intégration
B (+E)
D (+F)
A (+C)
A (+B (+E))
A (+D (+F))
Si on ajoute aussi les tests individuels on aura 5 + 6 = 11 tests
D2 Erreurs de codage
Les erreurs de codage les plus courantes sont les erreurs de références
aux données, les erreurs de déclaration des données, les erreurs algorithmiques,
les erreurs d’input output et les erreurs d’interfaçage.

2019-2020
34
CHAPITRE IV : PRINCIPES DE GESTION D’UN

PROJET INFORMATIQUE
Le principe vital de tout projet informatique tourne autour des points
essentiels suivants :
 Fixation d’un référentiel,
 Evaluation de la réalisation, et
 Conduite des bilans.
a) Le référentiel
Le cadre de tout projet informatique est composé des
 Efficacités organisationnelles,
 Efficacités informationnelles,
 Efficacités techniques,
 Efficacités économiques.
b) L’évaluation de la réalisation
Cette évaluation devra être périodique pendant tout le cycle de
développement et doit :
 Evaluer ce qui a déjà été fait en mettant en exergue la qualité
de ce qui est réalisé,
 Déterminer ce qui reste à faire par une mise à jour éventuelle
du cahier des charges.
Le but essentiel de cette évaluation périodique est de consolider le
projet informatique.
c) L’établissement des bilans ou conduite des bilans

Il s’agit d’établir plusieurs taux de rendement en vue de dégager des
bilans (intermédiaires, d’exploitations ou de fin de réalisation) pour mieux mesurer
les écarts par rapport aux prévisions initiales et pour capitaliser les potentialités
pour le futur.
Les BILANS DE FIN DE REALISATION servent principalement à
préparer les modalités de transferts à la maîtrise d’ouvrage.
LES BILANS D’EXPLOITATION sont essentiellement des bilans de
vérification de Return On Investment (ROI).

2019-2020
35
TABLE DES MATIERES
PLAN DU COURS ................................................................................ II
BUT ET OBJECTIF DU COURS ............................................................ II
CHAPITRE Ier : NOTIONS DE PROJETS INFORMATIQUES .............. II
CHAPITRE II : CAHIER DES CHARGES ET ACTEURS D’UN PROJET .. II
BIBLIOGRAPHIE ................................................................................ II
BUT ET OBJECTIF DU COURS ........................................................... III
CHAPITRE I : NOTIONS DES PROJETS INFORMATIQUES ................ 1
I.1. Définition................................................................................... 1
I.2. Gestion des projets .................................................................... 3
I.2.1. Introduction ......................................................................... 3
I.2.2. Remarques ........................................................................... 5
I.2.3. Outils de pilotage du projet .................................................. 5
I.3. Gestion de configuration ........................................................... 10
A. Notion de gestion de configuration........................................... 10
B. Objectifs de gestion de configuration ...................................... 10
C. Processus de gestion de configuration ...................................... 11
I.4. AVANTAGES DE FONCTIONNEMENT PAR PROJET ................. 12
I.5. GARDE-FOUS DE FONCTIONNEMENT PAR PROJET ................ 13
CHAPITRE II : CAHIER DES CHARGES ET ACTEURS D’UN PROJET ... 15
II.1. Définition ............................................................................... 15
II.2. Différentes sortes des cahiers des charges ............................. 15
II.3. Appel d’offres et choix des fournisseurs .................................. 16
II.4. Organisation générale du cahier des charges ............................ 16
II.5. Contenu du cahier des charges................................................. 17

2019-2020
36
II.6. Acteurs d’un projet ................................................................ 21
CHAPITRE III : DETAILS TECHNIQUES D’UN PROJET
INFORMATIQUE ....................................................................................... 23
A. RISQUES D’UN PROJET INFORMATIQUE ............................. 23
B. ACTIONS DE LIMITATION DES RISQUES ........................... 25
C. MODELISATION DU CYCLE DE VIE D’UN PROJET
INFORMATIQUE.................................................................................... 26
C1 Modèles de la CASCADE ............................................................. 28
..................................................................................................... 29
C2 Modèles en V ............................................................................. 29
C3 Modèles en spirale ..................................................................... 30
C4 Modèles par incrément ............................................................... 31
CHAPITRE IV : PRINCIPES DE GESTION D’UN PROJET
INFORMATIQUE ....................................................................................... 35
TABLE DES MATIERES..................................................................... 36

2019-2020
37

Seminaire L2 Ig 2020

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

Seminaire L2 Ig 2020

Transféré par

Droits d'auteur :

Formats disponibles

Cours de Séminaire Informatiques

L2 Informatique de Gestion UPL

La réussite est liée à la patience mais elle dépend également de beaucoup

Le succès du projet se mesure, à la satisfaction du client et à la qualité du

Hilaire LUFULUABO KENDA

BUT ET OBJECTIF DU COURS

1. Didier HALLÉPÉE, « Conduite et maîtrise des projets informatiques »,

2. GEDIN M., « Méthodes de conduite des projets informatiques », éditions

3. Hubert TARDIEU, Arnold ROCHFELD, Réné COLLETTI, Georges PANET,

4. Véronique MESSAGER ROTA, « Gestion de projet vers les méthodes

Hilaire LUFULUABO KENDA

BUT ET OBJECTIF DU COURS

La réalisation d’un projet informatique peut se faire même

Cependant, dès que le projet dépasse une certaine ampleur, les

L’utilisation d’une méthode de conduite de projets permet de

Hilaire LUFULUABO KENDA

CHAPITRE I : NOTIONS DES PROJETS INFORMATIQUES

Un projet informatique est un ensemble des tâches indissociables qui

Tout projet informatique est centré essentiellement autour de la prise de

Un projet informatique implique :

Un projet est généralement subdivisé en phases, chacune d’entre elles

Le succès du projet se mesure, à la satisfaction du client et à la qualité du

Pour atteindre l’objectif, le chef de projet doit toutefois prendre en

Hilaire LUFULUABO KENDA

Coût = Ressource Calendrier = Temps

Les relations entre les acteurs impliqués dans un projet informatique

Pilote Comite de pilotage

Tout projet, et en particulier tout projet informatique, nécessite donc la

De cette équipe, devront sortir un animateur et un communicateur.

 le pont entre le système d’information et le système de pilotage

Hilaire LUFULUABO KENDA

Le pilote, appelé aussi maître d’ouvrage, est l’initiateur du projet, il compte

Le chef du projet, appelé aussi maître d’œuvre, est le personnage central

I.2. Gestion des projets

Un projet informatique nécessite essentiellement deux gestions :

2. Une gestion des projets qui offre un espace méthodologique qui

Les méthodes de gestion d’analyse sont indépendantes de l’environnement

Les raisons essentielles pour lesquelles un projet informatique (Gros projet

1. la gestion des contraintes principales telles que la qualité technique du

Hilaire LUFULUABO KENDA

final, … en réalisant le meilleur compromis entre ces diverses contraintes

2. la favorisation de l’atteinte des résultats attendus par l’optimisation de

Le but essentiel des structures pour la gestion de projet est de pouvoir

Schématiquement, les aspects de base d’un projet sont :

Ensemble des tâches qui sont identifiées par

Hilaire LUFULUABO KENDA

2. un jalon est en fait considéré comme un produit intermédiaire

I.2.3. Outils de pilotage du projet

a. Règles générales de management

La phase de préparation du projet concerne :

Hilaire LUFULUABO KENDA

3) Le collationnement de toutes les listes de tâches, ce collationnement

La phase de mise en œuvre du projet concerne :

La phase de bilan du projet concerne :

C’est généralement au chef de projet que revient l’initiative de convoquer :

b. 1. Réunions au sein de l’équipe du projet

Hilaire LUFULUABO KENDA

essentiel de mesurer l’état d’avancement des travaux et de décrire les problèmes

Les actions correctives retenues y sont signalées et seront évaluées lors

Les outils automatiques d’aide à la décision peuvent aider les gestionnaires

Hilaire LUFULUABO KENDA

Les différentes tâches considérées individuellement peuvent être

La liste de PRESEANCE est un outil de planification qui permet