Document - Kadidia - Version - Du - 06-Mars-2015 - Corrigu00e9 - Avec Recaptures - F

CONCEPTION ET RÉALISATION D’UNE PLATE-FORME DE SUIVI –
EVALUATION DE PROJETS
2014
DEDICACE
Je dédie ce travail :
 A la mémoire de mon père Amadou ALI BEIDI

Le souvenir de ta présence me comble d’un réconfort sans pareil. Puisse Dieu t’accueillir
dans son paradis éternel ;
 A ma mère Zeinabou HAROUNA SIDIKOU

En témoignage de ma reconnaissance pour ton soutien, tes sacrifices et l’attention dont
tu as toujours su faire preuve. Puisse DIEU, Le Tout Puissant t’accorder santé, longue vie
et bonheur ;
 A mes frères et sœurs

Salamatou, Halimatou, Ibrahim, Souleymane, Aïssatou AMADOU ALI
Pour les moments de joie et d’ambiance fraternelle que vous m’avez fait vivre. Je vous
dédie ce travail avec tous mes vœux de bonheur, de santé et de réussite ;
 Aux familles Ali Beidi, Mailelé et Harouna SIDIKOU

Veuillez trouver dans ce travail, l’expression de mon affection ;
 A mes amis Kwensy BLU, Edem ETOU, Thomas GBINU, Koffi SANI, Mariama MATA,
Nadira HAMIDOU, Diella LOUBAKI, Sidikou Asoumana
Je vous dédie ce travail pour l’amitié qui nous unit et les souvenirs que nous avons
partagés.
Par AMADOU ALI Kadidiatou Page i

2014
REMERCIEMENTS
Je remercie Dieu le Tout Puissant de nous avoir donné la santé et la volonté d’entamer et
de terminer ce mémoire.
Mes remerciements vont vivement :
 Au Dr. Souleymane KOUSSOUBE, Directeur Général de l’IAI ;

 Au Pr. Jérôme AVOM, Directeur des enseignements de l’IAI ;
 A mon maître de stage Mr Ghislain PODA responsable de GPO Consulting, pour m’avoir
accueilli dans sa structure;
 A mon superviseur, Dr. Ange NAMBILA pour le suivi du travail, ses remarques
pertinentes qui m’ont été d’un grand secours pour la réalisation de ce travail ;
 Au Pr. Ousmane Balira KONFE, enseignant chercheur à l’IAI, pour sa disponibilité, son
soutien et l’attention qu’il m’a accordé pendant mon stage ; Veuillez trouver ici
l’expression de mon grand respect et mes vifs remerciements.
 Au coordonnateur de filière Mr Djérabé Goldoum BENADJINGAR pour l’encadrement
des étudiants de la filière ingénieur ;
 A mon encadreur, Mr Ousseyni TIAMA Informaticien à GPO Consulting, pour la qualité
de son encadrement, les explications pertinentes et les conseils précieux qui ont eu un
grand impact dans la réussite de ce projet ;
 A mon oncle, le Pr Soumana HAMMA BEIDI pour son aide, son soutien et ses
encouragements. Veuillez accepter ce travail, en gage de mon grand respect et de ma
profonde reconnaissance ;
 Au Dr Roger NOUSSI, pour ses conseils;
 A Mr Maman MATY, un remerciement particulier et sincère pour avoir toujours été
présent pour nous. Ce travail est l’occasion pour nous de vous témoigner notre profonde
gratitude ;
 Mr Fleury MOUMBANGA pour sa disponibilité et ses encouragements ;
 Aux encadreurs et à l’administration de l’Institut Africain d’Informatique (IAI) ;
 Aux membres du jury pour avoir accepté d’évaluer ce travail ;
 A tous mes camarades de promotion pour leur sens de collaboration ;
 A tous ceux qui ont apporté leur concours, d’une manière ou d’une autre, dans la
réalisation de ce travail.
Par AMADOU ALI Kadidiatou Page ii

2014
AVANT-PROPOS
L’Institut Africain d'Informatique (IAI) est un établissement d’enseignement Supérieur

Inter Etats créé en 1971 et regroupant onze Etats africains. A la fin du cursus de formation des
ingénieurs de conception en informatique, il intègre un stage de formation pratique d’une
durée de cinq mois en entreprise ou en centre de recherche. Ce stage vise à mettre les élèves
ingénieurs dans un environnement professionnel ou dans un centre de recherche et de
développement afin de permettre une insertion dans un contexte professionnel.
Ce document représente l’aboutissement de trois années de formations à l’IAI à

Libreville au Gabon et cinq mois de stage pratique effectué pour l’entreprise GPO consulting. Ce
stage nous a permis d’une part de concilier les connaissances théoriques acquises et les réalités
du monde professionnel, et d’autre part d’appréhender les concepts généraux se rapportant au
suivi et à l’évaluation de projets.
Par AMADOU ALI Kadidiatou Page iii

2014
RESUME
Les entreprises prestataires ressentent, de plus en plus, la nécessité d’améliorer leur

productivité en matière de gestion de projets. Au fur et à mesure qu'elles se développent, elles
manifestent le besoin d’outils performants et efficaces leur permettant de prendre de bonnes
décisions pour orienter leur politique de gestion. Ces décisions prises en temps opportun
permettront d’atteindre les résultats escomptés. Plusieurs progiciels de gestion de projets
existent sur le marché mais, compte tenu de leur cherté dans certains cas ou de leur complexité
dans d’autres, de nombreuses entreprises éprouvent d’énormes difficultés dans le suivi et
l’évaluation de leurs projets et activités.
Ces constats ont amené GPO Consulting à se pencher sur un projet de mise en place
d’un logiciel de suivi-évaluation de projets. Il a été question au cours de ce stage de mettre en
place une plate-forme permettant d’effectuer une évaluation systématique et continue de la
progression temporelle d’un projet par la collecte et l’analyse de l’information. Cette solution à
fonctionnalités multiples intègre une gestion des profils utilisateurs et une gestion de
notifications relatives aux différentes activités menées dans le projet. Elle permet aussi au chef
de projet d’établir un tableau de bord des projets afin d’anticiper leur stratégie de gestion.
L’informatisation de cette gestion implique un changement profond dans les méthodes de
travail. Elle permettra de gagner du temps dans le traitement des opérations avec des résultats
probants.
Ainsi, pour parvenir à mettre en place cette plateforme, nous avons utilisé une méthode
orientée objet (le processus 2TUP (2 Track Unified Process) et le langage UML). Cette méthode
de travail nous a permis de réaliser, après une étape d'analyse et de conception, une plateforme
web couplée à une base de données MySQL.
Mots clés : projet, suivi, évaluation, activité.
Par AMADOU ALI Kadidiatou Page iv

2014
ABSTRACT
Providers businesses are feeling more and more, the need to improve their project
management related productivity. Gradually, as they grow, they show the need for efficient and
effective tools to make good decisions to guide their management policy. These decisions in a
timely manner will achieve the desired results. Several project management software packages
on the market, but due to their high cost in some cases or complexity in others, many companies
face enormous difficulties in monitoring and evaluation of their projects and activities.
These facts have led GPO Consulting to focus on the implementation of a project
monitoring and evaluation package. During this internship program, it has been discussed to
come up with a platform to conduct a systematic and continuous evaluation of the temporal
progression of a project by collecting and analyzing information. This multi-functional solution
integrates management of user profiles and management of notifications about various
activities in the project. It also provides the project manager a dashboard of all the projects in
order to anticipate their management strategy. The computerization of this management
involves deep changes in peoples’ working manners. It will help save processing time with
substantial results.
Thus, to achieve the implementation of this platform, we used an object-oriented

method (development process 2TUP (2 Track Unified Process) and UML). This method allowed
us to achieve, after an analysis and design stage, a web platform combined to a MySQL database.
Keywords : project, monitoring, evaluation, activity.
Par AMADOU ALI Kadidiatou Page v

2014
LISTE DES FIGURES
Figure 1 : Organigramme de GPO Consulting ........................................................................................... 4

Figure 2 : Feuille de saisie des intervenants sur le projet ........................................................................ 16
Figure 3 : Feuille de saisie des paramètres du projet ............................................................................... 17
Figure 4 : Ordonnancement des tâches du projet .................................................................................... 17
Figure 5 : Présentation du cycle de vie d’UP ............................................................................................ 22
Figure 6 : Le système d’information soumis à deux types de contraintes ............................................ 24
Figure 7 : Le processus de développement en Y ...................................................................................... 25
Figure 8 : Diagramme de contexte statique de la plate-forme ............................................................... 29
Figure 9 : Diagramme de cas d’utilisation de la solution........................................................................ 31
Figure 10 : Package initialisation du projet ............................................................................................... 32
Figure 11 : Package Supervision du projet ............................................................................................... 32
Figure 12 : Package Gestion système ......................................................................................................... 33
Figure 13 : Diagramme d’activité du cas d’utilisation créer un projet ................................................. 41
Figure 14 : Diagramme d’activité du cas d’utilisation créer une tâche ................................................ 41
Figure 15 : Diagramme de séquence système du cas d’utilisation créer un projet ........................... 42
Figure 16 : Diagramme de séquence système du cas d’utilisation créer une tâche............................. 43
Figure 17 : Diagramme de séquence système du cas d’utilisation créer une équipe .......................... 44
Figure 18 : Diagramme de séquence système du cas d’utilisation Enregistrer un participant ......... 44
Figure 19 : Diagramme de séquence système du cas d’utilisation consulter le tableau de bord ...... 45
Figure 20 : Diagramme de séquence système du cas d’utilisation afficher le rapport de performance
......................................................................................................................................................................... 45
Figure 21: Diagramme de classes du système .......................................................................................... 49
Figure 22 : Diagramme d’état-transition de la classe tâche .................................................................... 50
Figure 23 : Schémas de l'architecture à trois niveaux .............................................................................. 55
Figure 24: Architecture réseau de la plate-forme ..................................................................................... 58
Figure 25 : Interface de connexion à l'application .................................................................................... 58
Figure 26: Liste des projets gérés ................................................................................................................ 59
Figure 27 : Liste des participants d'une équipe ........................................................................................ 59
Figure 28 : Liste des participants d'un projet ............................................................................................ 60
Figure 29 : Listes des matériels d'un projet ............................................................................................... 60
Figure 30 : Etat : Liste des participants par organisation ........................................................................ 61
Figure 31 : Formulaire d'affectation de matériels à une tâche................................................................ 61
Figure 32 : Formulaire d'affectation de participants à une tâche ........................................................... 62
Figure 33: Diagramme de Gantt prévisionnel .......................................................................................... 65
Figure 34 : Diagramme de Gantt réel ......................................................................................................... 66
Par AMADOU ALI Kadidiatou Page vi

2014
LISTE DES TABLEAUX
Tableau 1: Différences et complémentarités entre le suivi et l'évaluation............................................ 12

Tableau 2: Récapitulatif des méthodes de développement .................................................................... 19
Tableau 3: Tableau récapitulatif des diagrammes UML ......................................................................... 27
Tableau 4 : Récapitulatif des cas d'utilisation ........................................................................................... 30
Tableau 5 : Classification des cas d'utilisation.......................................................................................... 34
Tableau 6 : Cas d’utilisation - Créer un projet .......................................................................................... 34
Tableau 7 : Cas d’utilisation - Créer une tâche ......................................................................................... 35
Tableau 8 : Cas d’utilisation – Créer une équipe...................................................................................... 36
Tableau 9 : Cas d’utilisation – Enregistrer un participant ...................................................................... 37
Tableau 10 : Cas d’utilisation - Clôturer un projet ................................................................................... 37
Tableau 11 : Cas d’utilisation – Consulter le tableau de bord ................................................................ 38
Tableau 12 : Cas d’utilisation – Afficher le rapport de performance .................................................... 39
Tableau 13 : Cas d’utilisation - Gérer les utilisateurs .............................................................................. 39
Tableau 14 : Cas d’utilisation - S’authentifier ........................................................................................... 40
Tableau 15 : Phase de création du projet ................................................................................................... 46
Tableau 16 : Phase d'initialisation du projet ............................................................................................. 46
Tableau 17 : Phase d'exécution du projet .................................................................................................. 46
Tableau 18 : Phase de Clôture du projet .................................................................................................... 47
Tableau 19 : Découpage des phases du projet en tâches ......................................................................... 64
Tableau 20 : Intervenants au projet ............................................................................................................ 65
Tableau 21 : Tableau récapitulatif des charges du projet ........................................................................ 66
Par AMADOU ALI Kadidiatou Page vii

2014
LISTE DES ABREVIATIONS
ACRONYMES SIGNIFICATIONS
2TUP Two Tracks Unified Process
CSS Cascade Style Sheet
FTP File Transfer Protocol
HTTP HyperText Transfer Protocol
IAI Institut Africain d’Informatique
IP Internet Protocol
MAC Media Access Control
PHP Hypertext Preprocessor
SGBD Système de Gestion de Bases de Données
SQL Structured Query Language
TCP Transmission Control Protocol
UML Unified Modeling Language
UP Unified Process
WAMP Windows Apache MySQL PHP
XML eXtensible Markup Language
Par AMADOU ALI Kadidiatou Page viii

2014
TABLE DES MATIERES

DEDICACE------------------------------------------------------------------------------------------------------------- i
REMERCIEMENTS -------------------------------------------------------------------------------------------------- ii
AVANT-PROPOS----------------------------------------------------------------------------------------------------iii
RESUME --------------------------------------------------------------------------------------------------------------- iv
ABSTRACT ------------------------------------------------------------------------------------------------------------ v
LISTE DES FIGURES ------------------------------------------------------------------------------------------------ vi
LISTE DES TABLEAUX ------------------------------------------------------------------------------------------- vii
LISTE DES ABREVIATIONS ------------------------------------------------------------------------------------ viii
TABLE DES MATIERES -------------------------------------------------------------------------------------------- ix
INTRODUCTION GENERALE------------------------------------------------------------------------------------ 1
PARTIE 1 : LE SUJET ET SES GENERALITES -------------------------------------------------------------------- 2
I- LA STRUCTURE D'ACCUEIL ET LE SUJET ------------------------------------------------------------- 3
1- PRESENTATION DE LA STRUCTURE D’ACCUEIL ----------------------------------------------- 3
2- LE SUJET ET SON CONTEXTE -------------------------------------------------------------------------- 5
3- PROBLEMATIQUE DU SUJET --------------------------------------------------------------------------- 5
4- INTERET DU SUJET ---------------------------------------------------------------------------------------- 5
II- CONCEPTS LIES AU DOMAINE--------------------------------------------------------------------------- 6
1- ETUDE DES CONCEPTS DE BASE --------------------------------------------------------------------- 6
a- LA NOTION DE SUIVI DE PROJET ----------------------------------------------------------------- 6
b- TYPES DE SUIVI ------------------------------------------------------------------------------------------ 7
c- LES INDICATEURS -------------------------------------------------------------------------------------- 9
2- LA NOTION D’EVALUATION DE PROJET ---------------------------------------------------------- 9
a- DEFINITION ----------------------------------------------------------------------------------------------- 9
b- LES CRITERES D’EVALUATION ------------------------------------------------------------------ 10
c- LE TYPE D'EVALUATION SUIVANT LA FINALITE ----------------------------------------- 11
3- DIFFERENCES ET COMPLEMENTARITES ENTRE LE SUIVI ET L'EVALUATION ----- 11
4- LE TABLEAU DE BORD --------------------------------------------------------------------------------- 12
PARTIE 2 : ANALYSE, CONCEPTION ET REALISATION ------------------------------------------------- 14
I- ETUDE PRELIMINAIRE ------------------------------------------------------------------------------------ 16
1- ETUDE DE L’EXISTANT--------------------------------------------------------------------------------- 16
2- CRITIQUE DE L’EXISTANT ---------------------------------------------------------------------------- 18
II- ETUDE DES METHODOLOGIES D’ANALYSE ET DE CONCEPTION------------------------- 18
Par AMADOU ALI Kadidiatou Page ix

2014
1- ETUDE DE LA METHODE ADOPTEE -------------------------------------------------------------- 19

a- CHOIX DE LA METHODE --------------------------------------------------------------------------- 19
b- DEFINITION D’UN PROCESSUS DE DEVELOPPEMENT ---------------------------------- 20
c- LE PROCESSUS 2TUP --------------------------------------------------------------------------------- 23
d- LE LANGAGE UML ----------------------------------------------------------------------------------- 26
2- CAPTURE DES BESOINS FONCTIONNELS ET TECHNIQUES------------------------------- 27
a- BESOINS FONCTIONNELS-------------------------------------------------------------------------- 27
b- BESOINS TECHNIQUES ------------------------------------------------------------------------------ 28
3- ANALYSE ET CONCEPTION -------------------------------------------------------------------------- 28
III- DESCRIPTION DES SPECIFICATIONS DE LA SOLUTION ------------------------------------ 28
1- IDENTIFICATION DES ACTEURS-------------------------------------------------------------------- 28
2- DIAGRAMME DE CONTEXTE STATIQUE --------------------------------------------------------- 29
3- IDENTIFICATION DES CAS D’UTILISATION ---------------------------------------------------- 29
IV- STRUCTURATION DES CAS D’UTILISATIONS -------------------------------------------------- 30
1- CLASSIFICATION DES CAS D’UTILISATION ---------------------------------------------------- 33
2- DESCRIPTION TEXTUELLE DES CAS D’UTILISATION PAR PACKAGE ----------------- 34
3- DIAGRAMMES D’ACTIVITE--------------------------------------------------------------------------- 41
4- DIAGRAMMES DE SEQUENCE SYSTEME --------------------------------------------------------- 41
V- CONCEPTION DU SYSTEME ----------------------------------------------------------------------------- 46
1- REPRESENTATIONS EVENEMENTIELLES DES ACTIVITES D’UN PROJET ------------- 46
2- REGLES DE GESTION ----------------------------------------------------------------------------------- 48
3- CONCEPTION DETAILLEE ---------------------------------------------------------------------------- 48
4- DIAGRAMME DE CLASSES DU SYSTEME -------------------------------------------------------- 48
5- DIAGRAMMES D’ETATS-TRANSITIONS ---------------------------------------------------------- 50
PARTIE III - REALISATION ET DEPLOIEMENT ------------------------------------------------------------- 51
VI- RESEAU INFORMATIQUE ----------------------------------------------------------------------------- 52
1- CONCEPTS RESEAUX ----------------------------------------------------------------------------------- 52
2- ARCHITECTURE CLIENT/SERVEUR --------------------------------------------------------------- 52
3- CLIENTS LOURDS / CLIENTS LEGERS ------------------------------------------------------------ 54
4- SYNTHESE -------------------------------------------------------------------------------------------------- 55
VII- LES OUTILS UTILISES DANS LA REALISATION ------------------------------------------------ 56
1- OUTILS DE DEVELOPPEMENT ----------------------------------------------------------------------- 56
2- OUTILS DE MODELISATION -------------------------------------------------------------------------- 56
Par AMADOU ALI Kadidiatou Page x

2014
3- BIBLIOTHEQUES LOGICIELLES ---------------------------------------------------------------------- 57

4- DEPLOIEMENT DE LA PLATEFORME WEB ------------------------------------------------------ 57
5- CAPTURES D’ECRAN ----------------------------------------------------------------------------------- 58
PARTIE 3 : GESTION DE PROJET --------------------------------------------------------------------------------- 63
I- CONDUITE DE PROJET ------------------------------------------------------------------------------------ 64
1- ADMINISTRATION DU PROJET ---------------------------------------------------------------------- 64
a- DECOUPAGE DU PROJET --------------------------------------------------------------------------- 64
b- INTERVENANTS AU PROJET ---------------------------------------------------------------------- 64
c- DIAGRAMME DE GANTT --------------------------------------------------------------------------- 65
d- COUT MATERIEL DU PROJET --------------------------------------------------------------------- 66
2- APPORTS, DIFFICULTES ET PERSPECTIVES DU PROJET------------------------------------- 66
a- APPORTS ------------------------------------------------------------------------------------------------- 66
b- DIFFICULTES RENCONTREES --------------------------------------------------------------------- 67
c- PERSPECTIVES ----------------------------------------------------------------------------------------- 67
CONCLUSION GENERALE ------------------------------------------------------------------------------------- 69
BIBLIOGRAPHIE --------------------------------------------------------------------------------------------------- 70
ANNEXE ---------------------------------------------------------------------------------------------------------------- 71
ANNEXE 1 : DICTIONNAIRE DE DONNEES ----------------------------------------------------------- 72
Par AMADOU ALI Kadidiatou Page xi

2014
INTRODUCTION GENERALE
La rentabilité des projets est devenue, au fil du temps, une des préoccupations majeures
des organisations. Le caractère critique du respect des délais d’achèvement d’un projet s'est
accrue, on s'est alors rendu compte de l’importance d’un outil d’accroissement de la rentabilité,
non seulement pour un projet en cours de réalisation, mais aussi futur. C'est ainsi que dans la
majorité des organisations, les chercheurs se sont attelés à identifier les méthodes et outils qui
pouvaient permettre le suivi et l’évaluation d’un projet afin de contribuer efficacement à
l'atteinte de résultats.
Conçu durant la phase de planification, en même temps que la conception du projet, le

suivi et l’évaluation sont utilisés de manière continue durant toute la phase de mise en œuvre
du projet. On entend par la planification, le processus permettant de définir les objectifs,
d’élaborer les stratégies, de tracer les grandes lignes des dispositions de mise en œuvre et
d’attribuer les ressources nécessaires à la réalisation de ces objectifs.
Pour les institutions en général et celles en particulier des pays en voie de

développement, le suivi et l’évaluation de projets recèlent un potentiel de développement qui
commence à s’esquisser et des opportunités qu’il serait judicieux de saisir.
C’est dans cette optique que GPO consulting, une entreprise spécialisée dans le conseil
et la formation nous a accueilli et nous a confié la tâche consistant à mettre en œuvre une plate-
forme efficiente facilitant le suivi et l’évaluation de projets.
L'intérêt de cette étude réside dans le fait qu'elle permet d'analyser le fonctionnement
d’un système de suivi-évaluation, d'en appréhender les faiblesses pour enfin proposer des
mesures correctives afin d'assurer le plein exercice de son usage au sein de GPO.
Pour mener à bien la présentation du travail, nous l’avons scindée en trois (3) grandes
parties :
 La première partie est consacrée au sujet et à ses généralités. Nous y présenterons la

structure qui nous a accueillis pour cinq mois de stage, le sujet, ses contours et les
concepts liés au domaine d’étude.
 La deuxième partie abordera l’analyse, la conception et la réalisation du système, ainsi
que la mise en œuvre de la solution.
 La troisième partie traitera de la conduite, la planification et l’estimation globale de
notre projet.
Par AMADOU ALI Kadidiatou Page 1

2014
PARTIE 1 : LE SUJET ET SES

GENERALITES

2014
Nous présentons d’abord au premier chapitre de cette partie, l’entreprise au sein de laquelle
nous avons effectué notre stage de fin de cycle, ensuite le sujet dans son contexte, ainsi que la
problématique. Par la suite, nous mettons l’accent sur l’intérêt de cette étude.
Le second chapitre sera, quant à lui, consacré à l’exploration des différents concepts liés à notre
domaine d’étude.
I- LA STRUCTURE D'ACCUEIL ET LE SUJET
1- PRESENTATION DE LA STRUCTURE D’ACCUEIL

GPO Consulting est une entreprise spécialisée dans la formation, le conseil en
fiscalité et en comptabilité. Ses principaux axes de prestations sont :
 L’assistance aux PME et PMI

 Assistance comptable : mise en place et suivi d’un système comptable ; élaboration
des situations périodiques et des ECF (Etats Comptables et Financiers) en fin
d’exercice comptable.
 Assistance administrative : facilitation des relations avec les services administratifs
extérieurs ; aide à la compréhension et l’application de la législation sociale à la
gestion du personnel.
 Assistance fiscale : conseils et déclaration fiscaux.
 Le contrôle de Gestion
 Contrôle budgétaire : analyse, détermination et recherche des causes des écarts entre
les prévisions et la réalité.
 Analyse de gestion : appréciation de la qualité de la gestion financière et économique.
 Etude de faisabilité de projet

 Choix des investissements
 Etude de rentabilité de projets et détermination des besoins en fonds de roulement.
GPO Consulting offre également des formations orientées gestion et comptabilité d’entreprise
notamment en :
o Organisation et gestion des stocks ;

o Gestion des immobilisations ;
o Contrôle de gestion ;
o Organisation et mise en place de comptabilité ;
o Initiation et perfectionnement à l’utilisation de logiciels de gestion comptable.

2014
L’organigramme de GPO Consulting se présente comme suit (voir Figure 1). Ce travail a été
effectué pour le compte du pôle Technique et Développement.
GERANT
ASSISTANTE DU
GERANT
POLE FORMATION POLE TECHNIQUE ET

POLE CONSEILS
DEVELOPPEMENT
Consultant Consultant Consultant

Consultant Fiscalité
Comptabilité Contrôle de Externalisation Paie
Gestion
Figure 1 : Organigramme de GPO Consulting

2014
2- LE SUJET ET SON CONTEXTE
Le suivi-évaluation est une discipline récente qui gagne continuellement en importance

dans la gestion des projets. C’est un système d'information et un outil d'aide à la décision
constitué d'intervenants, de données dont la production, l'organisation et la circulation sont
régies par des procédures et s'inscrivent dans le processus de gestion des projets. On s’est alors
rendu compte qu’il pouvait augmenter, de manière significative, le pourcentage d’achèvement
des projets, éclairer les responsables de projets dans leur prise de décision et les aider à
améliorer leur rendement.
Fort de ce constat, de nombreuses entreprises sont à la quête d’outils leur permettant de

prendre en charge les besoins en gestion de projets mais, rencontrent d’énormes difficultés
liées au coût élevé des applications. A cela s'ajoutent la non-mobilité dans le traitement des
données pour certains logiciels qui exigent une installation multiposte et un défaut de fiabilité
des données dû au traitement manuel des informations. Ces difficultés inhérentes à tout
système de suivi évaluation non automatisé mettent en exergue la nécessité de la mise en place
d'un système opérationnel et efficace de gestion, de partage et de stockage des informations.
C’est dans ce cadre que GPO Consulting nous a attribué le sujet intitulé : «Conception et
réalisation d’une plate-forme de suivi-évaluation de projets ».
3- PROBLEMATIQUE DU SUJET
Pour mettre en place une application de suivi-évaluation de projet, une activité menée dans
le domaine précis de la gestion de projets, il est indispensable de bien comprendre quelles sont
ses principales fonctions, les besoins en matière d’informations et déceler la problématique
soulevée par ladite activité.
C’est dans cette lancée que les questions ci-dessous ont été élaborées afin de mieux éclairer
la compréhension de la question principale de notre étude.
 Comment mettre en place un système de suivi évaluation permettant de répondre aux

critères de pertinence et de bonne qualité ?
 Quelles informations mettre à la disposition des intervenants sur le système ?
 Comment retracer toutes les activités menées sur les projets gérés ?
 Comment évaluer la performance de chaque intervenant sur le système ?
 Quelle méthodologie adopter pour mener à bien notre travail ?
4- INTERET DU SUJET
L’intérêt de notre étude est de produire une application informatique permettant :

 De recueillir des données sur l’état d’avancement d’un projet ;
 D’identifier les indicateurs importants pour évaluer les résultats;

2014
 De mieux contrôler l’affectation des ressources au projet;

 D’améliorer l‘objectivité des résultats du suivi-évaluation ;
 De contrôler l’intervention des participants sur les activités du projet.
II- CONCEPTS LIES AU DOMAINE
Ce chapitre comporte trois sections : la première présente les concepts liés au sujet en
insistant sur les théories du suivi et la seconde met un accent sur l'évaluation. La troisième
section porte sur la complémentarité entre le suivi et l'évaluation de projets.
1- ETUDE DES CONCEPTS DE BASE

Bien que les termes « suivi et évaluation » tendent à être utilisés ensemble, comme s’il ne
s’agissait que d’une seule et même chose, le suivi et l’évaluation sont en fait deux séries bien
distinctes d’activités organisationnelles, reliées, mais non identiques.
a- LA NOTION DE SUIVI DE PROJET
DEFINITION
Dans tous les domaines de l'activité humaine, le suivi s'impose au quotidien plus
particulièrement au sein de l'organisation. Il ne suffit pas de monter et exécuter un projet ou
encore de prendre une décision pour être sûr du résultat escompté. Pour mieux comprendre la
notion de suivi en management, plusieurs auteurs ont essayé de lui donner une définition.
 La Banque Mondiale (2008) (1) définit le suivi comme étant « un processus continu
de collecte et d'analyse d'informations, pour apprécier comment un projet est mis en
œuvre, en comparant les résultats obtenus aux performances attendues. »
 Pour Verrière (2002) (2) « le suivi est une activité continue de collecte et de
traitement d'informations. Il s'agit d'un processus interne à l'exécution d'une action.
Le suivi est une démarche de gestion et de connaissance approfondie, évolutive et
critique de l'action en cours de réalisation ».
 Pour le PNUD (2008) (3) , « le suivi est un processus itératif de collecte et d'analyse
d'informations pour mesurer les progrès d'un projet au regard des résultats
attendus. Il fournit donc aux gestionnaires un retour d'informations régulier qui peut
aider à déterminer si l'avancement du projet est conforme à la programmation ».

2014
ROLES ET OBJECTIFS DU SUIVI
Pour comprendre le rôle du suivi dans un projet, il convient de se pencher sur ses
objectifs, ses actions, ses résultats et ses acteurs. Le rôle du suivi est en fait d'assurer un contrôle
continu et systématique des activités et des résultats du projet par la surveillance, la
vérification et la maîtrise du processus de mise en œuvre. En effet, il s'agit de vérifier si les
ressources humaines, matérielles et financières mises en place sont bien définies, administrées
et judicieusement utilisées. Dans ce contexte, l'objectif principal du suivi est de constater les
anomalies et d’attirer l'attention des décideurs du projet lorsqu'il y a déviation ou dérapage par
rapport aux buts initiaux et aux incidences désirées, afin qu'ils puissent apporter des solutions
pour un nécessaire réajustement.
b- TYPES DE SUIVI
Il existe plusieurs types de suivi en management de projets mais, leur regroupement fait
ressortir deux grandes catégories à savoir : le suivi des réalisations et le suivi du déroulement.
Le suivi des réalisations
Le suivi des réalisations consiste à vérifier dans quelle mesure les ressources du projet sont
employées en se référant au budget alloué et au calendrier prévu. Il vise également à savoir si
les résultats sont obtenus dans les délais et s'ils tiennent compte de l'efficacité et de l'efficience
dans la gestion. Ce type de suivi cherche également à identifier les problèmes et à les corriger
immédiatement. Le suivi des réalisations est lui-même subdivisé en trois catégories à savoir :
le suivi des délais, des coûts et des aspects physiques (4).
Le suivi des délais
Le suivi des délais consiste à veiller à ce que l'ensemble des activités du projet soient
réalisées à temps, dans les délais impartis et selon le calendrier prévu. Son objectif principal est
de mesurer les écarts (lorsqu'ils se produisent) entre les délais réels et ceux planifiés, d'essayer
d'y apporter des explications, aussi bien sur les causes que sur les conséquences que cela
pourrait avoir sur le début et l'achèvement des autres activités.
Le suivi des coûts
Le suivi des coûts sert à vérifier si l'exécution des activités du projet est réalisée en suivant
la ligne budgétaire qui avait été prévue. Il permet de comparer, tout au long de l'exécution du
projet, les coûts effectifs avec les coûts prévus et relever les écarts à l'attention des décideurs,
expliquer les causes et proposer des mesures correctives pour éviter ainsi tout dérapage de
coûts (5).
Le suivi des aspects physiques
Pour ce qui est du suivi des aspects physiques, il s'occupe de l'état d'avancement des
réalisations physiques du projet. Il couvre trois aspects essentiels à savoir : le suivi des

2014
ressources, le suivi de la conformité physique des réalisations (4) et le suivi des

approvisionnements.
Le suivi des ressources
Le suivi des ressources concerne l'élaboration et le suivi des procédures de mise en œuvre
qui utilisent de façon optimale les ressources disponibles. Son rôle principal est de surveiller le
planning d'utilisation des ressources, de dénoncer le cas échéant et à temps, toutes les
déviances et les erreurs de gestion constatées par comparaison au planning initial.
Le suivi de la conformité physique des réalisations
Le suivi de la conformité physique des réalisations cherche à vérifier et s'assurer que

l'exécution du projet s'effectue suivant les règles de l'art, tout en respectant scrupuleusement
ce qui avait été prévu dans le cahier de charges, en conformité avec les normes de qualité.
Le suivi des approvisionnements
Le suivi des approvisionnements permet de vérifier que tous les intrants nécessaires à la
réalisation sont fournis et mis à la disposition du projet en quantité suffisante, en qualité et
suivant le niveau de coûts prévu.
L'efficacité et la crédibilité du suivi des réalisations dépendent de la fiabilité et de la

pertinence des informations fournies par le système d'information mis en place dans le cadre
du projet ; cela dépend également de la pertinence des indicateurs choisis. Ce problème de
crédibilité se pose avec une plus grande acuité lorsque le processus de traitement de
l'information est manuel.
Le suivi des coûts pose le problème de la pertinence des prévisions budgétaires. Certains
auteurs demandent de s'appuyer sur les projets similaires qui ont été réalisés dans le passé
pour estimer les réalisations à venir, d'autres par contre pensent qu'il faudrait s'appuyer sur la
situation présente pour pouvoir évaluer les coûts à venir.
Si le suivi des réalisations donne la possibilité au manager de projet de s'assurer que les
délais des activités sont respectés, les coûts sont maîtrisés et les aspects physiques sont bien
gérés, il ne permet pas d'avoir une visibilité sur le déroulement, avec une analyse critique des
outils et méthodes utilisés, ainsi que de la fiabilité et de la pertinence de l'information obtenue.
Il est donc nécessaire d'envisager la mise en place d'un système de suivi du déroulement du
projet.
Le suivi du déroulement
Le suivi du déroulement permet d'examiner et de vérifier le degré d'efficacité des méthodes

et outils utilisés dans le suivi de la réalisation du projet. En effet, pour assurer un bon suivi, il
faut que les méthodes et outils utilisés permettent de collecter et de générer une information
pertinente, capable d'éclairer les décideurs dans leur processus de prise de décision.

2014
Le suivi du déroulement étudie également l'attitude des bénéficiaires tout au long du projet,
ainsi que la qualité du produit ou du service fourni. Il est aussi question de voir comment
l'environnement externe affecte la mise en œuvre normale du projet.
c- LES INDICATEURS
Les indicateurs de suivi sont un moyen d'apprécier les divers aspects d'un projet,
programme ou stratégie de développement : ressources, processus, produits, résultats et
impacts. Ils permettent aux gestionnaires de projets de suivre l'état d'évolution de l'action
entreprise, d'en déterminer les résultats, de les apprécier et d'apporter les mesures correctives.
D'après le programme de l'auto apprentissage du suivi-évaluation de la Banque mondiale
(2008) (1), il est important d'associer les principales parties prenantes à la définition des
indicateurs, car il y aura ainsi plus de chance que celles-ci sachent les comprendre et les utiliser
pour la prise de décision. Ceci étant, les indicateurs de suivi doivent être précisés dès l'origine
du projet. En effet, ils facilitent la mise en œuvre et l'efficacité par un renforcement continu des
capacités de gestion.
2- LA NOTION D’EVALUATION DE PROJET
a- DEFINITION
Il existe plusieurs définitions de l'évaluation, cela traduit la réalité d’une grande

diversité de démarches d’évaluation. L'évaluation a un sens assez large. Elle englobe les
examens périodiques auxquels procède l'équipe de direction, tout comme des interventions à
appellation précise effectuées à des dates fixes, comme l'évaluation à mi-parcours, l'évaluation
terminale et l'évaluation rétrospective. (6)
Par contre, la Banque mondiale (2008) (1) définit l'évaluation comme étant « une
mesure, aussi systématique et objective que possible, des résultats d'un projet, d'un
programme ou d'une politique en vue de déterminer sa pertinence et sa cohérence, l'efficience
de sa mise en œuvre, son efficacité et son impact, ainsi que la pérennité des effets obtenus ».
Enfin pour Neu D. (2001) (7), « évaluer, c'est apprécier la qualité pour faciliter la prise
de décision ».
Ces trois définitions prises individuellement restent incomplètes mais ensemble, elles
traduisent, avec une plus grande fidélité, la réalité de l'évaluation dans sa pratique et sa finalité.

2014
b- LES CRITERES D’EVALUATION
Le but d’une évaluation est d’analyser les effets d’un projet et de porter un jugement. Ce
jugement s’articule autour de six critères différents qui sont :
 Pertinence : concerne la relation entre les enjeux, les objectifs ou les besoins constatés,
les objectifs choisis pour y répondre et la mesure dans laquelle ces derniers présentent
un plus par rapport à l’existant ;
 Cohérence : s'interroge sur la stratégie et les méthodes (les moyens, activités, résultats
attendus vont-ils permettre d'atteindre les objectifs visés ? Sont-ils cohérents les uns
avec les autres ? Sont-ils adaptés au contexte du projet ?) ;
 Efficacité : c’est le degré de réalisation des objectifs d’un projet. L’efficacité s’apprécie
par comparaison entre résultats obtenus (produits, effets directs, impact) et résultats
attendus, tant du point de vue quantitatif que qualitatif ;
 Efficience : c’est le rapport entre les résultats obtenus et les moyens mis en œuvre
(financiers, humains, temps, etc.) ;
 Viabilité (la durabilité) : s’attache aux effets à long terme du projet, et à la pérennité de
ses résultats et de ses effets. L'analyse de la viabilité consiste à apprécier la capacité des
actions à se poursuivre de manière autonome; on apprécie ici leurs chances de survie
lorsque les appuis extérieurs auront cessé ;
 La mesure de l'impact est celle des effets directs, indirects et induits des résultats du
projet. L’évaluation de l’impact a pour objectifs de vérifier la présence des effets induits
par le projet sur les bénéficiaires en termes de changement, de renforcement ou
d’amélioration par rapport à la situation initiale du projet.

2014
c- LE TYPE D'EVALUATION SUIVANT LA FINALITE
Suivant la finalité de l'évaluation on distingue deux types : l'évaluation formative et

l'évaluation sommative (8) .
L'évaluation formative
L'évaluation formative vise à améliorer le fonctionnement d'un projet. Cela dit, elle est
effectuée durant la mise en œuvre du projet et correspond à l'évaluation en cours ou à mi-
parcours. Cette évaluation associe acteurs et opérateurs, qui vont se former durant l'évaluation
pour ensuite orienter le cours du projet si nécessaire. Cependant, cette évaluation peut être
réalisée aussi bien par l'équipe de suivi évaluation interne au projet que par une équipe
d'évaluation externe. Lorsque l'évaluation est mise en œuvre par l'équipe de suivi-évaluation
interne au projet, les conclusions de l'étude courent le risque de ne pas avoir un point de vue
neutre ou d'être influencées par la direction du projet, ce qui pourrait biaiser la prise de
décision (4). Ce type d'évaluation reste limité car il ne permet pas d'avoir une lisibilité claire
des résultats et de l'impact du projet.
L'évaluation sommative
L'évaluation sommative vient couvrir les limites observées dans l'évaluation formative.
En effet, elle est effectuée pour évaluer les résultats des projets et programmes, ainsi que les
effets générés. Ceci étant, elle est réalisée juste après, ou alors bien après la fin du projet. Pour
une bonne conduite des projets de développement, les évaluations formatives et sommatives
restent complémentaires.
3- DIFFERENCES ET COMPLEMENTARITES ENTRE LE SUIVI ET

L'EVALUATION
Dans le management de projets, le suivi et l'évaluation sont deux concepts différents
mais complémentaires. L'évaluation ne peut être facilement et correctement réalisée que s’il y
a eu au préalable un suivi rigoureux. En effet, l'évaluation s'effectue en s'appuyant sur
l'exploitation des informations générées par les instruments mis en place par le système de
suivi du projet ainsi les résultats obtenus par le système d'évaluation auront une forte
corrélation avec ceux du système de suivi. Dans ce sens, le suivi est un outil au service de
l'évaluation interne (auto évaluation ou temps évaluatif programmé par les équipes lors de la
réalisation), mixte ou externe. (7).
Les différences entre le suivi et l'évaluation peuvent être observées au niveau des
objectifs, des principales activités et la fréquence de réalisation (8).
• Au niveau des objectifs, le suivi vise à améliorer l'efficience par la comparaison des
réalisations aux prévisions, la compréhension, la justification et le réajustement des écarts.
L'évaluation examine les relations qui existent entre les activités et les résultats, ce qui permet
de fournir les informations nécessaires à l'amélioration de l'efficacité du projet ;

2014
• Au niveau des activités, le suivi recueille régulièrement les informations nécessaires à la

compréhension de l'évolution du projet dans le sens de l'atteinte des objectifs ou non.
L'évaluation cherche systématiquement à mesurer les effets avec des méthodes rigoureuses;
• Au niveau de la fréquence, le suivi est une démarche continue qui s'effectue depuis le début
jusqu'à la fin du projet. Il met en œuvre un dispositif outillé qui permet la mesure continue des
différentes réalisations du projet et de fournir les informations nécessaires à la gestion
quotidienne. L'évaluation est intermittente et s'effectue à des moments bien précis de la vie du
projet, elle s'intéresse aux effets produits par le projet même après sa fin. Il s'agit d'un outil
d'aide à la décision qui permet d'avoir la photographie d'un projet ou de son impact à un
moment donné pour l'apprécier par comparaison à une référence.
Tableau 1: Différences et complémentarités entre le suivi et l'évaluation
SUIVI EVALUATION
Objectifs o Améliorer l'efficience, modifier le plan o Examiner les relations causales
ou l'affectation des ressources conduisant des activités aux
résultats, expliquer pourquoi
o Clarifier les objectifs et leur certains résultats attendus n'ont
transformation en indicateurs de pas été atteints
performance
o Examiner la mise en œuvre
o Comparer régulièrement les
réalisations o Fournir des renseignements,
améliorer l'efficacité, les effets de
o Communiquer les progrès aux l'impact de la future
responsables et les alerter sur les programmation
difficultés
Principales o Définition des indicateurs, recueil o Appréciation, mesure systématique
activités régulier d'informations, comparaison des effets, recherche des causalités
avec plan, comptes rendus par des méthodes rigoureuses
Fréquence o Périodique: journalier, hebdoma- o Episodique, à mi-parcours, à

daire, mensuel, trimestriel posteriori
4- LE TABLEAU DE BORD
Le tableau de bord est un document constitué d'un ensemble d'indicateurs qui permet au
gestionnaire du projet de surveiller, contrôler, voire maîtriser l'avancement du projet et les
aléas (9). Compte tenu de l'exhaustivité des informations nécessaires au suivi du projet et du
fait qu'il faut absolument les collecter, le tableau de bord du projet doit être un document
synthétique qui rassemble tous les tableaux de bord de suivi des différentes activités du projet.

2014
Chaque tableau de bord de suivi d'une activité doit contenir les différents types
d'informations et de prévisions concernant les échéances par action, les charges de travail par
intervenant, les dépenses budgétaires, l'état d'avancement général du projet et le portefeuille
de risque. Généralement, on distingue les tableaux de bord de suivi des consommations de
ressources et les tableaux bord de suivi des coûts. L'analyse des écarts significatifs et des causes
de ces écarts entraine des mesures correctives et la réactualisation des tableaux de suivi. Mais,
le véritable problème du tableau de bord reste le choix d’indicateurs. En effet, si l'indicateur
qui devrait aider à apprécier une situation est mal choisi, il est évident que les décisions prises
à la suite de l'analyse de cet indicateur ne donneront pas le résultat attendu.
Nous avons présenté dans cette partie, de façon globale et distincte, le contexte de notre
étude, ainsi que les concepts qui y sont liés. Dans la prochaine partie intitulée « Analyse,
conception et réalisation », il sera question pour nous de faire un état des lieux de notre étude
et de son fonctionnement en décrivant, de façon aussi claire que possible, l’analyse de
l’organisation du travail.

2014
PARTIE 2 : ANALYSE, CONCEPTION

ET REALISATION

2014
La réussite d'un projet informatique passe par un ensemble d'invariants et d'étapes

nécessaires à son cycle de vie. Il s’agit des phases d’analyse et de modélisation du problème
posé. L’analyse explique comment réaliser un cahier de charges décrivant précisément ce que
l’on attend comme solution. Elle permet de modéliser le domaine d'application, d'analyser
l'existant et les contraintes de réalisation. Elle s'effectue par une abstraction et une séparation
des problèmes. La modélisation, quant à elle, est une représentation abstraite, dans le sens où
les valeurs des données individuelles observées sont ignorées au profit de la structure, des
relations, des noms et des formats des données pertinentes, même si une liste de valeurs valides
est souvent enregistrée. Le modèle de données ne doit pas seulement définir la structure de
données, il doit aussi définir leur sémantique ; c’est un outil majeur de communication entre
les différents intervenants au sein d’un projet.
Ainsi, la solution à mettre en place va passer par ces différentes phases. Ces dernières
vont nous permettre de recenser les besoins fonctionnels et techniques, les interactions entre
le système et les utilisateurs, et enfin de présenter le tout sous forme de modèles.
Dans cette partie, nous ferons, dans un premier temps, une étude préliminaire qui va
consister à un choix de méthode d'analyse et de conception parmi celles existantes ; cette
méthode sera utilisée pour la mise en place de notre solution. Ensuite, nous passerons à la
partie analyse et conception, phase mettant en œuvre tout un ensemble d'activités qui va de la
détermination des besoins à la représentation de ces derniers sous formes de modèles; à l’issue
de cette partie, un modèle logique utilisable à la phase d'implémentation est produit. Enfin,
nous ferons une représentation de l’architecture de la solution à mettre en place.

2014
I- ETUDE PRELIMINAIRE
Nous présentons dans ce chapitre les différents points portant sur l’étude de l’existant ;
cette phase de l’étude permet de prendre connaissance, en détail, des objectifs poursuivis par
GPO pour l’amélioration de ses activités et plus particulièrement, celles concernant le domaine
de l’étude. Elle est en effet suivie d’une critique qui analyse les points positifs et négatifs de
l’organisation actuelle du travail et dégage les améliorations à apporter. Cette critique sera ainsi
une transition vers la suite du travail qui est l’analyse des besoins.
1- ETUDE DE L’EXISTANT
L’étude de l’existant est une phase importante pour bien comprendre le système actuel et
définir ses objectifs. L’application dont nous disposons actuellement est développée sous
Microsoft Excel.
 La structure ci-dessous est celle d’un tableau Excel utilisé par GPO pour la saisie des
ressources affectées au projet ; il contient comme information l’identifiant de la
ressource, l’initiale des nom et prénom, l’équipe (Tudor, Comite, Projet, Admi, Pedago)
et l’organisation (Tudor, IAI) à laquelle elle appartient.
Figure 2 : Feuille de saisie des intervenants sur le projet
 La feuille suivante définit les paramètres d'un projet. Elle comprend le nom du projet, la
date de début, la date de fin, la granularité (avec W=Weekend, M=Mois, Q=Trimestre (W
{6 jours}, M {30 jours}, Q {3 mois})), la taille de l'équipe du projet (nombre de ressources
humaines affectées au projet).

2014
Figure 3 : Feuille de saisie des paramètres du projet
 La Feuille 'WBS & Gantt' représente quant à elle le diagramme de Gantt et

l’ordonnancement du projet dans le temps. Il faut noter que le projet est découpé en
tâches dont la durée ne dépasse pas celle du projet. Les tâches sont constituées de sous-
tâches qui sont elles-mêmes des tâches en ce sens qu'elles peuvent se décliner en sous-
tâches dont la durée ne dépasse pas celle de la tâche parent.
Figure 4 : Ordonnancement des tâches du projet
 Les trois dernières feuilles 'Resource requirements', ‘Team requirements' et 'Org

requirements' définissent respectivement les efforts fournis par les ressources
(participants), les équipes et les organisations intervenantes sur le projet.

2014
2- CRITIQUE DE L’EXISTANT
L’étude de l’existant nous a permis de dégager un certain nombre de lacunes :
 L'outil Microsoft Excel n'est pas à même de jouer pleinement le rôle de système efficace
de gestion de bases de données;
 Excel n’est pas fait pour gérer les bases composées de plusieurs tables. En fait, on
pourrait y parvenir partiellement avec des procédures lourdes et complexes mais la base
de données deviendrait trop lourde;
 Absence de traçabilité des données : lorsque le système est utilisé par plus d'une
personne, que ce soit pour l'ajout ou la vérification des informations, cela peut
provoquer des erreurs et la confusion car il n'existe pas de système de contrôle des
utilisateurs ; de ce fait, il est difficile, voire impossible, de dire qui ajoute quoi et quand ;
 Manque d’intégrité référentielle : la suppression d’une fiche dans Excel ne donne à
aucune vérification de cohérence ;
 Courbe d’apprentissage abrupte : Microsoft Excel contient un grand nombre de
caractéristiques qui ne sont pas intuitifs pour les débutants et des fonctionnalités
avancées comme le contrôle d'erreur, le formatage des cellules et les macros qui
prennent du temps à maîtriser ;
 Compatibilité du système : Excel est uniquement disponible sur Windows et Mac OS X,
ce qui pose un problème pour les utilisateurs de Linux et d'autres systèmes
d'exploitation.
 Expérience utilisateur : l’utilisation du système sera difficile pour une personne qui n’a
pas de connaissance technique sur un tableur (Excel). Par exemple, il pourrait être
amené à effectuer des opérations requérant des connaissances techniques pour
produire des résultats ou à manipuler des données complexes qui devraient
logiquement être réparties en plusieurs catégories plutôt que stockées dans une seule
feuille;
 Il n'existe pas non plus d'interface permettant l'identification de l’utilisateur sur le
système ; donc le système n'est pas du tout sécurisé et n'importe qui peut accéder aux
informations.
II- ETUDE DES METHODOLOGIES D’ANALYSE ET DE

CONCEPTION
La complexité croissante des systèmes informatiques a conduit les concepteurs à
s’intéresser aux méthodes de développement. Ces dernières ont toujours essayé d’apporter un
contrôle continu sur un projet tout au long de son processus de vie. Elles se définissent comme
étant un ensemble de procédés permettant de choisir des outils et des techniques dans le but
de produire efficacement un produit ou un logiciel.
On distingue ainsi plusieurs méthodes de développement dont les méthodes

cartésiennes qui sont les toutes premières, créées suite aux problèmes de développement du

2014
logiciel appelé crise du logiciel. Ces méthodes préconisent qu’un problème soit décomposé en
sous problèmes en vue d’en maîtriser la complexité. Quand les bases de données sont apparues,
on s’est rendu compte que le produit n’est pas seulement une fonction mais aussi un système,
ce qui a amené à la création des méthodes systémiques traitant données et fonctions. Quelques
années plus tard, ces méthodes ne répondaient plus aux besoins des développeurs. On avait des
difficultés à appliquer les fonctions aux données, d’où l’apparition des méthodes orientées
objets qui se sont basées sur UML (Unified Modeling Language) et les processus unifiés. Avec
l’avènement du concept objet, de nouvelles méthodes sont apparues et différentes notations
ont été établies. UML a ouvert le terrain de l’unification en fusionnant ces notations et en
apportant précision et rigueur à la définition des concepts introduits. Sur cet élan, les
spécialistes ont aussi pensé à unifier, non pas les processus, mais plus exactement les
meilleures pratiques de développement orienté objet. On constate aujourd’hui, l’émergence de
nouvelles approches : les méthodes agiles et les méthodes formelles.
Les méthodes agiles sont des méthodes itératives à planification souple qui leur
permettent de s’adapter à la fois aux changements du contexte et de spécifications du projet.
Elles fonctionnent sur la base de l'itératif et de l’incrémental, les tâches vont s’effectuer petit à
petit, par ordre de priorité, avec des phases de contrôle et d’échange avec le client.
Les méthodes formelles, quant à elles, sont des techniques permettant de raisonner
rigoureusement, à l'aide de logique mathématique, sur des programmes informatiques ou du
matériel électronique, afin de démontrer leur validité par rapport à une certaine spécification.
Elles sont basées sur les sémantiques des programmes, c'est-à-dire sur des descriptions
mathématiques formelles du sens d'un programme donné par son code source.
Dans la suite du travail, il sera question pour nous de faire un choix de méthodes parmi
celles citées ci-dessus ; cette méthode sera utilisée pour la mise en place de la solution et
l’identification des possibilités du système, ainsi que les besoins des utilisateurs qui seront par
la suite représentés sous forme de modèles.
1- ETUDE DE LA METHODE ADOPTEE
a- CHOIX DE LA METHODE
Devant le nombre de méthodes disponibles, le choix devient difficile. Pour cela, il sera
judicieux de se baser sur les besoins du futur système en tenant compte d’un certain nombre
de critères qui nous semblent importants pour le développement de notre application. Ceux
que nous avons sélectionnés se présentent dans le tableau ci-après :
Tableau 2: Récapitulatif des méthodes de développement
Critères Méthodes
Cartésiennes Systémiques Objets Agiles Formelles
Gestion des risques    

2014
Itératif   
Incrémental   
Centré sur l’architecture du    
système
Axé sur le développement    
Outil de modélisation  
Orienté utilisateur  
Facilité de mise en œuvre    
Compte tenu de tous ces critères, notre choix s’est porté sur une méthode orientée-objet
utilisant le langage UML et le processus 2TUP. Nous préconisons en effet pour notre projet un
processus de développement bien défini qui va de la détermination des besoins fonctionnels
attendus du système jusqu’à la conception et le codage final. Ce processus se base lui-même sur
le Processus Unifié (Unified Process) qui est devenu un standard général réunissant les
meilleures pratiques de développement. Il exploite le langage UML, standard incontournable
de la modélisation objet, riche (il couvre toutes les phases d'un cycle de développement) et
ouvert (il est indépendant du domaine d'application et des langages d'implémentation).
UML est un langage qui permet de représenter des modèles, mais il ne définit pas de processus
d'élaboration de ces modèles. Cependant, dans le cadre de la modélisation d'une application
informatique, les auteurs d'UML préconisent d'utiliser une démarche :
 Itérative et incrémentale ;
 Guidée par les besoins des utilisateurs du système ;
 Centrée sur l'architecture logicielle.
D'après les auteurs d'UML, un processus de développement qui possède ces qualités favorise la
réussite d'un projet et ces qualités constituent les caractéristiques principales du Processus
Unifié(UP).
b- DEFINITION D’UN PROCESSUS DE DEVELOPPEMENT

Un processus définit une séquence d’étapes, en partie ordonnées, qui concourent à
l’obtention d’un système logiciel ou à l’évolution d’un système existant. L’objectif d’un
processus de développement est de produire des logiciels de qualité qui répondent aux besoins
de leurs utilisateurs dans des temps et des coûts prévisibles. (10)
LES PROCESSUS UNIFIES
Le processus unifié (PU ou UP en anglais pour Unified Process) est un processus de

développement logiciel qui regroupe les activités à mener pour transformer les besoins d’un
utilisateur en système logiciel.
Caractéristiques essentielles du processus unifié :

2014
 Le processus unifié utilise le langage UML (ensemble d'outils et de diagramme) :
Les processus unifiés regroupent un ensemble de bonnes pratiques adaptées à une

conception à l’aide du langage UML.
 Le processus unifié est piloté par les cas d’utilisation :
Le but principal d'un système informatique est de satisfaire les besoins du client. Le
processus de développement sera donc accès sur l'utilisateur.
Les cas d'utilisation permettent d'illustrer ces besoins. Ils détectent puis décrivent les besoins
fonctionnels (du point de vue de l'utilisateur), et leur ensemble constitue le modèle de cas
d'utilisation qui dicte les fonctionnalités complètes du système.
 Centré sur l’architecture :
L’architecture représente les aspects statiques et dynamiques du système. L'architecture

émerge des besoins de l'entreprise, tels qu'ils sont exprimés par les utilisateurs et reflétés par
les cas d'utilisation. L'architecture propose une vue d'ensemble de la conception faisant
ressortir les caractéristiques essentielles, en laissant de côté les détails secondaires. Il faut
noter que tout produit est à la fois forme et fonction. L'une ou l'autre, isolément, ne saurait
suffire. Les cas d'utilisation et l'architecture doivent s'équilibrer pour créer un produit réussi.
 Itératif et incrémental :
Vu que les projets à réaliser sont de plus en plus complexes et grands, l'idée est de découper
le travail en mini projets. Chacun d'entre eux représente une itération qui donne lieu à un
incrément. Les itérations désignent des étapes de l'enchaînement d'activités, tandis que les
incréments correspondent à des stades de développement du produit.
 Le processus unifié est piloté par les risques :
La nécessité de produire régulièrement des incréments conduit à contrôler les risques

d’inadéquation aux besoins des utilisateurs (risques fonctionnels) et les risques d’incapacité à
intégrer techniquement la solution (risques techniques).
LES PHASES DU PROCESSUS UNIFIE
Le processus unifié est organisé suivant quatre phases : création, élaboration, construction
et transition. Chaque phase répète un nombre de fois, une série d'itérations et chaque itération
est composée de cinq activités : capture des besoins, analyse, conception, implémentation et
test (comme le montre la figure ci-dessous) : (11)

2014
Figure 5 : Présentation du cycle de vie d’UP
 Création :
C'est la première phase du processus unifié. Il s'agit de délimiter la portée du système, c'est-
à-dire tracer ce qui doit figurer à l'intérieur du système et ce qui doit rester à l'extérieur,
identifier les acteurs, lever les ambiguïtés sur les besoins et les exigences nécessaires dans cette
phase. Il s'agit aussi d'établir une architecture candidate, c'est-à-dire que pour une première
phase, on doit essayer de construire une architecture capable de fonctionner. Dans cette phase,
il faut identifier les risques critiques susceptibles de faire obstacles au bon déroulement du
projet.
Elle répond aux questions suivantes :

 Que va faire le système ? Par rapport aux utilisateurs principaux, quels services va-t-il
rendre?
 Quels sont les risques ?
 Quels vont être : les délais, les coûts, les ressources, les moyens à déployer?
Le jalon qui marque la fin de la phase est « vision du projet»=document.

 Elaboration :
C'est la deuxième phase du processus. Après avoir compris le système, dégagé les
fonctionnalités initiales, précisé les risques critiques, le travail à accomplir maintenant consiste
à stabiliser l'architecture du système. Il s'agit alors de raffiner le modèle initial de cas
d'utilisation, voire capturer de nouveaux besoins, analyser et concevoir la majorité des cas
d'utilisation formulés, et si possible implémenter et tester les cas d'utilisation initiaux.
Les objectifs de la phase d'élaboration sont les suivantes:

 Spécifier les cas d’utilisation

2014
 Concevoir l’architecture de base (squelette du système)

 Mettre en œuvre cette architecture
 Faire une planification complète
Le jalon de fin de phase :
- l’architecture qui doit être prototypée pour être validée et donc adoptée
- Peut-on passer à la construction ?
o Besoins, architecture, planning stable ? Risques contrôlés ?
 Construction :
Dans cette phase, il faut essayer de capturer tous les besoins restants, car il n'est
pratiquement plus possible de le faire dans la prochaine phase. Ensuite, continuer l'analyse, la
conception et surtout l'implémentation de tous les cas d'utilisation. A la fin de cette phase, les
développeurs doivent fournir une version exécutable du système.
Les objectifs de la phase de construction sont:

 Développer le système complet
 S'assurer que le produit peut être utilisé par ses clients
Le résultat est le logiciel dans une version « utilisable » (première version bêta).
 Transition :
C'est la phase qui finalise le produit. Il s'agit, au cours de cette phase, de vérifier si le système
offre véritablement les services exigés par les utilisateurs, détecter les défaillances, combler les
manques dans la documentation du logiciel et adapter le produit à l'environnement (mise en
place et installation). Les objectifs de cette phase sont :
 Livrer/déployer le produit
 Corriger le reliquat d’erreurs
 Améliorer le produit
 Former les utilisateurs
Jalon : «Livraison du produit» = produit déployé chez le client
c- LE PROCESSUS 2TUP
2TUP signifie «2 Tracks Unified Process». C’est un processus qui répond aux
caractéristiques du Processus Unifié et s’appuie sur UML tout au long du cycle de
développement. Le processus 2TUP apporte une réponse aux contraintes de changement
continuel imposées aux systèmes d’information de l’entreprise. En ce sens, il renforce le
contrôle sur les capacités d’évolution et de correction de tels systèmes.

2014
« 2 Tracks » signifie littéralement que le processus suit deux chemins. Il s’agit des
chemins « fonctionnels » et « techniques » qui correspondent aux deux axes de changement
imposés au système d’information. Le processus 2TUP constate que toute évolution imposée
au système peut se décomposer et se traiter parallèlement, suivant un axe fonctionnel et un axe
technique. On peut donc étudier indépendamment les évolutions liées aux changements des
besoins fonctionnels et des besoins techniques.
Contraintes Contraintes
fonctionnelles techniques
Figure 6 : Le système d’information soumis à deux types de contraintes
A l'issue des évolutions du modèle fonctionnel et de l'architecture technique, la

réalisation du système consiste à fusionner les résultats des deux branches. Cette fusion conduit
à l'obtention d'un processus de développement en forme de Y, comme illustré par la figure ci-
dessous :

2014
Figure 7 : Le processus de développement en Y
La branche fonctionnelle : capitalise la connaissance du métier de l’entreprise. Elle constitue

généralement un investissement pour le moyen et le long terme. Les fonctions du système
d’information sont en effet indépendantes des technologies utilisées. Cette branche
comporte les étapes suivantes :
 La capture des besoins fonctionnels : produit un modèle des besoins focalisé sur le
métier des utilisateurs. Elle réduit le risque de produire un système inadapté aux
utilisateurs. De son côté, la maîtrise d’œuvre consolide les spécifications, en vérifie la
cohérence et l'exhaustivité ;
 L’analyse : consiste à étudier précisément la spécification fonctionnelle de manière à
obtenir une idée de ce que va réaliser le système en terme de métier. Les résultats de
l'analyse ne dépendent d'aucune technologie particulière.
La branche architecture technique : capitalise un savoir-faire technique. Elle constitue un

investissement pour le court et moyen terme. Les techniques développées pour le système

2014
peuvent être en effet indépendantes des fonctions à réaliser. Cette branche comporte les étapes
suivantes :
 La capture des besoins techniques : recense toutes les contraintes et les choix
dimensionnant la conception du système. Les outils et les matériels sélectionnés, ainsi
que la prise en compte de contraintes d'intégration avec l'existant, conditionnent
généralement des prérequis d'architecture technique ;
 La conception générique : définit ensuite les composants nécessaires à la construction

de l'architecture technique. Cette conception est complètement indépendante des
aspects fonctionnels. Elle a pour objectif d'uniformiser et de réutiliser les mêmes
mécanismes pour tout un système. L'architecture technique construit le squelette du
système informatique et écarte la plupart des risques de niveau technique. L'importance
de sa réussite est telle qu'il est conseillé de réaliser un prototype pour assurer sa validité.
La branche du milieu comprend :
 la conception préliminaire, qui représente une étape délicate, car elle intègre le
modèle d'analyse dans l'architecture technique de manière à tracer la cartographie des
composants du système à développer ;
 la conception détaillée, qui étudie ensuite comment réaliser chaque composant ;
 l'étape de codage, qui produit ces composants et teste au fur et à mesure les unités de
code réalisées ;
 l'étape de recette, qui consiste enfin à valider les fonctions du système développé.
L'ensemble de ces étapes de développement sera illustré dans la suite du travail par la
mise en application du processus 2TUP à notre projet d’étude.
d- LE LANGAGE UML
UML (Unified Modeling Language qui veut dire "langage de modélisation objet unifié") est né
de la fusion des trois méthodes qui ont le plus influencé la modélisation objet au milieu des
années 90 : OMT, Booch et OOSE. Issu "du terrain" et fruit d'un travail d'experts reconnus, UML
est le résultat d'un large consensus. C’est un langage d'analyse et de conception, indépendant
de tout processus de développement et s'adapte aux différents types de systèmes.
UML unifie les notations nécessaires aux différentes activités d’un processus de
développement et offre, par ce biais, le moyen d’établir le suivi des décisions prises, depuis la
définition des besoins jusqu’au codage. (10) Il comporte ainsi treize types de diagrammes
représentant autant de vues distinctes pour représenter des concepts particuliers du système
d’information. Ils se répartissent en deux grands groupes : Six diagrammes structurels ou
diagrammes statiques et Sept diagrammes comportementaux ou diagrammes
dynamiques représentés dans le tableau ci-dessous :

2014
Tableau 3: Tableau récapitulatif des diagrammes UML
Structurel Comportemental
Diagramme de classes : Il permet d’établir un Diagramme de cas d’utilisation : Les cas

schéma conceptuel de la partie statique du d’utilisation permettront de décrire les
système d’information en décrivant les classes fonctionnalités du système et leurs
et les associations entre classes et informations. interactions avec l’utilisateur.
Diagramme d’objets : représente les instances Diagramme de vue d’ensemble des

des classes et les relations qui existent entre interactions : Il fusionne les diagrammes
elles. d’activité et de séquence pour combiner des
fragments d’interaction avec des décisions et
des flots.
Diagramme de package : Il montre Diagramme de séquence : représente les

l’organisation logique du modèle et les relations échanges de messages entre objets, dans le
entre packages. cadre d’un fonctionnement particulier du
système.
Diagramme de structure composite : expose Diagramme de collaboration : C’est un
la structure interne d'une classe ainsi que les diagramme constituant une autre version d’un
collaborations que cette dernière rend possible. scénario décrit sous forme d’un diagramme de
séquence. Ce diagramme permettra de mettre
en évidence les échanges d’informations entre
les objets du système.
Diagramme de composants : décrit Diagramme de temps : Il fusionne les
l'architecture physique et statique d'une diagrammes d’états et de séquence pour
application en termes de modules. montrer l’évolution de l’état d’un objet au
cours du temps.
Diagramme de déploiement : est utilisé pour Diagramme d’activités : Il permettra de
représenter l’architecture physique d’un modéliser les aspects dynamiques du système
système. en donnant une représentation des différents
processus faisant intervenir les acteurs
concernés et manipulant les ressources
nécessaires.
Diagramme d’états-transitions : représente
le cycle de vie d’un objet. Il spécifie les états
possibles d’une classe et leur enchainement.
2- CAPTURE DES BESOINS FONCTIONNELS ET TECHNIQUES
a- BESOINS FONCTIONNELS
Pour mener à bien ce travail, nous avons effectué plusieurs recherches pour identifier au
mieux les besoins de l’application, ceci afin de répondre aux attentes des utilisateurs et définir
le cadre de notre système ; ce qui nous a permis de recenser les besoins préliminaires suivants:

2014
 Faciliter la gestion des projets en mettant en place un système de contrôle de cohérence

de données pour diminuer les risques d’erreur ;
 Faciliter la gestion des activités(ou tâches) du projet ;
 Vérifier l’accomplissement de toutes les tâches du projet avant la clôture du projet ;
 si un participant ne termine pas une tâche, lui faire parvenir des notifications jusqu’à ce
que la tâche soit totalement accomplie ;
 Etablir un rapport de performance pour chaque participant au projet ;
 Elaborer un tableau de bord pour le suivi des activités du projet.
b- BESOINS TECHNIQUES
Les besoins techniques représentent les exigences implicites auxquelles le système doit
répondre. Ces besoins sont entre autre :
 Le système doit être une application web;

 Faciliter la gestion des utilisateurs et le paramétrage du système ;
 Assurer une meilleure sécurité des données et leur transaction par les utilisateurs ;
 La recherche d’une information en temps réel ;
 Rapidité des mises à jour des indicateurs grâce à une interaction avec le logiciel ;
 Traiter des volumes de données de plus en plus grand ;
 Centralisation des données dans une base de données;
 Fiabilité des données.
3- ANALYSE ET CONCEPTION
L'objectif de l'analyse est de comprendre le cahier des charges et d’écrire les spécifications
internes. Elle permet d'obtenir une vue interne du système et se concentre sur le "quoi faire".
La conception, quant à elle, a pour but de définir l'architecture du système en se basant sur le
"comment le faire". Dans ce chapitre, il sera alors question pour nous de définir les objectifs de
notre application par la traduction des besoins fonctionnels, des contraintes issues du cahier
des charges et de la spécification des exigences sous forme de modèles UML.
III- DESCRIPTION DES SPECIFICATIONS DE LA SOLUTION

Après avoir décrit les deux sommets du processus 2TUP qui sont les besoins fonctionnels et
techniques du système, nous allons maintenant énumérer les acteurs susceptibles d’interagir
avec le système, et par la suite, élaborer les cas d’utilisation possible formant les points de
départ de l’analyse.
1- IDENTIFICATION DES ACTEURS

Un acteur est un rôle joué par une personne physique ou un autre système. Il représente un
type d’utilisateur. Dans le cadre de notre étude nous avons énuméré quatre acteurs qui sont :

2014
 Gestionnaire de projet : Il est chargé de la création du projet, de la définition de ses

paramètres et de celle des tâches, ainsi que de la constitution des équipes. C’est lui qui
s’occupe du suivi et de l’évaluation des activités du projet.
 Superviseur : Le superviseur établit un rapport de performance de chaque participant

au projet. Il participe à la gestion des tâches du projet, suit leurs évolutions et fait
l’inventaire des ressources utilisées pour l’accomplissement des activités.
 Participant : Il participe à la gestion d’une tâche.
 Administrateur : Il est chargé de la gestion des profils des utilisateurs du système, de

l’attribution des droits d’accès au système de gestion de base de données et la
sauvegarde des informations.
2- DIAGRAMME DE CONTEXTE STATIQUE

Le diagramme de contexte statique exprime le nombre d’instance d’acteurs reliés au système
à un moment donné.
Figure 8 : Diagramme de contexte statique de la plate-forme
3- IDENTIFICATION DES CAS D’UTILISATION
Les cas d’utilisation (Uses case) ont été introduits par Ivar Jacobson dans sa méthode OOSE.
Ils constituent une technique qui permet de déterminer les besoins de l’utilisateur et de
capturer les exigences fonctionnelles d’un système. En d’autres termes, ils décrivent le
comportement d’un système du point de vue de ses utilisateurs. Ils décrivent les interactions

2014
entre les utilisateurs d’un système et le système lui-même. Ci-dessous, la liste par acteur des
cas d’utilisation de notre système :
Tableau 4 : Récapitulatif des cas d'utilisation
Acteurs Cas d’utilisation

 Gérer un projet
- Créer un projet
- Modifier un projet
- Clôturer un projet
 Gérer une tâche

- Créer une tâche
- Modifier une tâche
- Supprimer une tâche
Gestionnaire  Gérer un participant

- Enregistrer un participant
- Modifier un participant
- Affecter un participant à une tâche
- Supprimer un participant
 Consulter le rapport de performance
 Gérer une équipe

- Créer une équipe
- Modifier une équipe
- Supprimer une équipe

 Consulter le rapport de performance
Superviseur  Consulter le tableau de bord

Participant  Modifier une tâche (état d’avancement de la tâche)
 Gérer les utilisateurs

Administrateur  Faire la maintenance du système
IV- STRUCTURATION DES CAS D’UTILISATIONS

Après avoir identifié les acteurs et les cas d’utilisation, il est utile de restructurer l’ensemble
des cas d’utilisation que l’on a fait apparaître afin de rechercher les comportements partagés,
les cas particuliers et les généralisations.
UML définit trois types de relations standardisées entre cas d’utilisation, détaillées ci-après :

2014
 une relation d’inclusion : ce lien nommé « utilise » (ou « include ») indique que le cas
d’utilisation source contient le comportement décrit dans le cas d’utilisation destination.
 une relation d’extension : ce lien indique que le cas d’utilisation source « étend » (ou «
extend ») ou précise le cas d’utilisation destination.
 Une relation de généralisation : les cas d’utilisation descendants héritent de la

description de leur parent commun. Chacun d’entre eux peut néanmoins comprendre
des relations spécifiques supplémentaires avec d’autres acteurs ou cas d’utilisation.
A partir des différents cas d’utilisation fonctionnels, nous obtenons le diagramme de cas
d’utilisation suivant :
Figure 9 : Diagramme de cas d’utilisation de la solution
Pour améliorer notre diagramme ci-dessus, nous allons organiser les cas d'utilisation et les
regrouper en ensembles fonctionnels cohérents. Pour ce faire, nous utilisons le concept général

2014
d'UML, le package. Le package est un mécanisme général de regroupement d'éléments en UML,

qui peut être utilisé par exemple pour regrouper des cas d'utilisation, mais aussi des acteurs ou
des classes.
Figure 10 : Package initialisation du projet
Figure 11 : Package Supervision du projet

2014
Figure 12 : Package Gestion système
1- CLASSIFICATION DES CAS D’UTILISATION
Le processus unifié encourage une planification itérative pilotée à la fois par les risques et
par l’utilisateur. Cela signifie que les objectifs des premières itérations sont choisis afin
d'identifier les risques les plus importants et de construire les fonctionnalités visibles qui
comptent le plus pour l’utilisateur.
Pour chaque itération, on choisira des cas d'utilisation présentant ces qualités :
De grande valeur pour l’utilisateur(les fonctionnalités qui comptent vraiment pour lui) ;
A haut risque (par exemple : gérer plusieurs requêtes concurrentes).
On demande donc de hiérarchiser les cas d'utilisation identifiés en tenant compte des facteurs
suivants et en distinguant trois niveaux (Haut, Moyen et Bas) :
La priorité fonctionnelle (à déterminer avec l’utilisateur) ;

Le risque technique (estimer par le concepteur).
Ceci est représenté dans le tableau ci-dessous :

2014
Tableau 5 : Classification des cas d'utilisation
Cas d’utilisation Priorité Risques Nombre

fonctionnelle techniques d’itérations
Créer projet Haute Bas 1
Créer tâche Haute Bas 1
Créer équipe Haute Bas 1
Enregistrer participant Haute Bas 1
Gérer XXX (Modifier, Supprimer,.....) Moyenne Haut 1
Clôturer projet Moyenne Bas 1
Consulter tableau de bord Haute Moyen 1
Afficher rapport de performance Moyenne Moyen 1
Gérer profils utilisateurs Haute Moyen 1
S’authentifier Haute Bas 1
2- DESCRIPTION TEXTUELLE DES CAS D’UTILISATION PAR

PACKAGE
Tous les cas d’utilisation intitulés « Gérer XXX » se résument aux actions d’ajout, de
modification et de suppression, avec des exceptions à gérer notamment dans les cas de
contraintes d’intégrités liées à la base de données. Dans cette partie, nous nous attarderons sur
les principaux cas d’utilisation.
Package Initialisation du projet
 Cas d’utilisation « Créer un projet »
Tableau 6 : Cas d’utilisation - Créer un projet

Sommaire d’identification
Titre : Créer un projet
Résumé : Il permet de créer un projet
Acteur : Gestionnaire
Date de création : 17/09/2014
Version : 1.0
Auteur : AMADOU ALI Kadidiatou
Description des enchainements

Préconditions
 Le gestionnaire doit avoir les droits d’accès au système
 Le système doit être fonctionnel
Scénarios nominaux

2014
1. Le gestionnaire définit les paramètres du projet (le nom du projet, la durée, le

montant, la date de début, la date de fin,...)
2. Le système vérifie les informations saisies et informe le gestionnaire (A1)
3. Le gestionnaire définit les équipes du projet et valide
4. Le système enregistre les informations et envoie une confirmation au gestionnaire
5. Le gestionnaire définit les tâches du projet et valide
6. Le système enregistre les données et confirme au gestionnaire
7. Le gestionnaire définit les ressources matérielles du projet et valide
8. Le système sauvegarde les informations et envoie une confirmation au gestionnaire
Scénario alternatif
A1. Le gestionnaire peut oublier de renseigner un ou plusieurs champ(s) obligatoire(s)
A1.1 Le système affiche un message demandant au gestionnaire de remplir les champs
obligatoires
A1.2 Le gestionnaire vérifie et renseigne les champs obligatoires
A1.3 On repart au point 2 du scénario nominal
 Post condition
 Le projet est créé avec tous ses paramètres
 Cas d’utilisation « Créer une tâche »
Tableau 7 : Cas d’utilisation - Créer une tâche

Titre : Créer une tâche
Résumé : Il permet de créer une tâche
Version : 1.0

Préconditions
Scénarios nominaux
1. Le système demande au gestionnaire de saisir les informations
2. Le gestionnaire saisit les informations relatives à une tâche (nom de la tâche, la
durée, le coût, la date de début, la date de fin, la description de la tâche,...) et valide
3. Le système vérifie si les informations saisies sont valides (A1)
4. Le système demande au gestionnaire d’affecter une liste de participants à une tâche
5. Le gestionnaire sélectionne une liste de participants
6. Le système sauvegarde la sélection
7. Le système demande au gestionnaire d’affecter les ressources matérielles à une
tâche
8. Le gestionnaire sélectionne les matériels

2014
9. Le système enregistre les choix et informe le gestionnaire

Scénario alternatif
A1 Le gestionnaire peut saisir des informations existantes
A1.1 Le système indique au gestionnaire que les informations saisies existent déjà
 Post condition
 Le nombre de tâches se trouvant dans le système augmente d’un (1)
 Cas d’utilisation « Créer une équipe »
Tableau 8 : Cas d’utilisation – Créer une équipe

Titre : Créer une équipe
Résumé : Il permet de créer une équipe
Version : 1.0

 Préconditions
 Scénarios nominaux
1. Le système affiche un message demandant au gestionnaire d’entrer les informations
2. Le gestionnaire saisit les informations relatives à une équipe (nom,...) et valide
3. Le système vérifie les informations saisies et les enregistre (A1)
4. Le système demande au gestionnaire d’affecter une tâche à une équipe
5. Le gestionnaire sélectionne une tâche de la liste des tâches et l’affecte à une équipe
6. Le système enregistre la sélection et informe le gestionnaire
7. Le système demande au gestionnaire d’affecter une liste de participants à une tâche
8. Le gestionnaire sélectionne une liste de participants et valide
9. Le système enregistre les données
 Scénario alternatif
A1 Le gestionnaire peut oublier de renseigner un ou plusieurs champ(s) obligatoire(s)
A1.1 Le système affiche un message demandant au gestionnaire de remplir les
champs obligatoires
 Post condition
 Le nombre d’équipes se trouvant dans le système augmente d’un (1)

2014
 Cas d’utilisation « Enregistrer un participant »
Tableau 9 : Cas d’utilisation – Enregistrer un participant

Titre : Enregistrer un participant
Résumé : Il permet d’enregistrer un participant
Version : 1.0

 Préconditions
1. Le système demande au gestionnaire de saisir les informations
2. Le gestionnaire saisit les informations relatives à un participant (nom, prénom,
fonction, adresse, ...) et valide
3. Le système vérifie les informations saisies et les enregistre (A1)
champs obligatoires
 Post condition
 Le nombre de participants se trouvant dans le système augmente d’un (1)
Package Supervision du projet
 Cas d’utilisation « Clôturer un projet »
Tableau 10 : Cas d’utilisation - Clôturer un projet

Titre : Clôturer un projet
Résumé : Il permet de clôturer un projet
Version : 1.0

2014
 Préconditions
1. Le système informe le gestionnaire que toutes les tâches du projet ont été exécutées
2. Le gestionnaire enregistre les informations nécessaires à la fermeture du projet et
valide
3. Le système sauvegarde les informations et envoie une confirmation au gestionnaire
 Post condition
 Le projet est clôturé
 Cas d’utilisation « Consulter le tableau de bord »
Tableau 11 : Cas d’utilisation – Consulter le tableau de bord

Titre : Consulter le tableau de bord
Résumé : Il permet de consulter un tableau de bord de l’évolution des tâches du projet
Acteur : Superviseur
Version : 1.0

 Préconditions
 Le superviseur doit avoir les droits d’accès au système
 Il doit exister au moins deux tâches effectuées dans le système
1. Le système demande au superviseur de fournir les paramètres
2. Le superviseur fournit les paramètres et valide (A1)
3. Le système affiche le tableau de bord correspondant aux paramètres fournis
A1 Le superviseur peut oublier de renseigner un ou plusieurs champ(s) obligatoire(s)
A1.1 Le système affiche un message demandant au superviseur de remplir les
champs obligatoires
A1.2 Le superviseur vérifie et renseigne les champs obligatoires

2014
 Cas d’utilisation « Afficher le rapport de performance »
Tableau 12 : Cas d’utilisation – Afficher le rapport de performance
Titre : Afficher le rapport de performance
Résumé : Il permet d’afficher le rapport de performance d’un participant
Acteurs : Gestionnaire, Superviseur
Version : 1.0

 Préconditions
 Le gestionnaire et le superviseur doivent avoir les droits d’accès au système
 Il doit exister au moins un participant ayant effectué une tâche
1. Le système demande à l’utilisateur de fournir les informations du participant pour
lequel on veut établir un rapport de performance
2. L’utilisateur fournit les informations (matricule, nom, prénom, adresse, ...) et valide
3. Le système vérifie les informations fournies et affiche le rapport correspondant
(A1)
champs obligatoires
Package Gestion système
 Cas d’utilisation « Gérer les utilisateurs »
Tableau 13 : Cas d’utilisation - Gérer les utilisateurs

Titre : Gérer les utilisateurs
Résumé : Il permet de créer, modifier, supprimer des utilisateurs, de voir les sessions en cours
et de consulter l'historique des connexions
Acteur : Administrateur
Version : 1.0

2014

 Précondition
1. Le système demande à l’administrateur l’action à effectuer « créer », « modifier »,
« supprimer », …
2. L’administrateur choisit une action et valide
3. Le système demande une confirmation de l'action choisie et effectue l'opération
 Cas d’utilisation ʺS’authentifierʺ
Tableau 14 : Cas d’utilisation - S’authentifier
Titre : S’authentifier
Résumé : Il permet à un utilisateur de se connecter au système
Acteurs : Administrateur, Superviseur, Gestionnaire, Participant
Version : 1.0

 Précondition
1. Le système demande à l'utilisateur d'entrer son nom d'utilisateur et son mot de
passe
2. L'utilisateur saisit son nom d'utilisateur, son mot de passe et valide (A1)
3. Le système vérifie le nom d'utilisateur ainsi que le mot de passe saisis et informe
l'utilisateur que la connexion a réussi
A1 L’utilisateur est inconnu ou le mot de passe est incorrect
A.1.1 Le système informe l’utilisateur que les informations saisies sont erronées
A.1.2 On repart au point 2 du scénario nominal
 Scénario d’exception
E1 L’utilisateur est inconnu ou le mot de passe est incorrect après plusieurs tentatives de
connexion
E1.1 Le système informe l’utilisateur que la procédure de connexion a échoué
E1.2 Echec du cas d’utilisation

2014
3- DIAGRAMMES D’ACTIVITE
Les diagrammes d’activité sont adaptés à la description des cas d’utilisation. Plus
précisément, ils viennent illustrer et consolider la description textuelle des cas d’utilisation.
Nous représentons sur les figures suivantes les diagrammes d’activité de quelques cas
d’utilisations vus précédemment.
Figure 13 : Diagramme d’activité du cas d’utilisation créer un projet
Figure 14 : Diagramme d’activité du cas d’utilisation créer une tâche
4- DIAGRAMMES DE SEQUENCE SYSTEME

Les cas d’utilisation décrivent les interactions des acteurs avec le système que nous voulons
spécifier et concevoir. Lors de ces interactions, les acteurs produisent des messages qui
affectent le système informatique et appellent généralement une réponse de celui-ci. Pour les
messages propres à un cas d’utilisation, les diagrammes de séquence système montrent non
seulement les acteurs externes qui interagissent directement avec le système, mais également
ce système (en tant que boîte noire) et les événements système déclenchés par les acteurs.
L’ordre chronologique se déroule vers le bas et l’ordre des messages doit suivre la séquence
décrite dans le cas d’utilisation.
Nous allons représenter le diagramme de séquence système d’un scénario représentatif de

chacun des cas d’utilisation décrits précédemment.

2014
Figure 15 : Diagramme de séquence système du cas d’utilisation créer un projet

2014
Figure 16 : Diagramme de séquence système du cas d’utilisation créer une tâche

2014
Figure 17 : Diagramme de séquence système du cas d’utilisation créer une équipe
Figure 18 : Diagramme de séquence système du cas d’utilisation Enregistrer un participant

2014
Figure 19 : Diagramme de séquence système du cas d’utilisation consulter le tableau de bord
Figure 20 : Diagramme de séquence système du cas d’utilisation afficher le rapport de

performance

2014
V- CONCEPTION DU SYSTEME
1- REPRESENTATIONS EVENEMENTIELLES DES ACTIVITES D’UN

PROJET
Première étape : CREATION DU PROJET
Tableau 15 : Phase de création du projet
Evènement : Création du projet

Déclencheur : Expression des besoins (Cahier de charges du projet)
 Définition des objectifs du projet (les livrables)
 Définition des paramètres du projet
o Intervenants
o Ressources matérielles/financières
Actions : o Temps d’exécution du projet (date début, date fin)
 Définition des tâches du projet (durée, livrables)

 Définition des indicateurs
Deuxième étape : INITIALISATION DU PROJET
Tableau 16 : Phase d'initialisation du projet
Evènement : Initialisation du projet

Déclencheur : les ressources (matérielles, financières et humaines)
 Etablissement d’un calendrier et d’un programme d’activités
 Découpage du projet en tâches
 Estimer le temps nécessaire à l'accomplissement de chaque tâche
Actions :  Affectation des participants à une tâche
o Superviseur
o Participants
 Allocation des ressources à une tâche
Troisième étape : EXECUTION DU PROJET
Tableau 17 : Phase d'exécution du projet
Evènement : Exécution du projet

Déclencheur : Plan d’exécution du projet
Acteurs : Gestionnaire, Superviseur, participants
 Suivi
o Améliorer l'efficience, modifier le plan ou l'affectation des
ressources

2014
oClarifier les objectifs et leur transformation en indicateurs de

performance
o Comparer régulièrement les réalisations
o Communiquer les progrès aux responsables et les alerter sur
les difficultés
o si un participant ne termine pas une tâche, lui faire parvenir des
notifications jusqu’à ce que la tâche soit totalement accomplie
(à travers le système dès qu’il s’y connecte).
 Evaluation
Actions : o Examiner les relations causales conduisant des activités aux
résultats, expliquer pourquoi certains résultats attendus n'ont
pas été atteints
o Fournir des renseignements, améliorer l'efficacité
o Examiner la mise en œuvre
o Production d’un tableau de bord pour surveiller et contrôler
l’état d’avancement des activités à travers un diagramme (en
pourcentage par rapport aux prévisions).
 Mise à jour d’une activité (ou tâche) : durée, affectation des participants
et des ressources
 Etablissement d’un rapport de façon périodique (journalier, mensuel,

trimestriel) selon les variables et les programmes
Quatrième étape : CLOTURE DU PROJET
Tableau 18 : Phase de Clôture du projet
Evènement : Clôture du projet

Déclencheur : - Fin de l’exécution de toutes les tâches définie du le projet (livrables)
- Fermeture du projet par le promoteur pour des raisons personnelles
(avant la date prévue)
 Vérification de l’accomplissement de toutes les tâches du projet
 Clôture du projet
 Livrables du projet (résultats)
Actions :  Faire un bilan en comparant les résultats obtenus avec les objectifs
préétablis
 Suivi des tâches du projet même après fermeture
 Faire l’inventaire des ressources utilisées dans le projet (bilan)
 Evaluer la performance des participants au projet

2014
2- REGLES DE GESTION
 Un projet peut être géré par une ou plusieurs organisation(s) ;

 Une organisation peut gérer un ou plusieurs projet(s);
 Une organisation est composée de plusieurs équipes ;
 Un équipe ne peut appartenir qu’à une seule organisation ;
 Une équipe regroupe un ou plusieurs membres ;
 Un projet est découpé en une ou plusieurs tâche(s);
 Un calendrier regroupe plusieurs ligne calendriers;
 Un projet s’exécute selon un seul calendrier ;
 Un calendrier peut concerner un ou plusieurs projet(s) ;
 Le projet se ferme automatiquement si toutes les tâches définies dans le projet sont
totalement accomplies;
 Lorsqu’un projet est fermé, on ne peut plus y ajouter des tâches ;
 La date de clôture du projet est la date à laquelle la dernière tâche du projet est
accomplie ;
 Les tâches sont constituées de sous-tâches (qui sont elles-mêmes des tâches en ce sens
qu'elles peuvent se décliner en sous-tâches) dont la durée ne dépasse pas celle de la
tâche parent ;
 Le(s) participant(s) qui supervise(nt) une tâche peut (peuvent) participer ou non aux
sous-tâches de cette tâche;
 A une tâche est attribué un ou plusieurs superviseur(s) ;
 Si un participant ne termine pas une tâche, il faut lui faire parvenir des notifications
jusqu’à ce que la tâche soit totalement accomplie ;
 Un projet peut être financé par une ou plusieurs source(s) de financement ;
 A une tâche peuvent être affectés plusieurs matériels ;
 A une tâche peuvent être affectés plusieurs coûts journaliers.
3- CONCEPTION DETAILLEE
Après la modélisation des besoins puis l’organisation de la structure de la solution à travers
les diagrammes, la conception détaillée consiste à construire et à documenter précisément les
classes, les interfaces, et les méthodes qui faciliteront le codage de la solution. Le modèle
logique y est particulièrement important dans la mesure où c’est en conception détaillée que
l’on génère le plus gros volume d’informations.
4- DIAGRAMME DE CLASSES DU SYSTEME
Le diagramme de classes représente les classes constituant le système et les associations

entre elles. Les diagrammes de classes expriment de manière générale la structure statique d’un
système, en termes de classes et de relations entre ces classes.

2014
Figure 21: Diagramme de classes du système

2014
5- DIAGRAMMES D’ETATS-TRANSITIONS
Les diagrammes d’états-transitions d’UML présentent les séquences possibles d’états et
d’actions qu’une instance de classe peut traiter au cours de son cycle de vie en réaction à des
événements. Ils spéciﬁent habituellement le comportement d’une classe mais, parfois aussi le
comportement interne d’autres éléments tels que les cas d’utilisation.
Nous présentons ci-dessous le diagramme d’états-transitions de la classe tâche.
Figure 22 : Diagramme d’état-transition de la classe tâche

2014
PARTIE III - REALISATION ET

DEPLOIEMENT

2014
Ce chapitre se concentre essentiellement sur la définition de l’architecture du système ainsi

que sur l’implémentation de tous nos modèles en application. Nous allons également justifier
le choix du développement d’une application orientée web et présenter les différents outils de
développement utilisés pour la mise en place de la solution. Nous construirons par la suite
l’architecture réseau de notre solution.
VI- RESEAU INFORMATIQUE
1- CONCEPTS RESEAUX
UN RESEAU
Un réseau est un ensemble d'objets interconnectés les uns avec les autres. Il permet de faire
circuler des éléments entre chacun de ces objets selon des règles bien définies.
INTRANET
Un intranet est un ensemble de services internet (par exemple un serveur web) interne à
un réseau local, c'est-à-dire accessible uniquement à partir des postes d'un endroit particulier,
ou bien d'un ensemble de réseaux bien définis et invisible de l'extérieur. Il consiste à utiliser les
standards client-serveur de l'internet (en utilisant les protocoles TCP/IP), comme par exemple
l'utilisation de navigateurs internet (clients basés sur le protocole HTTP) et des serveurs web
(protocole HTTP), pour réaliser un système d'information interne à une organisation ou une
entreprise.
2- ARCHITECTURE CLIENT/SERVEUR
De nombreuses applications fonctionnent dans un environnement client/serveur, cela

signifie que des machines clientes (des machines faisant partie du réseau) contactent un
serveur, une machine généralement très puissante en termes de capacités d'entrée-sortie, qui
leur fournit des services. Ces services sont des programmes fournissant des données telles que
l'heure, des fichiers, une connexion. Ils sont exploités par des programmes, appelés
programmes clients, s'exécutant sur les machines clientes. On parle ainsi de client FTP, client
de messagerie, ... lorsque l'on désigne un programme, tournant sur une machine cliente, capable
de traiter des informations qu'il récupère auprès du serveur (dans le cas du client FTP il s'agit
de fichiers, tandis que pour le client de messagerie, il s'agit de courriers électroniques).
 Architecture 1-tiers
Dans une approche d'application de type 1-tiers (tiers signifiant tierce partie), toute la
logique de fonctionnement de l’application s'exécute sur la même machine. Dans ce cas, on ne
peut pas parler d'architecture client-serveur mais d'architecture centralisée.
L’avantage de ce type d’architecture est que la centralisation de toute la puissance sur une
seule et même machine permet une utilisation optimale des ressources.

2014
 Architecture 2-tiers
L'architecture à deux niveaux (aussi appelée architecture 2-tiers) caractérise les systèmes
clients/serveurs dans lesquels le client demande une ressource et le serveur la lui fournit
directement. Cela signifie que le serveur ne fait pas appel à une autre application afin de fournir
le service.
C'est parce que le client assume des tâches de présentation et de traitement, et donc de fait
communique avec le serveur sans intervention d'un autre processus que le client est dit "lourd"
par opposition à l'architecture 3-tiers où le client est constitué d'un simple navigateur internet
et communique avec le serveur.
L’architecture deux tiers présente l’avantage d’avoir des données centralisées, une interface
utilisateur riche et est efficace pour un nombre réduit de clients.
Par ailleurs ce type d’architecture présente aussi des limites comme par exemple la
limitation du nombre de clients car les performances du système se dégradent quand le nombre
de clients augmente et la base de données est en surcharge, aussi chaque intervention engendre
un coût important surtout pour la mise à jour des applications déployées sur les postes clients.
 Architecture 3-Tiers
Dans l'architecture à trois niveaux (aussi appelée architecture 3-tiers), il existe un niveau
intermédiaire, c'est-à-dire que l'on a généralement une architecture partagée entre :
 Un client, c'est-à-dire l'ordinateur demandeur de ressources, équipé d'une interface

utilisateur (généralement un navigateur web) chargée de la présentation (ou affichage).
Ce client est dit léger dans la mesure où il n’assume aucune fonction de traitement à la
différence du modèle 2-tiers.
 Le serveur d'applications (appelé également middleware), chargé de fournir la
ressource, mais faisant appel à un autre serveur ;
 Le serveur de données, fournissant au serveur d'application les données dont il a
besoin.
Dans l’architecture trois tiers le poste client ne supporte plus l’ensemble des traitements
applicatifs, la montée en charge est mieux gérée car le cadre applicatif a été renforcé. On a donc
une répartition de charge entre les différents serveurs et le poste client.

2014
3- CLIENTS LOURDS / CLIENTS LEGERS
Client lourd
Le terme « client lourd » désigne une application cliente graphique exécutée sur le système
d'exploitation de l'utilisateur. Un client lourd possède généralement des capacités de
traitement évoluées et peut posséder une interface graphique sophistiquée. Néanmoins, ceci
demande un effort de développement et tend à mêler la logique de présentation (l'interface
graphique) avec la logique applicative (les traitements).
 Installation
Ce type d'application étant généralement installé sur le système d'exploitation de

l'utilisateur, une nouvelle version doit être installée afin de la faire évoluer. Pour y remédier,
les éditeurs d'applications lourdes les dotent généralement d'une fonctionnalité exécutée au
lancement de l'application, permettant de vérifier sur un serveur distant si une version plus
récente est disponible et le cas échéant propose à l'utilisateur de la télécharger et de l'installer.
 Maintenance
La maintenance d’une application du type client lourd se fait par mise à jour manuelle ou
automatique. Elle est simple, rapide et généralement sans contrainte majeure, mais peut
nécessiter d’installer sur tous les ordinateurs des utilisateurs les mises à jour, ce qui devient
vite très difficile à envisager. On peut aussi redouter des incompatibilités avec des systèmes
d’exploitation dépassés ou avec des configurations des ordinateurs modifiées par chaque
utilisateur.
Client léger
Le terme « client léger », par opposition au client lourd, désigne une application accessible
via une interface web (en HTML) consultable à l'aide d'un navigateur web, où la totalité de la
logique métier est traitée du côté du serveur. Le concept de client léger a été adopté par de
nombreuses entreprises soucieuses de réduire leurs coûts de possession des postes de travail
en centralisant, sur des serveurs, les applications (bureautiques ou client/serveur)
habituellement exécutées par des ordinateurs et faciliter le déploiement et la maintenance des
applications de gestion.
 Installation
Pour les systèmes en client léger, l’installation est beaucoup plus simple. Il suffit
simplement d’installer une seule fois un serveur d’application et ensuite de partager le lien
d’accès à tous les utilisateurs.

2014
 Maintenance
Toute application installée sur le serveur est instantanément disponible pour tous les clients
et les réglages du système ou les mises à jour ne sont faites qu'une fois pour tout l'ensemble
serveur-clients légers.
4- SYNTHESE
Compte tenu des besoins techniques, nous orientons notre choix vers une architecture
client/serveur, avec un client léger. Le problème est de trouver le nombre de niveaux
nécessaires pour un bon fonctionnement et une fiabilité maximale du système. Pour cela, nous
avons opté pour une architecture à 3 niveaux. Dans l'architecture à 3 niveaux, les applications
au niveau serveur sont délocalisées, c'est-à-dire que chaque serveur est spécialisé dans une
tâche. Ainsi, on aura un serveur d'application et un serveur de base de données.
En effet, l'architecture à 3 niveaux offre :
 Une plus grande flexibilité du système ;

 Une plus grande sécurité des services ;
 Une meilleure performance par le partage des tâches coté serveur.
Figure 23 : Schémas de l'architecture à trois niveaux
Les clients légers offre de gros avantages qui sont suivants :
 Indépendance machine-environnement de travail : en cas de panne de matériel,

d’un changement de bureau ou lorsqu’un un utilisateur se trouve à une station autre
que la maison mère, il peut se connecter sur n'importe quel client et retrouver son
environnement de travail et ses documents.
 Maintenance système: toute application installée sur le serveur est instantanément
disponible pour tous les clients et les réglages du système ou les mises à jour ne sont
faites qu'une fois pour tout l'ensemble serveur-clients légers.
 Robustesse : une station spécialisée est bien moins sensible aux pannes qu'un
ordinateur muni d'un système et d'un disque dur ; une machine ancienne est facilement
remplaçable en cas de panne.

2014
VII- LES OUTILS UTILISES DANS LA REALISATION
1- OUTILS DE DEVELOPPEMENT
Pour la réalisation de ce projet, nous avons choisi de travailler avec :
 NetBeans 7.4
C’est un environnement de développement intégré (EDI) distribué en open source par Sun
depuis juin 2000 sous licence CDDL et GPLv2 (Common Development and Distribution
License). NetBeans supporte différents langages comme Java, PHP, Python, C, C++, XML, Ruby
et HTML. Il comprend toutes les caractéristiques d'un IDE moderne (éditeur en couleurs,
projets multi-langages, refactoring, éditeur graphique d'interfaces et de pages Web).
 PHP
Pour la réalisation de nos travaux, nous avons choisi PHP comme langage de développement.
En effet, dans ses dernières versions (4 et 5), PHP intègre à peu près tous les outils nécessaires
à la réalisation de sites web dynamiques. PHP permet de manipuler facilement des images, de
créer des fichiers PDF, d'instancier des objets. Ce langage possède près de trois milles (3000)
fonctions. Il permet de s'interconnecter à la quasi-totalité des SGBD commerciaux ou libres.
L'un des avantages majeurs de PHP est sa portabilité. En effet, un script PHP codé sous
Windows peut être utilisé sous un environnement Unix sans aucune modification. Tout ceci
confirme la puissance, la fiabilité et les performances de PHP qui s'est imposé au vu du nombre
de sites l'utilisant.
 WampServer
WampServer est une plate-forme de développement Web sous Windows pour des
applications Web dynamiques à l’aide du serveur Apache, du langage de scripts PHP et d’une
base de données MySQL. Il possède également PHPMyAdmin permettant de gérer plus
facilement les bases de données.
 MySQL
MySQL est un système de gestion de base de données (SGBD). Selon le type d'application, sa
licence est libre ou propriétaire. Il fait partie des logiciels de gestion de base de données les plus
utilisés au monde, autant par le grand public (applications web principalement) que par des
professionnels.
2- OUTILS DE MODELISATION
 Altova Umodel
C’est un logiciel de modélisation UML doté d’une interface visuelle riche et des
caractéristiques d'utilisation supérieures à la norme requise pour un outil de modélisation ; il

2014
comprend de nombreuses fonctionnalités sophistiquées fournissant aux utilisateurs les aspects

les plus pratiques de la spécification UML.
3- BIBLIOTHEQUES LOGICIELLES
Pour réaliser notre application, nous avons utilisé diverses bibliothèques logicielles. Ces
bibliothèques ont été très utiles pour diverses raisons. D’abord, l’application mise en place doit
permettre l’édition d’états et de rapports portant sur le suivi du projet; ensuite elles ont servi
aussi pour améliorer le design et l’ergonomie de l’application.
 Twitter Bootstrap
C'est une collection d'outils utile à la création de sites et applications web. C'est un ensemble
qui contient des codes HTML et CSS, des formulaires, des boutons, des outils de navigation et
autres éléments interactifs, ainsi que des extensions JavaScript en option.
 MPDF
Une classe PHP qui génère des fichiers PDF à partir de l’encodage UTF-8 codé HTML avec un
support de styles CSS très améliorée Il est basé sur FPDF et HTML2FPDF (deux autres
bibliothèques de même famille) avec un certain nombre d'améliorations.
 DHTMLX GANTT
DHTMLXGANTT est une bibliothèque JavaScript permettant l’intégration d’un diagramme de

GANTT interactif dans une interface web. Il permet aussi de visualiser un calendrier de projet
et montre les dépendances et la hiérarchie entre les tâches.
4- DEPLOIEMENT DE LA PLATEFORME WEB
ARCHITECTURE RESEAU DE LA SOLUTION
Pour une entité organisationnelle ayant pour vocation la gestion de projets et disposant des
équipements nécessaires, l’application ainsi élaborée sera déployée sur un équipement faisant
office de serveur web et pourra être accessible en intranet; cet équipement sera chargé de
récupérer des informations sur un serveur de base de données afin de satisfaire les requêtes
effectuées par les utilisateurs à travers un navigateur web.
Ainsi, les utilisateurs, quel que soit leur poste de travail, pourront accéder à l’application et
effectuer toutes les opérations. Cette architecture offre également l’avantage de la mobilité de
l’utilisateur grâce à un accès sans fil via un point d’accès.

2014
Figure 24: Architecture réseau de la plate-forme
5- CAPTURES D’ECRAN
1. Interface de connexion à l’application
Figure 25 : Interface de connexion à l'application

2014
2. Liste des projets gérés
Figure 26: Liste des projets gérés
3. Liste des participants d’une équipe
Figure 27 : Liste des participants d'une équipe

2014
4. Liste des participants d’un projet
Figure 28 : Liste des participants d'un projet
5. Liste des matériels d’un projet
Figure 29 : Listes des matériels d'un projet

2014
6. Etat : Liste des participants par organisation
Figure 30 : Etat : Liste des participants par organisation
7. Formulaire d’affectation de matériels à une tâche
Figure 31 : Formulaire d'affectation de matériels à une tâche

2014
8. Formulaire d’affectation de participants à une tâche
Figure 32 : Formulaire d'affectation de participants à une tâche
A l'issue de cette partie, nous avons pu exprimer clairement les objectifs attendus du
système conçu, ainsi que l'analyse associée à chaque cas d'utilisation et l’identification des
acteurs qui y interviennent.
En gros dans cette partie, nous nous sommes familiarisés avec le langage de
modélisation UML d'une part et d'autre part, avec la démarche du processus de développement
logiciel (Processus Unifié) qui nous a guidé dans la réalisation des différentes étapes de notre
projet. Nous avons également décrit la manière dont la plate-forme de la solution a été réalisée
et l’architecture réseau dans laquelle celle-ci sera déployée.

2014
PARTIE 3 : GESTION DE PROJET

2014
I- CONDUITE DE PROJET
Un projet est un processus unique qui consiste en un ensemble d'activités coordonnées et

maîtrisées, comportant des dates de début et de fin, entrepris dans le but d'atteindre un objectif
conforme à des exigences spécifiques, incluant des contraintes de délai, de coût et de ressource ;
il fait donc l'objet d'une budgétisation de moyens et d'un bilan indépendant de celui de
l'entreprise. La gestion d’un projet devient alors la démarche visant à organiser de bout en bout
le bon déroulement du projet, coordonner, diriger et surtout contrôler les ressources utilisées
et ce, de façon structurée et optimale. Nous présenterons dans cette dernière partie du
document l’organisation de notre projet notamment, son découpage en tâches et en phases, les
estimations des ressources humaines, matérielles et financières. Nous terminerons par le bilan
et les perspectives du travail effectué, sans bien sûr oublier de noter les apports et difficultés
liés à notre stage.
1- ADMINISTRATION DU PROJET
a- DECOUPAGE DU PROJET
Avant de se lancer dans la réalisation d’un projet, il est nécessaire de prendre le temps de le
découper en tâches afin de planifier leur exécution et de définir les ressources à mobiliser. Ce
découpage du projet permet de mener à bien le projet en respectant les contraintes de qualité,
de coût et de délai.
C’est ainsi que, dans le cadre de notre travail, nous avons défini un certain nombre de phases
pour notre projet. Ces phases sont découpées en tâches et illustrées dans le tableau suivant :
Tableau 19 : Découpage des phases du projet en tâches
TACHES
PHASES
Exploration du sujet - Lecture des documents portant sur le suivi-évaluation
de projets
Etude préliminaire - Etude de la solution existante
Réalisation de la solution - Analyse et modélisation des besoins du système
- Conception
- Validation et test
Documentation - Rédaction
b- INTERVENANTS AU PROJET
Au cours de notre stage, nous avons travaillé avec plusieurs personnes dont le responsable
du projet, notre encadreur et notre superviseur académique :

2014
Tableau 20 : Intervenants au projet
Intervenants Titre
Mr Ghislain PODA Gérant de GPO Consulting, maître de stage
Dr Ange NAMBILA Superviseur académique
Pr Ousmane B. KONFE Enseignant chercheur à IAI
Ingénieur Ousseyni TIAMA Responsable informatique de GPO Consulting et encadreur
c- DIAGRAMME DE GANTT
Le diagramme de GANTT est un outil utilisé dans la gestion de projets; il permet de réaliser
une représentation graphique du déroulement d'un projet et de rendre compte de son
avancement.
Nous présentons ci-dessous le diagramme prévisionnel (figure 25) qui a été élaboré au début
du projet puis, le diagramme réel (figure 26) qui est celui obtenu à la fin du projet.
Figure 33: Diagramme de Gantt prévisionnel

2014
Figure 34 : Diagramme de Gantt réel
d- COUT MATERIEL DU PROJET

Tableau 21 : Tableau récapitulatif des charges du projet
Ressources utilisées Coût

Ordinateur portable DELL + Windows 8 400 000 FCFA
Environnement WAMP Gratuit
Windows - Apache – MySQL - PHP
NetBeans 7.4 Gratuit
Dhtmlx gantt Gratuit
Boostrap Gratuit
Ndv3 Gratuit
Altova Umodel Gratuit
Edraw MAX 7 Gratuit
Prime de stage 150 000 FCFA (*5)
COUT TOTAL 1 150 000 FCFA
2- APPORTS, DIFFICULTES ET PERSPECTIVES DU PROJET
a- APPORTS
Notre travail a consisté à concevoir et à développer une application permettant de suivre le

déroulement de toutes les activités relatives au suivi-évaluation de projets.
L’étude et la réalisation de ce projet nous ont permis :

2014
 De mettre en application les connaissances théoriques, mais aussi pratiques acquises au

cours de nos années de formation ;
 D’approfondir nos connaissances sur la méthode d’analyse adaptée, en programmation
avec l’environnement Netbeans et MySQL pour l’implémentation de la base de données ;
 D’avoir une expérience dans le développement d’application web ;
 D’avoir une expérience en matière de gestion des projets informatiques ;
 De renforcer notre capacité à travailler en équipe ;
b- DIFFICULTES RENCONTREES
Nous avons rencontré de nombreuses difficultés durant ce stage. Il s’agit notamment de la
compréhension du fonctionnement du système existant, plus précisément l’analyse des
formules complexes utilisées pour le traitement des données.
c- PERSPECTIVES
L’intérêt que nous portons à ce travail nous laisse un sentiment de non achèvement du
projet.
 Les fonctionnalités développées :
o Gestion des projets
o Gestion des tâches
o Gestion des organisations
o Gestions des équipes
o Gestion des participants
o Gestion des matériels
o Attribution des coûts à une tâche
o Affectation des ressources (matérielles et humaines) à une tache
o Identification et spécification des indicateurs du projet
o Elaboration d’un tableau de bord pour le suivi du projet
o Elaboration d’un diagramme de GANTT
o Gestion des relations d’antécédence et de succession entre les tâches
o Gestion du niveau de priorité des tâches
o Etablissement d’un calendrier pour le projet
o Evaluation du travail d’un participant en fonction de sa charge de travail
 Les fonctionnalités en cours de développement :

o Etablissement du rapport de performance d’un participant sur le projet
o Gestion des tâches critiques
o Gestion de la disponibilité des participants
o Gestion de la surutilisation des ressources
En termes de perspective, nous souhaitons l’aboutissement complet du projet et nous

espérons y apporter notre concours. Notre travail a permis à la GPO Consulting de disposer d’un
outil de prestation pour la gestion de projets, plus précisément pour le suivi-évaluation de

2014
projets. Nous envisageons d’étendre l’aspect mobilité des utilisateurs de notre application, qui
n’est présentement réduite qu’à la couverture d’un réseau intranet.
Nous avons, au cours de cette partie, décrit les différentes phases de la gestion de notre
projet. Nous avons aussi présenté les différents intervenants qui ont contribué à sa réalisation
et dressé le bilan de notre projet, les difficultés rencontrées ainsi que les perspectives
envisagées.

2014
CONCLUSION GENERALE
L’objectif de notre projet de fin d’étude a été de concevoir et d’implémenter une
application de suivi-évaluation de projets. Le point de départ de la réalisation de ce projet fut
la récolte des informations nécessaires pour dresser un état de l’existant, présenter un aperçu
sur la problématique, ainsi qu’une étude des concepts liés au domaine.
Par la suite, nous nous sommes intéressés à l’analyse et la spécification des besoins qui
nous ont permis de distinguer les différents acteurs interagissant avec le système à l’étude.
L’objectif suivant était la conception détaillée, partie dans laquelle nous avons défini la
structure globale de l’application.
Le dernier volet de notre projet, la partie réalisation, a été consacrée à la présentation

des outils de travail et les interfaces les plus significatives de notre application.
L’apport de ce travail a été considérable. En effet, il nous a permis de suivre une

méthodologie de travail bien étudiée et d’approfondir nos connaissances dans le
développement d’applications.
La réalisation d’un tel projet nous a permis d’apprendre et de nous confronter à divers
aspects du métier de développeur et de concepteur.

2014
BIBLIOGRAPHIE
1. Banque mondiale. Séminaire de formation en suivi en suivi évaluation. Niger : s.n., 2008.
2. V, Verrière. Le suivi d'un projet de développement : démarche, dispositif, indicateurs. Paris : s.n., 2002.
3. PNUD. Dossier d'information sur le suivi évaluation. 2008.
4. Fofana I. Planification et contrôle opérationnel de projets. 2009.
5. Oger B. Comptabilité et contrôle de gestion. 2009.
6. Casley , D.J. et Kumar , K. Suivi et évaluation des projets agricoles. s.l. : Economica, 1987. p. 165
pages.
7. Neu D. Evaluer : apprécié la qualité pour faciliter la décision. Six notes pour contribuer à l'efficacité des
évaluations. 2001.
8. Bergeron G. Evaluation de projets. 2008.
9. Maders H.P. et Clet E. Pratiquer la conduite de projet. 2005.
10. Roques. UML 2 en pratique. s.l. : Eyrolles, 2006.
11. Ivar JACKOBSON, Grady BOOSH et James RAMBAUGH. Le processus unifé de

développement logiciel. s.l. : Edition Eyrolles, 1999.
12. Roques, P. et Vallée, F. UML 2 En Action (De l"analyse des besoins à la conception J2EE). Eyrolles :
s.n., 2004.

2014
ANNEXE

2014
ANNEXE 1 : DICTIONNAIRE DE DONNEES

2014

2014

2014

Document - Kadidia - Version - Du - 06-Mars-2015 - Corrigu00e9 - Avec Recaptures - F

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

Document - Kadidia - Version - Du - 06-Mars-2015 - Corrigu00e9 - Avec Recaptures - F

Transféré par

Droits d'auteur :

Formats disponibles

CONCEPTION ET RÉALISATION D’UNE PLATE-FORME DE SUIVI –

 A la mémoire de mon père Amadou ALI BEIDI

 A ma mère Zeinabou HAROUNA SIDIKOU

 A mes frères et sœurs

 Aux familles Ali Beidi, Mailelé et Harouna SIDIKOU

Par AMADOU ALI Kadidiatou Page i

Mes remerciements vont vivement :

 Au Dr. Souleymane KOUSSOUBE, Directeur Général de l’IAI ;

Par AMADOU ALI Kadidiatou Page ii

L’Institut Africain d'Informatique (IAI) est un établissement d’enseignement Supérieur

Ce document représente l’aboutissement de trois années de formations à l’IAI à

Par AMADOU ALI Kadidiatou Page iii

Les entreprises prestataires ressentent, de plus en plus, la nécessité d’améliorer leur

Mots clés : projet, suivi, évaluation, activité.

Par AMADOU ALI Kadidiatou Page iv

Thus, to achieve the implementation of this platform, we used an object-oriented

Keywords : project, monitoring, evaluation, activity.

Par AMADOU ALI Kadidiatou Page v

LISTE DES FIGURES

Figure 1 : Organigramme de GPO Consulting ........................................................................................... 4

Par AMADOU ALI Kadidiatou Page vi

LISTE DES TABLEAUX

Tableau 1: Différences et complémentarités entre le suivi et l'évaluation............................................ 12

Par AMADOU ALI Kadidiatou Page vii

LISTE DES ABREVIATIONS

Par AMADOU ALI Kadidiatou Page viii

TABLE DES MATIERES

Par AMADOU ALI Kadidiatou Page ix

1- ETUDE DE LA METHODE ADOPTEE -------------------------------------------------------------- 19

Par AMADOU ALI Kadidiatou Page x

3- BIBLIOTHEQUES LOGICIELLES ---------------------------------------------------------------------- 57

Par AMADOU ALI Kadidiatou Page xi

Conçu durant la phase de planification, en même temps que la conception du projet, le

Pour les institutions en général et celles en particulier des pays en voie de

 La première partie est consacrée au sujet et à ses généralités. Nous y présenterons la

Par AMADOU ALI Kadidiatou Page 1

PARTIE 1 : LE SUJET ET SES

Par AMADOU ALI Kadidiatou Page 2

I- LA STRUCTURE D'ACCUEIL ET LE SUJET

1- PRESENTATION DE LA STRUCTURE D’ACCUEIL

 L’assistance aux PME et PMI

 Etude de faisabilité de projet

o Organisation et gestion des stocks ;

Par AMADOU ALI Kadidiatou Page 3

POLE FORMATION POLE TECHNIQUE ET

Consultant Consultant Consultant

Figure 1 : Organigramme de GPO Consulting

Par AMADOU ALI Kadidiatou Page 4

2- LE SUJET ET SON CONTEXTE

Le suivi-évaluation est une discipline récente qui gagne continuellement en importance

Fort de ce constat, de nombreuses entreprises sont à la quête d’outils leur permettant de

 Comment mettre en place un système de suivi évaluation permettant de répondre aux

L’intérêt de notre étude est de produire une application informatique permettant :

Par AMADOU ALI Kadidiatou Page 5

 De mieux contrôler l’affectation des ressources au projet;

II- CONCEPTS LIES AU DOMAINE

1- ETUDE DES CONCEPTS DE BASE

a- LA NOTION DE SUIVI DE PROJET

Par AMADOU ALI Kadidiatou Page 6

ROLES ET OBJECTIFS DU SUIVI

Le suivi des réalisations

Le suivi des délais

Le suivi des coûts