P Fe Mohamed Coulibaly

REPUBLIQUE DE LA COTE D’IVOIRE
Union-Discipline-Travail
Ministère de l’Economie Numérique et de la Poste
Ecole Supérieure Africaine Des Technologies

de l’Information et de la Communication
Année Scolaire : 2019-2020
MEMOIRE DE FIN DE CYCLE POUR

L’OBTENTION DU MASTER EN
SECURITE INFORMATIQUE ET TECHNOLOGIE DU WEB
(SITW)
CONCEPTION ET DEVELOPPEMENT D’UNE APPLICATION

DEDIEE AU SYSTEME DE MANAGEMENT DE
PERFORMANCE DES AGENTS DE LA CRRAE-UMOA
Présenté par :
COULIBALY Mohamed Tiemogo Nanguin

Stage effectué du 10 juin au 9 octobre 2020
Encadrant académique : Maître de stage :
Pr. ASSEU Olivier, M. SOUMARE Moustapha,
Enseignant-Chercheur à l’INPHB Directeur des Systèmes d’Information de la CRRAE-UMOA

M. KOUAKOU Simon Louis,
Chef de la Division des Etudes et du Développement
Conception et développement d’une application dédiée au système de management de performance des
agents de la CRRAE-UMOA
DEDICACE
À ma très chère famille Je vous dois ce que je suis

aujourd'hui grâce à votre amour, à votre patience et vos
innombrables sacrifices.
II
-
REMERCIEMENTS
La rédaction de ce projet de fin d’études marque la fin d'un long parcours qui n'aurait
pas été possible sans le soutien et la présence de nombreuses personnes. Alors qu'il
me soit permis d'adresser mes sincères remerciements à tous ceux qui ont contribués
à l'aboutissement de ce projet.
J’adresse tout d'abord mes vifs remerciements au directeur général de l'ESATIC Pr

Adama KONATE qui nous a construit un cadre favorable à nos études. Je tiens
également à remercier Pr Olivier ASSEU mon encadrant académique pour l’aide
compétente qu’il m’a apportée, pour sa patience et son encouragement. Son œil
critique m’a été très précieux pour structurer le travail et pour améliorer la qualité des
différentes parties. Je tiens ensuite à remercier tout particulièrement mes deux
responsables de stage : M. Moustapha SOUMARE (Directeur des Systèmes
d’Information) et M. Simon Louis KOUAKOU (maitre de stage) pour m’avoir
accueilli dans leur service, pour leurs disponibilités et pour leurs conseils. Également
remercier les personnes qui ont travaillé à la CRRAE-UMOA pour les bons moments
que nous avons passés ensemble.
J’adresse enfin une pensée spéciale à mes parents pour leur soutien dans mes choix
et leur attention sans failles, ainsi qu’à ma bonne-maman, dont les encouragements
et l’amour inconditionnel m’accompagnent depuis toujours. Merci également à
Coulibaly Bintou et Coulibaly Yélé, qui ont toujours été présentes au moment où
j’avais besoin de leur aide financière ou morale. Un merci tout spécial à Koné Kafiné
pour ses impulsions et ses suggestions, son regard critique et sa relecture attentive. Je
remercie enfin tous ceux qui, d’une manière ou d’une autre, ont contribué à la réussite
de ce travail et qui n’ont pas pu être cités ici.
III
-
AVANT-PROPOS
Le numérique revêt une importance primordiale au sein de la société et de ce

fait, doit être considéré comme un levier stratégique contribuant dans une large
mesure au développement économique et social. Conscient de ce fait, le
gouvernement ivoirien a la volonté de faire de la Côte d’Ivoire un point de référence
en matière de Technologie de l’Information et de la Communication (TIC). C’est dans
cet élan qu’a été créée l'École Supérieure Africaine des Technologies de
l’Information et de la Communication (ESATIC). L’ESATIC a pour mission de
former des étudiants qualifiés et performants capables de répondre aux besoins du
marché des TIC qui est très compétitif.
En effet, cette formation est appuyée par des stages en entreprises que les
étudiants doivent effectuer durant leur cursus. Ceux-ci permettent à l’étudiant d’être
face aux réalités pratiques de l’entreprise, ce qui lui fait acquérir de l’expérience, le
préparant à un esprit d’adaptation au monde professionnel. C’est ce qui fonde ou
justifie notre stage à Caisse de Retraite par Répartition Avec Epargne de l’Union Monétaire
Ouest Africaine (CRRAE-UMOA) à la direction de systèmes d’information plus
précisément la division étude et développement, où il nous a été soumis le thème
suivant : «Conception et développement d’une application dédiée au système de
management de performance des agents de la CRRAE-UMOA ».
IV
-
LISTE DES FIGURES
Figure 1 : architecture MVC............................................................................................... 15

Figure 2 : processus scrum ................................................................................................. 22
Figure 3 : diagramme de cas d'utilisation global de l'application ..................................... 29
Figure 4 : Digramme des cas d’utilisation au niveau agent ............................................... 30
Figure 5 : Digramme des cas d’utilisation au niveau administratif ................................... 31
Figure 6 : Workflow fixation du contrat d’objectif ............................................................. 40
Figure 7 : Workflow évaluation à mi-parcours .................................................................. 41
Figure 8 : Workflow évaluation finale ............................................................................... 42
Figure 9 : Workflow appréciation des évaluations ............................................................. 43
Figure 10 : diagramme de séquence ''S'authentifier'' ......................................................... 44
Figure 11 : diagramme de séquence ''définir son contrat d'objectif '' ................................ 44
Figure 12 : diagramme de séquence ''faire une autoévaluation à mi-parcours'' ............... 45
Figure 13 : diagramme de séquence ''faire une autoévaluation finale'' Erreur ! Signet non
défini.
Figure 14 : diagramme de séquence ''faire une autoévaluation finale'' ............................. 46
Figure 15 : diagramme de séquence ''valider une évaluation finale'' ... Erreur ! Signet non
défini.
Figure 16 : diagramme de séquence " voir l'historique" .................................................... 48
Figure 17 : diagramme de séquence " créer des sessions" ................................................. 49
Figure 18 : diagramme de séquence "donner un niveau de performance" ........................ 49
Figure 19 : diagramme de séquence "accorder des échelons" ........................................... 50
Figure 20 : diagramme de séquence "faire des impression" .............................................. 50
Figure 21 : diagramme de séquence "faire de paramétrages" ........................................... 51
Figure 22 : diagramme de classe de l'application .............................................................. 52
Figure 23 : interface de connexion ..................................................................................... 62
Figure 24 : Tableau de bord ............................................................................................... 62
Figure 25 : Interface contrat d'objectif............................................................................... 63
Figure 26 : Interface évaluation à mi-parcours ................................................................. 64
Figure 27 : interface évaluation finale ............................................................................... 65
Figure 28 : interface création de d’exercice....................................................................... 66
Figure 29 : Interface de création de session ....................................................................... 66
Figure 30 : Interface agent ................................................................................................. 67
Figure 31 : Interface profile agent ..................................................................................... 67
V
-
LISTE DES TABLEAUX
Tableau 1 : Etude comparative des types d'applications ............................................................................... 14

Tableau 2 : Etude comparative des méthodes de développement ................................................................... 16
Tableau 3 : Interventions récurrentes des activités au niveau des phases d’EssUP ....................................... 18
Tableau 4 : Matrice de fonctionalités et acteurs ............................................................................................. 29
Tableau 5 : Description textuelle du cas d'utilisation ‘‘s'authentifier’’ ......................................................... 32
Tableau 6 : Description textuelle du cas d'utilisation ‘‘définir son contrat d’objectif’’ ................................. 33
Tableau 7 : Description textuelle du cas d'utilisation ‘‘ faire une évaluation à mi-parcours’’ ...................... 33
Tableau 8 : Description textuelle du cas d'utilisation ‘‘faire une évaluation à finale’’ ................................. 34
Tableau 9 : Description textuelle du cas d'utilisation ‘‘ voir l’historique des évaluations’’ .......................... 34
Tableau 10 : Description textuelle du cas d'utilisation ‘‘ valider un contrat d'objectif’’ ............................... 35
Tableau 11 : Description textuelle du cas d'utilisation ‘‘valider une évaluation à mi-parcours’’ ................. 35
Tableau 12 : Description textuelle du cas d'utilisation valider une évaluation finale .................................... 36
Tableau 13 : Description textuelle du cas d'utilisation ‘‘créer des sessions’’ ................................................ 36
Tableau 14 : Description textuelle du cas d'utilisation ‘‘donner un niveau de performance’’ ....................... 37
Tableau 15 : Description textuelle du cas d'utilisation ''accorder de échelon'' .............................................. 38
Tableau 16 : Description textuelle du cas d'utilisation ''Notifier les agents'' ................................................. 38
Tableau 17 : Description textuelle du cas d'utilisation ''Faire des impressions d’états'' .............................. 39
Tableau 18 : Description textuelle du cas d'utilisation ''Faire des paramétrages'' ........................................ 39
VI
-
LISTE DES SIGLES ET ABRÉVIATIONS
2TUP : Two Tracks Unified Process

AJAX : Asynchronous JavaScript And XML.
BECEAO : Banque Centrale des Etats de l’Afrique de l’Ouest.
BOAD : Banque Ouest Africaine de Développement.
CRRAE-UMOA : Caisse de Retraite par Répartition Avec Epargne de l’Union Monétaire
Ouest Africaine.
CSS : Cascading Style Sheets.
DG : Direction Générale.
DOM: Document Object Model.
EUP : Enterprise Unified Process
FAAM : Fonds Autonome d’Assurance Maladie.
HTML : Hypertext Markup Language.
HTTP : Hypertext Transfer Protocol.
MVC : Modèle-Vue-Contrôleur.
OS : Operating System.
PDF : Portable Document Format.
PHP : Hypertext Preprocessor.
PU : Processus Unifié
PCA : President du Conseil d’Administrateur.
RCPNC : Régime de Retraite Complémentaire du Personnel Non Cadre.
RRPC : Régime de Retraite par Répartition du Personnel Cadre.
RVC : Retraite Volontaire par Capitalisation.
RH : Ressource Humaine
SGBD : Système de Gestion de Base de Données.
SMP : Système de Management des Performances.
SQL : Structured Query Language.
VCS : Version Control System.
UML : Unified Modeling Language.
XML : eXtensible Markup Language.
XSS : Cross-site scripting.
VII
-
SOMMAIRE
INTRODUCTION
PREMIÈRE PARTIE : GÉNÉRALITÉS
CHAPITRE I : PRÉSENTATIONS GÉNÉRALES
CHAPITRE II : ÉTAT DE L’ART SUR LA REALISATION DU

PROJET
CHAPITRE III : CHOIX ET JUSTIFICATION
DEUXIÈME PARTIE : ETUDE CONCEPTUELLE
CHAPITRE IV : ETUDE DU SYSTÈME EXISTANT ET

IDENTIFICATION DES BESOINS
CHAPITRE V : CONCEPTION GÉNÉRALE
CHAPITRE VI : CONCEPTION DÉTAILLÉE
TROISIÈME PARTIE : IMPLÉMENTATION
CHAPITRE VII : ENVIRONNEMENT DE DÉVELOPPEMENT
CHAPITRE VIII : MISE EN ŒUVRE
CHAPITRE IX : BILAN DU PROJET
CONCLUSION
ANNEXE
VII
- I
Conception et développement d’une application dédiée au système de management de
performance des agents de la CRRAE-UMOA
INTRODUCTION
La gestion des performances du personnel constitue de nos jours un élément

indispensable à toutes organisations. En effet elle est l’un des principaux facteurs sur
lesquels repose la croissance mais aussi la pérennité d’une entreprise. De ce fait la
Caisse de Retraite par Répartition Avec Epargne de l’Union Monétaire Ouest
Africaine (CRRAE-UMOA) s’est doté d’un outil mis à la disposition de son personnel
à savoir le système de management des performances (SMP). De façon succincte, elle
consiste à la démarche de conduire le supérieur et l’agent à convenir des objectifs
précis à réaliser sur une période. Ces objectifs concernent aussi bien des activités
fonctionnelles, que des objectifs de comportement. Ensuite, ils procèdent à un bilan
intermédiaire, six mois après la fixation des objectifs. Enfin, les deux parties effectuent
conjointement une évaluation pour déterminer les résultats atteints par l’agent, les
difficultés rencontrées, les mesures de formation et de développement nécessaires. Cet
outil révèle être un instrument privilégié pour faire valoir la vision de la Caisse et
amorcer une réflexion sur les résultats visés. Cependant elle présente des faiblesses
dans sa mise œuvre.
Le fonctionnement du système est se base entièrement sur l’utilisation de fichiers excel
ne garantissant pas un certain nombre d’éléments à savoir : la difficulté de collaborer,
le manque d’automatisme et à cela s’ajoute le caractère manuel de l’envoi des lettres
notifications de niveau de performances et d’avancement.
Au vu de cela, la CRRAE-UMOA voudrait voir optimiser son système de management

des performances grâce à l'informatique garantissant le stockage et le traitement
automatisé des données. D'où l’intitulé de notre thème : Conception et développement
d’une application dédiée au système de management de performance des agents de la
CRRAE-UMOA. En d'autres termes, il s'agit de mettre en place une application
capable de gérer le processus de management des performances de manière
automatique.
Plusieurs préoccupations se posent face aux enjeux importants de ce projet à savoir :

quelle sont les avantages liés à la gestion automatique de ce processus. Quelles sont
les différentes étapes pour aboutir cette digitalisation du processus de management des
performances ?
1
-
Pour y répondre, nous articulerons notre travail autour de trois parties. Une première
partie intitulée généralités où nous ferons une présentation générale du sujet ensuite
faire l’état de l’art sur la réalisation du projet et terminer par l’adoption de méthodes
nécessaires à la réalisation du projet. Une deuxième partie appelée phase d’étude
conceptuelle qui fera l’objet d’une étude qui consistera à étudier le système existant
afin de dégager les limites et identifier les besoins fonctionnels et non fonctionnels du
futur système, aussi d’une étude conceptuelle générale et détaillée consacrée à la
conception de la plateforme. Et une troisième partie intitulée réalisation consacrée à la
mise en œuvre de l’application tout en présentant au préalable l’environnement de
développement.
2
-
PREMIÈRE PARTIE :
GÉNÉRALITÉS
L’objet de cette partie est d’examiner le cadre d’étude du projet afin d’en avoir une
claire compréhension. Nous allons par conséquent présenter la structure d’accueil
ainsi que le thème qui cristallise notre attention. Ensuite, nous ferons un état de l’art
sur la réalisation du projet afin de faire des choix qui nous aiderons à réaliser le
projet.
1
-
CHAPITRE I : PRÉSENTATION GÉNÉRALES
I- Présentation de CRRAE-UMOA
La Caisse de Retraite par Répartition Avec Epargne de l’Union Monétaire

Ouest Africaine (CRRAE-UMOA) est un Organisme public international de
prévoyance retraite, doté de la personnalité juridique, qui gère les Régimes de retraite
du Personnel de la Banque Centrale des Etats de l’Afrique de l’Ouest (BCEAO) et de
la Banque Ouest Africaine de Développement (BOAD).
Elle compte également parmi ses Adhérents, la plupart des Banques et Etablissements
Financiers de l’UMOA ainsi que les institutions financières de l’UMOA et les
Institutions Multinationales Africaines dont le siège est situé dans l’un des Etats
membres de l’UMOA.
La CRRAE-UMOA gère au profit de ses Adhérents et Participants, les régimes de

retraite et fonds ci-après :
 le Régime de Retraite par Répartition du Personnel Cadre (RRPC) ;

 le Régime de Retraite Complémentaire du Personnel Non Cadre (RCPNC) ;
 le Retraite Volontaire par Capitalisation (RVC) ;
 le Fonds Autonome d’Assurance Maladie (FAAM).
La mission de l’Institution se décline comme suit :
 assurer la pérennité et la viabilité des régimes en appliquant une gestion

performante et transparente, garantissant l’équilibre financier ;
 mettre à la disposition de nos clients une gamme de prestations et services
répondant à leur préoccupation de disposer d’une autonomie financière à la
retraite ;
 continuer à offrir aux assurés et aux adhérents les prestations et services les
plus attractifs et compétitifs du marché en Afrique ;
 fournir aux assurés et aux adhérents des prestations et services de premier
niveau s’inscrivant dans une dynamique continue d’amélioration de la qualité
de service.
4
-
II- Contexte du projet
La CRRAE-UMOA a adopté un cycle de planification stratégique quinquennal

depuis 2014. Afin d’accompagner sa mise en œuvre, une évolution du système
d’évaluation du personnel, vers un modèle fondé sur des objectifs préalablement fixés
a été opérée. Pour soutenir cette démarche, la Caisse a mis en place un nouvel outil à
la disposition de son personnel : le Système de Management des Performances (SMP).
Le SMP donne à l’Institution et aux agents des directives claires relatives à la fixation
et au suivi des objectifs, l’évaluation de la performance, la rétroaction utile, la
reconnaissance et la récompense, ainsi qu’au développement personnel.
A ce jour, ce système est géré à l’aide de fichiers Excel, en ce qui concerne la fiche
d’évaluation et les divers états de synthèse produits par la Direction de
l’Administration et des Ressources Humaines à l’occasion de la présentation des
résultats. À cela, il faut ajouter les notifications, par lettre, des avancements au
personnel. Cette pratique qui devient de plus en plus fastidieuse, rend le suivi du
dispositif difficile et ne permet pas une gestion centralisée des informations. Pour une
plus grande efficacité, la Caisse souhaite automatiser son Système de Management des
Performances (SMP).
III- Présentation du cahier de charge
III.1. Présentation du projet
Le thème choisi pour le projet interne s’intitule : « Conception et

développement d’une application dédiée au système de management de performance
des agents de la CRRAE-UMOA ». Ce projet a été proposé dans le cadre de
l’élaboration d’un stage de quatre mois au niveau de la CRRAE-UMOA. L'objectif
principal recherché est d’apporter une solution optimale à la gestion du processus de
management des performances des agents de la structure.
5
-
III.2. Les objectifs du projet
L’application qui sera disponible sur le réseau interne de la Caisse aura pour
objectif principal de permettre l’optimisation de la gestion du SMP. Plus
particulièrement, elle permettra de :
 dématérialiser la fixation des contrats d’objectifs ;

 dématérialiser les évaluations à mi-parcours et finales ;
 faciliter les échanges entre le personnel (gestion du workflow) ;
 interfacer l’application de gestion des ressources humaines en charge de la
gestion du personnel afin de récupérer la base de données du personnel qui
devra alimenter la nouvelle application.
 suivre l’évolution de la mise en œuvre des objectifs ou les résultats de
l’évaluation de performance par le supérieur hiérarchique en temps réel au
niveau individuel et fonctionnel ;
 reprendre l’historique des contrats d’objectifs et des évaluations (sur les 6 ans
dernières années) ;
 sécuriser les informations, conserver les historiques et y accéder aisément ;
 mettre en place des alertes pour une meilleure organisation du SMP ;
 réaliser des tableaux de bord pertinents nécessaires au pilotage du SMP. À cet
effet, il pourrait être envisagé une intégration des données de cette application
dans le Système Informatique d’Aide à la Décision (BI) de la Caisse.
III.3. Description de quelques opérations
La mise en place de l’application dédiée au système de management de

performances des agents de la CRRAE-UMOA doit permettre d’effectuer des
opérations ci-après :
 définir un contrat d’objectifs à tous les agents de la Caisse en début d’exercice.

Elle devra prendre en compte le savoir être, les activités courantes liées à la
fiche de poste et des objectifs spécifiques ;
 d’apprécier un agent à mi-parcours de son contrat d’objectifs. Cela devra se
faire par des observations sur l’état d’avancement des objectifs spécifiques
6
-
assignés, les critères d’appréciation de sa fiche de poste et les critères

d’appréciation du savoir être ;
 faire une évaluation finale (notée) en fin d’exercice sur les activités courantes,
les objectifs spécifiques et le savoir être ;
 faire des notifications aux agents sur les performances obtenues en fin
d’exercices ainsi que les avancements en fin d’exercice ;
 faire le reporting à travers les états et graphique qui devront être éditables
III.4. Contraintes
L’application dédiée au système de management de performances devra être

compatible avec le système d'information de la Caisse et doit être bâtie obligatoirement
sur les systèmes d'exploitation, les bases de données et les plateformes de
développement cités ci-après. Elle devra par ailleurs, prendre en compte l’objectif
d’intégration au système existant.
Les systèmes de base utilisés actuellement par la Caisse sont :
 les systèmes d'exploitation Microsoft Windows Server 2012/2019 et Oracle
Enterprise Linux 7.0 pour les serveurs et Microsoft Windows 10 pour les
postes de travail ;
 les systèmes de gestion de base de données Oracle Database 11gR2, Microsoft
SQL Server 2019 et MySQL ;
 les environnements et outils de développement Oracle Database, Oracle
APEX, JDEdwards Entreprise One 9.1, Sharepoint, .NET, PL SQL, SQL,
Java, C#;
 le serveur web Apache tomcat, Oracle Weblogic;
 Microsoft Exchange Server 2019 pour la messagerie électronique ;
 Microsoft SharePoint Server 2019 pour la gestion du portail intranet ;
 la suite bureautique Microsoft Office 2013/2016;
 le navigateur web Mozilla, Chrome et Internet Explorer.
La solution devra être modulaire et se reposer sur des architectures de type n-tiers et
orientée service (SOA). Les interfaces doivent également être riches de type web 2.0.
7
-
La solution devra être capable de garantir des performances linéaires en fonction de

l'accroissement du nombre d'utilisateurs et du volume de données.
8
-
CHAPITRE II : ÉTAT DE L’ART SUR LA REALISATION

DU PROJET
I- Présentation des types d’applications

Une « application » est un programme directement utilisé pour réaliser une tâche
et/ou assurer un ensemble de fonctions précises. Au fil du temps, 3 grandes familles
d’application ont vu le jour avec chacun sa particularité et son domaine d’application.
I.1. Présentation des applications bureau/desktop
Une application bureau/desktop est une application qui s’exécute complètement sur un
ordinateur portable. L’un de ses avantages est qu’elle est plus rapide et plus stable car
elle ne dépend pas des performances d’une autre application. Par contre, son
inconvénient c’est sa portabilité. Elle a besoin d’être installé sur chaque machine pour
être accessible. De plus, elles font face aux problèmes de compatibilité de système
d’exploitation [1].
I.2. Présentation des applications web
Une application Web est une application qui utilise les technologies du Web et
à laquelle on y accède en utilisant un navigateur (Firefox, Google Chrome, IE, etc.).
Son principal avantage c’est son coût qui est accessible. De plus, l’accès à une
application web se fait depuis n’importe quel type de poste (PC, téléphone mobile,
tablette, etc.) et depuis n’importe quel endroit. Outre, aucune compatibilité de système
d’exploitation n’est nécessaire. Un autre avantage, les applications web ont une
meilleure gestion de sécurité. Tout est centralisé sur un serveur et l’accès est contrôlé
par une identification. L’évolution et l’innovation sont continues car les mises à jour
sont automatiques et transparentes ce qui diminue considérablement le risque
d’obsolescence. Le principal inconvénient réside sur le fait que ce type d’application
n’est accessible que s’il y a un réseau Internet [1].
9
-
I.3. Présentation des applications mobile
Une application mobile est un programme téléchargeable qui a été conçu pour
fonctionner sur un appareil mobile tel qu’un assistant personnel, un téléphone portable,
un smartphone, une tablette ou encore sur certains ordinateurs fonctionnant avec un
système d’exploitation Windows phone ou Chrome OS. L’un des avantages d’une
application mobile réside sur le fait que l’application une fois installée, elle est
permanente dans votre smartphone. L’accès à votre application (via le logo) devient
alors simple et rapide. Outre, disposer d’une application mobile, c’est l’occasion
d’exploiter des outils inédits comme la géolocalisation. Son principal inconvénient est
que, la plupart du temps, elle est difficile à développer car elle doit respecter certaines
règles définies par différentes sociétés (Apple pour les applications iOS, Google pour
les applications Androïdes, Windows pour les applications Windows phone, etc…).
Un autre inconvénient est le coût lié à son développement qui est assez élevé [1].
II- Présentation des méthodes de développement

d’une application
Une méthode d'analyse et de conception informatique a pour objectif de

permettre de formaliser les étapes préliminaires du développement d'un système afin
de le rendre plus fidèle aux besoins du client. Et parmi toutes les approches existantes,
les plus utilisées sont la méthode MERISE et le Processus Unifié (PU) allié au langage
de modélisation UML. Nous présentons ici succinctement ces deux (2) méthodes avec
leurs principales approches et implémentations.
II.1. Présentation de la méthode MERISE
MERISE est une méthode française née dans les années 70, développée
initialement par Hubert Tardieu [2]. Elle fut ensuite mise en avant dans les années 80,
à la demande du Ministère de l'Industrie qui souhaitait une méthode de conception des
SI. Par ailleurs, MERISE est une méthode d'analyse et de conception des systèmes
d'information basée sur le principe de la séparation des données et des traitements. Elle
possède plusieurs modèles qui sont répartis sur 4 niveaux : le niveau conceptuel, le
10
-
niveau organisationnel, le niveau logique et le niveau physique. Elle se décline en deux

(2) principales approches que sont :
II.1.a. La démarche classique
C’est la démarche « par défaut » de la méthode. La conception se fait par étapes,

afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. En
outre, les données étant séparées des traitements, il faut vérifier la concordance entre
données et traitements afin de s’assurer que toutes les données nécessaires aux
traitements sont présentes et qu'il n'y a pas de données superflues.
II.1.b. La démarche classique
Cette démarche dite « RAD » est apparue au début des années 90, en s'opposant
aux démarches en cascade, jugées trop lourdes et trop contraignantes pour le
développement d'applications petites et moyennes [3]. Elle ne s’oppose pas
complètement à la démarche classique mais préconise plutôt une participation active
des utilisateurs, l’exigence d’une maîtrise des coûts et des délais, un cycle itératif de
conception/réalisation/amélioration et un contenu fonctionnel restreint et connu du
projet.
II.2. Présentation du processus unifié
Le processus unifié est un processus de développement logiciel itératif, centré

sur l'architecture, piloté par des cas d'utilisation et orienté vers la diminution des
risques. C'est un patron de processus pouvant être adapté à une large classe de systèmes
logiciels, à différents domaines d'application, à différents types d'entreprises, à
différents niveaux de compétences et à différentes tailles de l'entreprise. Il se décline
en plusieurs implémentations dont les plus utilisées sont :
II.2.a. Le Two Tracks Unified Process (2TUP)
Le 2TUP est un l’un des plus célèbres processus de développement logiciel qui
met en œuvre la méthode du Processus Unifié. Il propose un cycle de développement
en Y, qui dissocie les aspects techniques des aspects fonctionnels. En effet, Le principe
11
-
fondateur du 2TUP est que toute évolution imposée à un logiciel peut se décomposer
et se traiter parallèlement, suivant un axe fonctionnel et un axe technique. À l’issue
des évolutions du modèle fonctionnel et de l’architecture technique, la réalisation du
logiciel consiste à fusionner les résultats de ces deux branches du processus.
II.2.b. Le Rational Unified Process (RUP)
Le RUP est un processus itératif créé par Rational Software Corporation, une
division d'IBM depuis 2003. Il est basé sur des principes de l'ingénierie logicielle saine
comme la prise en charge d'une approche itérative et la concentration sur les besoins
et sur l'architecture du développement des logiciels. Par ailleurs, le RUP fournit
plusieurs mécanismes intéressants tels que des itérations à relativement court terme
avec des objectifs bien définis et offre le choix entre « avancer » ou « stopper » à la
fin de chaque phase, afin de fournir une bonne visibilité et un bon contrôle sur le
processus de développement. Et puisqu'il fournit un plan spécifique pour chaque étape
du processus de développement, il permet de minimiser le gaspillage des ressources
ainsi que les coûts de développement inattendus.
II.2.c. L'enterprise Unified Process (EUP)
La méthode EUP est une variante étendue du Processus Unifié qui a été
développée par Scott W. Ambler et Larry Constantine en 2000 pour être finalement
retravaillée en 2005 par Ambler, John Nalbone et Michael Vizdos. Cette méthode a en
fait été initialement introduite pour surmonter certaines limites de RUP. De ce fait,
deux phases et plusieurs nouvelles activités ont été ajoutées. Également, EUP
considère que le développement de logiciels n'est pas une activité autonome, mais
intégrée au cycle de vie du système (à construire ou à améliorer ou à remplacer), au
cycle de vie informatique de l'entreprise et au cycle organisationnel/commercial de
l'entreprise elle-même.
II.2.d. L'eXtreme Unified Process (XUP)
XUP est une instanciation hybride du Processus Unifié l’intégrant avec XP.
C’est un processus de développement logiciel se trouvant à mi-chemin entre le
Processus Unifié et le XP [4]. Il regroupe par conséquent les avantages de chacun de
12
-
ces processus en profitant notamment de la généricité du PU et de la rapidité

d’obtention du code de XP. Il est en effet basé sur les cas d’utilisation comme le PU
et utilise 20% d’UML pour modéliser 80% du système Il est de ce fait un bon choix
alliant rapidité et efficacité dans l’analyse et la conception des SI.
II.2.e. L'Open Unified Process (OpenUP)
Open Unified Process est une partie du projet Eclipse Process Framework
(EPF), un projet de la Fondation Eclipse qui fournit un cadre de développement de
processus. Il est basé sur le Rational Unified Process et préserve les caractéristiques
essentielles du PU et du RUP, lesquels incluent le développement itératif, le
développement piloté par les cas d'utilisation et les scénarios, la gestion du risque et
l'approche centrée sur l'architecture [6].
En outre, les parties les plus optionnelles du RUP ont été exclues et plusieurs éléments
ont été fusionnés. De ce fait, le résultat est un processus plus simple respectant les
principes du RUP.
II.2.f. L'Essential Unified Process (EssUP)
La méthode EssUP a été inventée par Ivar Jacobson en tant qu'amélioration du

Rational Unified Process [7]. Elle identifie les pratiques, telles que les cas d'utilisation,
le développement itératif, le développement axé sur l'architecture, les pratiques
d'équipe et les pratiques de processus, qui sont empruntées au RUP, au CMMI et au
développement agile.
L'idée est en fait qu’il est possible de choisir les pratiques applicables à une certaine
situation afin de les combiner dans le processus de fonctionnement d’une entreprise.
Ceci est considérées comme une innovation par rapport au RUP, car avec cette dernière
méthode, les pratiques sont presque toutes entrelacées et ne peuvent être appliquées
séparément.
13
-
CHAPITRE III : CHOIX ET JUSTIFICATION
I- Choix du type d’application

I.1. Etude comparative du types d’application
Le choix du type d’application se base sur la contrainte de compatibilité avec

le système d'information de la CRRAE-UMOA et d’un certain nombre d’exigences
que sont : la rapidité et la stabilité, la facilité des mises à jour, l’évolution et la
maintenance, la facilité de développement à un coût minime et la portabilité. Le
tableau ci-dessous (tableau 1) présente une confrontation des types d’application.
Application Application Application

desktop mobile WEB
Rapidité et stabilité ✓ ✓ ✓
facilité mise à jour ✓ ✓ ✓
Evolution et maintenance ✓ ✓ ✓
Fort taux d’utilisation ✓ ✓
Développement ✓
La portabilité ✓
Tableau 1 : Etude comparative des types d'applications
Seules les applications web et desktop répondent aux contraintes du système

d’information de la CRRAE-UMOA. Cependant, le tableau ci-dessous montre que
l’application web reste la meilleure.
I.2. Présentation du motif architecturel
Le Modèle-Vue-Contrôleur (MVC) est un pattern architectural qui sépare les

données (le modèle), l'interface homme-machine (la vue) et la logique de contrôle (le
contrôleur). Ce modèle de conception impose donc une séparation en 3 couches (figure
1):
14
-
 le modèle : Il représente les données de l'application. Il définit aussi

l'interaction avec la base de données et le traitement de ces données.
 la vue : Elle représente l'interface utilisateur, ce avec quoi il interagit. Elle

n'effectue aucun traitement, elle se contente simplement d'afficher les données
que lui fournit le modèle. Il peut tout à fait y avoir plusieurs vues qui présentent
les données d'un même modèle.
 le contrôleur : Il gère l'interface entre le modèle et le client. Il va interpréter la
requête de ce dernier pour lui envoyer la vue correspondante. Il effectue la
synchronisation entre le modèle et les vues.
Figure 1 : architecture MVC
II- Choix de la méthode de développement

II.1. Etude comparative des méthodes développement
Notons que même si MERISE offre une grande cohérence des données, des
niveaux d’abstractions clairs et établit aisément une documentation solide, sa mise en
œuvre est parfois lourde et inadaptée lorsque les besoins changent à une grande
fréquence. Quant au couple PU/UML, il permet une bonne compréhension de la
sémantique des objets qui sont autonomes et souvent réutilisables. Cependant, les
règles de modélisation demeurent floues pour certains diagrammes et le processus se
révèle être chronophage pour les petits projets.
15
-
De ce fait, le choix que nous effectuons ici n’est pas celui de « la méthode parfaite »
mais plutôt celui de l’approche qui cadre le plus avec les réalités de notre projet et le
fonctionnement de la CRRAE-UMOA. Le tableau (tableau 2) suivant présente une
confrontation des méthodes présentées et des exigences à respecter. Ces exigences sont
essentiellement basées sur les principes de Scrum.
METHODES
TWO TRACKS
ENTERPRISE
CLASSIQUE
ESSENTIAL
RATIONAL
EXTREME
RAPIDE
OPEN
EXIGENCES
GRANDE IMPORTANCE
ACCORDEE A LA ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
SATISFACTION DU CLIENT
EVOLUTION DU PROJET A
UN RYTHMESOUTENABLE ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
ET CONSTANT
GESTION AISEE DES

DEMANDES
✓ ✓ ✓ ✓ ✓ ✓ ✓
FREQUENTES DE
CHANGEMENT
LIVRAISONS FREQUENTES
DE VERSIONS
OPERATIONNELLES DE ✓ ✓ ✓ ✓ ✓ ✓ ✓
L’APPLICATION
PREFERENCE ACCORDEE A
LAMODELISATION OBJET ✓ ✓ ✓ ✓ ✓ ✓
AJUSTEMENTS FREQUENTS
POUR AUGMENTER ✓ ✓ ✓
L’EFFICACITE DE L’EQUIPE
AUTO-ORGANISATION
TOTALE DE L’EQUIPE
TRAVAILLANT SUR LE ✓
PROJET
Tableau 2 : Etude comparative des méthodes de développement
Comme l’indique le tableau ci-dessus (tableau 2), l’approche qui prend le plus en
compte les contraintes qui s’imposent à nous est la méthode Essential Unified Process.
C’est donc elle qui nous servira de guide tout au long de notre travail.
16
-
II.1. Présentation de la méthode EssUP
EssUP est un nouveau processus conçu par IJI (Ivar Jacobson International)
pour améliorer le développement des logiciels modernes. C’est en fait une méthode
qui intègre avec prudence les pratiques du Processus Unifié et des méthodes agiles,
possédant ainsi un certain nombre de pratiques simples et éprouvées qui peuvent être
utilisées comme base pour tous les types de développement. Par ailleurs, il se
concentre sur les éléments essentiels applicables aux projets, fournit des conseils sur
la mise en œuvre d'une approche cohérente, met l'accent sur l'amélioration des
compétences des personnes impliquées dans le développement et ajoute suffisamment
de mécanismes pour réduire les risques liés aux projets.
II.1.a. Cycle vie
Le cycle de vie de la méthode EssUP hérite complètement des phases du Processus

Unifié. Il prévoit ainsi les étapes suivantes :
 l’inception : il s’agit ici de lever les ambiguïtés sur les besoins et les exigences
du système à concevoir, d’en identifier les acteurs et d’en délimiter la portée;
 l’élaboration : elle permet de préciser la plupart des cas d'utilisation et de
concevoir l'architecture du système. Au terme de cette phase, l’on doit être en
mesure de prévoir les ressources nécessaires à l’achèvement du projet ;
 la construction : elle est principalement axée sur l’implémentation. Son
objectif est de produire un logiciel qui répond aux besoins prioritaires des
utilisateurs. A la fin de cette phase, les développeurs doivent fournir une
version exécutable du système ;
 la transition : c’est la phase qui finalise le produit. Il s’agit ici de vérifier si le
système offre véritablement les services exigés par les utilisateurs, de détecter
les défaillances, de combler les manques et d’adapter le produit
l’environnement de travail des utilisateurs.
Les phases précitées répètent à chaque itération des pratiques appelées activités. L’on
distingue six (6) activités qui sont :
 l’identification des besoins : cette activité permet d’inventorier les besoins
principaux du système à concevoir. De plus, elle permet de recenser les besoins
17
-
fonctionnels (qui conduisent à l'élaboration des modèles de cas d'utilisation)

ainsi que les besoins non fonctionnels ;
 l’analyse : son objectif est d'accéder à une bonne compréhension des besoins
et des exigences du client. Elle livre une spécification complète des besoins
issus des cas d'utilisation et les structure sous une forme qui facilite la
compréhension du futur système ;
 la conception : elle permet d'acquérir une bonne compréhension des
contraintes liées à la phase de construction. Elle constitue en effet un point de
départ à l'implémentation car elle crée une abstraction transparente de celle-ci
;
 l’implémentation : il s’agit d’implémenter le système sous forme de code
source, de scripts, d'exécutables et d'autres éléments du même type. Les
objectifs principaux de l'implémentation sont de planifier les intégrations des
composants pour chaque itération, et de produire les classes et les sous-
systèmes sous forme de codes sources ;
 les tests : ils permettent de vérifier des résultats de l'implémentation en testant
la construction. Cette activité est axée sur l'assurance de la qualité du logiciel ;
 le déploiement : c’est un ensemble d’étapes qui visent à placer le logiciel dans
son environnement cible de manière à ce qu'il soit prêt à être utilisé.
Notons que le PU gère le processus de développement selon deux (2) axes : un axe
vertical qui représente les enchaînements d'activités et un axe horizontal représentant
le temps et les enchainements de phases. Le tableau 2 ci-dessous présente la façon dont
les activités interviennent le plus souvent au niveau des phases :
INCEPTION ELABORATION CONSTRUCTION TRANSITION
BESOINS ✓
ANALYSE ✓
CONCEPTION ✓
IMPLEMENTATION ✓
TESTS ✓
DEPLOIEMENT ✓
Tableau 3 : Interventions récurrentes des activités au niveau des phases d’EssUP
18
-
Soulignons que n’importe quelle activité peut intervenir durant n’importe quelle phase
du processus. Le tableau 2 ci-dessus présente donc les manifestations récurrentes des
activités au niveau des phases et non leurs uniques interventions.
II.1. Présentation de UML
UML est un langage de modélisation graphique à base de pictogrammes conçu

pour fournir une méthode normalisée pour visualiser la conception d'un système. Il est
couramment utilisé en développement logiciel et en conception orientée objet. Il est le
résultat de la fusion de précédents langages de modélisation objet : Booch, OMT,
OOSE. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar
Jacobson, UML est à présent un standard adopté par l'Object Management Group
(OMG).
Par ailleurs, UML est utilisé pour spécifier, visualiser, modifier et construire les
documents nécessaires au bon développement d'un logiciel orienté objet. De plus, il
offre un standard de modélisation, pour représenter l'architecture logicielle. Grâce aux
outils de modélisation UML, il est aussi possible de générer automatiquement
totalement ou partiellement du code d'une application logicielle, à partir des divers
documents réalisés. En outre, UML est un langage graphique qui permet de représenter
les divers aspects du système d’information. Il se décompose en plusieurs sous-
ensembles que sont :
II.1.a. Les vues
Elles représentent les observables du système. Elles le décrivent d'un point de vue
donné. Et en les combinant toutes, il est possible de retrouver le système complet. Ce
sont :
 la vue des cas d'utilisation : c'est la description du modèle vu par les acteurs
du système. Elle correspond aux besoins attendus par chaque acteur ;
 la vue logique : c'est la définition du système vu de l'intérieur. Elle explique
comment peuvent être satisfaits les besoins des acteurs ;
 la vue d'implémentation : cette vue définit les dépendances entre les modules
;
 la vue des processus : c'est la vue temporelle et technique, qui met en œuvre
les notions de tâches concurrentes, stimuli, contrôle, synchronisation, etc. ;
19
-
 la vue de déploiement : cette vue décrit la position géographique et

l'architecture physique de chaque élément du système.
II.1.b. Les diagrammes

Les diagrammes sont des ensembles d'éléments graphiques. Ils décrivent le
contenu des vues, qui sont des notions abstraites. Et ils peuvent faire partie de plusieurs
vues. Les diagrammes sont par ailleurs dépendants hiérarchiquement et se complètent,
de façon à permettre la modélisation d'un projet tout au long de son cycle de vie.
Depuis UML 2.3, il en existe quatorze (14) répartis en trois (3) catégories :
CATEGORIE 1 : DIAGRAMMES STRUCTURELS OU STATIQUES

 le diagramme de classes : représentation des classes intervenant dans le
système ;
 le diagramme d'objets : représentation des instances de classes (objets)
utilisées dans le système ;
 le diagramme de composants : représentation des composants du système
d'un point de vue physique, tels qu'ils sont mis en œuvre (fichiers,
bibliothèques, bases de données...) ;
 le diagramme de déploiement : représentation des éléments matériels
(ordinateurs, périphériques, réseaux, systèmes de stockage...) et la manière
dont les composants du système sont répartis sur ces éléments matériels et
interagissent entre eux ;
 le diagramme des paquets : représentation des dépendances entre les paquets
(un paquet étant un conteneur logique permettant de regrouper et d'organiser
les éléments dans le modèle UML), c'est-à-dire entre les ensembles de
définitions ;
 le diagramme de structure composite : représentation sous forme de boîte
blanche des relations entre composants d'une classe (depuis UML 2.0) ;
CATEGORIE 2 : DIAGRAMMES COMPORTEMENTAUX
 le diagramme des cas d'utilisation : représentation des possibilités d'interaction

entre le système et les acteurs (intervenants extérieurs au système), c'est-à-dire
de toutes les fonctionnalités que doit fournir le système ;
20
-
 le diagramme d’états-transitions : représentation sous forme de machine à états

finis du comportement du système ou de ses composants ;
 le diagramme d'activité : représentation sous forme de flux ou d'enchaînement
d'activités du comportement du système ou de ses composants.
CATEGORIE 3 : DIAGRAMMES D’INTERACTION
 le diagramme de séquence : représentation de façon séquentielle du

déroulement des traitements et des interactions entre les éléments du système
et/ou de ses acteurs ;
 le diagramme de communication : représentation de façon simplifiée d'un
diagramme de séquence se concentrant sur les échanges de messages entre les
objets (depuis UML 2.0) ;
 le diagramme global d'interaction : représentation des enchaînements possibles
entre les scénarios préalablement identifiés sous forme de diagrammes de
séquences (depuis UML 2.0) ;
 le diagramme de temps : représentation des variations d'une donnée au cours
du temps (depuis UML 2.3).
Ces diagrammes, d’une utilité variable selon les cas, ne sont pas nécessairement
tous produits à l’occasion d’une modélisation. Les plus utiles pour la maîtrise
d’ouvrage sont les diagrammes d’activités, de cas d’utilisation, de classes, d’objets, de
séquence et d’états-transitions. Dans le cas de la réalisation de notre projet, nous
utiliserons les diagrammes d’activités, de cas d’utilisation, de classes, et de séquence.
II.1.c. Les modèles d’éléments
Les modèles d’éléments désignent tout simplement les éléments graphiques des
diagrammes présentés en amont.
III- Choix de la méthode de gestion du projet
Scrum est la méthode choisi pour la gestion de notre projet. En effet, Elle fait
partie de la famille des méthodes dites « agile ». L’approche agile consiste à se donner
des objectifs à courts termes, une fois l’objectif terminé nous faisons le point et suivant
le résultat nous adapte les nouveaux objectifs en fonctions du résultat obtenue
21
-
précédemment et ainsi de suite jusqu’à atteindre le résultat final. Le commanditaire est

impliqué dans le projet du début à la fin ce qui lui donne de la visibilité.
Cela permet en autre d’éviter « l’effet tunnel », c’est-à-dire se lancer sur un projet
et arriver à termes avec un produit qui ne correspond pas aux attentes des clients ou ne
pas mener le projet à terme. La méthodologie Scrum est l’approche agile la plus utilisée
des approches agiles existantes et est simple à comprendre.
Figure 2 : processus scrum
Comme le montre l’image ci-dessus (figure 2), la méthodologie SCRUM est composée
de quatre phases (on parle aussi de réunion):
 Planification du Sprint
 Revue de Sprint
 Rétrospective de Sprint
 Mêlée quotidienne
La planification du sprint correspond au listing des points prioritaires que l'équipe

pense pouvoir réaliser au cours d'un sprint.
La revue du sprint a lieu en fin de sprint, l'équipe de développement présente les

fonctionnalités terminées au cours du sprint et recueille les retours du représentant des
utilisateurs finaux, c'est aussi à ce moment que la mise en place des prochains sprints
peut être anticipée.
22
-
La Rétrospective de Sprint permet de faire un point sur le sprint en lui-même

(productivité, efficacité, qualité…) afin de pouvoir s'améliorer pour les prochains
sprints.
Enfin la mêlée quotidienne permet de faire un point sur les avancements de chacun,
elle est courte et chacun réponds à trois questions principales : Qu'est-ce que j'ai
terminé depuis la dernière mêlée ? Qu'est-ce que j'aurai terminé d'ici la prochaine
mêlée ? Quels obstacles me retardent ?
23
-
DEUXIÈME PARTIE : ETUDE

CONCEPTUELLE
Dans cette partie, il sera question d’une part d’une étude des besoins des
utilisateurs afin d’avoir une meilleure compréhension de notre application à
concevoir et d’autre part de la présentation des différents diagrammes qui découlent
de cette étude.
24
-
CHAPITRE VI : ETUDE DU SYSTÈME EXISTANT ET

IDENTIFICATION DES BESOINS
(INCEPTION)
I. Description du système existant
Le Système de Management des Performances (SMP) est un outil de gestion des

ressources humaines intimement lié aux objectifs de l’Institution dans le sens où
l’approche permet une déclinaison en cascade des objectifs de l’Institution tirés du
plan stratégique, en passant par les objectifs assignés aux structures, jusqu’à ceux fixés
aux agents.
Le SMP permet entre un supérieur et un agent de décliner des objectifs précis à réaliser
sur une période [Annexe1]. Ces objectifs concernent aussi bien des activités
fonctionnelles, que des objectifs de comportement. Ensuite, ils procèdent à un bilan
intermédiaire [Annexe2], six mois après la fixation des objectifs. Enfin, les deux
parties effectuent conjointement une évaluation [Annexe3] pour déterminer les
résultats atteints par l’agent, les difficultés rencontrées, les mesures de formation et de
développement nécessaires.
Les informations issues de l’entretien d’évaluation, viennent irriguer d’autres sous

processus RH, tel que la Formation, la gestion des compétences, le cheminement de
carrière, la mobilité, les rémunérations.
II. Critique de l’existant
D'après les informations recueillies nous constatons que le processus existant

révèle à la fois des points forts mais aussi des insuffisances du à son fonctionnement.
En effet, bien qu’il présente une très bonne organisation nous notons des faiblesses
que sont :
 un manque d’automatisme ;
 une difficulté de collaboration ;
 un suivi difficile du processus ;
25
-
 un caractère manuel pour certains processus.
III. Proposition de solutions
Au vu des insuffisances énumérées plus haut, il est judicieux de mettre en place

une application utilisant les nouvelles technologies pour une meilleure gestion. Cette
application dédiée système management des performances doit pallier les
insuffisances révélées par le système existant. Il doit être opérationnel, évolutif,
convivial et offrir une disponibilité en temps réel afin de permettre aux agents de la
CRRAE-UMOA de suivre l’évolution de leur contrat d’objectif de la fixation à
l’évaluation finale. Pour cela le système doit satisfaire les besoins de ceux-ci.
IV. Spécification des besoins
IV.1. Besoins fonctionnels
Dans le souci de répondre convenablement aux attentes citées en amont et de

respecter les objectifs de notre projet, les fonctionnalités que nous identifions pour
notre application sont les suivantes :
 définir un contrat d’objectif ;
 faire des évaluations de performances à mi-parcours et finale ;
 notifier les agents de l’évolution de leur contrat d’objectif, des performances et
des avancements en fin d’exercice ;
 voir l’historique des contrats d’objectifs et des évaluations ;
 réaliser des tableaux de bord pertinents nécessaires au pilotage du SMP.
IV.2. Besoins non fonctionnels
Les besoins non fonctionnels désignent un ensemble de spécifications non

explicites qui améliorent la qualité d’une application. Dans notre cas notre application
doit répondre aux critères suivants :
26
-
La rapidité de traitement: Vu le nombre important de transactions qui se feront à long

terme, il serait important que la durée d'exécution des traitements se rapproche le plus
possible du temps réel.
La performance: Une application doit avant tout être performante, ses fonctionnalités
doivent répondre à toutes les exigences des usagers d’une manière optimale.
La convivialité: La plateforme doit être facile à utiliser. En effet, les interfaces doivent
être simples, conviviales, ergonomiques et adaptées à l’utilisateur.
La confidentialité : l'application doit avoir un niveau de sécurité élevé pour garantir la
confidentialité des données des utilisateurs.
V. Identification des acteurs
Un acteur représente l’abstraction d’un rôle joué par des entités externes qui
interagissent directement avec le système étudié. Dans notre cas, les acteurs
susceptibles d’interagir avec l’application sont les suivants :
 l’agent N correspond à l’employé ou l’agent à qui est fixé un contrat ;
 l’agent N+1 correspond au supérieur hiérarchique de l’agent, il est chargé
de valider le contrat d’objectif de l’agent N (son collaborateur de niveau
inférieur), d’effectuer une évaluation à mi-parcours et finale ;
 l’agent N+2 représente le supérieur hiérarchique de l’agent N+1, il est
chargé de valider le contrat d’objectif de l’agent N (le collaborateur de
niveau inférieur de l’agent N+1), d’effectuer une évaluation à mi-parcours
et finale ;
 les RH (Ressources Humaines) sont chargées du suivi et du bon
déroulement du processus ;
 le CGPC (Comité de Gestion des Performances et Carrières) est chargé de
la validation des contrats, des performances et échelons obtenus à l’issue
des évaluations finales ;
 le DG (Directeur Général) est chargé de la validation des échelons obtenus
 le PCA (Président du Conseil d’Administration) est chargé de la validation
des échelons obtenus ;
NB: Soulignons que les Agents N+1 et N+2 sont également des agents N à la
différence que ceux-ci possèdent des collaborateurs de niveau inférieur
27
-
CHAPITRE V : CONCEPTION GÉNÉRALE (ANALYE)
I- Matrices des fonctionnalités et des acteurs
La matrice des fonctionnalités et des acteurs est utilisée pour lister toutes les
fonctionnalités d’une application à concevoir et de faire le lien avec les acteurs
intervenant. Elle permet d’élaborer aisément le diagramme de cas d’utilisation de
l’application. Dans notre cas, le tableau ci-après présente la matrice de fonctionnalités
et des acteurs de l’application
ACTEURS
Agent Agent Agent CGP PC R
FONCTIONNALITES DG
N N+1 N+2 C A H
Définir un contrat d’objectif en début
d'exercice (décliner les objectifs spécifiques et
leur pondération, donner la pondération des X
activités courantes et du savoir être)
Valider un contrat d’objectif (Modifier dans le
cas échéant) X X X
Consulter le contrat d’objectif X
Faire une autoévaluation à mi-parcours
(commenter les activités courantes, les X X X
objectifs spécifiques et le savoir être)
Faire une autoévaluation finale en fin
d'exercice (évaluer les activités courantes, les X
objectifs spécifiques et le savoir être)
Valider une autoévaluation finale (ou faire une
évaluation dans le cas échéant) X X
Donner un niveau de performance X
Accorder des échelons X X X
Voir l’historique des exercices d’évaluation X X X X X X X
Créer des sessions (Fixation de contrat
d’objectif, évaluation à mi-parcours et X
évaluation finale)
Faire des paramétrages nécessaires au
processus (la valeur indiciaire, la grille
indiciaire, grilles de notations, la grille X
performances-échelons, créer un utilisateur, la
hiérarchie,…)
Notifier les agents de leurs des performances et
des avancements en fin d’exercice X
28
-
Effectuer le reporting à travers les états et

graphiques (récapitulatifs de tous les objectifs
fixés, au personnel, des évaluations par collège, X
Synthèse des évaluations…)
Tableau 4 : Matrice de fonctionalités et acteurs
II- Elaboration des digrammes des cas d’utilisation
Les diagrammes de cas d’utilisation sont des diagrammes UML utilisés pour
donner une vision globale du comportement fonctionnel d’un système logiciel.
C’est la description du modèle vu par les acteurs du système. En effet, les cas
d’utilisation et les acteurs dans les diagrammes de cas d’utilisation décrivent ce
que le système fait et comment les acteurs l’utilisent, mais ne montrent pas
comment le système fonctionne en interne. La figure ci-après présente le
digramme de cas d’utilisation global de l’application. [Annexe 4]
Figure 3 : diagramme de cas d'utilisation global de l'application
29
-
II.1. Digramme des cas d’utilisation au niveau agent
Figure 4 : Digramme des cas d’utilisation au niveau agent
30
-
II.2. Digramme des cas d’utilisation au niveau

administratif
Figure 5 : Digramme des cas d’utilisation au niveau administratif
31
-
III- Description textuelle des digrammes des cas

d’utilisation
Pour documenter les cas d’utilisation, la description textuelle est très utile, car elle
permet de communiquer aisément avec les utilisateurs. Pour chacun des cas
d’utilisation préalablement identifiés, nous présentons une fiche de description.
III.1. S’authentifier
ACTEURS Agent N, Agent N+1, Agent N+2, CGPC, DG, PCA, RH
Ils se connectent afin de pouvoir accéder à leurs différents

RESUME
espaces dédiés.
Ils doivent déjà enregistrer dans l’active directory et se trouver
PRECONDITION
sur la page de connexion.
POSTCONDITIO Ils sont authentifiés dans l’application et redirigés vers le tableau
N de bord de leurs espaces.
1) Ils accèdent à la page de connexion de l’application et
saisissent leurs informations d’authentification (Nom
d’utilisateur/Mot de passe) ;
SCENARIO 2) L’application vérifie les informations d’authentification
NOMINAL avec l’active directory ;
3) Si les informations sont correctes ils sont authentifiés et
redirigés vers leurs espaces dans le cas contraire ils restent
sur la page de connexion avec un message d’erreur
Tableau 5 : Description textuelle du cas d'utilisation ‘‘s'authentifier’’
III.2. Définir son contrat d’objectif

ACTEUR Agent N
L’agent N définit son contrat d’objectif en se fixant des
objectifs spécifiques avec une pondération, une date
RESUME
d’échéance et aussi affecter des pondérations aux activités
courantes et au savoir être.
L’Agent N doit être authentifié à l’application et les ressources
PRECONDITION
humaines doivent activer une session de fixation de contrat.
Le contrat est enregistré et en attente de validation de la part
POSTCONDITION
des agents N+1, N+2 et CGPC
32
-
1) Les ressources humaines créent une session de fixation

d’objectif de l’exercice en cours.
2) L’agent se connecte et sélectionne l’onglet destiné à la
SCENARIO
fixation d’objectif
NOMINAL
3) Choisit la session de fixation de contrat active et définit
son contrat d’objectif.
4) Puis valide et laisse la main à ses supérieures
Tableau 6 : Description textuelle du cas d'utilisation ‘‘définir son contrat d’objectif’’
III.3. Faire une autoévaluation à mi-parcours
ACTEUR Agent N
L’agent N faire des commentaires sur l’état d’avancement

RESUME dans la réalisation de ses objectifs spécifiques et aussi des
commentaires sur activités courantes et son savoir être.
L’Agent N doit être authentifié à l’application et les
PRECONDITION ressources humaines doivent activer une session de
d’évaluation à mi-parcours.
L’autoévaluation à mi-parcours de l’agent est enregistrée et
POSTCONDITIO
en attente de l’évaluation à mi-parcours des agents N+1et
N
N+2
1) Les ressources humaines créent une session d’évaluation
à mi-parcours de l’exercice en cours.
2) L’agent se connecte et sélectionne l’onglet destiné à
SCENARIO l’évaluation à mi-parcours
NOMINAL 3) Choisit la session d’évaluation à mi-parcours active et
fait ses commentaires.
Tableau 7 : Description textuelle du cas d'utilisation ‘‘ faire une évaluation à mi-parcours’’
III.4. Faire une autoévaluation finale
ACTEUR Agent N
L’agent N doit s’autoévaluer sur la réalisation de son

RESUME contrat d’objectifs en se notant sur ses activités courantes,
son savoir être et ses objectifs spécifiques.
L’Agent N doit être authentifié à l’application et les
PRECONDITION ressources humaines doivent activer une session de
d’évaluation finale.
33
-
L’autoévaluation de l’agent est enregistrée et en attente de

POSTCONDITION
la validation des agents N+1et N+2
1) Les ressources humaines créent une session
d’évaluation finale de l’exercice en cours.
SCENARIO l’évaluation finale
NOMINAL 3) Choisit la session d’évaluation finale active et fait ses
commentaires.
Tableau 8 : Description textuelle du cas d'utilisation ‘‘faire une évaluation à finale’’
III.5. Voir l’historique des évaluations
ACTEUR Agent N, Agent N+1, Agent N+2, CGPC, DG, PCA, RH
Ils doivent pouvoir avoir accès à ses évaluations

RESUME précédentes ou celui de ses collaborateurs de niveau
inférieur et les visualisés.
Ils doivent être authentifiés à l’application et avoir des
PRECONDITION évaluations archivées ou celui des collaborateurs de niveau
inférieur archivé.
POSTCONDITION Une possibilité d’imprimer l’historique

l’historique ;
2) Choisit l’exercice et choisit l’agent dont on voudrait
SCENARIO visualiser l’historique (dans le cas d’un collaborateur
NOMINAL de niveau supérieur) ;
3) Visualiser l’historique et imprimer dans le cas échéant
Tableau 9 : Description textuelle du cas d'utilisation ‘‘ voir l’historique des évaluations’’
III.6. Valider un contrat d’objectif
ACTEUR Agent N+1, Agent N+2, CGPC
Ils valident ou invalident à tour de rôle le contrat d’objectif

RESUME de l’agent N. En cas d’invalidation, le contrat d’objectif est
redéfini. Seule la validation du CGPC est retenue.
Ils doivent être authentifiés à l’application et l’agent N doit
PRECONDITION
avoir défini son contrat d’objectif.
34
-
 Dans le cas de l’agent N+1 celui-ci laisse la main à

l’agent N+2
 Dans le cas de l’agent N+2 celui-ci laisse la main au
POSTCONDITION
CGPC
 Dans le cas Du CGPC celui-ci laisse la place à une
évaluation à mi-parcours
1) Ils se connectent et sélectionnent l’onglet destiné à la
fixation d’objectif
2) Choisissent ensuite l’agent et la session de fixation de
SCENARIO contrat active et visualisent son contrat d’objectif.
NOMINAL 3) Puis valide ou invalide le contrat d’objectif en cas
d’invalidation, le contrat d’objectif est redéfini par
l’agent en question et le valide en laissant la main à son
supérieur (la validation du CGPC est définitive)
Tableau 10 : Description textuelle du cas d'utilisation ‘‘ valider un contrat d'objectif’’
III.7. Faire une évaluation à mi-parcours
ACTEUR Agent N+1, Agent N+2
Ils font des commentaires sur l’état d’avancement dans la

réalisation des objectifs spécifiques de l’agent N ainsi que
RESUME
des commentaires sur ses activités courantes et son savoir
être.
PRECONDITION
avoir fait l’étape de la fixation de son contrat d’objectif.

l’agent N+2
POSTCONDITION  Dans le cas du N+2 celui-ci laisse la place à une
évaluation finale ou une autre évaluation à mi-
parcours
1) Ils se connectent et sélectionnent l’onglet destiné à
l’évaluation à mi-parcours ;
2) Choisissent ensuite l’agent et la session d’évaluation à
SCENARIO mi-parcours active et visualisent ses commentaires ;
NOMINAL 3) Puis font leurs commentaires et laisse la main à son
supérieur (dans le cas du N+1) ou clôture l’évaluation
à mi-parcours (dans le cas du N+2).
Tableau 11 : Description textuelle du cas d'utilisation ‘‘valider une évaluation à mi-

parcours’’
35
-
III.8. Valider une évaluation finale
ACTEUR Agent N+1, Agent N+2
Ils font une évaluation sur la réalisation du contrat

RESUME d’objectif de l’agent N en se notant sur ses activités
courantes, son savoir être et ses objectifs spécifiques. .
PRECONDITION
avoir fait l’étape de la fixation de son contrat d’objectif.

l’agent N+2 ;
POSTCONDITION
 Dans le cas du N+2 celui-ci laisse la place à une
appréciation de performance.
l’évaluation finale ;
2) Choisissent ensuite l’agent et la session d’évaluation
SCENARIO finale active et visualisent son autoévaluation;
NOMINAL 3) Puis font leur évaluation et laisse la main à son
supérieur (dans le cas du N+1) ou au CGPC (dans le
cas du N+2).
Tableau 12 : Description textuelle du cas d'utilisation valider une évaluation finale
III.9. Créer des sessions
ACTEUR RH
Les ressources humaines créent selon un intervalle de

temps des sessions de fixation de contrat d’évaluation à
RESUME
mi-parcours et finale pour permettre aux agents (Agent N,
N+1 et N+2).
Il doit être authentifié à l’application et doit avoir créé un
PRECONDITION
exercice d’évaluation de performance.
POSTCONDITION Choisir les agents pour une session de fixation de contrat
1) Ils se connectent et sélectionnent l’onglet destiné à la

création de session;
2) Choisissent ensuite le type de session et renseigne les
SCENARIO informations relatives à la session ;
NOMINAL 3) Puis choisissent les agents à affecter à la session dans
le cas d’une fixation d’objectifs.
Tableau 13 : Description textuelle du cas d'utilisation ‘‘créer des sessions’’
36
-
III.9. Donner un niveau de performance
ACTEUR CGPC
RESUME Il donne un niveau de performances à une évaluation
Il doit être authentifié à l’application et l’agent N+2 doit

PRECONDITION avoir validé ou effectué l’évaluation finale de l’agent N
dans le cas où l’évaluation serait jugée surjective.
POSTCONDITION Il laisse la main au DG pour accorder des échelons.
1) Il se connecte et sélectionne l’onglet destiné au

CGPC ;
2) Choisissent ensuite l’exercice et l’agent et visualisent
SCENARIO son résultat issu de l’évaluation;
NOMINAL 3) Puis donne un niveau de performance dans le cas où
l’évaluation serait jugée surjective et laisse la main au
DG.
Tableau 14 : Description textuelle du cas d'utilisation ‘‘donner un niveau de performance’’
III.10. Accorder des échelons
ACTEUR DG, PCA
RESUME Il donne un niveau de performances à une évaluation
Ils doivent être authentifiés à l’application et le CGPC doit

avoir effectué l’étape de donner les niveaux de
PRECONDITION performance (dans le cas du DG)
Le DG doit avoir l’étape d’accordé des échelons (dans le
cas du PCA)
 Dans le cas de l’agent DG celui-ci laisse la main à

l’agent PCA ;
POSTCONDITION  Dans le cas du PCA celui-ci laisse la place aux
ressources humaines pour l’envoi de notification de
performances et avancement.
37
-
1) Ils se connectent et sélectionnent l’onglet destiné au

DG ou au PCA (en fonction de l’acteur) ;
SCENARIO 2) Choisissent ensuite l’exercice et l’agent et visualisent
NOMINAL son résultat issu de l’évaluation et du CGPC;
3) Puis donne un niveau de performance dans le cas où
l’évaluation serait jugée surjective et laisse la main au
PCA dans le cas du DG ou RH afin de clôturer et
archiver l’exercice dans les cas du PCA.
Tableau 15 : Description textuelle du cas d'utilisation ''accorder de échelon''
III.11. Notifier les agents
ACTEUR RH
Ils font la clôture de l’exercice d’évaluation et notifient par

RESUME
mail les agents ayant participé.
Ils doivent être authentifiés à l’application et le PCA doit
avoir fait l’étape d’accordé des échelons
POSTCONDITION Impression d’état

DG ou au PCA (en fonction de l’acteur) ;
2) Choisissent ensuite l’exercice et l’agent et visualisent
son résultat issu de l’évaluation et du CGPC;
SCENARIO
3) Puis donne un niveau de performance dans le cas où
NOMINAL l’évaluation serait jugée surjective et laisse la main au
PCA dans le cas du DG ou RH afin de clôturer et
archiver l’exercice dans les cas du PCA.
Tableau 16 : Description textuelle du cas d'utilisation ''Notifier les agents''
III.12. Faire des impressions d’états
ACTEUR RH
RESUME Imprimer des états pour une gestion administrative
Selon le type d’état,

Pour le contrat d’objectif il faut l’étape que la fixation des
PRECONDITION
objectifs soit effectuée.
Pour le bilan il faut que l’exercice soit clôturé…
POSTCONDITION Néant
38
-

SCENARIO l’impression d’état ;
NOMINAL 2) Choisissent ensuite le type d’état;
3) Puis lance l’impression.
Tableau 17 : Description textuelle du cas d'utilisation ''Faire des impressions d’états''
III.13. Faire des paramétrages
ACTEUR RH
RESUME Faire des paramétrages pour la gestion du processus
PRECONDITION Il doit être authentifié à l’application
POSTCONDITION Néant

SCENARIO paramétrage ;
NOMINAL 2) Choisissent ensuite le type de paramétrage;
3) Puis faire le paramétrage.
Tableau 18 : Description textuelle du cas d'utilisation ''Faire des paramétrages''
39
-
CHAPITRE VI : CONCEPTION DÉTAILLÉE

(CONCEPTION)
I- Modélisation du workflow avec le digramme

d’activité
La description textuelle des digrammes de cas d’utilisation montre qu’il existe une
représentation d’une suite d’opérations effectuées par des acteurs dans certains
processus tels que la fixation du contrat d’objectif, l’évaluation à mi-parcours et finale.
Notons que le processus d’évaluation peut être divisé en deux processus que sont
l’évaluation finale destinée aux agents et une évaluation finale destinée à
l’administration que nous nommerons appréciations des évaluations.
Nous utiliserons le diagramme d’activité pour faire la modélisation du workflow
associé à ces processus. [Annexe 5]
I.1. Workflow fixation du contrat d’objectif

Figure 6 : Workflow fixation du contrat d’objectif
40
-
Description : la fixation du contrat d’objectif est une suite d’opération faisant

intervenir différent acteur avec des actions bien précises que sont ;
 les RH pour la création de session de fixation d’objectif ;

 L’agent N pour la définition de son contrat d’objectif ;
 L’agent N+1 pour la validation du contrat d’objectif ou la redéfinition du
contrat d’objectif de son collaborateur de niveau inférieur en cas de désaccord ;
 L’agent N+2 pour la validation ou la redéfinition du contrat d’objectif de
l’agent N en cas de litige entre ce dernier et son supérieur ;
 Le CGPC pour la validation définitive du contrat d’objectif.
Figure 7 : Workflow évaluation à mi-parcours
I.2. Workflow évaluation à mi-parcours
Description : l’évaluation à mi-parcours est une suite d’opération faisant intervenir

différent acteur avec des actions bien précises que sont ;
 les RH pour la création de session d’évaluation à mi-parcours ;

 L’agent N pour faire des observations sur l’état d’avancement de la réalisation
de son contrat d’objectif ;
 L’agent N+1 faire des observations sur l’état d’avancement de la réalisation de
son contrat d’objectif de son collaborateur de niveau inférieur ;
41
-
 L’agent N+2 faire des observations sur l’état d’avancement de la réalisation de

son contrat d’objectif de l’agent N en tenant compte des observation de l’agent
N+1;
I.3. Workflow évaluation finale
Figure 8 : Workflow évaluation finale
Description : l’évaluation à finale est une suite d’opération faisant intervenir différent
acteur avec des actions bien précises que sont ;
 les RH pour la création de session d’évaluation finale ;

 L’agent N pour son autoévaluation notée sur la réalisation de son contrat
d’objectif ;
 L’agent N+1 pour la validation de l’évaluation du contrat d’objectif de l’agent
N ou la réévaluation en cas de désaccord ;
 L’agent N+2 pour la validation ou la réévaluation du contrat d’objectif de
l’agent N en cas de litige entre ce dernier et son supérieur ;
42
-
I.4. Workflow appréciation des évaluations
Figure 9 : Workflow appréciation des évaluations
Description : l’appréciation des évaluations qui est la suite de l’évaluation à finale est
une suite d’opération faisant intervenir différent acteur avec des actions bien
précises que sont ;
 Le CGPC pour donner des niveaux de performances à des évaluations ;

 Le DG pour accorder des échelons à un agent ;
 Le PCA pour accorder des échelons à un agent ;
 Les RH pour la clôture du processus d’appréciation des performances et l’envoi
des notifications sur le niveau de performances et les avancements
II- Elaboration des digrammes de séquences
Le diagramme de séquence est une représentation de façon séquentielle du

déroulement des traitements et des interactions entre les éléments du système et/ou de
ses acteurs. . [Annexe 6]
43
-
II.1. S’authentifier
Figure 10 : diagramme de séquence ''S'authentifier''

II.2. Définir son contrat d’objectif
Figure 11 : diagramme de séquence ''définir son contrat d'objectif ''
44
-
II.3. Faire une autoévaluation à mi-parcours
Figure 12 : diagramme de séquence ''faire une autoévaluation à mi-parcours''
II.4. Faire une autoévaluation finale
Figure 13 : diagramme de séquence ''faire une autoévaluation finale''
45
-
II.5. Valider un contrat d’objectif
Figure 14 : diagramme de séquence ''faire un contrat d’objectif''
46
-
II.6. Valider une évaluation finale
Figure 15 : diagramme de séquence ''valider une évaluation finale ''
47
-
II.7. Valider une évaluation à mi-parcours
Figure 16 : diagramme de séquence ''valider une évaluation à mi-parcours’’
II.8. Voir l’historique
Figure 17 : diagramme de séquence '' voir l'historique’’
48
-
II.9. Créer des sessions
Figure 18 : diagramme de séquence " créer des sessions"
II.10. Donner un niveau de performance
Figure 19 : diagramme de séquence "donner un niveau de performance"
49
-
II.11. Accorder des échelons
Figure 20 : diagramme de séquence "accorder des échelons"
II.12. Faire des impressions d’états
Figure 21 : diagramme de séquence "faire des impression"
50
-
II.13. Faire des paramétrages
Figure 22 : diagramme de séquence "faire de paramétrages"
III- Elaboration du diagramme de classe
Le diagramme de classes est le diagramme le plus important de la modélisation objet.

C’est une représentation statique des objets du système qui interagissent pour réaliser
les cas d’utilisation. En nous basant sur nos diagrammes de séquence, nous réalisons
ci-dessous le diagramme de classes de notre système (voir figure 22 ci-dessous).
[Annexe 7] :
51
-
III.1. Le diagramme de classe de l’application
Figure 23 : diagramme de classe de l'application
52
-
III.2. Description du diagramme de classe

Ce diagramme ci-dessus (figure22) représente les classes nécessaires pour
assurer un bon fonctionnement du système à mettre en œuvre. Ce diagramme est décrit
comme suit :
 la classe enploye représente l’ensemble des employés de la CRRAE-UMOA

concernés par le processus de management de performances ;
 la classe absence représente les absences d’un employé lors du processus de
management de performances ;
 la classe avancement représente les avancements d’un employé lors du
processus de management de performances ;
 la classe exercice représente la période de déroulement du processus de
management des performances (sur une année) ;
 la classe session représente les différentes sessions du processus de
managements des performances ;
 la classe typesession représente les types de session intervenant dans le
processus de management de performances (fixation de contrat, évaluation à
mi-parcours et finale) ;
 la classe contrat représente le résumé du contrat d’objectif d’un agent sur un
exercice ;
 la classe detailcontrat représente les détails du contrat d’objectif d’un agent ;
 la classe typedetailcontrat représente les parties de la fixation du contrat
d’objectif que sont les activités courantes, les objectifs spécifiques et le savoir
être ;
 la classe evaluation représente les évaluations dans le processus de
management des performances ;
 la classe hierachie représente la hiérarchie au sein de la CRRAE-UMOA ;
 la classe affectation représente les affectations au sein de la CRRAE-UMOA ;
 la classe poste représente les postes présent au sein de la CRRAE-UMOA ;
 la classe direction représente les directions présentes au sein de la CRRAE-
UMOA ;
 la classe structure représente les divisions présentes au sein de la CRRAE-
UMOA ;
53
-
TROISIÈME PARTIE :
IMPLÉMENTATION
Cette dernière partie abordera dans un premier temps la présentation des éléments
nécessaires à l’implémentation de notre application puis le second volet présenterons
les interfaces issu de l’implémentation et terminerons par un bilan de la réalisation
du projet.
54
-
CHAPITRE VII : ENVIRONNEMENT DE

DÉVELOPPEMENT
I- Les outils de développements

I.1. Le Framework laravel
Laravel est un cadre de travail, c'est-à-dire un ensemble d’outil visant à faciliter
le travail du développeur en regroupant en général les fondations d’un logiciel
informatique ou d’une application web. Il a été écrit en PHP, basé sur l’architecture
MVC et créé par Taylor Otwel. Il a été, en ce sens, construit en se basant sur Symfony,
un autre Framework PHP reconnu mondialement pour sa robustesse.
De ce fait, il embarque des briques logicielles testées et approuvées par une grande
communauté permettant d’améliorer la rapidité des développements et la robustesse
l’application[8].
I.2. Microsoft SQLServer

Microsoft SQL Server est un système de gestion de base de données (SGBD) Son rôle
est de stocker les données, sous forme de tables, et de permettre la manipulation de ces
données à travers les requête SQL. Développé et commercialisé par la
société Microsoft, il incorpore un SGBDR (SGBD relationnel) et il est multi-thread
(peut exécuter plusieurs processus en même temps), multi-utilisateur, multibase et
multischéma. Il fonctionne sous les OS Windows et Linux (depuis mars 2016), mais il
est possible de le lancer sur Mac OS via Docker.
I.3. SQLServer Manager studio
SQL Server Management Studio (SSMS) est l'outil multilingue de gestion des
bases de données de Microsoft SQL Server et permet l'interaction entre le
code SQL nécessaire à la manipulation des bases de données par les développeurs,
comme à la gestion par les administrateurs de bases de données des différentes
instances SQL Server.
55
-
I.4. Apache
Apache est un serveur web, permettant à des clients d'accéder à des pages web
à partir d'un navigateur. Son rôle est d'interpréter les requêtes HTTP arrivant sur le
port associé au protocole HTTP (port 80 par défaut), et de fournir une réponse à travers
ce même protocole.
I.5. Gitea
Gitea est une forge logicielle libre en Go sous licence MIT, pour
l'hébergement de développement logiciel, basé sur le logiciel de gestion de versions
Git pour la gestion du code source, comportant un suivi de tickets de bugs, un wiki,
ainsi que des outils pour la relecture de code. Il comporte également un système
d'extension, fournissant notamment de l'intégration continue, avec les plugins Agola,
appveyor, Concourse, Metroline ainsi que de la livraison continue avec drone et
Metroline.
I.6. Visual studio code

Visual Studio Code est un éditeur de code extensible développé
par Microsoft pour Windows, Linux et macOS. Il permet d’éditer du code dans plus
44 langages de programmations différents offrant aussi la possibilité de télécharger
des extensions pour gérer d'autres langages que ceux qui sont inclus par défaut.
Les fonctionnalités incluent la prise en charge du débogage, la mise en évidence de la

syntaxe, la complétion intelligente du code, les snippets, la refactorisation du code
et Git intégré. Les utilisateurs peuvent modifier le thème, les raccourcis clavier, les
préférences et installer des extensions qui ajoutent des fonctionnalités
supplémentaires.
II- Langage de développement
II.1. HTML/CSS
HTML (HyperText Markup Language) : est le langage de balisage conçu

pour représenter les pages web. C’est un langage permettant d’écrire de l’hypertexte,
56
-
d’où son nom. HTML permet également de structurer sémantiquement et logiquement

et de mettre en forme le contenu des pages, d’inclure des ressources multimédias dont
des images, des formulaires de saisie et des programmes informatiques.
CSS (Cascading style Sheets) : est un langage informatique qui décrit la

présentation des documents HTML et XML. Il permet entre autres de définir
l’apparence des textes (taille, police, couleur…), l’agencement ainsi que bien d'autres.
II.2. Javascript
JavaScript est un langage de programmation de scripts principalement employé

dans les pages web interactives mais aussi pour les serveurs. C'est un langage orienté
objet à prototype, c'est-à-dire que les bases du langage et ses principales interfaces sont
fournies par des objets qui ne sont pas des instances de classes, mais qui sont chacun
équipés de constructeurs permettant de créer leurs propriétés, et notamment une
propriété de prototypage qui permet d'en créer des objets héritiers personnalisés.
II.3. PHP
PHP (Hypertext Preprocessor) est un langage de script, permettant de d’écrire

dans unepage web, un affichage dynamique d'information via un serveur HTTP, c'est-
à-dire quele texte affiché peut dépendre des variables. Le langage PHP est utilisé en
tant que langage de script côté serveur(Apache), ce qui veut dire que c'est le serveur
qui va interpréter le code PHP et générer du code (constitué généralement de XHTML
ou de HTML, de CSS, et parfois de JavaScript) qui pourra être interprété par un
navigateur.
Pour la mise en place de l’application la version de PHP utilisée est le 7.2.
II.4. Blade
Blade est un mini-langage de programmation propre à laravel qui permet

d’écrire des scripts dans du code HTML, Ce script sera interprété par le moteur de
template de laravel qui va le traduire en du code PHP définitive. Il est d’une grande
utilité dans la manipulation des données avec des syntaxes typiques pour le formatage
de données, des expressions et des structures de contrôle basique (if/else, for …).
57
-
II.5. SQL
SQL (Structured Query Language) est un langage informatique normalisé

servant à exploiter des bases de données relationnelles. Il se subdivise en :
 une partie langage de manipulation des données de SQL permet de
rechercher, d'ajouter, de modifier ou de supprimer des données dans
les bases de données relationnelles ;
 une partie langage de définition des données permet de créer et de
modifier l'organisation des données dans la base de données ;
 une partie langage de contrôle des données permet d'autoriser ou
d'interdire ;
 l'accès à certaines données à certaines personnes ;
 une partie langage de contrôle de transaction permet de commencer et
de terminer des transactions.
III- Les bibliothèques utilisées
III.1. Bootstrap
Bootstrap est une collection d'outils utile à la création du design (graphisme,

animation et interactions avec la page dans le navigateur ...) de sites et d'applications
web. C'est un ensemble qui contient des codes HTML et CSS, des formulaires,
boutons, outils de navigation et autres éléments interactifs, ainsi que des extensions
JavaScript en option.
III.2. jQuery
JQuery est une bibliothèque Javascript libre et multiplate-forme créée pour faciliter
l'écriture de scripts côté client dans le code HTML des pages web. La bibliothèque
contient notamment les fonctionnalités suivantes :
 parcours et modification du DOM ;
 événements ;
 effets visuels et animations ;
58
-
 manipulations des feuilles de style en cascade (ajout/suppression des classes,

d'attributs…) ;
 Ajax ;
 plugins ;
 utilitaires (version du navigateur web…).
59
-
CHAPITRE VIII : MISE EN OEUVRE
I. Mise en œuvre des mesures de sécurité de l’application

L’application dédiée au système de management des performances va sans doute
contenir de donnes à caractères personnelle. Et vu le règlement général sur la
protection des données(RGPD), il est primordiale de mettre œuvre des mesure de
sécurité de l’application. Ceci étant, nous nous sommes basés sur la liste des dix (10)
principales vulnérabilités les plus critiques des applications Web du projet de sécurité
des applications web ouvertes (OWASP) comme principal guide pour la mise en œuvre
des mesures de sécurité (Nous allons nous limiter aux vulnérabilités liées à
l’application WEB et non au serveur ).
I.1. L’injection
La faille d'injection, telles que l'injection SQL, NoSQL, OS et LDAP, se produit
lorsque des données non fiables sont envoyées à un interpréteur dans le cadre d'une
commande ou d'une requête. Les données hostiles de l'attaquant peuvent inciter
l'interpréteur à exécuter des commandes involontaires ou à accéder aux données sans
autorisation appropriée. Dans le cas de notre application, nous somme exposé à
l’injection SQL ;
Mesure de sécurité : Comme mesure de sécurité, nous avons opté pour le générateur
de requêtes Laravel qui utilise la liaison de paramètres PDO pour protéger l'application
contre les attaques par injection SQL (les valeurs passées paramètres nettoyées
automatiquement) contrairement à l’exécution des requêtes SQL brutes.
I.2. L’Authentification rompue

Elle est dû à la mauvaise implémentation des fonctions applicatives liées à
l'authentification et à la gestion de session, ce qui permet aux attaquants de
compromettre les mots de passe, les clés ou les jetons de session, ou d'exploiter d'autres
failles d'implémentation pour assumer temporairement ou définitivement l'identité des
autres utilisateurs.
Mesure de sécurité : Comme mesure de sécurité, nous avons opté pour la limitation
du nombre de tentatives de connexion avec un middleware utilisé immédiatement dans
60
-
les routes et contrôleurs pour limiter les requêtes, limitation de la durée de session a
60 minutes et le chiffrage de des données de session.
I.3. Exposition de données sensibles

Les données sensibles repos ou en transit, peuvent être compromis sans
protection supplémentaire, Elles nécessitent des précautions particulières lorsqu'elles
sont échangées avec le navigateur.
Mesure de sécurité : Comme mesure de sécurité, il faut opter pour un protocole

d’échange sécurisé comme le HTTPS avec un certificat TLS. Aussi rediriger les
utilisateurs qui essaient d'accéder à l'équivalent HTTP vers la route sécurisée.
I.4. Contrôle d’accès rompu

La mauvaise application des restrictions sur ce que les utilisateurs authentifiés
sont autorisés à faire. Peut-être exploiter par les attaquants pour accéder à des
fonctionnalités et / ou des données non autorisées, comme accéder aux comptes
d'autres utilisateurs, afficher des fichiers sensibles, modifier les données d'autres
utilisateurs, modifier les droits d'accès, etc.
Mesure de sécurité : Comme mesure de sécurité, il faut opter pour l’implémentation

des packages RBAC (Role-Based Access Control) pour gérer les autorisations et les
rôles des utilisateurs dans l’application.
I.5. Scriptage intersite (XSS)

XSS permet aux attaquants d'exécuter des scripts dans le navigateur de la
victime, ce qui peut détourner les sessions des utilisateurs, altérer les sites Web ou
rediriger l'utilisateur vers des sites malveillants. Elles permettent aux attaquants
d'exécuter des scripts dans le navigateur de la victime, ce qui peut détourner les
sessions des utilisateurs, altérer les sites Web ou rediriger l'utilisateur vers des sites
malveillants.
Mesure de sécurité : Comme mesure de sécurité, il faut opter de ne pas afficher les
entrées fournies par l'utilisateur sans échapper aux données grâces moteur de template
de Laravel, Blade, qui échappe automatiquement le contenu rendu en utilisant la {{
$var }} .
61
-
II. Présentation des interfaces de l’application

II.1. Interface de connexion
Figure 24 : interface de connexion
Cette interface permettra aux utilisateurs de s’authentifier à l’application.
II.2. Tableau de bord
Figure 25 : Tableau de bord
Cette interface constitue le tableau de bord de l’utilisateur et est constituée :

 des informations sur l’agent N à savoir le nom, les prénoms, le matricule, la
catégorie, la date d’embauche, la date d’affectation au poste, la direction, la
division et le poste occupé ;
62
-
 d’une courbe d’évolution des évaluations et des échelons par année ;

 de raccourci vers des évaluations ;
 de l’historique des évaluations des 4 derniers exercices ;
 de la liste des agents N-1 et N-2 sous sa responsabilité avec une possibilité
d’évaluer en tant que N+1 ou N+2 et aussi de voir les détails sur l’agent
sélectionné.
II.3. Interface fixation de contrat d’objectif
Figure 26 : Interface contrat d'objectif
63
-
Cette interface permettra à l’agent de définir son contrat d’objectifs sur

l’exercice en cours. Pour cette partie, Il devra définir les pondérations de ses activités
courantes et son savoir être et ajouter ses objectifs spécifiques de l’année.
Cette interface est similaire à celui des agents N+1 et N+2 et aussi à celui du
CGPC.
II.4. Interface d’évaluation à mi-parcours
Figure 27 : Interface évaluation à mi-parcours
Cette interface permettra à l’agent de faire des commentaires sur l’évolution

de son contrat d’objectif. Pour cette partie, Il devra faire des commentaires sur ses
activités courantes, son savoir être et ses objectifs spécifiques de l’année.
64
-
Cette interface est similaire à celui des agents N+1 et N+2.
II.5. Interface d’évaluation finale
Figure 28 : interface évaluation finale
Cette interface permettra à l’agent de faire une évaluation notée de son

contrat d’objectif. Pour cette partie, Il devra noter ses activités courantes, son savoir
être et ses objectifs spécifiques de l’année.
Cette interface est similaire à celui des agents N+1 et N+2.
65
-
II.6. Interface de création d’exercice
Figure 29 : interface création de d’exercice
Cette interface permettra aux ressources humaines de créer des exercices pour le
déroulement du processus de management des performances.
II.7. Interface de la liste de session
Figure 30 : Interface de création de session
Cette interface permettra aux ressources humaines de créer des sessions pour les
processus de fixation de contrat, d’évaluation à mi-parcours et d’évaluation finale.
66
-
II.8. Interface de collaborateurs de niveau inférieur
Figure 31 : Interface agent
Cette interface permettra aux collaborateurs de niveau supérieur pour les

processus de fixation de contrat, d’évaluation à mi-parcours et d’évaluation finale de
l’agent.
II.9. Interface profile agent
Figure 32 : Interface profile agent
Cette interface permettra aux collaborateurs de niveau supérieur d’avoir des

informations sur l’agent.
67
-
CHAPITRE IX : BILAN DU PROJET
I. Bilan
Au vu de la méthode de gestion adopté (Scrum), il a fallu diviser le projet en des

modules (sprint) pour la réalisation. Pour cela nous avons recensé au total 8 modules
que sont :
 l’authentification ;
 la fixation du contrat d’objectif ;
 l’évaluation à mi-parcours ;
 l’évaluation finale ;
 les appréciations ;
 les historiques ;
 la sécurité de l’application ;
 les paramétrages.
À la date du 08/10/2020 s’est tenue une rencontre avec le product owner sur l’état
d’avancement du projet. Sur les 8 modules listés seulement 6 ont pu être réalisés soit
un taux d’avancement de 80%. Aussi il en est ressorti une incompréhension de besoin
sur le module de fixation d’objectif plus précisément les objectifs spécifiques qui
doivent avoir des sous objectifs nécessaires à l’accomplissement de l’objectif. Hormis
cela le product owner s’est dit satisfaire de l’état d’avancement et espère voir
l’application en production la plus tôt possible.
II. Les difficultés rencontrées
La principale difficulté rencontrée lors de la réalisation de ce projet se situe au

niveau de la mise place du système d’authentification avec l’active directory. En
effet, le plugin qui permettait l’authentification à l’application depuis l’active
directory était peu documenté et peu utilisé d’où la difficulté de la mettre en place. A
cela peut s’ajouter la modélisation dont le début nous a été un peu difficile. Cela est
dû à l’absence de notions en atelier génies logiciels car le cursus suivi est plus orienté
sécurité des systèmes d’information et dispose presque de cours de génie logiciel.
Cependant, la lecture et les recherches nous ont permis de pallier cette difficulté.
68
-
III. Les perspectives
Comme perspective en vue d’amélioration de l’application, nous devons :
 prendre en compte les remarques sur l’incompréhension du besoin lié à

la fixation du contrat d’objectif ;
 trouver une alternative au système d’authentification de l’application ;
 mettre en place le état présentable pour les impressions ;
 terminer l’application et la mettre en production.
69
-
CONCLUSION
Ce mémoire documente le travail effectué lors de notre stage de quatre mois

au sein de la Caisse de Retraite par Répartition Avec Epargne de l’Union Monétaire
Ouest Africaine (CRRAE-UMOA) dans le cadre de l’obtention du diplôme de
Master. Ce travail a consisté à mettre une application dédiée au système de
management des performances visant à faciliter la gestion du processus.
Pour cela, nous avons fait en premier lieu une présentation générale du
projet avec tous ses contours et par la suite faire l’état de l’art sur sa réalisation
afin de faire des choix nécessaires à la mise en place du projet. Ensuite, nous avons
fait l’étude du système existant afin de mieux appréhender les besoins et identifier
les acteurs. Nous sommes allés plus loin avec la phase conceptuelle générale et
détaillée ou nous avons décrit les besoins de chaque acteur sous forme de cas
d’utilisation. Et pour chaque cas d’utilisation, nous avons fait la description
textuelle qui nous a permis de mettre en évidence les différents workflows et établit
le diagramme de séquence dont l’objectif était de représenter les interactions entre
les objets du système tout en indiquant la chronologie des échanges. Aussi, la
réalisation d’un modèle statique représenté par le diagramme de classes. Enfin, on
a pris le temps de réaliser à bien notre application tout en spécifiant les outils de
développements ainsi que les langages de programmation utilisés, suivi d’un
aperçu des interfaces que comprend celle-ci.
Ce travail nous a permis d’acquérir une expérience personnelle et

professionnelle. Il nous a été très bénéfique car nous avons eu la chance d’avoir
des compétences dans le domaine du génie logiciel étant donné que nous avons fait
la sécurité des systèmes d’information et que celui-ci demande d’avoir une vue
transversale.
Ce travail étant réalisé à un taux de 80%, nous pouvons dire que le système
de management des performances des agents de la CRRAE-UMOA est loin d’être
achevé, il serait donc judicieux de la terminer afin de la mettre en production pour
le bonheur des agents.
70
-
BIBLIOGRAPHIE / WEBOGRAPHIE
[1] https://www.uni2growcameroun.com/application-mobile-desktop-web-laquelle-
choisir/# consulté le 12/10/2020 ;
[2] http://ineumann.developpez.com/tutoriels/merise/initiation-merise consulté le

12/10/2020 ;
[3] Dominique NANCI, Bernard ESPINASSE, Ingénierie des systèmes d’information :

MERISE deuxième génération, Vuibert, 4e édition 2000, 538 pages ;
[4] https://fr.slideshare.net/faroukgh/uml-processus-unifi consulté le 12/10/2020 ;
[5] http://xavier.mehaut.free.fr/publications/LivreBlanc%20-%20OpenUp%20-
%20v1.11.doc, consulté le 12/01/2020 ;
[7] http://www.bawiki.com/wiki/concepts/sdlc-process-models/unified-process/,
consulté le 17/10/2020 ;
[8] MAURICE CHAVELLI, Découvrez le Framework PHP LARAVEL, Paris,

ÉDITIONS EYROLLES www.editions-eyrolles.com, 08/09/2016, 325 pages ;
[9] PASCAL ROQUES, UML 2 Modéliser une application Paris, ÉDITIONS

EYROLLES www.editions-eyrolles.com, 02/02/2006, 246 pages.
[10] PASCAL ROQUES, UML 2 par la pratique, Paris, ÉDITIONS EYROLLES

www.editions-eyrolles.com, 17/04/2008, 236 pages.
[11] KABLY HAMID Conception et réalisation d’une application web de gestion

d’école, UNIVERSITE SIDI MOHAMED BEN ABDELLAH Soutenu le : 15 / 06 /
2017,
[12] BAHRI Mustapha et HAMDAOUI Ahmed Conception et réalisation d’une

application web e-commerce Université ABDERRAHMANE MIRA BEJAÏA, 2017,
70 pages,
71
-
ANNEXE
ANNEXE 1 : Fiches de contrat d’objectifs fonctionnels individuel
72
-
ANNEXE 2 : Fiche d’appréciation des performances à mi-parcours
73
-
ANNEXE 3 : Fiche d’évaluation à finale
FICHE D'APPRECIATION DES PERFORMANCES

I – IDENTIFICATION
Année :
Direction :
Division :
Mois Année Mois Année

Période d’évaluation : de à
JANVIER 2018 DÉCEMBRE 2018
Entretien planifié le :
AGENT A EVALUER (N)
Nom : Poste :
Direction : Division : -
Catégorie : Date d'embauche :
Matricule Ancienneté à la Caisse :
AVANCEMENT ET PROMOTIONS DES 5 DENIERS EXERCICES
Nb Echelons Nb Echelons Nb Echelons Nb Echelons Nb Echelons Nb Echelons

Exercice 2012 Exercice 2013 Exercice 2014 Exercice 2015 Exercice 2016 Exercice 2017
ABSENCES EN DEHORS DU CONGE ANNUEL

Nombre de jours
(au cours de l'exercice 2018)
Congés pour maladie ou accident
Congés de maternité
Congés exceptionnels
74
-
Congés divers
Autres absences
TOTAL 0
SUPERIEUR HIERARCHIQUE DIRECT (N+1)
Nom : Poste :
Direction: Division :
SUPERIEUR HIERARCHIQUE DIRECT (N+2)
Nom : Poste :
Direction : Division :
NB : cette page est à remplir par la DARH
ANNEXE 4 : Concepts de base diagramme de cas d’utilisation
Le diagramme de cas d'utilisation se compose de trois éléments principaux :
Un Acteur : Entité extérieure qui interagit avec le système. Il se représente par un petit
bonhomme avec son nom inscrit dessous.
Un cas d’utilisation : représentation d’une fonctionnalité du système. Le cas

d’utilisation se représente par une ellipse contenant un nom décrivant la fonctionnalité.
Les relations : Il existe trois types que sont :
75
-
• L’association entre cas et acteur illustré par le fait que l'acteur demande un
service au système, on la représente par une association entre un acteur et un
cas d’utilisation par une ligne pleine.
Figure 8: représentation d’une association cas d'utilisation et acteur UML
• Les relations entre les cas d’utilisation : il en existe trois avec leur
caractéristique et symbole :
Inclusion : B est une partie obligatoire de A et on lit A inclut B (dans le sens

de la flèche).
Figure 9: représentation d’une inclusion entre cas d'utilisation UML
Extension : B est une partie optionnelle de A et on lit B étend A (dans le sens

de la flèche).
Figure 10: représentation d’une extension entre cas d'utilisation UML
Généralisation : le cas A est une généralisation du cas B et on lit B est une

sorte de A.
• Les relations entre acteurs : La seule relation possible entre deux acteurs est la
généralisation, un acteur A est une généralisation d’un acteur B si l’acteur A
peut-être substitué par l’acteur B. Dans ce cas, tous les cas d’utilisation
accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.
76
-
ANNEXE 5 : Concepts de base diagramme d’activité
Le diagramme d’activités se compose d’éléments que sont :
un nœud d’activité : représente une exécution d’un mécanisme, autrement dit, un

déroulement d’étapes séquentielles. Il est représenté par un rectangle aux coins
arrondis qui contient sa description textuelle.
Figure 17 : représentation d'un nœud d’activité UML
une transition : Le passage d’une activité vers une autre est matérialisé par une
transition. Graphiquement les transitions sont représentées par des flèches en traits
pleins qui connectent les activités entre elles. Elles sont déclenchées dès que l’activité
source est terminée et provoquent automatiquement et immédiatement le début de la
prochaine activité à déclencher.
un nœud de décision : C’est un nœud de contrôle qui permet de faire un choix entre
plusieurs flots sortants. Il possède un arc entrant et plusieurs arcs sortants,
accompagnés de conditions de garde pour conditionner le choix. Il est représenté par
un losange.
ANNEXE 6 : Concepts de base diagramme de séquence
77
-
Les Lignes de vie : Une ligne verticale en trait pointillés, qui représente la séquence
des événements, produite par un participant, pendant une interaction, alors que le
temps progresse en bas de ligne.
Les Messages : Un message définit une communication particulière entre des lignes
de vie (objets ou acteurs). Sa réception provoque une période d’activité (rectangle
vertical sur la ligne de vie) marquant le traitement du message.
Plusieurs types de messages existent, dont les plus courants :
• l’envoi d’un signal ;

• l’invocation d’une opération (appel de méthode) ;
• la création ou la destruction d’un objet
Fragments : Un fragment (ou cadre) permet d’identifier une sous-partie d’une

interaction afin que celle-ci soit référencées par d’autres interactions ou de lui
spécifier des conditions particulières d’exécution (boucle, optionnel, ...).
Quelques exemples des fragments :
 sd : fragment du diagramme de séquence
en entier.
 alt : fragment alternatif (Si ... Alors ...
Sinon ...).
 ref : référence à une interaction dans un
autre diagramme.
78
-
ANNEXE 6 : Concepts de base diagramme de class
Classe : est une description abstraite (condensée) d’un ensemble d’objets.

Elle définit leur structure, leur comportement et leurs relations.
Les classes sont représentées par des rectangles compartimentés :
1er compartiment représente le nom de la classe
2ème compartiment représente les attributs de la classe
3ème compartiment représente les opérations de la classe
• un attribut : représente la modélisation d’une information élémentaire

représentée par son nom et son format.
• une opération : est une fonctionnalité assurée par une classe.
Une association : est une relation entre deux classes (association binaire) ou plus
(association n-aire), qui décrit les connexions structurelles entre leurs instances. Une
association indique donc qu'il peut y avoir des liens entre des instances des classes
associées.
Chaque classe qui participe à l’association joue un rôle défini par 2 propriétés
79
-
• la multiplicité : elle définit le nombre d’instances de l’association pour une

instance de la classe. La multiplicité est définie par un nombre entier ou un
intervalle de valeurs. Quelques exemples de multiplicité :
 exactement un : 1 ou 1..1
 plusieurs : * ou 0..*
 au moins un : 1..*
 de un à six : 1..6
• la navigabilité : indique si l’association fonctionne de manière unidirectionnelle

ou bidirectionnelle. Par défaut les associations sont navigables dans les deux
sens.
Dans certains cas, une seule direction de navigation est utile.
Une classe-association : Elle possède les caractéristiques des associations et des

classes : elle se connecte à deux ou plusieurs classes et possède également des attributs
et des opérations.
80
-
TABLE DES MATIÈRES
DEDICACE ............................................................................................................................. II
REMERCIEMENTS .............................................................................................................. III
AVANT-PROPOS ................................................................................................................. IV
LISTE DES FIGURES ........................................................................................................... V
LISTE DES TABLEAUX...................................................................................................... VI
LISTE DES SIGLES ET ABRÉVIATIONS ........................................................................ VII
SOMMAIRE ....................................................................................................................... VIII
INTRODUCTION ................................................................................................................... 1
PREMIÈRE PARTIE : GÉNÉRALITÉS ................................................................................. 1
CHAPITRE I : PRÉSENTATION GÉNÉRALES ................................................................... 4
I- Présentation de CRRAE-UMOA ................................................................................. 4
II- Contexte du projet .................................................................................................... 5
III- Présentation du cahier de charge .............................................................................. 5
III.1. Présentation du projet....................................................................................... 5
III.2. Les objectifs du projet ...................................................................................... 6
III.3. Description de quelques opérations ................................................................. 6
III.4. Contraintes ....................................................................................................... 7
CHAPITRE II : ÉTAT DE L’ART SUR LA REALISATION DU PROJET .......................... 9
I- Présentation des types d’applications .......................................................................... 9
I.1. Présentation des applications bureau/desktop ...................................................... 9
I.2. Présentation des applications web........................................................................ 9
I.3. Présentation des applications mobile ................................................................. 10
II- Présentation des méthodes de développement d’une application .......................... 10
II.1. Présentation de la méthode MERISE ................................................................. 10
II.1.a. La démarche classique ................................................................................... 11
II.1.b. La démarche classique ................................................................................... 11
II.2. Présentation du processus unifié ........................................................................ 11
II.2.a. Le Two Tracks Unified Process (2TUP) ........................................................ 11
II.2.b. Le Rational Unified Process (RUP) ............................................................... 12
II.2.c. L'enterprise Unified Process (EUP) ............................................................... 12
II.2.d. L'eXtreme Unified Process (XUP) ................................................................. 12
II.2.e. L'Open Unified Process (OpenUP) ................................................................ 13
II.2.f. L'Essential Unified Process (EssUP) ............................................................. 13
CHAPITRE III : CHOIX ET JUSTIFICATION ................................................................... 14
81
-
I- Choix du type d’application ....................................................................................... 14

I.1. Etude comparative du types d’application ......................................................... 14
I.2. Présentation du motif architecturel .................................................................... 14
II- Choix de la méthode de développement ................................................................ 15
II.1. Etude comparative des méthodes développement.............................................. 15
II.1. Présentation de la méthode EssUP ..................................................................... 17
II.1. Présentation de UML ......................................................................................... 19
III- Choix de la méthode de gestion du projet .............................................................. 21
DEUXIÈME PARTIE : ETUDE CONCEPTUELLE ............................................................ 24
CHAPITRE VI : ETUDE DU SYSTÈME EXISTANT ET IDENTIFICATION DES
BESOINS (INCEPTION) ...................................................................................................... 25
I. Description du système existant ................................................................................. 25
II. Critique de l’existant .................................................................................................. 25
III. Proposition de solutions ......................................................................................... 26
IV. Spécification des besoins ....................................................................................... 26
V. Identification des acteurs ........................................................................................... 27
CHAPITRE V : CONCEPTION GÉNÉRALE (ANALYE) .................................................. 28
I- Matrices des fonctionnalités et des acteurs ................................................................ 28
II- Elaboration des digrammes des cas d’utilisation ................................................... 29
II.1. Digramme des cas d’utilisation au niveau agent ................................................ 30
II.2. Digramme des cas d’utilisation au niveau administratif .................................... 31
III- Description textuelle des digrammes des cas d’utilisation .................................... 32
III.1. S’authentifier.................................................................................................. 32
III.2. Définir son contrat d’objectif ......................................................................... 32
III.3. Faire une autoévaluation à mi-parcours ......................................................... 33
III.4. Faire une autoévaluation finale ...................................................................... 33
III.5. Voir l’historique des évaluations ................................................................... 34
III.6. Valider un contrat d’objectif .......................................................................... 34
III.7. Faire une évaluation à mi-parcours ................................................................ 35
III.8. Valider une évaluation finale ......................................................................... 36
III.9. Créer des sessions .......................................................................................... 36
III.9. Donner un niveau de performance ................................................................. 37
III.10. Accorder des échelons ................................................................................... 37
III.11. Notifier les agents .......................................................................................... 38
III.12. Faire des impressions d’états ......................................................................... 38
III.13. Faire des paramétrages ................................................................................... 39
CHAPITRE VI : CONCEPTION DÉTAILLÉE (CONCEPTION) ....................................... 40
I- Modélisation du workflow avec le digramme d’activité............................................ 40
82
-
I.1. Workflow fixation du contrat d’objectif ............................................................ 40

I.2. Workflow évaluation à mi-parcours................................................................... 41
I.3. Workflow évaluation finale ............................................................................... 42
I.4. Workflow appréciation des évaluations ............................................................. 43
II- Elaboration des digrammes de séquences .............................................................. 43
II.2. Définir son contrat d’objectif ............................................................................. 44
III- Elaboration du diagramme de classe ...................................................................... 51
TROISIÈME PARTIE : ......................................................................................................... 54
IMPLÉMENTATION ............................................................................................................ 54
CHAPITRE VII : ENVIRONNEMENT DE DÉVELOPPEMENT ...................................... 55
I- Les outils de développements .................................................................................... 55
I.1. Le Framework laravel ........................................................................................ 55
I.2. Microsoft SQLServer ......................................................................................... 55
I.3. SQLServer Manager studio ................................................................................ 55
I.4. Apache ............................................................................................................... 56
I.5. Gitea ................................................................................................................... 56
I.6. Visual studio code .............................................................................................. 56
II- Langage de développement .................................................................................... 56
II.1. HTML/CSS ........................................................................................................ 56
II.2. Javascript............................................................................................................ 57
II.3. PHP .................................................................................................................... 57
II.4. Blade .................................................................................................................. 57
II.5. SQL .................................................................................................................... 58
III- Les bibliothèques utilisées .................................................................................... 58
III.1. Bootstrap ........................................................................................................ 58
III.2. jQuery ............................................................................................................ 58
CHAPITRE VIII : MISE EN OEUVRE ................................................................................ 60
I.1. L’injection .......................................................................................................... 60
I.2. L’Authentification rompue ................................................................................ 60
I.3. Exposition de données sensibles ........................................................................ 61
I.4. Contrôle d’accès rompu ..................................................................................... 61
I.5. Scriptage intersite (XSS) .................................................................................... 61
CHAPITRE IX : BILAN DU PROJET ................................................................................. 68
CONCLUSION ...................................................................................................................... 70
BIBLIOGRAPHIE / WEBOGRAPHIE ................................................................................. 71
ANNEXE ............................................................................................................................... 72
83
-
RESUME
Dans ce travail, Il était question de concevoir et développer une application

dédiée au système de management de performances des agents de la CRRAE-
UMOA. Ce projet nous a permis d’aboutir à la mise en place d’une application web
avec un taux d’avancement de 80%. Au travers de nos recherches, nous avons
connu plusieurs méthodes de développement d’applications regroupées en deux
grandes catégories à savoir le Processus Unifié (Unified Process) et MERISE. Pour
la conception et le développement, nous avons fait le choix de la
méthode Essential Unified Process (EssUP) qui a permis à mieux appréhender les
besoins et identifier les acteurs. Cela a permis de mettre en place les diagrammes
de cas d’utilisation, de séquences et le digramme de classe. Grâce à cette
modélisation nous avons pu aborder aisément la phase d’implémentation. Ce qui a
été fait avec le framework laravel et dans plusieurs langages à savoir le PHP, le
HTML/CSS, le Javascript, le SQL et Blade.
ABSTRACT
In this work, it was a question of designing and developing an application

dedicated to the performance management system of agents of the CRRAE-
UMOA. This project allowed us to set up a web application with an 80% progress
rate. Through our research, we have experienced several application development
methods grouped into two main categories: Unified Process and MERISE. For the
design and development, we chose the Essential Unified Process (EssUP) method
which allowed us to better understand the needs and identify the actors. This made
it possible to set up the use case diagrams, sequences and class digram. This made
it possible to set up the use case diagrams, sequences and class digram. Thanks to
this modeling we were able to easily approach the implementation phase. This was
done with the laravel framework and in several languages including PHP,
HTML/CSS, Javascript, SQL and Blade.
X
-

P Fe Mohamed Coulibaly

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

P Fe Mohamed Coulibaly

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DE LA COTE D’IVOIRE

Ministère de l’Economie Numérique et de la Poste

Ecole Supérieure Africaine Des Technologies

Année Scolaire : 2019-2020

MEMOIRE DE FIN DE CYCLE POUR

CONCEPTION ET DEVELOPPEMENT D’UNE APPLICATION

COULIBALY Mohamed Tiemogo Nanguin

Encadrant académique : Maître de stage :

Pr. ASSEU Olivier, M. SOUMARE Moustapha,

Enseignant-Chercheur à l’INPHB Directeur des Systèmes d’Information de la CRRAE-UMOA

À ma très chère famille Je vous dois ce que je suis

J’adresse tout d'abord mes vifs remerciements au directeur général de l'ESATIC Pr

Le numérique revêt une importance primordiale au sein de la société et de ce

LISTE DES FIGURES

Figure 1 : architecture MVC............................................................................................... 15

LISTE DES TABLEAUX

Tableau 1 : Etude comparative des types d'applications ............................................................................... 14

LISTE DES SIGLES ET ABRÉVIATIONS

2TUP : Two Tracks Unified Process

PREMIÈRE PARTIE : GÉNÉRALITÉS

CHAPITRE I : PRÉSENTATIONS GÉNÉRALES

CHAPITRE II : ÉTAT DE L’ART SUR LA REALISATION DU

CHAPITRE III : CHOIX ET JUSTIFICATION

DEUXIÈME PARTIE : ETUDE CONCEPTUELLE

CHAPITRE IV : ETUDE DU SYSTÈME EXISTANT ET

CHAPITRE V : CONCEPTION GÉNÉRALE

CHAPITRE VI : CONCEPTION DÉTAILLÉE

TROISIÈME PARTIE : IMPLÉMENTATION

CHAPITRE VII : ENVIRONNEMENT DE DÉVELOPPEMENT

CHAPITRE VIII : MISE EN ŒUVRE

CHAPITRE IX : BILAN DU PROJET

La gestion des performances du personnel constitue de nos jours un élément

Au vu de cela, la CRRAE-UMOA voudrait voir optimiser son système de management

Plusieurs préoccupations se posent face aux enjeux importants de ce projet à savoir :

CHAPITRE I : PRÉSENTATION GÉNÉRALES

La Caisse de Retraite par Répartition Avec Epargne de l’Union Monétaire

La CRRAE-UMOA gère au profit de ses Adhérents et Participants, les régimes de

 le Régime de Retraite par Répartition du Personnel Cadre (RRPC) ;

La mission de l’Institution se décline comme suit :

 assurer la pérennité et la viabilité des régimes en appliquant une gestion

II- Contexte du projet

La CRRAE-UMOA a adopté un cycle de planification stratégique quinquennal

III- Présentation du cahier de charge

III.1. Présentation du projet

Le thème choisi pour le projet interne s’intitule : « Conception et

III.2. Les objectifs du projet

 dématérialiser la fixation des contrats d’objectifs ;

III.3. Description de quelques opérations

La mise en place de l’application dédiée au système de management de

 définir un contrat d’objectifs à tous les agents de la Caisse en début d’exercice.

assignés, les critères d’appréciation de sa fiche de poste et les critères

L’application dédiée au système de management de performances devra être

La solution devra être capable de garantir des performances linéaires en fonction de

CHAPITRE II : ÉTAT DE L’ART SUR LA REALISATION

I- Présentation des types d’applications

I.1. Présentation des applications bureau/desktop

I.2. Présentation des applications web

I.3. Présentation des applications mobile

II- Présentation des méthodes de développement

Une méthode d'analyse et de conception informatique a pour objectif de

II.1. Présentation de la méthode MERISE

niveau organisationnel, le niveau logique et le niveau physique. Elle se décline en deux

II.1.a. La démarche classique