Mpi05 03 15

Conception et Mise en place d’un système de gestion automatisée des éléments
variables soldes de la SETRAG
DEDICACES
A la mémoire de mon très cher père dont le vide n’est pas encore comblé;
A ma très chère mère,

Pour ton amour , tes prières, ton soutien moral, Trouves en ce travail, les premiers
fruits des multiples sacrifices consentis pour mon éducation ;
A ma fille Ulda Précieuse OKAMBA KOBY et les autres que l’éternel soit votre guide
pour réaliser tous vos projets.
Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page I

EPIGRAPHE
"Toutes choses concourent au bien de ceux qui aiment Dieu"

Romains 8. 23
Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page II

REMERCIEMENTS
Ce travail n'aurait pas pu être accompli sans l'aide précieuse et les conseils encourageants
de nombreuses personnes.
Pour cela, je rends grâce à l’Eternel DIEU tout puissant, à qui revient le mérite de toute
reconnaissance ;
J’adresse mes remerciements à M. Guillaume VERSCHAEVE, Directeur Général de la SETRAG

(Société d’Exploitation du Transgabonais) et M. Simon MBOUMBA, directeur du SICOM
(Système d’Information et de Communication) pour m’avoir accepté dans leur entreprise, qu'ils
trouvent ici l'expression de mon profond respect et de ma gratitude.
J'adresse mes remerciements les plus chaleureux au Dr. SOULEYMANE KOUSSOUBE,

Directeur Général de l’IAI, pour nous avoir accueillis à l’IAI. Qu'il trouve ici l'expression de mon
profond respect et de ma gratitude.
J'exprime ma reconnaissance à mon encadreur académique, M. Felix HOUTSA pour m’avoir

honoré en acceptant de superviser ce travail, Qu'il trouve ici l'expression de ma profonde gratitude.
A mes encadreurs professionnels messieurs M. Copland MOUGONGOU et M. Johnny

DACKEY, je dis un grand merci.
Je voudrai exprimer ma gratitude à mes frères, sœurs, amis et à toute la famille pour leur soutien
inconditionnel. Une pensée toute particulière à mon amie pour sa disponibilité, son amour et la
patience dont elle a fait montre depuis notre rencontre.
J'aimerais adresser mes remerciements les plus affectueux à l’ensemble des étudiants de l’IAI en
particulier ceux de la promotion 2014 pour leur soutien multidimensionnel.
Merci à tout le corps enseignant de l'IAI-GABON et administratif de l’IAI Qu'ils trouvent ici
l'expression de ma profonde gratitude.
Je ne saurais oublier l'ensemble du personnel du SETRAG en particulier de fonction SICOM avec

qui j'ai été amené à travailler, pour avoir fait preuve de disponibilité et d'attention à mon égard
tout au long de mon stage.
Enfin, à tous ceux qui, de près ou de loin, ont participé à l'élaboration de ce rapport, je vous dis
sincèrement merci.
Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page III
AVANT PROPOS
L'Institut Africain d'Informatique (IAI) est une école Inter-États basée à Libreville au
Gabon. Il a été créé en 1971 à Ndjamena au Tchad. Ses états membres sont actuellement : le
Bénin, le Burkina Faso, le Cameroun, la Centrafrique, la Côte d’Ivoire, la république du Congo, le
Gabon, le Niger, le Sénégal, le Tchad, le Togo.
IAI forme des ingénieurs informaticiens, des Maîtrise Informatique Appliquée à la Gestion des
Entreprises (MIAGE), des analystes-programmeurs. Depuis septembre 2012, cet institut a intégré
le système Licence-Master-Doctorat (LMD).
La formation des Ingénieurs de conception en Informatique à l’Institut Africain d’Informatique

s’achève par un stage pratique dans une entreprise ou dans un laboratoire de recherche d’une durée
de cinq mois. Ce stage vise à :
 Mettre les étudiants dans un environnement de conception et de développement

d’applications informatiques suffisamment importantes,
 Favoriser l’insertion des étudiants dans un contexte professionnel et scientifique.
Nos cinq mois de stage au sein de la Société d’Exploitation Transgabonais rentrent dans cette
logique.
Ce document représente l’aboutissement de cinq mois de stage pratique effectués à la

Société d’Exploitation Transgabonais (SETRAG).
Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page IV

RESUME
De nos jour, les technologiques informatiques sont devenues des outils indispensables pour
les entreprise, et ce quel que soit l’emploi occupé (les activités commerciales, l’administration
courante, la sécurité, gestion juridique de l’entreprise, la gestion comptable et financière, les études
générales, la communication, gestion des ressources humaines, etc.). Ces outils sont utiles pour la
SETRAG afin de remédier aux problèmes rencontrés dans le traitement des activités quotidiennes
de l’entreprise.
De ce fait, nous avons été sollicités par les responsables études et projets afin de concevoir un
système d'information automatisé pour la gestion quotidienne des éléments variables solde.
Pour la réalisation de cette tâche, notre choix s'est porté sur le Processus Unifié. En effet, le
processus unifié est une solution de développement logiciel adaptée à tout type de projet. Ses traits
distinctifs tiennent en trois notions : piloté par les cas d'utilisation, centré sur l'architecture, itératif
et incrémental.
Le langage de modélisation que nous avons utilisé est UML (Unified Modeling Language), qui est
une partie intégrante de la démarche UP. Ses diagrammes sont largement utilisés dans chaque
étape et phase de ce processus de développement.
Pour l'implémentation, le choix du langage de programmation a été dicté par le type de

l'application qui doit être réalisée d'une part, et être accessible via le réseau Intranet de la SETRAG
d'autre part. Ainsi, le choix s'est porté sur le langage de programmation PHP. La base de données
est implémentée avec ORACLE 10G qui est largement compatible avec PHP.
Mots clés : Eléments variables soldes, paie, base de données, agent sédentaire et roulant, prime,
indemnité, UML, UP, PHP.
Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page V

ABSTRACT
These days, computer technology have become indispensable tools for business and
whatever employs busy (the commercial, the current administration, security, legal, business
management, accounting and financial management, general studies, communication, human
resources management, etc.). These tools are useful for SETRAG to address the problems
encountered in handling daily operations of the company.
Therefore, it has been asked by official’s studies and projects to develop an automated information
system for the daily management of the remaining variable elements.
To achieve this task, our choice fell on the Unified Process. Indeed, the process is a unified
software development solution for any type of project. Its distinctive features include three
concepts: driven by use cases, focusing on architecture, iterative and incremental.
The modeling language that we used is UML (Unify Modeling Language), which is an integral
part of the UP approach. His charts are widely used in every stage and phase of this process of
development.
For the implementation, the choice of programming language was dictated by the type of
application that needs to be done first, and be accessible via the intranet of the other SETRAG.
Thus, the choice fell on the PHP programming language. The database is implemented with
ORACLE 10G which is largely compatible with PHP.
Key words: Balances variable elements, payroll, database, and rolling sedentary agent, bonus,
compensation, UML, UP, PHP.
Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page VI

TABLE DES MATIERES
DEDICACES ............................................................................................................................................................ I
EPIGRAPHE ........................................................................................................................................................... II
REMERCIEMENTS ..............................................................................................................................................III
AVANT PROPOS .................................................................................................................................................. IV
RESUME................................................................................................................................................................. V
ABSTRACT ........................................................................................................................................................... VI
TABLE DES MATIERES .................................................................................................................................... VII
LISTE DES ABREVIATIONS ...............................................................................................................................IX
LISTE DES FIGURES ............................................................................................................................................X
LISTE DES TABLEAUX .......................................................................................................................................XI
INTRODUCTION GENERALE ............................................................................................................................. 1
PREMIERE PARTIE : CONTEXTE GENERAL DE L’ETUDE .......................................................................... 2
INTRODUCTION ................................................................................................................................................. 3
CHAPITRE 1 : LA STRUCTURE D’ACCUEIL ................................................................................................ 4

1.1 HISTORIQUE .......................................................................................................................................... 4
1.2 ACTIVITES ET MISSIONS ................................................................................................................... 5
1.3 ORGANIGRAMME ................................................................................................................................. 5
1.4 LA FONCTION SICOM .......................................................................................................................... 6
CHAPITRE 2 : LE SUJET, SES OBJECTIFS, SA PROLEMATIQUE ........................................................ 7

2.1 CONTEXTE DU SUJET .......................................................................................................................... 7
2.2 OBJECTIFS DU SUJET ......................................................................................................................... 7
2.3 PROBLEMATIQUE ................................................................................................................................ 8
CHAPITRE 3 : CONCEPTS GENERAUX LIES AU PROJET ...................................................................... 9
3.1 DEFINITIONS .......................................................................................................................................... 9
3.2 REGLEMENT INTERIEUR DE A SETRAG ..................................................................................... 10
3.3 ELEMENTS VARIABLES SOLDE AGENTS SEDENTAIRES ET ROULANTS .......................... 12
3.4 INCRÉMENTATION POUR LA SAISIE DES PRIMES .................................................................. 18
3.5 PROPOSITION DU PRECESSUS DU MODE OPERATOIRE POUR LE TRAITEMENT DES
EVS D’UN CHEF DE GROUPE AU RESPONSABLE DE FONCTION ...................................................... 19
3.6 IMPACT SUR LE MODE OPERATOIRE D’UN GESTIONNAIRE PAIE .................................... 19
3.7 ARCHITECTURE MODELE/VUE/CONTROLEUR ........................................................................ 20
3.8 PRESENTATION DE L'ARCHITECTURE CLIENT/SERVEUR ................................................... 21
3.9 ARCHITECTURE MVC OU 3-TIER ? ............................................................................................... 24
CONCLUSION .................................................................................................................................................... 24
............................................................................................................................................................................... 25
Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page VII
DEUXIEME PARTIE : ANALYSE, CONCEPTION DU SYSTEME ETUDIE .................................................. 25
INTRODUCTION ............................................................................................................................................... 26
CHAPITRE 4 : PRESENTATION DE LA METHODE DE CONDUITE DE PROJET ................................ 27

4.1 PRÉSENTATION DE QUELQUES MÉTHODES D’ANALYSE ET DE CONCEPTION ............ 27
4.2 ETUDE DE LA METHODE D’ANALYSE ET DE CONCEPTION ................................................. 28
CHAPITRE 5 : ANALYSE ET CONCEPTION ................................................................................................ 36

5.1 ETUDE PRELIMINAIRE ..................................................................................................................... 36
5.2 CAPTURE DES BESIONS FONCTIONNELS ET NON FONCTIONNELS .................................. 41
5.3 CONCEPTION DU SYSTÈME ............................................................................................................ 57
TROISIEME PARTIE : MISE EN ŒUVRE ET CONDUITE DU PROJET ...................................................... 64
INTRODUCTION ............................................................................................................................................... 65
CHAPITRE 6 : MISE EN ŒUVRE................................................................................................................... 66

6.1 ENVIRONNEMENT DE TRAVAIL .................................................................................................... 66
6.2 ASPECT SECURITE DU SYSTÈME .................................................................................................. 69
6.3 QUELLEQUES CAPTURES D’ECRAN DE L’APPLICARION ..................................................... 70
CHAPITRE 7 : CONDUITE DE PROJET ................................................................................................... 73

7.1 INTERVENANTS ET DEROLEMENT DU PROJET ....................................................................... 73
7.2 DECOUPAGE DU PROJET EN ITERATION ................................................................................... 73
7.3 DIAGRAMME DE GANT PREVISIONNEL...................................................................................... 75
7.4 DIAGRAMME DE GANT REEL ......................................................................................................... 75
7.5 COUT DU PROJET ............................................................................................................................... 76
7.6 BILAN DU STAGE ................................................................................................................................ 76
CONCLUSION .................................................................................................................................................... 77
CONCLUSION GENERALE ................................................................................................................................ 78
BIBLIOGRAPHIE ................................................................................................................................................. 79
ANNEXES .............................................................................................................................................................. 80
Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page VIII
LISTE DES ABREVIATIONS
2TUP : Two Tracks Unified Process, Instanciation de UP proposé par Valtech prenant en compte
les aléas et contraintes liées aux changements perpétuels et rapides des SI des entreprises.
AICR : Aide Controleur
AM : Agile Methods, Méthode Agile
CRL : Controleur de Line
CRLO : Controleur de Line
EVS : Éléments Variables Soldes
HTML : HyperText Markup Language. Format du document du web ; il nous permet de définir les pages
web
HTTP : HyperText Transfer Protocol. Protocole de transmission des données sur le web
IAI : Institut Africain D’informatique
MVC : Modèle Vue Contrôleur
PHP : Hypertext Preprocessor
SETRAG : Société d’Exploitation Transgabonais
SICOM : Système Informatique et Communication
UML : de l'anglais Unified Modeling Language), ou Langage de modélisation unifié
UP : Unified Process, la dénomination anglaise de PU Processus unifié, désigne les préceptes généraux
de la méthode
Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page IX

LISTE DES FIGURES
Figure 1: organigramme de la SETRAG ................................................................................................................. 6

Figure 2 : Processus pour traitement EVS d’un chef de groupe au responsable de fonction ............................... 19
Figure 3 : Mode opératoire gestionnaire paie........................................................................................................ 20
Figure 4 : Les rôles respectifs de la vue, du contrôleur et du modèle dans l'architecture MVC. ......................... 21
Figure 5 : Schéma de fonctionnement d'un système client/serveur. ...................................................................... 22
Figure 6 : Architecture 1-tier................................................................................................................................. 22
Figure 7 : Architecture 2-tiers................................................................................................................................. 23
Figure 8 : Architecture 3-tiers ............................................................................................................................... 23
Figure 9 : Le processus de développement en Y .................................................................................................... 33
Figure 10 : Le processus de développement en Y (suite) ....................................................................................... 34
Figure 11 : diagramme de contexte dynamique. ................................................................................................... 40
Figure 12 : diagramme des cas d’utilisation global. .............................................................................................. 53
Figure 13 : Diagramme de cas utilisation « S’authentifier » ................................................................................. 53
Figure 14 : CU « administrateur » ......................................................................................................................... 54
Figure 15 : Diagramme des classes saisir prime .................................................................................................... 56
Figure 16 : Diagramme de classes de conception .................................................................................................. 56
Figure 17 : architecture technique. ........................................................................................................................ 58
Figure 18 : Organisation des Framework techniques. ......................................................................................... 59
Figure 19 : Diagramme de déploiement. ................................................................................................................ 60
Figure 20 : Diagramme de séquence « s’authentifier » ......................................................................................... 61
Figure 21 : Diagramme d’activité « s’authentifier » ............................................................................................. 61
Figure 22 : Diagrammes de séquences (Gérer utilisateur) .................................................................................... 62
Figure 23 : Diagrammes d'activité (ajout d'un utilisateur) ................................................................................... 62
Figure 24 : Diagramme de séquence de saisir les EVS de l’agent ......................................................................... 63
Figure 25 : « Formulaire de connexion » ............................................................................................................... 70
Figure 26 : Formulaire menu ................................................................................................................................. 70
Figure 27 : Gérer période de saisie ........................................................................................................................ 71
Figure 28 : Formulaire de décompte EVS ............................................................................................................. 71
Figure 29 : Formulaire de décompte EVS (suite) .................................................................................................. 72
Figure 30 : Gérer Prime ......................................................................................................................................... 72
Figure 31 : Formulaire exporter EVS ................................................................................................................... 72
Figure 32 : Diagramme Gantt prévisionnel ........................................................................................................... 75
Figure 33 : diagramme de Gantt réel .................................................................................................................... 75
Figure 34 : Cout du projet ..................................................................................................................................... 76
Figure 35 : schéma mode opératoire d’un agent administratif ............................................................................... 80
Figure 36 : schéma représentatif du mode opératoire d’gestionnaire paie. .......................................................... 81
Figure 37 : Fiche de collecte de service individuel du personnel roulant .............................................................. 82
Figure 38 : Fiche mensuelle de pointage (SICOM)................................................................................................ 83
Figure 39 : Fiche de décompte de frais de déplacement. ....................................................................................... 83
Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page X

LISTE DES TABLEAUX
Tableau 1: Primes d’astreinte. ............................................................................................................................... 14

Tableau 2 : Indemnité pour les frais de déplacement ............................................................................................ 17
Tableau 3: Tableau d’incrémentation pour chaque prime ................................................................................... 18
Tableau 4 : Explication des messages émis et reçues par le système. .................................................................... 39
Tableau 5: Niveau d’accréditation......................................................................................................................... 39
Tableau 6 : Messages émis et reçu par le système. ................................................................................................ 41
Tableau 7 : les EVS. .............................................................................................................................................. 41
Tableau 8: identification des cas utilisations. ........................................................................................................ 45
Tableau 9 : Structuration en package des CU ....................................................................................................... 54
Tableau 10 : Découpage en Itérations selon le processus 2TUp .......................................................................... 74
Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page XI

INTRODUCTION GENERALE
L'outil informatique, faisant partie du quotidien de tout travailleur devient de ce fait le

compagnon idéal de l'homme dans le monde du travail tout en lui facilitant certaines tâches qui
jadis paraissaient comme corvées.
La gestion des éléments variables soldes qui est sujet notre étude, aura pour but de créer
une application permettant un traitement plus efficace et efficient des éléments variables de
soldes. En effet, elle mettra fin à un processus qui s’avère être archaïque et administrativement
lourd et ce en utilisant les nouvelles technologies informatiques.
En effet, Nous avons pu constater, pendant nos recherches que l'ensemble des traitements
des éléments variables soldes au sein de la SETRAG se faisait manuellement, ce qui engendre un
certain nombre de problèmes tels que la lenteur dans l'accès aux données et le risque de perte
d'informations ; donc la meilleure solution pour pallier aux problèmes est l'informatisation afin
d'assurer l'accès instantané aux données et une sécurisation de ces dernières ; ce qui simplifie
l'activité administrative.
Pour atteindre notre objectif nous avons partagé le travail comme suit :
Dans la première partie intitulée << CONTEXTE GENERAL DE L’ETUDE» nous

commençons à présenter l'organisme d'accueil, la compréhension du contexte du sujet ensuite
énumérer les objectifs et la problématique.
Au niveau de la deuxième partie intitulée intitulé << ANALYSE, CONCEPTION DU

SYSTEME ETUDIE», nous analysons les principaux objectifs attendus du futur système à
concevoir ; ceux-ci seront décrits par les diagrammes des cas d'utilisation. Nous étendons la
représentation des diagrammes effectués au niveau de l'analyse en y intégrant les aspects
techniques les plus proches des préoccupations physiques.
Finalement dans la dernière partie qu'on a nommé << MISE EN ŒUVRE ET

CONDUITE DU PROJET » nous présentons les outils de développement qui nous ont servi pour
le développement de l'application, et enfin l'activité test qui consiste, justement, à la tester dans
le but de s'assurer de son bon fonctionnement.
Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page 1

PREMIERE PARTIE : CONTEXTE GENERAL DE L’ETUDE

INTRODUCTION
Dans cette partie, nous allons présenter au premier chapitre, la structure d’accueil où nous
avons effectué le stage, le sujet dans son contexte ainsi que la problématique qu’il soulève. Le
second chapitre est consacré à l’exploration des concepts liés à ce sujet.

CHAPITRE 1 : LA STRUCTURE D’ACCUEIL
1.1 HISTORIQUE
Dès avril 1972, le bureau technique du chemin de fer est remplacé par l’Office du Chemin de
Fer Transgabonais (OCTRA) qui est chargé de l’étude, de la réalisation et de l’exploitation du
chemin de fer. Le 30 décembre 1973, la première traverse est posée et en octobre 1974, le
lancement officiel des travaux de construction est fait. Un consortium de 14 entreprises est
constitué avec près de 4000 employés Gabonais et expatriés confondus. Dès 1977, l’exploitation
du chemin de fer commence avec la mise en circulation du premier train voyageur entre Owendo
et Ntoum. En 1979, suit l’inauguration du tronçon Owendo-Ndjolé, et le 30 décembre 1986,
officiellement celle du réseau Owendo- Franceville par le président de la république, son
excellence Albert Bernard Bongo.
En juillet 1987, il y a eu la mise en circulation du premier train voyageur sur la relation
Owendo - Franceville.
Mai 1989, la mise en circulation des trains minéraliers sur le réseau gabonais a lieu.
L’Octra (Office du Chemin de Fer Transgabonais) a été habileté à gérer et exploiter la voie
ferrée (gestion para publique) longue de sept cent kilomètres. Elle a eu la charge de cette gestion
et de cet investissement de 1972 à 1999.
Dans le cadre de la restructuration du programme de développement de la voie ferrée,
l’Etat se désengage du secteur public en 1995 ; il est présenté au parlement la loi fixant les règles
de privatisation et en avril 1996, le gouvernement annonce la mise en concession de l’Octra. Le
28 décembre 1998, la Compagnie Chemin de Fer Transgabonais (le Transgabonais) est choisie
pour succéder à l’Octra et ce, sous l’égide du FMI (Fonds Monétaire International).
Le 15 mai 2002 l’Etat prononce à nouveau la déchéance du Transgabonais et dès le 1er

janvier 2003, la Société d’Exploitation du Transgabonais(SETRAG) filiale du groupe ERAMET
(deuxième producteur de manganèse dans le monde) est retenue pour un mandat de quatre (4)
mois renouvelable une fois. En avril 2004, ce mandat est prorogé pour une période de dix-huit
(18) mois. Enfin, le 11 août 2005, une convention de mise en concession est signée et dès
novembre, la SETRAG a pris en charge de main de maître les destinées du chemin de fer du
Gabon après vingt-neuf (29) mois de mise à l’épreuve pour une durée de trente (30) ans
minimum pour réaliser ses ambitions, se développer, accroître sa notoriété et monter en
puissance pour devenir une entreprise moderne, incontestable, performante et au cœur du
développement du Gabon.

1.2 ACTIVITES ET MISSIONS
Depuis sa concession, la SETRAG joue un rôle prépondérant dans l’économie Gabonaise.

C’est une Société Anonyme avec conseil d’administration au capital de dix milliards de FCFA
(10 000 000 000) souscrit en numéraire uniquement et ayant pour activité principale le transport
ferroviaire.
Les moyens de télécommunication utilisés par l’entreprise sont :

Le VSAT : pour la circulation des trains par cantonnement téléphonique (omnibus, téléphone,
fax et transmission datas....) ;
Thur aya : liaisons satellitaires entre le poste de commande et les locomotives ;
GPS : pour le repérage sur grand écran de tous les trains en mouvement.
Les missions de la SETRAG depuis sa concession sont: Transporter dans les meilleures
conditions deux des principales richesses du pays, le manganèse et le bois, mais aussi améliorer
la mobilité des personnes et des biens.
Cependant l’on ne peut parler des missions et des obligations de la SETRAG sans avoir à
préciser les moyens qu’elle utilise pour se développer.
Les ressources humaines et le matériel
Mille trois cent trente-neuf (1339) agents sont au service de la SETRAG.
La SETRAG dispose d’un parc matériel très diversifié et spécialisé : locomotives de ligne
1.3 ORGANIGRAMME
Cette organisation s’articule autour d’entités opérationnelles contribuant directement à la
bonne marche des outils de production de l’offre de transport, à la commercialisation de l’offre
et à son exécution sure et performante, garante de la satisfaction des clients :
- Direction Commerciale
- Direction du trafic
- Direction du Matériel Roulant
- SICOM (système d’information & communication)
Entités supports, apportant un soutien logistique, procédural et normatif aux entités

opérationnelles :
- Direction des Ressources Humaines

- Direction des Affaire Financière
- Achats
- QHSE & PMO
D’entités en appui direct à la Direction Générale dans ses missions régaliennes :
- Communication
- Juridique
- PFSI (Police Ferroviaire & Sécurité Incendie)
- Service Généraux

Figure 1: organigramme de la SETRAG
1.4 LA FONCTION SICOM
Regroupant les services informatiques et télécommunication de la SETRAG, le SICOM a en

charge la gestion du parc informatique et les infrastructures de Télécommunication.
Les activités principales du SICOM sont basées sur :
- La mise en place d'une infrastructure réseaux, systèmes et télécommunications

performant;
- La réalisation des projets d'études, de développements et la maintenance évolutive;
- La fiabilisation et la sécurisation de l’intégrité des données et du système d'informations;
- La garantie d'un support technique de qualité aux utilisateurs et la maintenance corrective
et préventive des équipements SICOM.

CHAPITRE 2 : LE SUJET, SES OBJECTIFS, SA PROLEMATIQUE
2.1 CONTEXTE DU SUJET
Le contexte actuel fait que pour relever et traiter les éléments variables des 1339 agents
que comptent l’entreprise, les gestionnaires concernés par la paie (agents administratif, chefs de
bureau…) de SETRAG sont dans l’obligation de transcrire à la main toutes les informations(les
unes après les autres) qui sont liées aux éléments variables à l’aide de documents conçus de leur
propre chef. Par la suite, ils transmettent (à une période spécifique du mois) les éléments
variables sous formes de pli appelé classeur au service Rémunération pour contrôle et intégration
dans la paie. Travail que le Gestionnaire Paie fait pour chaque agent et ce individuellement.
Cette lourde tâche entraine souvent :
 Des erreurs de calcul ;

 Un temps de traitement lent;
Les Gestionnaires après chaque opération se trouvent dans l’obligation d’archiver ; ce qui à la
longue devient encombrant pour son service.
2.2 OBJECTIFS DU SUJET
Le projet soumis à l’étude a pour but de créer une application permettant un traitement plus
efficace et efficient des éléments variables de solde. En effet, elle mettra fin à un processus qui
s’avère être archaïque et administrativement lourd et ce en utilisant les technologies
informatiques. Il s’agira donc pour nous de réaliser un progiciel permettant le traitement
quotidien, par les agents administratifs et les gestionnaires paie, des éléments variables solde.
Le projet a ainsi pour objectif principal d’obtenir un gain de productivité et de transformer

tout ce lourd processus en une application simple.
Il permettra à chaque utilisateur concerné de pouvoir mettre à jour les EVS (éléments variables
solde) de leur service. Et à la suite le service Rémunération aura la tâche de contrôler si les
données enregistrées correspondent réellement avant l’intégration des états dans la paie pour
paiement.

Cette application aura pour objectif spécifique une sécurisation plus importante, un traitement
plus efficace et une économie en utilisation de papier impropre à l’environnement et source de
charge.
2.3 PROBLEMATIQUE
Nous remarquons quelques contraintes quant à la réception, la réalisation et à l’utilisation future

de cette application.
 Le temps est la plus grande contrainte que nous pourrions rencontrer au cours de ce
projet. En effet afin de cerner entièrement tous les points que doit prendre cette
application il faut le chronogramme, car pour certains services, il n’est pas du tout aisé de
retranscrire leurs éléments variables en mode opératoire en application informatique.
 Le progiciel doit pouvoir fonctionner sous Windows quelle que soit la version.
 Le progiciel doit être développé avec un langage de programmation particulier afin qu’il
puisse être mis en relation avec les autres logiciels de rémunération.
 Plusieurs utilisateurs peuvent s’y connecter en même temps sans pour autant surcharger
l’application, à Owendo ; comme à l’intérieur du pays. Le serveur doit être en mesure de
supporter ces opérations.
 Chaque chef de gare/ de groupe/ de section doit posséder un ordinateur qui plus est, doit
être connecté au réseau.
 Tous les salariés de l’entreprise exerçant la même charge ou la même nature de travail et
possédant des qualifications similaires perçoivent les mêmes primes.

CHAPITRE 3 : CONCEPTS GENERAUX LIES AU PROJET
3.1 DEFINITIONS
Convention Collective de Travail:

La convention collective est un accord conclu entre un employeur (ou un groupement
d'employeurs) et une (ou plusieurs) organisation(s) syndicale(s) représentative(s) des
salariés. Elle complète la législation du travail par des dispositions propres à un champ
d'application donné.
Agents Sédentaires : les travailleurs dont la profession n'exige pas de déplacements
fréquents hors du lieu où elle s'exerce : Les employés de bureau constituent un personnel
sédentaire.
Agents Roulants : Agents de conduite, contrôleurs, travaillant à bord des trains.
Salaire : le salaire est défini comme la contrepartie de la prestation de travail. En ce sens
il constitue donc un élément nécessaire du contrat de travail. Quelle que soit sa forme,
qu’il soit versé en argent ou en nature, (qu’il soit calculé en temps, en pièces ou à la
commission etc.) il ne peut être modifié sans l’accord du salarié.
Indemnités : Les indemnités sont des sommes intégrées à la paie ou versées par des
organismes extérieurs à l’entreprise en compensation de circonstances ou de situations
imposées au salarié (chômage) ou dont celui-ci profite (congés payés). Il peut également
s’agir de sommes versées par l’employeur en compensation forfaitaire de frais engagés
par le salarié dans l’exercice de son activité professionnelle : indemnité de transport,
indemnité de repas, de déplacements, etc. Lorsqu’elles sont versées par l’employeur, ces
indemnités sont détaillées sur le bulletin de paie remis au salarié; lorsqu’elles sont
versées par des tiers, elles font l’objet d’autres justificatifs.
Prime : Une prime est un complément de salaire octroyé par les entreprises pour les
employés afin de les récompenser, motiver ou dédommager de certaines conditions de
travail.
Eléments variables de solde : primes et indemnité divers à caractères variables.

3.2 REGLEMENT INTERIEUR DE A SETRAG
Le règlement intérieur d’une entreprise est un document rédigé unilatéralement par

l’employeur dans lequel il définit les règles exclusivement relatives à l'hygiène, la sécurité et la
discipline sur le lieu de travail (l’entreprise). Ces règles sont légalement applicables à tout salarié
intégrant l’entreprise.
Cette limitation dans les thèmes du règlement est imposée par le Code du Travail, et est
destinée à prévoir l’abus de pouvoir de certains employeurs qui pourraient y introduire certaines
dispositions subjectives. Notez tout de même que le document doit également rappeler les
dispositions légales applicables au cas d’harcèlement sexuel et d’harcèlement moral.
3.2.1 OBJET ET CHAMP D’APPLICATION

Conformément à l’article 110 du code du travail, le règlement intérieur a pour objet de :
- Définir les règles relatives à l’organisation technique du travail,

- Préciser les normes et procédures disciplinaires applicables à SETRAG,
- Informer sur les prescriptions en matière d’hygiène, de sécurité et de santé au travail,
- Expliquer les modalités de paiement des salaires.
Tout salarié ou autre collaborateur stagiaire doit prendre connaissance du règlement intérieur lors
de son embauche ou de son arrivée à SETRAG. Il est disponible sur l’internet de la société.
Champ d’application
Le Règlement intérieur est applicable, sans réserve ni restriction, à toute personne amenée à
exercer une activité sur l’un des sites énoncés ci-dessous ou dans le cadre de tout autre lieu
d’activité, bâtiment ou local relevant de la disponibilité de la SETRAG.
- Owendo, Ntoum, Andem, Mbel, Oyan, Abanga, Ndjolé, Otoumbi, Ayem, Lopé,
Offoué, Booué, Ivindo, Mouyabi, Milolé, Lastourville, Doumé, Mboungou Badouma,
Moanda, Franceville
MODALITES ET CONDITIONS D’ATTRIBUTION D'UNE PRIME
Les primes sont calculées en fonction des accords ou engagements préalablement consentis
(contrat de travail, convention collective…). L’octroi selon la fonction, le résultat ou la nature du
travail ne doit aucunement être discriminatoire et doit se faire de manière totalement licite.

3.2.2 ORGANISATION TECHNIQUE DU TRAVAIL
Durée et horaire du travail
Régime du travail
La durée du travail est régie par les dispositions légales et règlementaires. Elle s’étale sur cinq
(5) jours, à raison de quarante (40) heures de travail par semaine.
Le régiment journalier de travail est de 8h00 par jour du lundi au vendredi, avec repos le samedi
et le dimanche pour l’ensemble du personnel à l’exception des activités qui fonctionnent suivant
des horaires spéciaux et pour lesquelles cette durée est fixée selon des équivalences prévues par
la législation du travail.
Horaires de travail :
En application du décret n° 933 du 30 Décembre 2010 relatif à la répartition journalière du

travail, le personnel doit respecter l’horaire hebdomadaire de 40 heures et l’horaire prévu pour
les équipes successives tel qu’il est arrêté par la direction :
- Pour le personnel soumis au régime normal :

De Lundi à Vendredi de 7h30 à 15h30 minutes,
Avec une pause 30 minutes qui doit être prise dans l’horaire 11h30 et 13h30.
- Pour le personnel soumis au régime de travail des équipes successives :
Roulement « 3x8 »
06h00 à 14h00
14h00 à 21h00
21h00 à 06h00
Roulement « 2x12 »
06h00 à 18h00
18h00 à 06h00
Pour le personnel roulant, un ordre général de service signé du Directeur Général fixera les
dispositions particulières.
En cas de nécessité, des aménagements internes peuvent être apportés par voie d’affichage.

Le travail nécessaire au rétablissement des circulations des trains est obligatoire pour le
personnel d’astreinte. Il peut également être fait appel au personnel disponible.
Des heures supplémentaires peuvent être effectuées et rémunérées dans les limites et aux
conditions fixées par les lois et les règlements en vigueur. Elles seront accomplies et rémunérées
à la limite et aux conditions fixées par la législation en vigueur. Toutefois, les heures
supplémentaires qui sont accomplies en dehors des conditions ci-dessus ne seront pas payées.
Les jours déclarés chômés dans des conditions légales font l’objet de récupération lorsque le
personnel est appelé à travailler. A cet effet, la direction de l’entreprise informera le personnel
des modalités de récupération par voie d’affichage.
3.3 ELEMENTS VARIABLES SOLDE AGENTS SEDENTAIRES ET ROULANTS
3.3.1 HEURES SUPPLÉMENTAIRES
Conformément aux dispositions de l'article 165 du Code du Travail et du décret

réglementant le régime des dérogations à la durée légale du travail, les N° 000726lPR,
heures de travail effectuées au-delà de la durée légale du travail sont considérées Comme
heures supplémentaires et donnent lieu à une majoration de salaire.
En cas d'impossibilité de rémunération dûment justifiée, les heures

supplémentaires peuvent faire l'objet de repos compensateurs. L'entreprise se réserve le droit de
faire effectuer des heures supplémentaires dans la limite et aux conditions fixées par la
législation et la réglementation en vigueur. Lorsque l'employeur souhaite recourir aux
heures supplémentaires, il doit impérativement respecter une procédure d'autorisation
préalable de l'Inspection du Travail.
RÉMUNÉRATION DES HEURES SUPPLÉMENTAIRES
Les heures effectuées au cours d'une semaine, à la demande de la direction, au-delà de la durée
légale du travail prévue par l'un ou l'autre des régimes (durée hebdomadaire de 40h ou régime
des rotations) sont des heures supplémentaires et à ce titre, rémunéré aux taux normaux,
Le salaire horaire auquel s’applique la majoration est le salaire effectif, c’est-à-dire le salaire
horaire du travailleur et non le salaire de base de la Convention Collective. Dans le calcul du
salaire effectif, doivent être comprises les primes inhérentes à la nature du travail effectué,

telles que primes de danger, d'insalubrité, nuisance atelier. Les taux normaux majorés des
pourcentages de rémunération des heures supplémentaires sont les suivants :
HEURES SUPPLÉMENTAIRES DE JOUR
- 30% de majoration pour les heures effectuées les jours ouvrables (entre 6h et 21h) ;
- 55% de majoration pour les heures effectuées les dimanche ou jours de repos
hebdomadaires (entre 6h et 21h);
- 100% de majoration pour les heures effectuées les jours fériés (entre 6h et 21h).
HEURES SUPPLÉMENTAIRES DE NUIT
- 60% de majoration pour les heures supplémentaires de nuit effectuées les jours
ouvrables (entre 21h et 6h);
- 100% de majoration pour les heures supplémentaires de nuit effectuées les dimanches
ou jours de repos hebdomadaire et jours fériés (entre21het 6h).
3.3.2 PRIME DE NUIT

Une prime de nuit est allouée aux travailleurs des catégories Exécution et Maîtrise qui
assurent leur service normal de nuit, entre 21hOO et 6h00 du matin. Le montant de cette prime
est de 25% du taux horaire du travail
3.3.3 PRIME DE DIMANCHE ET JOURS FERIES
Une prime de dimanche et jours fériés est allouée aux travailleurs des
catégories Exécution et Maîtrise qui assurent leur service normal les dimanches et jours fériés.
Son montant est de 50% du taux horaire du travail de jour, et de 100% de nuit.
3.3.4 PRIME DE BLANCHISSAGE
La prime de blanchissage est allouée aux travailleurs des catégories Exécution et

Maîtrise ayant effectué des travaux particulièrement salissants. Son taux uniforme est de 300
FCFA par jour.
3.3.5 PRIME D'ASTREINTE
La prime d'astreinte est allouée aux travailleurs de toutes catégories, à l'exception des
Cadres Supérieurs, soumis, selon un planning défini, au régime de l'astreinte.
Son taux qui varie en fonction de la période de travail et de la catégorie professionnelle

du travailleur est défini comme indiqué au tableau ci-après :

Période Montant par catégorie
Cadres Maîtrises Exécutions
Jours ouvrables 350 FCFA/jour 300 FCF A/jour 250 FCF A/jour
Samedis/Dimanches /Jours fériés 1750 FCF A/jour 1500 FCF A/jour 1250 FCF A/jour
Tableau 1: Primes d’astreinte.
3.3.6 PRIME DE SECURITE - MANOEUVRE

Cette prime est allouée aux travailleurs qui, dans les gares, assurent des fonctions de
sécurité manœuvre engageant leur responsabilité. Son montant, par journée effective de travail,
est fixé comme suit :
- 700 FCFA chef de sécurité et d'interception

- 600 FCFA chef de manœuvre et pilote
- 400 FCFA agent de manœuvre
3.3.7 PRIME DE RECETTES

Cette prime est allouée aux travailleurs des catégories Exécution et Maîtrise, en service
dans les bureaux des gares et dans les trains, amenés par leurs fonctions à manipuler les fonds.
Le montant de la prime de recette varie en fonction de la recette journalière effectuée par le

travailleur concerné :
- Jusqu'à 2 500 000 FCFA : 700 F CFA / Jour

- De 2 500 001 à 5 000 000 FCFA : 900 F CFA / Jour
- dessus de 5 000 000 FCFA : 1200 FCFA/jour.
3.3.8 PRIME DE BILLETAGE
Cette prime est allouée aux travailleurs chargés de payer, chaque fin de mois, le salaire du
personnel. Son montant est fonction des sommes payées, en fin de mois, par billeteur.
- Jusqu'à 1 000 000 FCFA : 2000 FCFA

- De 1 000 001 à 2 000 000 FCFA : 2500 FCFA

- De 2 000 001 à 3 000 000 FCFA : 3000 FCFA
- Au-dessus de 3 000 000 FCFA : 4000 FCFA
3.3.9 PRIME DE PANIER
A l'exception des travailleurs roulants qui assurent effectivement leur service de route
(travailleurs de conduite et travailleurs d'accompagnement des trains), la prime de panier
est allouée à tout travailleur qu'une amplitude de travail empêche de prendre normalement son
repas à domicile.
Elle n'est pas due lorsque le travailleur est nourri aux frais de la SETRAG. Elle n'est pas
cumulable avec l'indemnité de frais de déplacement. Son taux est uniformément de 1400 FCFA
/jour de travail effectif.
3.3.10 PRIME DE RELEVAGE OU DE TRAVAUX ACCIDENTELS
Cette prime est allouée aux travailleurs de toutes catégories qui participent
effectivement aux opérations de rétablissement des circulations sur voies principales ou secondaires à
la suite d'un accident ou d'un incident. Elle se cumule avec les heures supplémentaires et les
indemnités pour frais de déplacement
Son montant est, pour chaque période inférieure ou égale à 24 heures, fixé comme suit :
- Exécutions : 1500 FCF A/jour

- Maîtrises : 2000 FCF A/jour
- Cadres : 2500 FCFA/jour
3.3.11 PRIME DE TRACTION
Elle est allouée au travailleur de catégorie Exécutions et Maîtrise appartenant à la filière

traction qui assure effectivement le service de route et de manœuvre.
Elle comporte 2 fractions :
* L'une journalière, variable avec le grade du travailleur

* L'autre kilométrique, fonction de la qualification du travailleur ainsi que du nombre de
kilomètres parcourus
La prime de traction est payée pour chaque journée de travail et pour les jours de repos compensateurs.

Les conducteurs de draisine bénéficient de la première fraction uniquement. Les taux de la fraction
journalière sont définis comme suit :
- Conducteur niveau maîtrise : 2050 FCFA /jour

- Conducteur de ligne niveau exécution : 1600 FCFA/jour
- Conducteur de locotracteur ou de draisine : 1350 FCFA /jour
- Aide conducteur : 850 FCFA /jour
Les taux de la fraction kilométrique sont fixés comme suit :
- Conducteur de ligne : 20 F CFA/Km

- Aide conducteur : 13F CFA/Km
- Le conducteur de manœuvre est rémunéré à l’heure au taux de 55 F CFA
3.3.12 PRIME DE CONTROLE AU SOL

Cette prime est allouée aux travailleurs de toutes catégories qui participent
effectivement aux opérations de contrôle au sol avant l'embarquement des passagers et des
colis à bord des trains. Son montant est, pour chaque train contrôlé de : 3750 FCFA
3.3.13 PRIME DE FORMATION

Cette prime est allouée aux travailleurs de toutes catégories désignés pour dispenser, en qualité de
vacataire, les actions de formation au sein de l'entreprise.
Le formateur vacataire conserve les primes et avantages liés à son poste de travail habituel et
bénéficie de l'indemnité pour frais de déplacement pendant la période de dispense des actions de
formation.
Le taux de la prime de formation est fixé à 1550 F CFA/heur
3.3.14 PRIME EXCEPTIONNELLE

Une prime exceptionnelle peut être accordée à tout travailleur qui a eu à exécuter des travaux
particuliers ou qui s'est distingué dans une circonstance exceptionnelle et difficile, par des actes de
probité, de vigilance, de dévouement ou de courage.
Elle est attribuée en cours d'année, à l'occasion du fait générateur, sur proposition de la hiérarchie
concernée et après validation de la Direction Générale.

3.3.15 INDEMINITE D’ASTREINTE DIRECTION

Elle est allouée aux Cadres Supérieure soumis au régime d'astreinte.
Le montant de cette prime forfaitaire varie de 200 000 à 250 000 F CFA/mois.
3.3.16 INDEMNITE POUR FRAIS DE DEPLACEMENT
Les indemnités pour frais de déplacement alloués individuellement aux travailleurs de

la SETRAG se déplaçant temporairement à l'intérieur où hors du Gabon, sur ordre et pour
des besoins de service, sont celles destinées à couvrir les frais de repas, d'hébergement et
de transport que supportent les travailleurs du fait de déplacement.
3.3.17 LES INDEMNITES POUR FRAIS DE DEPLACEMENT A L'INTERIEUR

DU GABON SONT FIXEES COMME SUIT :
Exécution Maîtrise Cadre
Petit déjeuner 1 500 FCFA/jour 2 000 FCFA/jour 2 000 FCFA/jour
Déjeuner 3 000 FCFA/jour 4 500 FCFA/jour 7 000 FCFA/jour
Dîner 3 000 FCFA/jour 4 500 FCFA/jour 7 000 FCFA/jour
Hébergement 6 000 FCFA/jour 9 000 FCFA/jour 14 000 FCFA/jour
Transport 1 000 FCFA/jour 1 000 FCFA/jour 1 000 FCF A/jour
TOTAL 14 500 FCFA/jour 21 000 FCFA/jour 31 000 FCFA/jour
Tableau 2 : Indemnité pour les frais de déplacement

3.4 INCRÉMENTATION POUR LA SAISIE DES PRIMES
Tableau 3: Tableau d’incrémentation pour chaque prime
Il s’agit ici d’un tableau d’incrémentation qui indique sous quelle unité sont saisies les
données dans l’application. En effet, pour ces données (primes) soient prises en compte par
l’application paie (sage) il faut que la saisie de départ corresponde à un format (unité) précis.

3.5 PROPOSITION DU PRECESSUS DU MODE OPERATOIRE POUR LE

TRAITEMENT DES EVS D’UN CHEF DE GROUPE AU RESPONSABLE DE
FONCTION
Figure 2 : Processus pour traitement EVS d’un chef de groupe au responsable de fonction
On rencontre donc 3 paliers d’habilitations pour ce processus. Le chef de groupe (ou

d’équipe ; de section) renseigne l’application d’informations concernant les EVS de son service,
il les transmet au chef de la sous Fonction pour expertise et celui-ci renvoi le tout au
Responsable de la Fonction qui valide et transmet à la sous Fonction paie. Nous avons alors 3
acteurs, et le contrôle est plus minutieux, on rencontre moins de risque d’erreur.
3.6 IMPACT SUR LE MODE OPERATOIRE D’UN GESTIONNAIRE PAIE
Le gestionnaire paie réceptionne et vérifie la conformité via l’application les EVS. Le

responsable sous fonction paie prend le relais pour générer es fichiers transférables sur
SAGE et procède à l’édition de pré-bulletins. Ceux-ci édités, le gestionnaire paie reprend le
tout pour n dernier contrôle et correction, puis, le responsable de la sous fonction paie lance
l’impression finale afin que les bulletins de paie soient classés par service et répartis par
point de paie

Figure 3 : Mode opératoire gestionnaire paie
3.7 ARCHITECTURE MODELE/VUE/CONTROLEUR
Le développement des applications web ne prend de l’essor que longtemps après la mise en
place des patrons de conception. Mais avec la découverte de nouvelles architectures et la
vulgarisation de l’internet ces applications ont pris de l’étendue. Le design pattern MVC (Model
Vue Contrôleur) a donc été mis en place pour ce type de développement.
MVC organise une application interactive (web, client-serveur, services web, etc.) en trois
couches techniques séparées. Une telle séparation permet de :
 clarifier le code,
 le rendre flexible et maintenable.
Les trois parties du pattern MVC sont les suivantes :
Le Modèle : Le modèle défini les données de l'application et les méthodes d'accès. Tous les
traitements sont effectués dans cette couche. Une fonction AfficherPrime ou ModifierPrime peut
typiquement être considérée comme un modèle
La deuxième couche est formée des Vues, qui permettent de présenter les données fournies par
les modèles. Une vue interroge le modèle pour obtenir les données et les présenter. Elle est

chargée aussi de récupérer les interactions des utilisateurs (clics, entrée dans les formulaires) et
de les fournir au contrôleur. C’est le rôle des pages JSP (Java Server Pages), qui ne sont pas
censées contenir du code, ou des langages de Template PHP. Une vue est typiquement un fichier
FichePrime.jsp ; ou un fichier FormulaireDeModificationPrime.tpl, dans le langage de Template
Smarty, destiné à PHP.
Troisième couche, le Contrôleur lie les modèles et les vues, en fonction d’une logique de
navigation et d’un contexte. Dans le cas des applications Web, il intercepte et interprète les GET
et POST http, exécute le modèle adapté, et choisit la vue en conséquence. Le modèle peut, par
exemple, envoyer une donnée au contrôleur, pour qu’il rafraîchisse une vue
Figure 4 : Les rôles respectifs de la vue, du contrôleur et du modèle dans l'architecture MVC.
3.8 PRESENTATION DE L'ARCHITECTURE CLIENT/SERVEUR
FONCTIONNEMENT D'UN SYSTEME CLIENT/SERVEUR
L'architecture client-serveur est un modèle de fonctionnement logiciel qui se réalise sur

tout type d'architecture matérielle (petites à grosses machines), à partir du moment où ces
architectures peuvent être interconnectées.
On parle de fonctionnement logiciel dans la mesure où cette architecture est basée sur
l'utilisation de deux types de logiciels, à savoir un logiciel serveur et un logiciel client s'exécutant
normalement sur 2 machines différentes.
L'élément important dans cette architecture est l'utilisation de mécanisme de communication

entre les 2 applications. Le dialogue entre les applications peut se résumer par :

Figure 5 : Schéma de fonctionnement d'un système client/serveur.
 Le client émet une requête vers le serveur grâce à son adresse et le port, qui désigne un
service particulier du serveur
 Le serveur reçoit la demande et répond à l'aide de l'adresse de la machine client et son
port.
TYPES D'ARCHITECTURES RESEAUX
ARCHITECTURE 1-TIER
Dans une approche d'application de type 1-tiers, les trois couches sont fortement et
intimement liées, et s'exécutent sur la même machine. Dans ce cas, on ne peut pas parler
d'architecture client-serveur mais d'informatique centralisée.
Dans un contexte simple utilisateur, la question ne se pose pas, mais dans un contexte multiutilisateurs, on
peut voir apparaître deux types d'architectures mettant en œuvre des applications 1-tiers : des applications
sur site central ; des applications réparties sur des machines indépendantes communiquant par partage de
fichiers
Figure 6 : Architecture 1-tier
ARCHITECTURE 2-TIERS
Dans une architecture 2-tiers, encore appelée client-serveur de première génération ou

client-serveur de données, le poste client se contente de déléguer la gestion des données à un

service spécialisé. Le cas typique de cette architecture est une application de gestion
fonctionnant sous Windows ou Linux et exploitant un SGBD centralisé.
Ce type d'application permet de tirer de la puissance des ordinateurs déployés en réseau pour
fournir à l'utilisateur une interface riche, tout en garantissant la cohérence des données, qui
restent gérées de façon centralisée.
Figure 7 : Architecture 2-tiers
ARCHITECTIRE 3-TIERS
Dans l'architecture à trois niveaux (appelée architecture 3-tiers), il existe un niveau

intermédiaire, c'est-à-dire que l'on a généralement une architecture partagée entre :
 Un client, c'est-à-dire l'ordinateur demandeur de ressources, équipée d'une interface

utilisateur (généralement un navigateur web) chargée de la présentation;
 Le serveur d'application (appelé également middleware), chargé de fournir les
ressources mais faisant appel à un autre serveur
 Le serveur de données, fournissant au serveur d'application les données dont il a besoin
Figure 8 : Architecture 3-tiers

3.9 ARCHITECTURE MVC OU 3-TIER ?
La différence fondamentale se trouve dans le fait que l'architecture 3-Tier sépare la couche
Buisness logic (couche métier) de la couche Data access (accès aux données).
Pour qu'une application MVC soit une vraie application 3-Tier il faut lui ajouter une couche
d'abstraction d'accès aux données de type DAO (Data Access Object).
Inversement pour qu'une application 3-Tier respecte MVC il faut lui ajouter une couche de
contrôle entre User interface et Buisness logic.
Loin d'être antagonistes, ces deux pratiques se combinent et sont la fondation de la plupart des
frameworks de création d'applications Web
CONCLUSION
Tout au long de cette première partie, nous avons essayé de mettre au point le cadre
général de notre travail. Nous avons tout d'abord précisé l'organisme d'accueil qui s'avère un
élément fondamental dans l'environnement du projet et 'ensuite une étude des concepts liés au
projet en plus, énumérer les architectures réseaux et enfin nous avons présenté les principaux
concepts de base du Travail demandé.

DEUXIEME PARTIE : ANALYSE, CONCEPTION DU SYSTEME ETUDIE

INTRODUCTION
Dans cette partie, nous allons définir la méthode puis les outils mettant en évidence la
réalisation de notre projet. Nous commencerons à présenter le langage de modélisation unifié
UML (Unified Modeling Language), avec la démarche du processus de développements logiciel
qui l'accompagne. Enfin produire l’analyse et la conception du système étudié.

CHAPITRE 4 : PRESENTATION DE LA METHODE DE CONDUITE

DE PROJET
4.1 PRÉSENTATION DE QUELQUES MÉTHODES D’ANALYSE ET DE

CONCEPTION
Un projet informatique, quelle que soit sa taille et la portée de ses objectifs, nécessite la mise en
place d'un planning organisationnel tout au long de son cycle de vie. C'est ainsi qu'est apparue la
notion de méthode.
Une méthode, dans le contexte informatique, peut être définie comme une démarche fournissant
une méthodologie et des notations standards qui aident à concevoir des logiciels de qualité.
Malgré la diversité des méthodes d'analyse et de conception, il est possible de les classer en trois
catégories
METHODES CARTESIENNES ou FONCTIONNELLES : (dites de première génération)

Avec cette méthode, le système étudié est abordé par les fonctions qu'il doit assurer plutôt que
par les données qu'il doit gérer. Le processus de conception est vu comme un développement
linéaire. Il y a décomposition systématique du domaine étudié en sous domaines, eux-mêmes
décomposés en sous-domaines jusqu'à un niveau considéré élémentaire. SADT (Structured-
Analysis-Design-Technique) en est un exemple
METHODES SYSTEMIQUES (dites de deuxième génération) Les méthodes systémiques sont

des méthodes s'appuyant sur une approche systémique. Elles définissent différents niveaux de
préoccupation ou d'abstraction et proposent de nombreux modèles complémentaires. Les
méthodes systémiques sont souvent spécialisées pour la conception d'un certain type de
systèmes. Comme exemple de méthode systémique nous pouvons citer MERISE, AXIAL …
METHODES OBJETS (dites de troisième génération)
Ce sont des méthodes consistant à créer une représentation informatique des éléments du monde
réel auxquels on s'intéresse, sans se préoccuper de l'implémentation, ce qui signifie
indépendamment d'un langage de programmation. Il s'agit donc de déterminer les objets présents
et d'isoler leurs données et les fonctions qui les utilisent. Pour cela des méthodes ont été mises au
point. Entre 1970 et 1990, de nombreux analystes ont mis au point des approches orientées
objets, si bien qu'en 1994 il existait plus de 50 méthodes objet. Toutefois seules 3 méthodes ont
véritablement émergé :
 La méthode OMT de Rumbaugh

 La méthode BOOCH'93 de Booch

 La méthode OOSE de Jacobson.
LES METHODES AGILES : Les méthodes de développement dites « méthodes agiles » (en
anglais Agile Modeling) visent à réduire le cycle de vie du logiciel (donc accélérer son
développement) en développant une version minimale, puis en intégrant les fonctionnalités par
un processus itératif basé sur une écoute client et des tests tout au long du cycle de
développement. Comme méthode agile nous pouvons citer eXtreme Programming (XP).
4.2 ETUDE DE LA METHODE D’ANALYSE ET DE CONCEPTION
4.2.1 LE LANGAGE UML
En regardant les objectifs fixés pour la réalisation du projet, nous

remarquons que nous sommes face à une application modulaire et qui devra rester ouverte
pour les améliorations futures. De ce fait, il est très important d’utiliser un langage universel
pour la modélisation afin de clarifier la conception et de faciliter les échanges. Notre choix est
porté sur le langage UML puisqu’il convient pour toutes les méthodes objet et se prête bien à la
représentation de l’architecture du système.
UML (Unified Modeling Language) est un langage de modélisation unifié

qui permet de modéliser une application logicielle d’une façon standard dans le cadre de la
conception orienté objet. UML permet de couvrir le cycle de vie d’un logiciel depuis
la spécification des besoins jusqu’au codage en offrant plusieurs moyens de description et de
modélisation des acteurs et de l’utilisation système, du comportement des objets, du
flot de contrôle interne aux opérations, des composants d’implémentation et leurs relations,
de la structure matérielle et de la distribution des objets et des composants
indépendamment des techniques d’implémentation et peut être mis à jour selon les
besoins.
Les avantages d’UML :
- Universel.
- Adopté par les grandes entreprises.
- Notation unifiée.
- Facile à comprendre.

- Adopté par plusieurs processus de développement

- Limite les risques d’erreur.
- N’est pas limité au domaine informatique.
UML dans sa version 2 s'articule autour de treize diagrammes ; chacun d'entre eux est dédié à la
représentation d'un système logiciel suivant un point de vue particulier. Ces diagrammes sont
regroupés dans deux grands ensembles: les diagrammes structurels et les diagrammes de
comportement.
DIAGRAMMES STRUCTURELS (LES VUES STATIQUES)
Ces diagrammes permettent de visualiser, spécifier, construire et documenter l'aspect

statique ou structurel du système d'information. Il s'agit outre les diagrammes de cas d'utilisation,
des diagrammes de classes, d'objets, mais aussi de déploiement et de composants
Les cas d'utilisation (uses cases)
Les cas d'utilisation sont une technique de description du système étudié privilégiant le
point de vue de l'utilisateur. Ils décrivent sous la forme d'actions et de réactions, le
comportement d'un système et servent, par conséquent, à structurer les besoins des utilisateurs et
les objectifs correspondants du système.
Les diagrammes d'objets
Ce type de diagramme UML montre des objets (instances de classes dans un état
particulier) et des liens (relations sémantiques) entre ces objets. Les diagrammes d'objets
s'utilisent pour montrer un contexte (avant ou après une interaction entre objets par exemple). Il
sert essentiellement en phase exploratoire, car il possède un très haut niveau d'abstraction.
Les diagrammes de classes
Les diagrammes de classes expriment de manière générale la structure statique d'un système, en
termes de classes et de relations entre ces classes.
Une classe permet de décrire un ensemble d'objets (attributs et comportement), tandis qu'une
relation ou association permet de faire apparaître des liens entre ces objets.

Les diagrammes de paquetages (ou package)
Les paquetages sont des éléments d'organisation des modèles. Ils regroupent des éléments de
modélisation, selon des critères purement logiques. Ils permettent d’encapsuler des éléments de
modélisation et de structurer un système en catégories ( vue logique) et sous-systèmes ( vue des
composants). Ils servent de « briques » de base dans la construction d'une architecture.
Les diagrammes de composants et de déploiement
Les diagrammes de composants permettent de décrire l'architecture physique et statique d'une

application en termes de modules : fichiers sources, librairies, exécutables, etc. Ils montrent la
mise en œuvre physique des modèles de la vue logique avec l'environnement de développement.
Les diagrammes de déploiement montrent la disposition physique des matériels qui composent le
système et la répartition des composants sur ces matériels. Les ressources matérielles sont
représentées sous forme de nœuds, connectés entre eux à l'aide d'un support de communication.
DIAGRAMMES COMPORTEMENTAUX (LES VUES DYNAMIQUES)
Ils modélisent les aspects dynamiques du système, c'est à dire les différents éléments qui sont
susceptibles de subir des modifications. Parmi eux on distingue, les diagrammes de séquence, de
collaboration, d'états - transitions et d'activités.
Ils représentent la dynamique du système, à savoir, non seulement les interactions entre le
système lui-même et les différents acteurs du système, mais aussi, la façon dont les différents
objets contenus dans le système communiquent entre eux.
Les diagrammes de séquence
Les diagrammes de séquences permettent de représenter des collaborations entre objets selon un
point de vue temporel ; on y met l'accent sur la chronologie des envois de messages. Les
diagrammes de séquences peuvent servir à illustrer un cas d'utilisation.

Les diagrammes de collaboration
Les diagrammes de collaboration montrent des interactions entre objets (instances de classes et
acteurs). Ils permettent de représenter le contexte d'une interaction, car on peut y préciser les
états des objets qui interagissent.
Les diagrammes d'états- transitions
Ces diagrammes servent à représenter des automates d'états finis, sous forme de graphes d'états,
reliés par des arcs orientés qui décrivent les transitions. Ils permettent de décrire les changements
d'états d'un objet ou d'un composant, en réponse aux interactions avec d'autres objets/composants
ou avec des acteurs.
Un état se caractérise par sa durée et sa stabilité, il représente une conjonction instantanée des
valeurs des attributs d'un objet.
Une transition représente le passage instantané d'un état vers un autre. Une transition est
déclenchée par un événement. En d'autres termes : c'est l'arrivée d'un événement qui conditionne
la transition. Les transitions peuvent aussi être automatiques, lorsqu'on ne spécifie pas
l'événement qui la déclenche. En plus de spécifier un événement précis, il est aussi possible de
conditionner une transition, à l'aide de "gardes" : il s'agit d'expressions booléennes, exprimées en
langage naturel (et encadrées de crochets).
Les diagrammes d'activités
UML permet de représenter graphiquement le comportement d'une méthode ou le déroulement

d'un cas d'utilisation, à l'aide de diagrammes d'activités (une variante des diagrammes d'états-
transitions). Une activité représente une exécution d'un mécanisme, un déroulement d'étapes
séquentielles. Le passage d'une activité vers une autre est matérialisé par une transition. Les
transitions sont déclenchées par la fin d'une activité et provoquent le début immédiat d'une autre
(elles sont automatiques).
Le langage UML, offre ainsi de nombreux avantages pour l'analyse et la conception d'un système
d'information. Par conséquent, nous combinerons UML au Processus Unifié pour mener à terme
notre système.

4.2.2 LES PROCESSUS UNIFIES
Définition :
Pour définir le processus unifié, nous allons simplement définir les deux termes qui le composent
:
Processus : Suite continue d'opérations constituant la manière de fabriquer. En d'autres

termes, c'est une succession de tâches dans le but d'accomplir un travail, un projet.
Unifié : Etre amené à l'unité, se fondre en un tout. En fait, les méthodes d'analyse et de
conception orientées objet, étaient variées jusqu'à ce que Rambaugh, Jacobson et Booch
eut l'idée de les unifier.
Le processus unifié : un cadre général
Le processus unifié est une démarche de développement logiciel : il regroupe les activités à
mener pour transformer les besoins d'un utilisateur en système logiciel. Ses principales
caractéristiques sont:
 Il est à base de composants,

 Il utilise le langage UML (ensemble d'outils et de diagrammes),
 Il est piloté par les cas d'utilisation,
 Il est centré sur l'architecture,
 Il est itératif et incrémental.
 Guidée par les besoins des utilisateurs du système,
Une démarche itérative et incrémentale ?
L'idée est simple : pour modéliser (comprendre et représenter) un système complexe, il vaut
mieux s'y prendre en plusieurs fois, en affinant son analyse par étapes. Cette démarche
devrait aussi s'appliquer au cycle de développement dont le but est de mieux maîtriser la part
d'inconnu et d'incertitudes qui caractérisent les systèmes complexes.
Une démarche pilotée par les besoins des utilisateurs ?
Avec UML, ce sont les utilisateurs qui guident la définition des modèles :

- Le périmètre du système à modéliser est défini par les besoins des utilisateurs (les
utilisateurs définissent ce que doit être le système).
- Le but du système à modéliser est de répondre aux besoins de ses utilisateurs (les
utilisateurs sont les clients du système).
- Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de
développement (itératif et incrémental) :
- A chaque itération de la phase d'analyse, on clarifie, affine et valide les besoins des
utilisateurs.
- A chaque itération de la phase de conception et de réalisation, on veille à la prise en
compte des besoins des utilisateurs.
- A chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont
satisfaits.
Une démarche centrée sur l'architecture ?
Une architecture adaptée est la clé de voûte du succès d'un développement. Elle décrit des
choix stratégiques qui déterminent en grande partie les qualités du logiciel (adaptabilité,
performances, fiabilité...). Ph. Kruchten propose différentes perspectives, indépendantes
et complémentaires, qui permettent de définir un modèle d'architecture.
4.2.3 LA METHODE 2TUP
Le cycle en Y ou processus 2TUP présente une branche fonctionnelle et une branche technique
bien distincte durant la phase de capture des besoins et d'analyse préalable.
Figure 9 : Le processus de développement en Y

Figure 10 : Le processus de développement en Y (suite)
BRANCHE FONCTIONNELLE
Les principales étapes de la branche fonctionnelle se présentent comme suit :
L’étape capture des besoins fonctionnels : Cette phase a pour objectif de définir :
- La frontière fonctionnelle entre le système et son environnement.

- Les activités attendues des différents utilisateurs par rapport au système.
L’étape d’analyse : consiste à étudier précisément les spécifications fonctionnelles de manière à

obtenir une idée de ce que va réaliser le système en terme de métier.
BRANCHE TECHNIQUE
Les principales étapes de la branche technique se présentent comme suit :
 L’étape capture des besoins techniques : Cette étape recense toutes les contraintes sur les
choix de technologies pour la conception du système. Les outils et le matériel
sélectionnés ainsi que la prise en compte des contraintes d’intégration avec l’existant (pré
requis d’architecture technique).
 L’étape conception générique : Définit les composants nécessaires à la construction de
l’architecture technique. Cette conception est complètement indépendante des aspects fonctionnels. Elle
permet de générer le modèle de conception technique qui définit lesFrameworks.
PHASE CONCEPTION - REALISATION

Les principales étapes de cette branche se présentent comme suit :
 L’étape conception préliminaire : Cette étape permet de produire le modèle de conception

système. Ce dernier organise le système en composants, délivrant les services techniques
et fonctionnels ; ce qui induit le regroupement des informations des branches technique
et fonctionnelle.
 L’étape conception détaillée : permet d’étudier comment réaliser chaque composant. Le
résultat fournit l’image prête du système complet.
 L’étape de codage : permet d’effectuer la production des composants et les tests des unités
de code au fur et à mesure de leur réalisation.
 L’étape de recette : consiste à valider les fonctionnalités du système développé.

CHAPITRE 5 : ANALYSE ET CONCEPTION
Afin de garantir la réussite et l'efficacité de notre projet, il faut à ce stade du travail

définir avec précision la bordure de la solution à développer. Ceci inclut l'énumération des
différents services que notre système est supposé offrir aux différents utilisateurs.
Dans ce chapitre, nous commençons par définir les besoins fonctionnels et non fonctionnels de
notre solution. Puis, en se basant sur cette analyse, nous dégageons une spécification détaillée de
la solution retenue.
5.1 ETUDE PRELIMINAIRE
CAHIERS DE CHARGES
La fonction administrative et financière est l’instigatrice de ce projet. Afin de rester efficient

dans l’élaboration de leurs activités, elle trouve plus adéquat que les tâches affilées au traitement
de la paie se fassent de manière informatisées, permettant ainsi un gain de temps, une diminution
des risques d’erreurs, un meilleur contrôle des informations qui concernent les EVS.
Le progiciel doit être une application qui
 Fonctionne en réseau (accessible quel que soit le lieu de connexion tant que c’est sur le
réseau de SETRAG.
 Doit être fiable (les informations doivent être sure et engage la responsabilité de l’agent
qui les a fourni).
 Sécurisé (Accès et confidentialités limitées qu’aux utilisateurs ayant une habilitation).
 Compatible (Application compatible avec les autres applications de la rémunération).
5.1.1 SYSTEME A METTRE EN PLACE
Le projet soumis à l’étude a pour but de créer une application permettant un traitement
plus efficace et efficient des éléments variables de solde. En effet, elle mettra fin à un processus
qui s’avère être archaïque et administrativement lourd et ce en utilisant les nouvelles

technologies informatiques. Il s’agira donc pour nous de réaliser un progiciel permettant le

traitement quotidien, par les gestionnaires paie, des éléments variables solde.
5.1.2 IDENTIFICATION DES ACTEURS DU SYSTÈME
UML n'emploie pas le terme d'Utilisateur mais d'acteur. Les acteurs d'un système sont les entités
externes à ce système qui interagissent avec lui.
Suivant les besoins de notre système on peut présenter comme acteurs : un

administrateur système, agent administratif et un agent travaillant pour la société. La manière
d'accéder aux services de l'application pour l'un et pour l'autre est la même. La différence réside
sur les droits d'accès et les limites de chacun.
La cible concernée par les EVS est entièrement SETRAG, car les éléments variables de solde
sont payés à tous les agents de toutes catégories, et de toute fonction confondue, seule, la
proportion diffère.
Agents administratifs : Qui ont pour tâches d’élaborer et de traiter les éléments
variables de solde de leurs agents.
 En amont : Les chefs de gare/ de groupe/ d’équipe/ de section et
responsable de la fonction
 En aval : les gestionnaires paie et le responsable de la sous fonction paie.
Agent SETRAG. : Il accède au système pour consulter ses EVS enregistrés.
Administrateur système : C'est le super-utilisateur qui gère le système. Il gère les
comptes des utilisateurs du système et met à jour la base de données du système.
PRIORITE ASSIGNEE AUX UTILISATEURS :
Les priorités assignées aux utilisateurs sont spécifiques. En effet, selon la tâche à
accomplir dans le processus des EVS (Renseignement ; Contrôle ; et Validation), chaque
utilisateur aura une habilitation spécifique. Un regroupement par catégorie et par type de
responsabilité se fera afin de configurer des paliers d’accréditation ; ces paliers permettront selon
la tâche, à faire des saisies, des enregistrements, des modifications, des validations…
IMPLICATION NECESSAIRE DE LA PART DES UTILISATEURS DANS LE PROJET :

Afin que le projet atteigne son but, c’est-à-dire la conceptualisation des éléments
variables de solde en application informatique, il faut que les acteurs de ce domaine (des agents
administratifs au gestionnaire concerné pour la paie) s’impliquent d’avantages pour que le projet
soit une affaire de tous et que chacun trouve son avantage dans la nouvelle méthode de travail.
UTILISATEURS CONCERNES PAR LES OPERATIONS DE MAINTENANCE DU

PROGICIEL :
L’utilisateur concerné dans la maintenance du progiciel est la Fonction SICOM, elle garde
une place d’administrateur du système. Par rapport aux besoins des clients, elle aura la tâche de
veiller au bon fonctionnement de l’application et à la sécurisation de la base de données.
5.1.3 IDENTIFICATION DES MESSAGES DU SYSTÈME
Explications
VISUALISER Il s’agit de voir en aperçu comment sont

renseignés les EVS, ou fiche agent.
SAISIR Il s’agit de renseigner à l’aide des fiches EVS

l’application, c’est-à-dire d’inscrire les primes de
chaque agents dans sa fiche EVS.
MODIFIER Il s’agit de faire des modifications lorsqu’il y a

des erreurs à un endroit précis. Cette commande
est exclusivement réservée au chef de sous
fonction.
ENREGISTRER Il s’agit ici d’enregistrer des modifications,

saisies.
CORRIGER Il s’agit ici de corriger toute la fiche EVS en

entier. C’est une sorte de remise à zéro de la
fiche.
NOTIFIER Il s’agit d’une alerte/ message à son collaborateur

en général ; elle informe que les données sont
prêtes.
VALIDATION GENERALE Il s’agit d’une validation, ici lorsque chaque fiche

EVS est enregistrée après le contrôle définitif on
valide intégralement.
REJETER Il s’agit d’un rejet du système d’une fiche EVS,

en général elle s’accompagne d’une notification
adressée à l’utilisateur en charge dudit document.
Le rejet s’active lorsque l’utilisateur constate des
anomalies sur sa fiche.

GENERER Il s’agit ici de générer des tableau pour

consultation ou impression. Ainsi que convertir
les données de l’application pour exportation sur
SAGE PAIE.
ORDONNER LE PAIEMENT Il s’agit ici de faire comprendre à la sous fonction

paie que les EVS sont prêt et qu’il faut passer au
paiement, c’est une sorte de mail ou notification
afin qu’elle contrôle et paie.
Tableau 4 : Explication des messages émis et reçues par le système.
NIVEAU D’HABILITATION :
Il existe plusieurs niveaux d’habilitation. Tous dépendent du pouvoir que l’utilisateur est capable
de faire sur l’application. Des habilitations peuvent aussi être données exceptionnellement ou
temporairement tout dépend de ce que fera l’utilisateur comme activité.
NIVEAU HABILITATION CATEGORIES POUVOIRS
 Le chef de groupe/ Visualiser ; saisir ; modifier ;

section/ équipe : enregistrer ; corriger ; notifier ;
validation;
Accréditer niveau 1
Accréditation niveau 2  Le chef de sous Visualiser ; enregistrer ;

fonction : corriger ; notifier ; générer ;
validation générale ;
Accréditation niveau 3  Le gestionnaire paie : Visualiser ; rejeter ; ordonner le

paiement ; générer ;
Accréditation niveau 4  Le responsable sous Visualiser ; générer ; rejeter ;

fonction paie : valider le paiement ;
Tableau 5: Niveau d’accréditation
5.1.4 LA RÉALISATION DES DIAGRAMMES DE CONTEXTE

L'application est considérée comme étant une boite noire qui interagit avec les déférents
acteurs. Des liens relient l'application à chacun des acteurs sur lesquels sont montrés les
messages en entrée et en sortie de l'application.

Figure 11 : diagramme de contexte dynamique.
Message reçus et émis par le système
Acteurs Messages envoyés au Messages émis par le

système système
Administrateur système 2. Saisir 1. Visualiser
3. Modifier
4. Générer
Utilisateur ou Agent 2.Saisir 1. Visualiser

SETRAG 6. Notifier
Chef de gare /Section 2. Saisir ; 1. Visualiser ;

/Groupe /Equipe 3. Modifier ; 6. Notifier
4. Enregistre ;
5. Corriger ;
7. Valider

Responsable de sous 2. Saisir ; 1. Visualiser ;

Fonction 3. Modifier ; 6. Notifier
4. Enregistre ; 9. Rejeter
5. Corriger ;
7. Valider ;
10. Ordonner le
paiement
Responsable de sous 7. Valider ; 1. Visualiser ;

fonction paie / Responsable 6. Notifier
de la Fonction Paie 8. Générer
9. Rejeter
Tableau 6 : Messages émis et reçu par le système.
5.2 CAPTURE DES BESIONS FONCTIONNELS ET NON FONCTIONNELS
5.2.1 CAPTURE DES BESIONS FONCTIONNELS

Les besoins de l’utilisateur : doit pouvoir jouir des fonctionnalités suivantes ;
S'authentifie
Récupérer le mot de passe oublié
Inscrire les primes de chaque agent dans sa fiche EVS
Générer des tableaux pour consultation ou impression
Convertir les données de l’application pour exportation sur SAGE PAIE.
L’application conservera les procédures de calcul des éléments variables grâce aux données
suivantes :
 HEURES SUPPLEMENTAIRES  PRIME d’ASTREINTE

 MAJORATIONS  PRIME de SECURITE MANŒUVRE
 PRIMES de NUIT  PRIME de PANIER
 PRIMES de DIMANCHE et FETES  PRIME de CONTROLE au SOL
 PRIME de RECETTES  PRIME de BILLETAGE
 PRIME de TRAVAUX ACCIDENTELS  INDEMNITES FRAIS de DEPLACEMENT
 PRIME de TRACTION  PRIME de TRAVAUX SALISSANT
Tableau 7 : les EVS.

5.2.2 CAPTURE DES BESIONS NON FONCTIONNELS
A part les besoins fondamentaux, notre futur système doit répondre aux critères suivants:
LA RAPIDITE DE TRAITEMENT:
En effet, vu le nombre important des transactions quotidiennes, il est impérativement

nécessaire que la durée d'exécution des traitements s'approche le plus possible du temps réel.
LA PERFORMANCE:
Un logiciel doit être avant tout performant c'est à-dire à travers ses fonctionnalités,
répond à toutes les exigences des utilisateurs d'une manière optimale.
LA CONVIVIALITE :
Le futur logiciel doit être facile à utiliser. En effet, les interfaces utilisateurs doivent être
conviviales c'est-à-dire simples, ergonomiques et adaptées à l'utilisateur.
ERGONOMIE OU CONVIVIALITE DU LOGICIEL :
Hormis la facilité d’exploitation, il faut que l’application soit conviviale et que

l’utilisateur se trouve vite au sein de celle-ci, qu’il puisse travailler sans complexe, que tous les
accès qui lui sont attribués soient facile à exploiter.
L’INTERFACE :
L’application doit être insérée dans l’onglet LOGICIEL de l’intranet. Tout comme les
autres applications, elle sera simple à trouver pour les utilisateurs. Le même design de l’interface
doit être similaire à celui des autres applications.
RAPIDITE D’EXECUTION ET TEMPS DE DE LATENCE :
L’application doit être capable d’exécuter toutes ses fonctionnalités dans un laps de
temps donné. En effet, un calendrier sera constitué afin que l’enregistrement des éléments
variables se fasse à une période précise du mois. L’application elle-même annoncera la date
butoir par une alerte.

CAPACITE DE STOCKAGE :
S’assurer que le progiciel est capable de traiter les volumes attendus. En somme il doit
pouvoir recueillir au moins 10 ans d’archives sous forme de base de données consultable.
LES DIFFERENTS MOYENS DE CONTROLE :
L’application est en mesure de faire des états par types. En somme, selon l’accréditation
de l’utilisateur, certains états peuvent être demandés par ce dernier à des fins de contrôle. Un
état est le regroupement d’informations sous forme de tableau par exemple un tableau permettant
de reconstituer à une date précise l’ensemble des primes reçues par un département spécifique ou
agent.
PROTECTION DES DONNEES A CARACTERE PERSONNEL :
L’application doit s’assurer de la protection de la vie privée des personnes sur lesquelles
des informations sont stockées. Elle doit aussi être conforme aux lois sur la protection des
données à caractère personnel.
AUDIT ET TRAÇABILITE :
L’application doit conserver des informations sur qui l’a utilisée, quand, pourquoi ; qui a
modifié telle informations, quand, pourquoi… l’objectif est d’augmenter la sécurité, et minimiser
les risques d’intrusion ayant pour objectif de nuire : une personne ne pourra pas nier avoir utilisé
le logiciel ni avoir participé à telle enregistrement en utilisant l’application.
PROTECTION CONTRE LES INFECTIONS :
Construire un produit aussi sur que possible face aux interférences malintentionnées comme les
virus, et c’est donc au serveur d’assurer cette protection.
FACILITE D’UTILISATION ET FACTEURS HUMAINS :
FACILITE D’UTILISATION :
L’application doit être simple à utiliser, en somme, elle est la retranscription de fiche
EVS en progiciel informatique.
FACILITE D’APPRENTISSAGE :
Une formation se fera afin que tous les acteurs des EVS aient la capacité d’utiliser cette
application conformément aux exigences qu’elle requiert.

LIMITE DU PRODUIT :
Aucune limite ne peut être instaurée pendant la création de l’application car ce n’est
qu’en l’expérimentant que nous pourrons apporter des modifications.
ACCES AU SYSTEME :
L’accès au système est conditionné par un login et un password. Ces attributions sont émises
par la fonction informatique lorsque la demande est faite par une fonction ressource de ce
système. A chaque attribution son habilitation.
5.2.3 IDENTIFICATION DES CAS D’UTILISATION
Cas d’utilisations Acteurs Messages émis Messages reçu
Gérer la période de Gestionnaire paie, Consulter, Modifier, Visualiser,

collecte administrateur Supprimer s’authentifier
Planifier les Le chef de groupe/ Consulter, Modifier, Visualiser,

activités de l’agent section/ équipe, chef Supprimer, ajouter s’authentifier
de fonction
Collecter les EVS Le chef de groupe/ Saisir ; modifier ; Visualiser

de l’agent section/ équipe, chef enregistrer ; corriger ;
de fonction notifier ; validation
Gérer la présence Le chef de groupe/ Saisir ; modifier ; Visualiser

de l’agent section/ équipe, chef enregistrer ; corriger ;
de fonction notifier ; valider
Valider les EVS de chef de fonction Enregistrer ; corriger ; Visualiser ;

chaque agent. notifier ; générer ; valider;
Exporter les Le responsable sous Enregistrer ; corriger ; Visualiser

données de l’agent fonction paie : notifier ; générer ; valider
Gere les utilisateurs Administrateur Création, modification, S’authentifie

suppression, consultation
Gérer les profils Administrateur Création, modification, S’authentifie

Gérer les EVS administrateur Création, modification, S’authentifie

Visualiser ou Utilisateur S’authentifie S’authentifie

Consulter la fiche
des EVS de l’agent
S’authentifier Utilisateur S’authentifie S’authentifie
Tableau 8: identification des cas utilisations.
5.2.4 DESCRIPTION DES CAS D’UTILISATION
CAS UTILISATION « PLANIFIER LES ACTIVITES D’UN AGENT »
Titre : Planifier les activités d’un agent
Résumé : Cette fonctionnalité permet d’organiser les tâches et planning du travail de l’agent :
quotidien, hebdomadaire, mensuel.
Acteur : Agent administratif : Le chef de groupe/ section/ équipe, chef de fonction
Date de création : 28/08/2014 Date de modification : 30/09/2014
Version : 1.0 Responsable : Sylvain MPIGA
Pré conditions: Le système est déployé. Il fonctionne normalement.

Post conditions : Le cas d’utilisation « S’authentifier » s’est effectué avec succès
Scénario nominal :
 La connexion intranet est disponible
 Ce cas d’utilisation commence lorsque l’agent administratif s’est connecté à
l’application.
Création
 L’agent administratif saisie le non de l’agent de son service
 L’agent administratif enregistre le planning de travail de l’agent ;
 Il enregistre les tâches de l’agent ;
Mise à jour
Pré condition : Un agent est planifier au départ dans le système ;
 L’agent administratif identifie l’agent de son service à modifier ;
 Il modifie le planning de travail de l’agent ;
 Il enregistre la mise à jour ;
Suppression
Pré condition : un agent au moins existe dans le système ;
 L’agent administratif identifie le planning à supprimer ;

 L’agent administratif supprime l’agent planifier ;

 Il enregistre la suppression ;
.
CAS UTILISATION « GERER LA PERIODE DE COLLECTE »
Titre : Gérer la période de collecte
Résumé : Cette fonctionnalité permet Gestionnaire paie, administrateur d’ouvrir et clôturer le

calendrier de saisie.
Acteur : Gestionnaire paie, administrateur

Post conditions :
 Gestionnaire paie, administrateur est authentifié
Scénario nominal :
Ce cas d’utilisation commence lorsque Gestionnaire paie, administrateur s’est connecté à l’application.
Création
 Gestionnaire paie défini la date de début et date de fin
 Il enregistre les informations;
 Le système informe au Gestionnaire du succès de l’enregistrement.
Mise à jour
Pré condition : La période de collecte au moins existe dans le système ;
 Gestionnaire paie identifie la période à modifier ;
 Le Gestionnaire modifie la période;
Suppression
Pré condition : la période au moins existe dans le système ;
 Gestionnaire paie, administrateur identifie la période à supprimer ;
 Le Gestionnaire supprime la période ;
.

CAS UTILISATION « COLLECTER OU SAISIR LES EVS DE L’AGENT »
Titre : Collecter, saisir les EVS de l’agent
Résumé : Cette fonctionnalité permet à l’agent administratif de saisir, modifier, supprimer les
EVS de l’agent de son service quotidiennement.
Acteur : l’agent administratif (le chef de groupe/ section/ équipe, chef de fonction)
Version : 1.0 Responsable :Sylvain MPIGA
Post conditions :

 L’agent administratif est authentifié
Scénario nominal :
Ce cas d’utilisation commence lorsque l’agent administratif s’est connecté à l’application.
Création
 L’agent administratif identifie l’agent dans le système ;
 L’agent administrateur saisie les différents EVS de l’agent ;
 Il enregistre les données dans le système ;
 Le système informe l’agent administratif du succès de l’enregistrement.
Mise à jour
Pré condition : les EVS sont attribués à l’agent au départ dans le système ;
 L’agent administratif identifie les EVS de l’agent de son service à modifier ;
 L’agent administrateur modifie les EVS de l’agent ;
Suppression
Pré condition : les EVS sont attribués à l’agent au départ dans le système ;
 L’agent administrateur identifie les EVS de l’agent à supprimer ;
 L’agent administrateur supprime les EVS de l’agent;
.

CAS UTILISATION « GERER LA PRESENCE DE L’AGENT»
Titre : Gérer la présence de l’agent
Résumé : Ce cas d’utilisation permet à l’agent administratif de savoir le statut de l’agent ( si

l’agent est présent au poste, en cas d’absence donner le motif).
Acteur : Agent Administratif (le chef de groupe/ section/ équipe, chef de fonction)

Post conditions : L’agent administratif est authentifié
Scénario nominal :
 l’agent administratif s’est connecté à l’application.
Création
 l’agent administratif identifie un agent de son service dans le système ;
 L’agent administratif définit le statut de l’agent ;
 Le système affiche la liste des agents et des statuts
 L’agent administrateur enregistre les données dans le système ;
Mise à jour
Pré condition : le statut de l’agent au moins existe dans le système ;
 L’agent administratif identifie le statut de l’agent de son service à modifier ;
 L’administrateur modifie le statut de l’agent;
Suppression
Pré condition : le statut de l’agent au moins existe dans le système ;
 L’agent administratif identifie le statut de l’agent de son service à supprimer ;
 L’administratif supprime le statut de l’agent;
.
CAS UTILISATION « VALIDER LES EVS DE CHAQUE AGENT»
Titre : Valider les EVS de chaque agent.
Résumé : Ce cas d’utilisation permet à l’agent administratif ici lorsque chaque fiche EVS est
enregistrées après le contrôle définitif on la valide.
Acteur : Agent Administratif (le chef de groupe/ section/ équipe, chef de fonction)

Pré conditions :
 L’acteur est bien connecté à l’application
Scénario nominal :
Création :
1. l’agent administratif visualise la liste des agents dans le système ;
2. L’agent administratif identifie un agent ;
3. Le système affiche la liste des agents
4. Le système affiche l’agent et la liste des EVS obtenue
5. L’agent administratif vérifie la conformité des EVS de l’agent;
CAS UTILISATION « EXPORTER LES DONNEES»
Titre : Exporter les données

But : transport des fichiers
Résumé : Cette fonctionnalité permet de convertir les données en fichier.txt. Pour importer vers
le logiciel paie SAGE
Acteurs : Gestionnaire paie
Pré condition :
 La connexion internet est disponible
 Le gestionnaire paie s’est authentifié avec succès
Post conditions : Le système fonctionne
Scénario nominal
Ce cas d’utilisation commence lorsqu’un acteur veut transférer les EVS à la paie;
1. Le gestionnaire paie sélection le service des agents;
2. le système affiche le fichier texte du service des agents;
3. le gestionnaire valide ;
4. puis enregistre le fichier.
CAS UTILISATION « GERER LES UTILISATEURS»
Titre : Gérer les utilisateurs.
But : L’administrateur gère les droits d’accès de tous les autres utilisateurs du système, il peut
créer, modifier ou supprimer les comptes de tous les autres types d’utilisateurs.
Acteur : Administrateur.


Pré conditions : Le cas d’utilisation « S’authentifier » s’est effectué avec succès.
Post conditions : L’administrateur s’est authentifié

Scénario nominal :
Ce cas d’utilisation commence lorsque l’administrateur s’est connecté à l’application.
Création
 L’administrateur crée un nouvel utilisateur dans le système ;
 L’administrateur définit le profil de l’utilisateur ;
 Il enregistre le nouvel utilisateur dans le système ;
Mise à jour
Pré condition : Un utilisateur au moins existe dans le système ;
 L’administrateur identifie l’utilisateur à modifier ;
 L’administrateur modifie le profil de l’utilisateur ;
Suppression
Pré condition : un utilisateur au moins existe dans le système ;
 L’administrateur identifie l’utilisateur à supprimer ;
 L’administrateur supprime le profil de l’utilisateur ;
.
CAS UTILISATION «GERER LES PRIVILEGES »
Titre : Gérer les privilèges

Résumé : Cette fonctionnalité permet à l’administrateur d’ajouter, modifier, supprimer les privilèges
Acteur : Administrateur
Pré conditions: Le système est déployé et le système fonctionne normalement
Post conditions : L’administrateur est authentifié et le privilège est modifié

CAS UTILISATION «S’AUTHENTIFIER»
Titre : S’authentifier
But : Assurer la sécurité et l’intégrité des données
Résumé : Tous les utilisateurs peuvent accéder au système Cependant, chacun d'eux à un certain
nombre de privilèges. C'est pour cela, qu'il faut au début s'identifier en donnant son login et son
mot de passe.
Acteurs : Utilisateur, administrateur. Agent administratif
Date de création : 28/08/2014 Date de modification :
28/08/2014
Pré condition :
 Le système est déployé. Il fonctionne normalement
Post conditions : Le système fonctionne l’acteur est authentifié
Scénario nominal
Ce cas d’utilisation commence lorsqu’un acteur veut utiliser l’application;
1. Le système demande à l’acteur de s’authentifier ;
2. L’acteur saisit son login et son mot de passe puis valide ;
3. Le système vérifie ces informations (E)
4. Le système ouvre la section correspondante ;
Exception (E) du Scénario nominal
Si lors du contrôle des informations ne sont pas correctes
a)le système renvoie un message d’erreur soit sur le login ou le mot de passe et retourne en
2.
CAS UTILISATION «CONSULTER LES EVS DE L’AGENT»
Titre Consulter les EVS de l’agent
But : visualise les EVS

Résumé : Cette fonctionnalité permet à l’utilisateur de voir la liste de ces EVS obtenus
Acteur : agent administratif, administrateur, agent SETRAG
Version : 1.0 Responsible: Sylvain MPIGA
Pré conditions:

 Le système est déployé. Il fonctionne normalement.
Post condition : l’utilisateur s’authentifie.

Scénario nominal
1. L’acteur invoque l’écran d’affichage de la fiche de ces EVS dans un zone
2. Le système affiche la fiche
3. L’acteur vérifie la conformité
4. Il notifie
CAS UTILISATION «GERER LES ELEMENTS VARIABLES SOLDE»
Titre : Gérer les éléments variables solde.
But : Permet à l’administrateur d’ajouter, modifier, supprime un EVS
Acteur : Administrateur.
Pré conditions :
Post conditions :
Scénario nominal :
Ce cas d’utilisation commence lorsque l’administrateur s’est connecté à l’application.
Création
1. L’administrateur demande la liste des EVS dans le system.

2. Le système lui restitue cette liste.
3. L’administrateur sélectionne un EVS dans la liste.
4. Le système affiche les données.
5. l’administrateur procède à la manipulation des données
Mise à jour
Pré condition : un des EVS au moins existe dans le système ;
 L’administrateur identifie l’EVS à modifier ;
 L’administrateur modifie l’EVS ;
Suppression
Pré condition : un EVS au moins existe dans le système ;
 L’administrateur identifie l’EVS à supprimer ;
 L’administrateur supprime l’EVS ;
 Il enregistre le suppression ;
.

5.2.5 DIAGRAMME DES CAS D’UTILISATION
Le but de ces diagrammes et d'avoir une vision globale sur les interfaces du futur logiciel. Ces
diagrammes sont constitués d'un ensemble d'acteurs qui agit sur des cas d'utilisation.
Figure 12 : diagramme des cas d’utilisation global.
Diagramme de CU «s’authentifier»
Figure 13 : Diagramme de cas utilisation « S’authentifier »

Diagramme de CU «Administrateur »
Figure 14 : CU « administrateur »
5.2.6 STRUCTURATION EN PACKAGES
CAS D’UTILISATIONS ACTEURS PACKAGE
 Gérer la période de collecte Gestion des EVS

 Collecter les EVS de l’agent des agents
 Planifier les activités de l’agent Utilisateur,
 Générer la présence de chaque Agent administratif
agent
 Exporter les données
 Visualiser ou Consulter les EVS de
chaque agent
 S’authentifier
 Gérer les profils Gestion des

 Gérer les privilèges Administrateur utilisateurs
 Gérer les EVS
 Gérer utilisateurs
Tableau 9 : Structuration en package des CU

ANALYSE DU SYSTÈME
UML 2.0 comporte treize types de diagrammes représentant autant de vues distinctes
pour représenter des concepts particuliers du système d’information. Ils se répartissent en
deux grands groupes : les diagrammes structurels ou statiques et les diagrammes
comportementaux ou dynamiques. Mais la production de tous ceux-ci n’est pas primordiale
pour cerner le fonctionnement de l’application. Toutefois les diagrammes statiques
présentent au mieux la structuration du système.
5.3.1 DEVELOPPEMENT DU MODELE STATIQUE
A l’occasion d’une modélisation, tous les diagrammes ne sont pas nécessairement

produits. C’est ainsi qu’au niveau du modèle statique, le diagramme de classes est
généralement celui retenu car il représente l’architecture conceptuelle du système. Il
exprime la structure statique du système en termes de classes et de relations entre ces
classes. L’intérêt du diagramme de classes est de modéliser les entités du système
d’information. Il permet de représenter l’ensemble des informations finalisées qui sont
gérées par le domaine.
Une classe est une description abstraite d’un ensemble d’objets du domaine de
l’application.
* DIAGRAMME DES CLASSES PARTICIPANTES
Le diagramme de classes est le point central dans un développement orienté objet. En analyse, il
a pour objectif de décrire la structure des entités manipulées par les utilisateurs. En
conception, le diagramme de classes représente la structure d'un code orienté.
 Une classe : Représente la description abstraite d'un ensemble d'objets possédant les
mêmes caractéristiques. On peut parler également de type.
 Un objet: Est une entité aux frontières bien définies, possédant une identité et
encapsulant un état et un comportement. Un objet est une instance (ou occurrence) d'une
classe.
 Un attribut : Représente un type d'information contenu dans une classe.

 Une opération: Représente un élément de comportement (un service) contenu dans une
classe.
 Une association: Représente une relation sémantique durable entre deux classes.
 Une superclasse : Est une classe plus générale reliée à une ou plusieurs autres classes
plus spécialisées (sous-classes) par une relation de généralisation. Les sous-classes «
Héritent » des propriétés de leur superclasse et peuvent comporter des propriétés
spécifiques supplémentaires.
Diagramme des classes
Figure 15 : Diagramme des classes saisir prime
Figure 16 : Diagramme de classes de conception

5.3.2 DEVELOPPEMENT DU MODELE DYNAMIQUE
Le modèle dynamique utilise un bon nombre de diagrammes pour traduire la

dynamique du système. On peut citer entre autre les diagrammes d’activités, les
diagrammes d’états-transitions, les diagrammes de collaboration, les diagrammes de
séquence.
La vue des cas d’utilisation est une description fonctionnelle des besoins,
structurée par rapport à des acteurs. Le passage à l’approche objet s’effectue en
associant une collaboration à chaque cas d’utilisation. Une collaboration décrit les
objets du domaine, les connexions entre ces objets et les messages échangés par les
objets.
Le diagramme de collaboration permet de mettre en évidence les interactions

entre les différents objets du système et une interaction définit la communication
entre les objets sous la forme d’un ensemble partiellement ordonné de messages.
Quant au diagramme de séquence, même s’il est une variante du diagramme de

collaboration, il privilégie la représentation temporelle par rapport à la représentation
spatiale et est plus apte à modéliser les aspects dynamiques du système.
C’est pourquoi nous avons choisi de développer notre modèle dynamique à

l’aide des diagrammes de séquence puisqu’il permet de visualiser les messages par
une lecture de haut en bas. L’axe vertical représente le temps et l’axe horizontal les
objets qui collaborent. Une ligne verticale en pointillés est attachée à chaque objet et
représente sa durée de vie.
5.3 CONCEPTION DU SYSTÈME
5.4.1 ARCHITECTURE TECHNIQUE EXTERNE
Le système que nous mettons en place repose sur les web services. Le système
publie donc ses fonctions pour permettre aux différents clients de les consommer.
On retrouve dans cette architecture autant d’intervenants que de niveaux d’abstraction.

Ces derniers se partagent, en effet, les tâches comme suit : le serveur de la base de données
permet le stockage des informations pertinentes et persistantes pour le système. Le serveur Web,
quant à lui, en plus de traiter les requêtes HTTP en provenance du client, gère un moteur PHP lui
permettant d’interpréter les scripts PHP attachés à ces dernières.

5.4.2 ARCHITECTURE LOGICIELLE
L’architecture qui portera l’application est celle que nous présentons dans la suite.
Figure 17 : architecture technique.
5.4.3 FRAMEWORK TECHNIQUES
En Programmation Orientée Objet (POO), un Framework est composé de classes mères qui
seront dérivées et étendues par héritage en fonction des besoins spécifiques à chaque logiciel qui
utilisera le Framework. Le Framework technique ne concerne que les fonctionnalités de la
branche droite du processus 2TUP. L es Framework techniques sont décrits comme suit :
Framework « Présentation » :
Permet de gérer la communication avec l’utilisateur pour la saisie des données, l’affichage et
l’impression. Il ne fait pas de traitement, il fait juste une validation élémentaire des données
saisies. Cette couche sera composée de vues ou interfaces web et chaque interface est représentée
par des formulaires, tableaux, menu, boutons…
Framework « Applicatif » :
Permet de gérer le déroulement des fonctionnalités du logiciel et la communication avec les

autres applications et services. Il n’y a pas de vérification de règles de gestion ni de calculs
complexes. Cette partie n’est pas visible par l’utilisateur du système. Elle permet de regrouper

les interfaces précédentes qui exécutent certaines commandes et actions afin de communiquer
avec la couche métier.
Framework « Métier » :
Permet de gérer les informations associées aux catégories d’objets et d’appliquer les règles de
calculs et de gestion. Cette couche va comporter la liste de tous les services métier
correspondant aux cas d’utilisation et faisant liaison entre les commandes de l’utilisateur et la
couche de données.
Framework « Accès aux données » :

Permet de gérer l’accès aux données persistantes provenant de notre base de données gérée par
un Système de Gestion de Base de Données. Le serveur d’application hébergeant notre
plateforme contient plusieurs applications et notre application dispose de plusieurs
fonctionnalités chose qui devrait causer l’alourdissement des temps de réponses aux requêtes.
Ceci dit on a pris compte de cette contrainte et nous avons proposé la solution de «Sessions » qui
offrira la possibilité de partage et d’intégrité entre plusieurs utilisateurs.
ORGANISATION DU MODELE LOGIQUE DE CONCEPTION TECHNIQUE
L’organisation du modèle logique reprend les couches logicielles. À chaque couche correspond
un Framework technique, en partie abstrait, qui définit des interfaces de réalisation des
responsabilités logicielles
Figure 18 : Organisation des Framework techniques.

5.4.4 DIAGRAMME DE DEPLOIEMENT

Le diagramme de déploiement définit l’architecture matérielle de l’application. Il
présente les périphériques utilisés et la répartition du système sur ces différents éléments. Il
montre aussi les liens de communication entre ces diverses entités.
Figure 19 : Diagramme de déploiement.

5.4.5 LES DIAGRAMMES DE SEQUENCES
Diagramme de séquence du cas d'utilisation "authentification"
1. l'utilisateur demande le formulaire d'authentification.

2. L'application affiche le formulaire d'authentification.
3. L'utilisateur saisit le mot de passe.
4. Le système vérifie la validité du mot de passe.
5. L'application affiche la page d'accueil.

Figure 20 : Diagramme de séquence « s’authentifier »
Le diagramme d'activité d'authentification nous permet de voir les comportements internes du

système, lors du démarrage de l'application par l'utilisateur, le système lui affiche le formulaire
d'authentification, après que le mot de passe soit saisit le système vérifie sa validité et affiche la
page d'accueil sinon il affiche un message d'erreur.
Diagramme d’activité du cas d'utilisation "authentification"
Figure 21 : Diagramme d’activité « s’authentifier »

Diagrammes de séquence (ajout d'un utilisateur)
Figure 22 : Diagrammes de séquences (Gérer utilisateur)
Diagrammes d'activité (ajout d'un utilisateur)
Figure 23 : Diagrammes d'activité (ajout d'un utilisateur).

Diagramme de séquence saisir les EVS de l’agent
Figure 24 : Diagramme de séquence de saisir les EVS de l’agent
CONCLUSION
L’analyse et la conception de notre projet ont été faites dans ce chapitre grâce au duo 2TUP-
UML. L’étape suivante qui sera abordée au prochain chapitre est la mise en œuvre de notre
projet.

TROISIEME PARTIE : MISE EN ŒUVRE ET CONDUITE DU PROJET

INTRODUCTION
Dans cette partie, consacrée à la mise en œuvre et la conduite du projet ; nous présenterons
l’environnement matériels et logiciel du projet les outils de développement adoptés, les aspects
sécuritaire et les résultats de notre travail. Nous finirons par le bilan du travail réalisé.

CHAPITRE 6 : MISE EN ŒUVRE
6.1 ENVIRONNEMENT DE TRAVAIL
6.1.1 ENVIRONNEMENT MATERIEL
Le déploiement nécessite l’implémentation des ressources suivantes :
 Un réseau TCP/IP à haut débit offrant une bande passante suffisamment large pour
supporter le déplacement d’une quantité importante de données
 le système d’exploitation Windows quelle que soit la version pour les clients;
 Un serveur performant Linux pour l’hébergement de l’application
 Un serveur performant pour le traitement et le stockage des données.
 Un poste client.
6.1.2 ENVIRONNEMENT LOGICIEL

Nous étudions ici la faisabilité de l'application à travers le choix adéquat des outils de
travail. Un accent est mis sur l'exploitation des logiciels et systèmes libres qui ne cessent de faire
leurs preuves en informatique
CHOIX DE SMARTY :
C’est un environnement propre à la SETRAG. Smarty est un moteur de Template pour PHP.
Plus précisément, il facilite la séparation entre la logique applicative et la présentation.
L'un des aspects unique de Smarty est la compilation des Template. Cela signifie que Smarty lit
les Template et crée des scripts PHP à partir de ces derniers. Une fois créés, ils sont exécutés. Il
n'y a donc pas d'analyse coûteuse de Template à chaque requête, et les Template peuvent
bénéficier des solutions de cache PHP comme Zend Accelerator ou PHP Accelerator.
Smarty peut identifier de nombreuses erreurs comme des attributs de balises manquants ou de
noms de variables malformés et indique le nom du Template, le numéro de la ligne et l'erreur.

LA BASE DE DONNEES
Une base de données est composée de données stockées dans des mémoires de masse
sous une forme structurée, et accessibles par des applications différentes et des utilisateurs
différents. Une base de données doit pouvoir être utilisée par plusieurs utilisateurs en même
temps.
Un SGBD (Système de Gestion de Bases de Données) est un ensemble de logiciels

chargés d'assurer les fonctions minimales suivantes :
Le maintien de la cohérence des données entre elles
Le contrôle d'intégrité des données accédées
Les opérations classiques sur les données (consultation, insertion, modification,
suppression)
Les autorisations d'accès aux données.
 SQL (Structured Query Language) est un langage de manipulation de bases de données
mis au point dans les années 70, et il permet trois types de manipulations :
La maintenance des tables : création, suppression, modification de la structure des tables.
La manipulation des données : sélection, modification, suppression d'enregistrements.
La gestion des droits d'accès aux tables : contrôle des données; droits d'accès, validation
des modifications.
CHOIX D’ORACLE
Afin de stocker les données il fallait également une base de données. Oracle est un système
de gestion de base de données relationnelle très connu. Il est réputé pour être performant,
fiable,... Oracle est en fait la référence en matière de base de données relationnelle. Les
possibilités d'administration sont importantes et permettent de gérer des bases de tailles
importantes
CHOIX DE TOAD
Toad™ Data Point est un outil d'intégration de données et de recherche inter-plateformes qui
simplifient l'accès aux données, l'analyse et le provisioning pour les professionnels de la gestion
des données. Cet outil d'analyse de données permet une connectivité pour la transmission des
données pratiquement illimitée, une intégration des données de bureau, la création de requêtes
visuelles et l'automatisation du workflow.
Il permet principalement :

- Consulter le schéma et les informations sur les bases de données

- Lancer des requêtes
- Consulter le plan EXPLAIN et les statistiques
- Créer des requêtes (query builder)
- Vérifie et Lance des procédures PL/SQL
- Créer des scripts
CHOIX DE PHP5 (PHP HYPERTEXT PREPROCESSOR)
PHP (HyperText Preprocessor) est un langage interprété (un langage de script) et exécuté
du côté serveur. PHP est l'un des langages les plus utilisés dans le développement web et mieux
depuis la prise en charge dans sa version 4 de la Programmation Orientée Objet (POO). Presque
tous les SGBD du marché peuvent s'interfacer avec PHP (commerciaux ou venant du monde
libre). Nous l'avons utilisé pour insérer des données dans la base de données à partir des
formulaires de saisie aussi pour extraire des données de la base de données.
HTML/CSS :
HTML (HyperText Markup Language) est le langage de base pour concevoir des pages
destinées à être publiées sur le Web. Il permet la mise en forme du contenu d'une page web.
CSS (Cascading Style Sheets : feuilles de style en cascade) est utilisé pour la présentation des
documents HTML. Il sépare la structure d'une page web de ses divers styles de présentation.
Nous avons utilisé ces deux langages pour réaliser nos interfaces web : les formulaires de saisie
de données notamment.
JAVASCRIPT
C’est un langage de programmation qui est inclue dans le code HTML. Il permet
d'apporter des améliorations au langage HTML en permettant d'exécuter des commandes.
ENVIRONNEMENT DE DEVELOPEMENT EASYPHP

EasyPHP est un package qui vous permet en une seule installation d'avoir sur votre PC un
environnement de développement PHP complet, vous permettant de créer vos sites dynamiques.
EasyPHP installe et configure automatiquement tous les outils nécessaires, dont le serveur
Apache, le parser (Algorithme qui permet d'analyser un texte et d'en déterminer sa structure
syntaxique afin d'effectuer divers traitement, comme par exemple une compilation.) PHP, la base
de données et d'autres éléments pouvant se révéler utile.

SERVEUR WEB APACHE

Notre choix s'est porté sur Apache comme serveur web pour la diffusion de l'information.
Apache est le serveur web le plus répandu sur Internet. Le serveur web Apache possède de
nombreuses fonctionnalités et il est libre puis facile à installer. Il est possible avec le serveur
Apache de définir une configuration spécifique à chaque fichier ou répertoire partagé, aussi de
définir des restrictions d'accès
6.2 ASPECT SECURITE DU SYSTÈME

INSTALLATION DU SYSTEME ET SA MAINTENANCE :
L’application tire sa source d’un serveur au sein de la FONCTION SICOM. Sa

maintenance est assurée par la dite fonction. Un livret devra notamment être crée permettant à
tout autres informations de pouvoir s’y trouvé si besoin est.
LA SECURITE PHYSIQUE
La sécurité physique concerne la protection de tout le matériel disponible dans le réseau

et tout ce qui s'y ajoutera (régulateur, onduleur, câbles etc.). Aussi, l'administrateur devra
procéder à la sauvegarde des données sur des disques externes en cas de panne du système.
LA SECURITE LOGIQUE
Elle concerne la sécurité du système elle-même et on n'y distingue plusieurs niveaux :

L'accès au système est assujetti à un nom d'utilisateur (pseudo ou compte) et un mot de passe. Le
contrôle d'intégrité du mot de passe est assuré par le cryptage en MD5. L'algorithme MD5
(Message Digest 5) inventé par Ronald Rivest a pour but d'empêcher de reconstruire une source
de données différente produisant un résultat donné. Il est très répandu et sert beaucoup à stocker
les mots de passe. Il comprend des caractères hexadécimaux
L'accès direct à une page web est redirigé vers une page d'authentification. Chaque utilisateur
dispose d'un droit d'accès au système, ce qui permet la gestion des permissions en fonction de ce
droit.

6.3 QUELLEQUES CAPTURES D’ECRAN DE L’APPLICARION
Page d’authentification
Figure 25 : « Formulaire de connexion »
Formulaire menu
Figure 26 : Formulaire menu

Formulaire Gérer période de saisie
Figure 27 : Gérer période de saisie
Formulaire saisie EVS
Figure 28 : Formulaire de décompte EVS

Figure 29 : Formulaire de décompte EVS (suite)
Formulaire Gérer Prime
Figure 30 : Gérer Prime
Formulaire Exporter EVS
Figure 31 : Formulaire exporter EVS

CHAPITRE 7 : CONDUITE DE PROJET
7.1 INTERVENANTS ET DEROLEMENT DU PROJET
Tout au long de ce stage, nous avons échangé avec la plupart des Directeurs et chefs de
divisions surtout sur les phases d’interviews et de conception de notre solution. Il s’agit entre
autre de :
 La Fonction Administrative et Financière

 Monsieur MITOUKOU Christian (Chef de division rémunération)
 Monsieur DACKEY Johnny (Concepteur Développeur Informaticien)
 Monsieur MOUGONGOU Coplan (Chef de service projet et études)
 Mademoiselle NZANG MBA Pulchérie (Chef de service retenu)
 Monsieur PEPA Dimitri (Développeur informaticien)
 Monsieur MPIGA Sylvain (Concepteur Développeur Informaticien)
7.2 DECOUPAGE DU PROJET EN ITERATION
Les itérations nous permettrons de limiter les risques d’ordre fonctionnels et techniques afin
d’atteindre nos résultats. Chaque itération intègre une phase d’analyse, une phase de conception
et de spécification technique selon le processus 2TUP.

Cas Risque Priorité Itération Description du

d’utilisations risque
Collecter saisir haut haute N°1 Correspondance

les EVS de avec les besoins
l’agent des utilisateurs
Visualiser ou haut haut N°1 Correspondance

Consulter la avec les besoins
fiche des EVS des utilisateurs
de l’agent
Valider les haut haute N°1 Erreur de saisie

EVS de chaque ou manipulation
agent. (bug logiciel)
Gérer la haut haute N°2 Erreur de

présence de programmation
l’agent (bug logiciel)
Gérer la haut haute N°2 Erreur de

période de programmation
collecte
Planifier les haut haute N°2 Erreur de

activités de programmation
l’agent (bug logiciel)
S’authentifier bas Basse N°3 le manque de

connexion
Exporter les haut moyenne N°2 le manque de

données de connexion
l’agent
Gere les bas basse N°3 le manque de

utilisateurs connexion
Gérer les profils moyen basse N°3 le manque de

connexion
Gérer les EVS bas basse N°3 le manque de

connexion
Tableau 10 : Découpage en Itérations selon le processus 2TUp

7.3 DIAGRAMME DE GANT PREVISIONNEL
Figure 32 : Diagramme Gantt prévisionnel
7.4 DIAGRAMME DE GANT REEL
Figure 33 : diagramme de Gantt réel

7.5 COUT DU PROJET
DESIGNATIONS DETAILS COUTS
Serveur HP ProLiant Existe déjà dans l’entreprise
BL490c G7 : C’est le serveur

de base de données
Serveur HP ProLiant BL490c G7 : Existe déjà dans l’entreprise

C’est le serveur Linux pour
l’application
Windows Seven Professionnel Système d’Exploitation Existe déjà dans l’entreprise
ORACLE 10G System de Gestion de Base de Existe déjà dans l’entreprise

Données
EasyPHP Un Framework d’architecture Gratuit

MVC
TOAD Pour la connexion avec la base Gratuit
STAGIAIRE 5 mois de stage 800 000 F CFA
Figure 34 : Cout du projet
7.6 BILAN DU STAGE
Toutes les fonctionnalités du système attendues ont été testées et implémentées avec succès. Il
s’agit en effet de :
- La gestion automatisée des EVS,

- La gestion des utilisateurs,
- La production et la consultation
- L’authentification.
- L’export de fichier pour importer dans SAGE PAIE.
APPORTS DU STAGE :
Ce stage nous a été d’un apport considérable :
 Nous avons pu confronter les théories reçues au cours des trois années de formation à
l’Institut Africain d’Informatique aux réalités du terrain. Des notions qui jusqu’ici

n’étaient pour nous que de la théorie, ont pu être mises en pratique et par conséquent
être consolidées ;
 Nous avons acquis de nouvelles connaissances particulièrement dans le domaine de
la pragrammation PHP et de Smarty ce qui a fortement enrichi notre culture
informatique ;
 Enfin, grâce à l’ensemble de ressources humaines à notre disposition tout au long de
ce stage, nous avons pu confirmer que l’informatique est un travail d’équipe. Nous
avons eu le privilège de travailler avec des ingénieurs developeurs d’application et
reseau et cette collaboration a été pour beaucoup dans la réalisation de notre
solution.
DIFFICULTES :
Le stage s’est toutefois déroulé avec quelques difficultés. La principale concerne

l’apprentissage de nouvelles technologies.
CONCLUSION
Dans cette partie, nous venons de présenter les diffèrent outils mise en œuvre pour
aboutir à la réalisation de notre solution. Nous avons établi les diagrammes e Gantt pour la gestion du
projet.

CONCLUSION GENERALE
Ce projet était bénéfique pour nous à plusieurs titres. Il nous a permis :
 De nous perfectionner en améliorant nos connaissances en programmation et en

conception.
 De bien comprendre et mettre en œuvre le déroulement d'un cycle de vie d'un logiciel.
 De découvrir le monde de l'entreprise (fonctionnement).
Nous avons réalisé ce projet dans le but de faciliter, d'améliorer la gestion et le traitement des
éléments variables de ces agents.
Nous avons appliqué au maximum possible les règles de bases permettant d'avoir une
application performante. Nous avons appliqué UML pour concevoir une grande partie de notre
travail. Nous avons utilisé aussi PHP et ORACLE pour implémenter notre application.
Ce projet a fait aussi l'objet d'une expérience intéressante, qui nous a permis d'améliorer nos
connaissances et nos compétences en entreprise. Nous avons appris à mieux manipuler les
langages PHP, HTML, SQL et Java Script.
Grâce aux architectures que nous avons utilisé (MVC et client/serveur) et du fait que PHP est un
langage adaptable dans plusieurs domaines, notre application peut avoir des extensions ou des
modifications dans le futur.

BIBLIOGRAPHIE
OUVRAGE :
[Roques, 2006] Pascal (ROQUES), UML 2 par la pratique, EYROLLES, Paris, 2006, 364 pages
;
[Vallée, 2007] Pascal (ROQUES), Franck Vallée, UML2 en action, EYROLLES, Paris, 2007,
394 pages.
[PR] Pascal ROQUES, UML 2 modéliser une application web, 4 e édition EYROLLES Paris,
2006, 236 pages
DOCUMENTS: Relation Sociale de la SETRAG
 Accord_Etablissement_Setrag_2013
 Nouvelle Convention Collective
 REGLEMENT_INTERIEUR_SETRAG
NOTES DE COURS :
 AVOM J Cours de Rédaction scientifique, IAI, 2014

 NAMBILA A., Cours de Bases de données, IAI, 2014
 NOUSSI R., Cours de Qualité Logiciel, IAI, 2014
SITES WEB
www.commentcamarche.net
www.memoireonline.com/
www.wikipedia.com /
MEMOIRES
 LAHLOU L., Conception et réalisation d'une application web pour la gestion des stocks cas
d'étude magasin de la faculté des sciences exactes de l'université de Bejaia, Université de
 Bejaia, 2010.

ANNEXES
Mode opératoire d’un agent administratif avant le système automatisé.
Figure 35 : schéma mode opératoire d’un agent administratif

Ancien mode opératoire des gestionnaires concernés par la paie.
Figure 36 : schéma représentatif du mode opératoire d’gestionnaire paie.

Fiche de collecte de service individuel du personnel roulant
Figure 37 : Fiche de collecte de service individuel du personnel roulant

Fiche mensuelle de pointage d’un agent de SICOM
Figure 38 : Fiche mensuelle de pointage (SICOM).
Figure 39 : Fiche de décompte de frais de déplacement.

Mpi05 03 15

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

Mpi05 03 15

Transféré par

Droits d'auteur :

Formats disponibles

Conception et Mise en place d’un système de gestion automatisée des éléments

variables soldes de la SETRAG

A ma très chère mère,

Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page I

"Toutes choses concourent au bien de ceux qui aiment Dieu"

Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page II

J’adresse mes remerciements à M. Guillaume VERSCHAEVE, Directeur Général de la SETRAG

J'adresse mes remerciements les plus chaleureux au Dr. SOULEYMANE KOUSSOUBE,

J'exprime ma reconnaissance à mon encadreur académique, M. Felix HOUTSA pour m’avoir

A mes encadreurs professionnels messieurs M. Copland MOUGONGOU et M. Johnny

Je ne saurais oublier l'ensemble du personnel du SETRAG en particulier de fonction SICOM avec

La formation des Ingénieurs de conception en Informatique à l’Institut Africain d’Informatique

 Mettre les étudiants dans un environnement de conception et de développement

Ce document représente l’aboutissement de cinq mois de stage pratique effectués à la

Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page IV

Pour l'implémentation, le choix du langage de programmation a été dicté par le type de

Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page V

Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page VI

TABLE DES MATIERES

AVANT PROPOS .................................................................................................................................................. IV

TABLE DES MATIERES .................................................................................................................................... VII

LISTE DES ABREVIATIONS ...............................................................................................................................IX

LISTE DES FIGURES ............................................................................................................................................X

LISTE DES TABLEAUX .......................................................................................................................................XI

INTRODUCTION GENERALE ............................................................................................................................. 1

PREMIERE PARTIE : CONTEXTE GENERAL DE L’ETUDE .......................................................................... 2

CHAPITRE 1 : LA STRUCTURE D’ACCUEIL ................................................................................................ 4

CHAPITRE 2 : LE SUJET, SES OBJECTIFS, SA PROLEMATIQUE ........................................................ 7

DEUXIEME PARTIE : ANALYSE, CONCEPTION DU SYSTEME ETUDIE .................................................. 25

CHAPITRE 4 : PRESENTATION DE LA METHODE DE CONDUITE DE PROJET ................................ 27

CHAPITRE 5 : ANALYSE ET CONCEPTION ................................................................................................ 36

TROISIEME PARTIE : MISE EN ŒUVRE ET CONDUITE DU PROJET ...................................................... 64

CHAPITRE 6 : MISE EN ŒUVRE................................................................................................................... 66

CHAPITRE 7 : CONDUITE DE PROJET ................................................................................................... 73

CONCLUSION GENERALE ................................................................................................................................ 78

LISTE DES ABREVIATIONS

AICR : Aide Controleur

AM : Agile Methods, Méthode Agile

CRL : Controleur de Line

CRLO : Controleur de Line

EVS : Éléments Variables Soldes

IAI : Institut Africain D’informatique

MVC : Modèle Vue Contrôleur

PHP : Hypertext Preprocessor

SETRAG : Société d’Exploitation Transgabonais

SICOM : Système Informatique et Communication

UML : de l'anglais Unified Modeling Language), ou Langage de modélisation unifié

Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page IX

LISTE DES FIGURES

Figure 1: organigramme de la SETRAG ................................................................................................................. 6

Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page X

LISTE DES TABLEAUX

Tableau 1: Primes d’astreinte. ............................................................................................................................... 14

Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page XI

L'outil informatique, faisant partie du quotidien de tout travailleur devient de ce fait le

Dans la première partie intitulée << CONTEXTE GENERAL DE L’ETUDE» nous

Au niveau de la deuxième partie intitulée intitulé << ANALYSE, CONCEPTION DU

Finalement dans la dernière partie qu'on a nommé << MISE EN ŒUVRE ET

Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page 1

PREMIERE PARTIE : CONTEXTE GENERAL DE L’ETUDE

Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page 2

Sylvain MPIGA Mémoire de fin de cycle ingénieur IAI - 2014 Page 3

CHAPITRE 1 : LA STRUCTURE D’ACCUEIL